数据库选择:高写,低读

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的数据.您可以从云托管服务提供商处租用1 TB的数据,每月约250美元,或者从EqualLogic等SAN供应商处购买,价格约为15,000美元.

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

如果您(或您的团队成员)已经掌握了特定产品的技能,那就坚持下去吧.如果您的问题域中存在特定产品,请使用该产品.

这不是需要任何类型的分布式魔法独角兽粉末的问题类型.