数据库选择：高写入、低读取

Question

我正在构建一个用于记录历史数据的组件。最初，我希望它每秒执行大约 30 次写入，而每秒读取不到 1 次。

数据永远不会被修改，只会添加新数据。读取可能会使用新记录。

需求可能会迅速增加，预计一年内写入速度约为 80 次/秒。

我可以选择分发我的组件并使用 MySql 等通用数据库，或者我可以使用 MongoDb 等分布式数据库。无论哪种方式，我都希望数据库能够很好地处理写入。

数据库必须是空闲的。开源将是一个加号:-)

注意：记录是可变大小的纯文本，通常为 50 到 500 个字。

Answer 1

您的问题可以通过几种不同的方式解决，所以让我们分解一下，看看您提出的具体要求：

1. Writes - 听起来您所做的大部分工作是仅以相对较低的容量（80 次写入/秒）追加写入。市场上几乎所有具有合理存储后端的产品都能够处理这个问题。您正在查看正在保存的 50-500 个“单词”数据。我不确定什么构成一个词，但为了论证，我们假设一个词平均有 8 个字符，所以你的数据将是某种元数据，一个键/时间戳/任何东西加上 400-4000字节的单词。除非不同 RDBMS 的具体实现细节，这仍然很正常，我们可能每条记录最多（包括记录开销）写入 4100 字节。这最大为每秒 328,000 字节，或者，正如我喜欢说的那样，写的不多。

2. 删除 - 您还需要能够删除您的数据。对此我无话可说。删除就是删除。

3. 阅读 - 这就是事情变得棘手的地方。您提到它主要是主键，并且正在对新数据进行读取。我不确定这两个是什么意思，但我认为这并不重要。如果您只进行密钥查找（例如，我想要记录 8675309），那么生活是美好的，您几乎可以使用任何东西。

4. 联接 - 如果您需要在数据库处理联接的地方编写实际联接的能力，那么您已经摆脱了主要的非关系数据库产品。

5. 数据大小/数据寿命 - 这就是有趣的地方。您估计您的写入速度为 80/秒，我猜是每条记录 4100 字节或每秒 328,000 字节。一天有 86400 秒，这给了我们 28,339,200,000 个字节。可怕！即 3,351,269.53125 KB、27,026 MB 或大约 26 GB/天。即使您将数据保留 1 年，也就是 9633 GB 或 10TB 的数据。您可以以每月 250 美元左右的价格从云托管提供商处租用 1 TB 数据，或者以大约 15,000 美元的价格从 EqualLogic 等 SAN 供应商处购买。

结论：我只能想到几个无法处理这种负载的数据库。 10TB 变得有点棘手，需要一些管理技能，您可能需要查看某些数据生命周期管理技术，但几乎所有 RDBMS 都应该能够胜任这项任务。同样，几乎任何非关系/NoSQL 数据库都应该能够胜任这项任务。事实上，几乎任何类型的任何数据库都应该能够胜任这项任务。

如果您（或您的团队成员）已经具备特定产品的技能，请坚持下去。如果有特定产品在您的问题领域中表现出色，请使用它。

这不是那种需要分发任何种类的魔法独角兽粉的问题。

Answer 2

对于 MySQL，我建议您使用不带任何索引的 InnoDB，希望使用主键，即使这样，如果您可以跳过它们，那将是一件好事，以使输入流不中断。

索引优化读取，但降低写入能力。

您也可以使用 PostgreSQL。您还需要跳过索引，但您不会选择引擎，而且它的编写能力也非常强大。

您想要的这种方法实际上在某些解决方案中使用，但有两个数据库服务器，或至少两个数据库。第一个是接收大量新数据（您的情况），而第二个与第一个通信并将其存储在结构良好的数据库中（带有索引、规则等）。然后，当您需要读取数据或制作数据快照时，您可以引用第二个服务器（或第二个数据库），您可以在其中使用事务等等。

您应该查看并参考 Oracle Express（我认为这是它的名称）和 SQL Server Express Edition。后两种性能更好，但也有一些局限性。有更详细的图片。