数据库选择 : High-write, 低读

Question

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

数据永远不会被修改，只会添加新数据。读取很可能是用新记录完成的。

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

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

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

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

Answer 1

您的问题可以通过几种不同的方式解决，所以让我们将其分解并查看您提出的个别要求:

1. 写入 - 听起来您正在做的大部分工作都是仅以相对较低的量(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 数据库都应该能够胜任这项任务。事实上，几乎任何类型的任何数据库都应该能够胜任这项任务。

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

这不是那种需要任何分布式魔法 unicorn 粉的问题。