什么是存储映射“键 - >事件流”的最有效方式？

Question

假设有〜10,000个密钥，其中每个密钥对应于一系列事件。我想支持以下操作：

• push(key, timestamp, event) - 推动事件的关键事件队列，标有给定时间戳。确保特定键的事件时间戳按排序或几乎排序顺序推送。
• tail(key, timestamp) - 获得自给定时间戳以来的所有关键事件。通常，给定密钥的时间戳请求几乎是单调递增的，几乎与同一个密钥的推送同步。

这个东西必须是持久的（虽然它不是绝对必须立即坚持推动并保持拖尾严格同步），所以我打算使用某种数据库。

此任务的最佳数据库结构类型是什么？使用关系数据库，键值存储还是其他的更好？

Answer 1

对硬件有任何说法可以使用吗？ 假设这将有更多的读取比写入，这可能是SSD的理想应用程序，加上TomTom提到的 - 将事件作为文件存储在专用目录中。

如果你这样做，我建议有一个目录为每个“关键”，并组织他们在子目录。

也就是说，假设你有一个这样的关键：HJ029084930A

你应该有：

/streams 
/streams/HJ02 
/streams/HJ02/9084 
/streams/HJ02/9084/930A/HJ029084930A 
/streams/HJ02/9084/930A/HJ029084930A/20100315/230257.trc 
/streams/HJ02/9084/930A/HJ029084930A/20100316/000201.trc 
/streams/HJ02/9084/930A/HJ029084930A/20100316/000203.trc 
/streams/HJ02/9084/930A/HJ029084930A/20100316/010054.trc 
... 
/streams/HJ02/9084/930A/HJ029084930A/20100317/010230.trc 

我所暗示的是，你应该尽最大努力避免“太多”的文件（或目录），或者操作系统可能会减慢检索你的东西。

一个可能的问题是当一个流从一天结束到下一个结束时重叠。 看看你是否可以拆分它，以便你可以在23:59:59完成，并从第二天的00:00:00开始创建一个新的。这取决于你的情况下“tail（）”的语义。

Answer 2

使用财务数据？ ;）我在这里有一个应用程序，在测试中提供了150万个这样的流（CME complete feed）;）

关系 - 你可以做到，但它是浪费。我所做的是PER STREAM的二进制存储，并将这些线索变成二进制高效的三角洲格式（时间戳总是上升 - 因此不需要保持它们总数，只有阿尔卑斯小小的ldelta）。我将它们存储在15分钟的片段中，并且检索尾部的系统知道如何获取数据。在关系方面也减少了很多负担。

Ther eare为此专门的数据库，但它们是淫秽的（每个处理器核心10.000美元，最低许可证8核心 - 是的，正确）。

某些应用程序会使用平面文件（每个键一个），即使是非风格应用程序。我个人不喜欢这个。