我认为没有任何 DBMS 可以满足您的需求并允许使用现成的报告工具。低延迟分析系统的构建并不快速且容易。非结构化数据的低延迟是非常雄心勃勃的。
不过,您将不得不将数据保存在某种数据库中。
我认为您可能需要仔细研究您的问题域。您是在尝试运行低延迟分析报告,还是在某些事件发生时提示业务内部采取某些行动的运营报告?对于低延迟系统,您需要对什么构成运营报告和什么构成分析非常无情。
编辑:除非企业准备好付款,否则不鼓励“可能两者兼而有之”的心态。投资银行和对冲基金斥巨资购买超级计算机来进行“实时分析”。这不是一项微不足道的工作。当您尝试构建这样一个系统并构建它以实现高正常运行时间时,它就更不简单了。
即使在诸如收费短信服务和 .com 应用程序之类的应用程序上,当您对问题进行现实的范围和成本分析时,企业也经常会退缩。我不能这么说。对“实时”要求要非常非常无情。
如果业务真的非常需要实时分析,那么您可以制作混合 OLAP 架构,在该架构中,您可以在事实表上拥有一个前进的引导分区。这是一种体系结构,其中事实表或多维数据集完全为历史数据建立索引,但有一个未编制索引的小型前导分区,因此插入数据相对较快。
分析查询将对相对较小的领先数据分区进行表扫描,并在其他分区上使用更有效的方法。这为您提供了低延迟数据以及对历史数据运行高效分析查询的能力。
每晚运行一个进程,滚动到新的前导分区并合并/索引先前的前导分区。
这适用于您拥有诸如位图索引(在数据库上)或物化聚合(在多维数据集上)之类的插入成本很高的项目。前导分区相对较小且表扫描成本低,但对涓流插入很有效。翻转过程逐渐将此引导分区合并到索引历史数据中,从而可以有效地查询它以获取报告。
编辑 2: 公共字段可能是在事实表上设置为维度的候选者(例如调用者、时间)。不太常见的领域是(大概)编码。对于有效的模式,您可以将可选编码移动到一个或多个“垃圾”维度。.
简而言之,垃圾维度是代表两个或多个代码的每个现有组合的维度。表中的一行与单个系统实体无关,而是与编码的唯一组合有关。维度表上的每一行对应于原始数据中出现的不同组合。
为了获得任何分析值,您仍然必须组织数据,以便垃圾维度中的列包含一致有意义的内容。这可以追溯到一些要求工作,以确保来自源数据的映射有意义。您可以使用诸如零长度字符串 ( ''
) 之类的占位符值来处理并不总是记录的项目,这可能比空值更好。