mysql - 数百万条目的数据库设计

Question

假设有一个消息系统。这个系统有数以百万计的条目要发送和报告，并且这个数量每小时增长 100K。2个服务访问db，一个是sender，一个是reporter。那么，为了获得最佳性能，您有什么建议？如何设计数据库？

您还建议在 mysql、postgresql、mongodb 等中使用什么开源 RDBMS 来充实这个大容量数据库？

谢谢

Answer 1

除了关于预期数据量的一些评论之外，您并没有真正提供有关您的要求的太多信息。大量数据的简单存储没有真正的内在价值，只有访问数据的能力才具有真正的价值；因此，了解您希望如何从数据库中检索信息比您要存储多少数据更重要。

这些消息是否真的需要像 MongDB 这样的文档数据库，或者它们的结构是否足以使用像 Postgresql 或 MySQL 这样的直接 RDBMS。您需要全文搜索功能吗？针对此消息数据执行的查询频率和类型是什么？你想写自己的推特吗？

如果这些是您当前的数据量，请考虑使用数据库复制来获得弹性。考虑分区您的消息表，也许按发布日期。正如 Konerak 所建议的那样，使用主/从（甚至多主/多从）。查看不太可能被查询但仍然可用的旧消息的存档表的可能性。看看像 Oracle 这样的商业数据库可以为您提供什么。让专业人士帮助调整数据库的性能，而不是简单地在 SO 之类的网站上寻求免费建议。

还要考虑您的硬件……多台负载平衡服务器来帮助处理卷（我们有 14 台专门用于接收新消息的专用服务器，以及 3 台用于查询数据的高性能服务器）。