data-warehouse - 数据仓库原理和 NoSQL

Question

使用 MongoDB、CouchDB 和相关技术，我们可以获得更快的查询，那么这仍然有效吗？

“交易数据的副本，专门针对查询和分析进行了重组。” （R. Kimball 数据仓库工具包，1996

我的意思是，我们真的需要将我们的数据重组为 OLAP 方案来查询它以进行分析吗？更具体地说，是否可以使用 NoSQL（不一定使用 OLAP 建模）来实现用于分析目的的钻取、切片和切块以及其他报告？我们是否也可以克服 OLAP 的“数据子集”查询限制并使用 NoSQL 报告整个数据世界？

Answer 1

在我看来，OLAP 子集或结构不会消失，并且可能会因为一些原因而变得更加普遍。没有特别的顺序： f) Map-reduce 在很多情况下都是你得到的。Mongodb 以更快的聚合管道站稳了脚跟；u) NoSQL 的一个大问题是缺乏连接或关系。这意味着您的基础数据具有为了支持许多OLAP报告而变得丑陋；b) 构建“丢弃”或易失性数据子集以保持干净的主表/集合是值得的；a) NoSQL 非常适合冗余数据集：不需要创建表甚至模式，启动和终止集合非常简单；r) 对于附加数据集，NoSQL 比 SQL 更容易扩展；d) 初出茅庐的初创公司可以避免支持两种数据库技术（一种用于 OLAP，一种用于 OLTP）所需的成本和资源；并且，b）您会发现您的后端/前端代码使用经过处理的数据集更加容易和可管理；并且，c) 具有自己的预制索引的预制数据集的无与伦比的速度优势。

Answer 2

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

正如您只提到查询/分析/OLAP，我假设这里唯一的考虑是创建一个查询/报告平台。因此，OLTP 系统以及 NoSQL 是否可以处理它不在讨论范围内。

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

如果你是为一个团队/部门设置它，量不是很大，查询它的用户数量较少，查询频率不是那么高，那么 OLAP 仍然有效。但是，如果数量巨大、查询频率高、用户数量多，并且您发现将来需要扩展，那么 NoSQL 将是您的选择。

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

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