有效存储7.300.000.000行

您将如何解决以下存储和检索问题？

每天(365天/年)将添加大约2.000.000行,每行包含以下信息:

id(唯一行标识符)

entity_id(取值介于1和2.000.000之间)

date_id(每天增加一个 - 将取1到3.650之间的值(十年:1*365*10))

value_1(取值介于1和1.000.000之间)

value_2(取值介于1和1.000.000之间)

entity_id与date_id相结合是唯一的.因此,每个实体和日期最多只能有一行添加到表中.数据库必须能够保存10年的每日数据(7.300.000.000行(3.650*2.000.000)).

上面描述的是写模式.读取模式很简单:所有查询都将在特定的entity_id上进行.即检索描述entity_id = 12345的所有行.

不需要事务支持,但存储解决方案必须是开源的.理想情况下我想使用MySQL,但我愿意接受建议.

现在 - 您将如何解决所描述的问题？

更新:我被要求详细说明读写模式.写入表将每天一批完成,新的2M条目将一次性添加.读取将连续进行,每秒读取一次.

"现在 - 你将如何解决所描述的问题？"

用简单的平面文件.

这就是原因

"所有查询都将在特定的entity_id上进行.即检索描述entity_id = 12345的所有行."

你有2.000.000个实体.基于实体编号的分区:

level1= entity/10000
level2= (entity/100)%100
level3= entity%100

每个数据文件都是 level1/level2/level3/batch_of_data

然后,您可以读取目录的给定部分中的所有文件以返回样本进行处理.

如果有人想要一个关系数据库,那么将给定entity_id的文件加载到数据库中供他们使用.

编辑 日期数字.

该date_id/ entity_id独特的规则是不是东西,有来处理.这是(a)对文件名的简单强加和(b)与查询无关.

在date_id"利添利"并不意味着什么-有没有查询,所以没有必要重命名任何东西.本date_id应只是成长过程中没有从时代日期界.如果要清除旧数据,请删除旧文件.

由于没有查询依赖date_id,因此无需任何操作.它可以是所有重要的文件名.

要date_id在结果集中包含,请将其写入文件中,并使用文件每行中的其他四个属性.

在打开/关闭时编辑

对于写作,您必须保持文件打开.你定期刷新(或关闭/重新打开),以确保东西真正进入磁盘.

作者的架构有两种选择.

有一个"编写者"进程来整合来自各种源的数据.如果查询相对频繁,这将非常有用.您支付在写入时合并数据的费用.

同时打开几个文件进行写入.查询时,将这些文件合并为一个结果.这有用的是查询比较少见.您需要支付在查询时合并数据的费用.

使用分区.使用您的读取模式,您希望通过entity_id散列进行分区.

您可能想看看这些问题:

大型主键:超过10亿行MySQL + InnoDB？

大型MySQL表

就个人而言,我还考虑计算你的行宽,让你知道你的表有多大(根据第一个链接中的分区注释).

HTH,

小号