实施 MySQL NDB Cluster 有哪些限制？
我想为 MySQL Cluster 6 实现 NDB Cluster。我想为至少有 200 万条记录的非常庞大的数据结构执行此操作。
我想知道实施 NDB cluster 是否有任何限制。例如，RAM 大小、数据库数量或 NDB 集群的数据库大小。
I want to implement NDB Cluster for MySQL Cluster 6. I want to do it for very huge data structure with minimum 2 million records.
I want to know is if there are any limitations of implementing NDB cluster. For example, RAM size, number of databases, or size of database for NDB cluster.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
200万个数据库？我猜你指的是“行”。
无论如何，关于限制：要记住的最重要的事情之一是 NDB/MySQL Cluster 不是通用数据库。最值得注意的是，连接操作以及子查询和范围操作（例如：现在到一周前创建的订单）可能比您预期的要慢得多。这部分是由于数据分布在多个节点上。尽管已经进行了一些改进，但 Join 性能仍然非常令人失望。
另一方面，如果您需要处理许多（最好是小型）并发事务（通常是通过主键进行单行更新/插入/删除查找）并且您设法将所有数据保留在内存中，那么它可能会非常困难。可扩展且高性能的解决方案。
您应该问自己为什么需要集群。如果您只是想要现在拥有的普通数据库，除了增加 99,999% 的可用性，那么您可能会失望。当然，MySQL 集群可以为您提供出色的可用性和正常运行时间，但您的应用程序的工作负载可能不太适合集群所适合的事物。另外，您也许可以使用另一种高可用性解决方案来增加传统数据库的正常运行时间。
顺便说一句 - 这是根据文档的限制列表： http ://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
但无论你做什么，尝试集群，看看它是否适合你。 MySQL集群不是“MySQL + 5个9”。当你尝试时你就会发现。
2 million databases? I asssume you meant "rows".
Anyway, concerning limitations: one of the most important things to keep in mind is that NDB/MySQL Cluster is not a general purpose database. Most notably, join operations, but also subqueries and range opertions (queries like: orders created between now and a week ago), can be considerably slower than what you might expect. This is in part due to the fact that the data is distributed across multiple nodes. Although some improvements have been made, Join performance can still be very disappointing.
On the other hand, if you need to deal with many (preferably small) concurrent transactions (typically single row updates/inserts/delete lookups by primary key) and you mangage to keep all of your data in memory, then it can be a very scalable and performant solution.
You should ask yourself why you want cluster. If you simply want your ordinary database that you have now, except with added 99,999% availability, then you may be disappointed. Certainly MySQL cluster can provide you with great availability and uptime, but the workload of your app may not be very well suited for the thtings cluster is good for. Plus you may be able to use another high availability solution to increase the uptime of your otherwise traditional database.
BTW - here's a list of limitations as per the doc: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
But whatever you do, try out cluster, see if its good for you. MySQL cluster is not "MySQL + 5 nines". You'll find out when you try.
NDB cluster 有两种类型的存储选项。
1.内存存储。
2.磁盘存储。
NDB作为内存数据存储引入，从7.4版本（MYSQL 5.6）开始支持磁盘存储。
当前版本 7.5（MySQL 5.7）支持磁盘存储，在这种情况下，不会有大小限制，因为数据将驻留在磁盘中，并且限制取决于您可用的磁盘存储空间。
磁盘存储配置 - https:// dev.mysql.com/doc/refman/5.7/en/mysql-cluster-disk-data-symlinks.html
NDB集群中的内存存储也相当成熟，您可以在管理节点配置中定义内存使用情况。 ini 文件。
例子 -
数据内存=3072M
平均表中的IndexMemory=384M
（取决于列中存储的数据）总数据库大小应小于 1GB，可以轻松配置。
注意 - 在我自己的实现中，我面临一个性能挑战，因为 NDB 的性能随着表中行数的增加而降低。
在高负载下，并发读取会随着行数的增加而降低。
确保不进行全表扫描并提供足够的 where 子句谓词。
为了获得适当的性能，请根据您的查询模式正确定义二级索引。
定义二级索引将再次增加内存消耗，因此请相应地规划查询模式和内存资源。
NDB cluster comes with two type of storage options.
1.In Memory Storage.
2.Disk storage.
NDB introduced as in memory data storage and in version 7.4(MYSQL 5.6) onwards started supporting disk storage.
current version 7.5(MySQL 5.7) supports disk storage and in this case there will be no size constraints as data is going to reside in disk and limit depend on disk storage space available with you.
Disk Storage configurations - https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-disk-data-symlinks.html
In Memory storage in NDB cluster is also quite mature and you can define memory usage in management node config.ini file.
example -
DataMemory=3072M
IndexMemory=384M
in an average table(depend on data stored in columns) total db size should be less then 1GB which can easily be configured.
Note - in my own implementation i faced one performance challenge as performance of NDB degrades with increasing number of rows in table.
Under high load concurrency read will degrade with number of increasing row.
Make sure you don't go for full table scan and provide sufficient where clause predicate.
For proper performance define secondary index properly as per your query pattern.
Defining secondary index will again increase memory consumption so plan your query pattern and memory resources accordingly.