数据仓库原则和NoSQL

时间:2014-12-01 17:40:41

标签: data-warehouse business-intelligence olap datamart nosql

使用MongoDB,CouchDB和相关技术,我们可以更快地查询,这仍然有效吗?

“交易数据的副本,专门用于查询和分析。”(R. Kimball The Data Warehouse Toolkit,1996

我的意思是,我们是否真的需要将数据重组为OLAP方案以进行分析以进行分析?更具体地说,可以使用NoSQL(不一定使用OLAP建模)实现向下钻取,切片和骰子以及其他报告以进行分析?我们还可以克服OLAP的“数据子集”查询限制并用NoSQL报告整个数据世界吗?

2 个答案:

答案 0 :(得分:3)

在我的估计中,OLAP子集或结构不会消失,并且由于某些原因可能会变得更常见。没有特别的顺序:f)Map-reduce是你在很多情况下得到的。 Mongodb通过更快速的聚合管道更加稳固; u)NoSQL的一个重要问题是缺少连接或关系。这意味着您的基础数据 是丑陋的,以支持许多OLAP报告; b)仅仅为了保持干净的主表/集合而构建“丢弃”或易失性数据子集是值得的; a)NoSQL完全适用于冗余数据集:不需要创建表甚至模式,它很容易旋转并杀死集合; r)NoSQL比其他数据集更容易扩展,而不是SQL; d)刚刚起步的初创公司可以避免支持两种数据库技术所需的成本和资源(一种用于OLAP,另一种用于OLTP);并且,b)使用按摩数据集,您会发现您的后端/前端代码更容易和易于管理;并且,c)具有自己的预制指数的预制数据集的无与伦比的速度优势。

答案 1 :(得分:2)

回答你的两个问题是肯定的。 1.重构您的交易数据以进行分析仍然有效。 2.您可以使用NoSQL来处理您提出的所有问题。

正如您刚才提到的查询/分析/ OLAP,我假设这里唯一考虑的是创建一个查询/报告平台。因此,OLTP系统以及NoSQL是否能够处理它是不可能的。

如果没有与之相关的背景,很难回答这个问题。您是否为组织的团队,部门,垂直,业务线等创建此平台的上下文,或者您正在为整个组织创建此平台作为中央存储库。

如果您正在为团队/部门进行设置,则卷不是很大,用户会查询的次数较少,查询频率不高,那么OLAP仍然有效。但是如果音量很大并且查询频率很高且用户数量很多,而且你发现将来需要扩展,那么NoSQL将是你的赌注。

此外,如果您在企业级别为NoSQL创建平台。说 - 您创建一个企业数据仓库或数据湖,迎合组织中的任何和每个受众。但在组织团队/部门内部,可以通过创建数据集市来满足自己的需求,从而创建自己的OLAP。因此,在这种情况下,OLAP和NoSQL仍然有效。

我想说这完全取决于你的用例。要做出决定,需要考虑各种因素。对于任何考虑的技术,总是有利有弊。这些比较没有通用的答案。您需要回答诸如以下问题:您的数据源及其格式是什么;如果它们是结构化的,半结构化的,非结构化的?谁是你的用户和多少人;如果有多个部门有不同的需求,如果他们需要单独的仪表板,他们是否需要访问彼此的数据?您将处理的数据量是多少?查询报告平台的频率是多少?还有更多问题你可以问自己。在回答完这些问题后,请确定最合适的选项。