存储映射“key->event stream”最有效的方法是什么?

你对将要使用的硬件有什么看法吗? 假设这将有更多的读写,这可能是一个理想的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()”在您的案例中的语义。

处理财务数据?;)我这里有一个应用程序在测试中处理了150万个这样的流(cme完整的feed;)

关系型——你可以这么做,但这是浪费。我所做的是对每个流进行二进制存储,并将值放入一种二进制高效的delta格式中(时间戳总是向上-因此不需要保持它们的总数,只需要从alst中获得少量ldelta)。我目前将它们存储在15分钟的切片中,检索尾部的系统知道如何获取数据。同时也减少了关系方面的负载。

有专门的数据库,但它们是淫秽的(每个处理器核10.000美元,最低许可证8核-是的,对)。

有些应用程序使用平面文件(每个键一个),即eventraling样式的应用程序。我个人不喜欢。