数据仓库原理与NoSQL

Question

使用MongoDB、CouchDB及相关技术，我们可以实现更快的查询。那么这个说法是否仍然有效呢？

“一份为了查询和分析而重新构造的交易数据副本。”（R. Kimball《数据仓库工具箱》1996年）

我的意思是，我们真的需要将数据重构为OLAP模式才能查询并进行分析吗？更具体地说，针对分析目的，可以使用NoSQL（不一定是OLAP建模）来实现钻取、切片和其他报告功能吗？另外，我们能否通过NoSQL克服OLAP的“数据子集”查询限制，并对整个数据宇宙进行报告?

- ivansabik

---

首先，我会质疑这些系统是否能够为BI/报告工作负载提供更快的查询性能。市面上有许多类型的NoSQL系统，每种都适用于不同的场景。例如，列式数据库非常适合报告，但它们真的算是NoSQL吗？SQL Server也包括在内。Kimball所说的重构既包括了性能，也包括了易用性。祝你好运，试着让你的终端用户使用NoSQL数据库，而不带任何OLAP层或语义模型 :-) - Rich

Answer 1

据我所知，OLAP子集或结构并不会消失，而且可能会因为以下几个原因而变得更加普遍：f）在许多情况下，唯一可用的就是Map-reduce。Mongodb通过更快的聚合管道处于更稳定的状态；u）NoSQL的一个大问题是缺少连接或关系。这意味着您的基础数据必须很丑陋才能支持许多OLAP报告；b）值得构建“一次性”或易失性数据子集，只是为了保持干净的主表/集合；a）NoSQL非常适用于冗余数据集：不需要创建表格甚至架构，轻松启动和删除集合；r）与SQL相比，NoSQL更易于扩展额外的数据集；d）初创企业可以避免支持两种数据库技术（OLAP和OLTP）所需的成本和资源；b）通过修饰数据集，您会发现后端/前端代码更加容易管理；c）预制数据集具有自己的预制索引，具有无可匹敌的速度优势。

- Gabe Rainbow

Answer 2

回答你的两个问题都是肯定的。 1. 重组交易数据以进行分析仍然有效。 2. 您可以使用NoSQL来完成您所要求的一切。

由于您提到的只是查询/分析/OLAP，我假设这里唯一需要考虑的是创建一个查询/报告平台。因此，OLTP系统是否能够处理它已经不在讨论范围内。

没有上下文关联，很难回答这个问题。上下文是指您是为组织的团队、部门、垂直、业务线等创建此平台，还是为整个组织创建此平台作为中央存储库。

如果您为团队/部门设置它，那么数据量不会很大，查询用户数量较少，查询频率不是很高，则OLAP仍然有效。但是，如果数据量很大，查询频率很高且用户数量众多，并且您认为未来需要扩展，则NoSQL将是您的选择。

此外，如果您在企业级别上创建NoSQL平台。例如-您创建了企业数据仓库或数据湖，可为组织中的任何受众提供服务。但是，在组织内部，团队/部门可能会通过创建数据集市来创建自己的OLAP，以满足其自身需求。因此，在这种情况下，OLAP和NoSQL仍然有效。

我会说它完全取决于您的用例。要做出决策，需要考虑各种因素。任何技术都有其利弊。这些比较没有通用答案。您需要回答问题，例如-您的数据源及其格式是什么；如果它们是结构化、半结构化、非结构化的？谁是您的用户以及有多少个；如果有多个部门具有不同的需求，是否需要他们自己的仪表板，是否需要访问彼此的数据？您将处理的数据量是多少？查询报告平台的频率是多少？您可以问自己更多的问题。回答这些问题后，再决定哪个选项最适合您。

- Siddharth Shukla