大型NoSQL报表应用的DateRange数据库选择

Question

我有一个应用程序，在这个应用程序中，任何用户使用的应用程序的特性都会连续地登录到一个文本文件中，然后(非高峰时间)一个计划好的应用程序将这些日志记录插入到基于MS的RDBMS中。您可以猜到，这会生成相当多的数据(因为单个用户会话将生成许多记录，并且有数百个用户整天都在并发地使用应用程序)。该数据库目前有数以百万计的记录，主要用于生成基于日期范围的报告，该报告提供了对给定日期范围使用了多少次的特征的汇总，这也是数据库给性能带来问题的地方。

现在我知道了，直接解决这个问题的方法就是修复数据库设计(如果有可能的话！)以提高业绩。但我不应该建议进行任何SQL设计更改。我应该使用类似于我前面解释的数据集来评估NoSQL数据库。

我开始研究NoSQL数据库，我被不同类型的NoSQL数据库轰炸了。通过我的初步研究，我确信我可以排除面向图形的数据库。键值存储似乎也不适合我的目的，因为它主要允许我只使用键查询，无论我从这论文中了解到什么，都可以在DynamoDB上查询。虽然对日期范围的要求很重，但选择按特性查询是可取的。

这给我留下了面向文档的数据库和列族商店。

因此，基于所有这些观点，你会为我的案例推荐哪一个数据库？

PS:请不要建议任何基于云的解决方案，因为我不应该在云上迁移数据！

Answer 1

任何支持有效范围扫描或分区扫描的内容对于您的用例都会很好。

这包括MongoDB、Cassandra、HBase、任何关系数据库管理系统(尤其是支持分区的关系数据库管理系统)。这里不包括CouchDB，因为我不认为Javascript /reduce可以与用C/C++/Java实现的NoSQL/RDBMS引擎竞争。

列族商店通常用于处理时间序列。例如，看看基于OpenTSDB的HBase项目。

最后，您还可以考虑只使用搜索引擎而不是NoSQL存储或关系数据库管理系统。越来越多的搜索引擎(如Lucene)被用于分析工作负载。例如，看看弹性搜索、洛格斯塔什、基巴纳三重奏。

Answer 2

我建议Redis和SSDB，内置数据类型zset是存储基于时间的数据的理想数据类型。一个序列被存储(在任何时候插入和删除)，你可以通过时间戳找到。

下面是一些代码片段：

$ssdb->zset('z', 'a', 1384423054);
$ssdb->zset('z', 'b', 1384423055);
$ssdb->zset('z', 'c', 1384423056);
$items = $ssdb->zrange('z', 1384423054, 1384423057, $limit=100);

这两个数据库的不同之处在于，Redis仅为内存(磁盘用于备份)，但SSDB基于磁盘并使用内存作为缓存。