问MySQL :用于高更新频率的大型集的表组织

EN

根据我多年使用MySQL的经验，我的两分钱是，你的后一种选择听起来更符合逻辑和现实。

与当前模式相比，每个客户使用一个数据和一个data_tag具有更简单的总体可管理性。第二个选项的编码也会更简单。

您可以询问更多的MySQL专家；您的第二个选择是最好的。

如果你愿意的话，我可以详细介绍，这是一个简单的答案，一个简单的问题，一个大的问题。它是双向的

在不了解您的应用程序的情况下，除了您在这里放置的应用程序之外，它还有点难说。您的数据模型非常简单，这对您的好处就像您预期的那样，实际上是数十亿行。我将避免创建超过5k的表，因为如果尝试这样做，您可能会遇到文件描述符问题和缓存限制。

当然，您可能可以将它们解压/配置，但这仍然不是最佳配置。

您是否也在为非键数据创建索引？例如，这些名称列？这可能会减慢您的写入性能，以便备份15分钟的批处理作业。

老实说，如果这是我的申请，我会考虑两种可能的解决方案：

1. 如果性能成为问题，那么就按照您现在的情况，将客户划分为多个MySQL服务器。除非您有这些数据，并且这些客户排队，这还不是一个问题。不要花太多时间为“万一”而设计。坚持使用简单的模式，并将第一组用户介绍给第一台服务器。当您开始使用容量时，请引入第二台服务器并将这些新用户隔离到该数据库中。切分，可以这么说。用资源监控和良好的管理技术来支持它，这样您就可以知道“容量”线何时接近了。
2. 像卡桑德拉或MongoDB这样的东西会起作用吗？我对你的问题还不太了解，不能提出建议，也不能排除。MongoDB可能是一种选择。值得一看。

所以，我想简单地说，让MySQL做它做得好的事情，运行更多的它们。或者，如果可能的话，看看像蒙戈这样的东西。

嗯，根据我的经验-你确定MySQL甚至是最好的数据库吗？尝试查看Oracle或Server (尽管oracle集群在这里可能有优势)？

如果你认为授权成本会杀死你，让我说你还不知道你需要什么硬件来运行它。一旦你得到SAN的第一份报价，你就需要这样做--你可能会嘲笑相应软件的价格。

只是个主意。

• 顾客-让我们说10.000，如果你认为它会增长很快。
• 数据--让我们假设一个普通客户有700万美元。这已经是数据表的70行了。是啊，抱歉，四个零加起来了。
• 如果每个数据都有10个标记(没有任何指示)，我们将讨论data_tag字段的7,000亿行。

变得更疯狂。

• 如果DataTag没有索引，没有开销(它有)，那么数据:标记是每个条目10个字节-- tag_id是2个(65536就够了)，遗憾的是，data_id是8个--您不能用4个字节来处理7000亿个条目。这是大约7800 12的原始数据(700.000.000.000 *12/ 1024 / 1024 / 1024)。索引POSSIBlY使其加倍。

为了有效地处理这个问题，这是一个高端SAN。我们这里不谈论"10盘“，我们谈论的是一个高端的SAN，可能有400张以上的光盘来处理所有这些数据--别忘了，到目前为止，我们还没有任何指数。

我所有这些都是在一个MySQL 5.0专用服务器(四核，8 8Go内存)上运行的。

很好的尝试。这到底对什么有好处？很抱歉问你，但是8gb内存不会有帮助(这里没有印象)，去一台256 go的机器.这可能需要AMD和其中一个真正昂贵的Opteron 8000。但你需要内存。

无论如何，这将是世界上最大的数据库安装之一(我怀疑您是否正确地表示了事实)。

您肯定需要一些能够处理这个问题的东西--如果您真的需要这样做的话，Oracle集群或Server集群可能会加快速度。这是远远超出免费数据库所能想到的处理方式的。真的。

而且您需要适当的备份过程(这是MySQL缺乏的)。您还可能喜欢Serve 2008数据页压缩，这可能会使磁盘上的数据大小减少50%左右。不仅是为了节省磁盘成本，而且因为它意味着更少的IO -这直接转化为更高的性能(因为您不能在内存中缓存表)。

尽管我不想这么说，但您可能还想考虑在一个不错的大型机上使用IBM -我不是说在它上运行Linux。由于硬件架构的原因，VMS在处理超大规模数据库方面有着极大的优势。不要问价格;)