MySQL NDBCLUSTER：对于大规模解决方案有好处吗？
关于 NDBCLUSTER 的一个问题。
我继承了一个基于NDBCLUSTER 5.1解决方案（LAMP平台）的网站的编写。
不幸的是，设计前一个解决方案的人没有意识到这个数据库引擎有很大的限制。第一，一张表最多可以有128个字段。这位前程序员设想的表在一行中有369个字段，一个字段代表一年中的每一天，再加上一些关键字段（他最初使用的是MyISAM引擎）。好吧，无论如何，我知道它必须重构。
更重要的是，引擎需要大量的调整：表的最大属性数（默认为1000，有点太少了）和许多其他参数，一旦您对这些参数进行误解或低估，可能会导致严重的问题。在使用数据库进行生产时，您被迫更改某些内容。
即使 NDBCLUSTER 表的磁盘存储如果没有精确配置，也是一种偶然：即使在 CREATE TABLE 语句中指定，引擎似乎更喜欢将数据保存在内存中 - 这解释了速度 - 但如果你的表在节点 1 应该突然崩溃（就像在测试期间那样）。所有节点上的所有表数据都丢失，并且仅在 1000 条记录后表就损坏。
我们使用的是具有 8Gb RAM 的服务器，并且该表只有 27 个字段。
请注意，没有运行节点关闭的 ndb_mgm 操作来危及表数据。它就这样跌倒了，完全停止了。我们的提供商不明白为什么。
所以问题是：您会推荐 NDBCLUSTER 作为大规模 Web 服务数据库的稳定解决方案吗？
我们正在讨论的数据库应包含数百万条记录、数千个表和数千个目录。
如果不是，您会推荐哪个数据库最适合完成创建国家级规模的 Web 服务的任务。
提前致谢。
one question about NDBCLUSTER.
I inherited the writing of a web site basing on NDBCLUSTER 5.1 solution (LAMP platform).
Unfortunately, who designed the former solution didn't realize that this database engine has strong limits. One, the maximum number of fields a table can have is 128. The former programmer conceived tables with 369 fields in a single row, one for each day of the year plus some key field (he originally worked with MyISAM engine). Ok it must be refactored, anyways, I know.
What is more, the engine needs a lot of tuning: maximum number of attributes for a table (which defaults to 1000, a bit too few) and many other parameters, the misinterpretation or underestimation of which can lead to serious problems once you're in production with your database and you're forced to change something.
Even the fact that disk storage for NDBCLUSTER tables is kind of aleatory if not precisely configured: even if specified in CREATE TABLE statements, the engine seems to prefer keeping data in memory - which explains the speed - but can be a pain if your table on node 1 should suddenly collapse (as it did during testing). All table data lost on all nodes and table corrupted after 1000 records only.
We were on a server with 8Gb RAM, and the table had just 27 fields.
Please note that no ndb_mgm operation for nodes shutdown ran to compromise table data. It simply fell down, full stop. Our provider didn't understand why.
So the question is: would you recommend NDBCLUSTER as a stable solution for a large scale web service database?
We're talking about a database which should contain several millions of records, thousands of tables and thousands of catalogues.
If not that which database would you recommend as the best to accomplish the task of making a nation-level scale web service.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在 NDBCLUSTER 上的经历很糟糕。它是具有范围失效功能的 memcached 的良好替代品，仅此而已。该解决方案不具备稳定性和可配置性。您不能强制所有进程侦听特定端口，备份正在工作，但我必须在 vim 中编辑 bkp 文件来恢复数据库等。
I have a terrible experience with NDBCLUSTER. It's good replacement for memcached with range invalidation, nothing more. The stability and configurability does not exist for this solution. You can not force all processes to listen on specific ports, backup was working but I have to edit bkp files in vim to restore database etc..