【发布时间】:2014-01-08 13:47:14
【问题描述】:
有几个 SO questions about time series databases ,但没有一个能解决我的具体问题,虽然 this one 最接近,但它已经 3 岁了。
要求:
- 多个数据集。它们的组织方式无关紧要(单独的表、数据库、进程、文件等)。
- 单主机操作(至少最初是这样),因此我们被限制为大约 1TB 磁盘和 10GB RAM。
- 读取延迟/吞吐量是关键性能指标。
数据行为:
- 数据集只能追加,记录是不可变的。
- 每条记录(独立于数据集)都需要时间戳。
- “简单”数据集中的记录将是 32 位或 64 位整数,而更“复杂”的数据集将是 32 位和 256 位之间的整数向量,每个条目不超过约 1kb。
- 将有一个主要的“大”表,其中包含 200M 或更多的“复杂”(参见前一点)性质的条目。
- 将有许多 (10
愿望清单:
- 从单个主机开始,我们确实希望避免复杂的“大数据”-y 对后端(例如 HBase)的依赖,同时会考虑更简单的替代方案。这需要例如OpenTSBD 不在讨论范围内。
- 高级语言的友好绑定。 Ruby、Python、PHP 等,但如果无法避免,我们可以使用 C、C++、Java 等。
- 最好使用 Streaming/pubsub/realtime API。
- 自定义查询 - 我们需要的不仅仅是简单的统计平均值/中位数/众数/标准差运算,如果我们可以将我们的分析编码为“原生”查询/命令/结构而不是读出,那就太好了所有数据只是为了计算应用程序代码中的所有内容。
OpenTSBD 基于 HBase,TempoDB 无法在成本/性能的基础上运行,Redis、Mongo、CouchDB 等似乎都会阻塞如此大量的数据,我们不知道我们是否做梦。如果我低估了任何上述系统(或其同时代系统),请纠正我。 这样的事情是否存在?如果不存在,我们是否能够通过仅满足列出的要求或愿望之一来完成工作?
【问题讨论】:
-
查看erol.si/2015/01/… 了解所有可用时间序列数据库的概述
标签: database performance architecture time-series