数百万条目的数据库设计答案

【问题标题】：Database design with millions of entry数百万条目的数据库设计
【发布时间】：2010-07-10 19:13:43
【问题描述】：

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

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

谢谢

【问题讨论】：

您是否有理由要使用 RDBMS 而不是消息队列？
我建议先聘请有经验的 DBA。
上校。弹片——作为一家未来的创业公司，我会..
leonm - 消息需要被持久化。
这取决于如何查询数据。考虑带有复制的 MySQL：INSERT 在主服务器上进行，SELECT 在从服务器上进行——这样它们就不会阻塞插入。

标签： mysql database-design mongodb high-volume

【解决方案1】：

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

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

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

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

【讨论】：

我认为你的回答倾向于在 cmets 中上校 Shrapnel 的建议。
@Brian - 这将是我的第一条建议。我试图添加比上校 Shrapnel 说的更多，以证明它是一个答案；但是问题的变幻莫测……我在这种级别上处理数据量，并强调了我用于处理大型数据库的一些技术；但如果 OP 仍在争论是选择文档数据库还是 rdbms，并且更关心数据量而不是如何访问该数据，那么我怀疑他确实需要专业帮助
相当。我并不想敲你的答案，如果我给人留下了这样的印象，我很抱歉；我什至赞成它，因为有一些有用的建议。