与MongoDB，CouchDB和相关技术我们可以更快地查询，所以这仍然有效吗？数据仓库原理和NoSQL
“的交易数据的副本，特别是重组进行查询和分析。”（R.金博尔数据仓库工具包，1996年
我的意思是，我们真的需要我们的数据重组到OLAP方案查询用于分析目的？更具体地说，可以使用NoSQL（不一定需要OLAP建模）来实现深入分析，切片和切片以及用于分析目的的其他报告？也可以通过查询OLAP的“数据子集”查询限制并报告整个数据领域与NoSQL？
在我的估计OLAP子集或结构不会消失，并可能会更常见的原因有几个：没有特定的顺序： f）Map-Reduce是你在许多情况下得到的。 Mongodb凭借其更快速的聚合管道走稳了脚步; u）NoSQL的一个大问题是缺乏联接或关系。这意味着您的基础数据有是丑陋的，以支持许多OLAP报告; b）值得构建“丢弃”或易变的数据子集，只是为了保持干净的主表/集合; a）NoSQL非常适合冗余数据集：没有创建表或甚至架构需要，其死亡简单的启动和杀死集合; r）与SQL相比，NoSQL对于附加数据集的扩展更容易; d）初出茅庐的启动可以避免支持两种数据库技术（一种用于OLAP，另一种用于OLTP）所需的成本和资源; b）通过按摩数据集，你会发现你的后端/前端代码更容易和易于管理;以及c）预制数据集具有其自己的预制指数的无与伦比的速度优势。
对你的两个问题的回答是YES。 1.重构您的交易数据以进行分析仍然有效。 2.你可以使用NoSQL来完成你所要求的一切。
正如你所提到的只是查询/分析/ OLAP，我假设这里唯一的考虑是创建一个查询/报告平台。所以，OLTP系统和NoSQL是否可以处理它都没有讨论。
如果没有关联的上下文，很难回答这个问题。上下文就像您是否为组织的团队，部门，垂直，业务线等创建此平台一样，或者您是为整个组织创建此平台作为中央存储库。
如果您正在为团队/部门进行设置，则卷不会很庞大，用户查询数量会减少，查询频率不会太高，那么OLAP仍然有效。但是，如果数量巨大，而且查询频率高且大量用户，并且您看到将来需要扩展，那么NoSQL将是您的选择。
此外，如果您在企业级创建NoSQL平台。假设 - 您创建了一个企业数据仓库或数据湖，以满足组织中的任何和每个受众。但是在组织内部，团队/部门可以通过创建数据集市来满足自己的需求来创建自己的OLAP。因此，在这种情况下，OLAP和NoSQL仍然有效。
我会说这完全取决于您的使用情况。为了做出决定，需要考虑各种因素。考虑任何技术的优点和缺点总是存在的。这种比较没有通用的答案。您需要回答以下问题 - 您的数据源和格式是什么？如果它们是结构化的，半结构化的，非结构化的？你的用户是谁，有多少;如果有多个不同需求的部门，他们是否需要单独的仪表板，他们是否需要访问其他数据？你将要处理的数据量是多少？查询报告平台的频率是多少？还有更多的问题你可以问自己。回答完这些问题后，再决定什么是最适合你的选择。
首先，我会质疑这些系统是否为bi/reporting工作负载提供更快的查询性能。有许多类型的nosql系统，每个系统都适用于不同的场景。柱状dbs擅长报告例子，但他们真的是nosql吗？ Sql服务器也包含它。 Kimball意味着性能重构和易用性。祝你好运，要求你的最终用户使用没有某种olap层或语义模型的nosql db :-) – Rich 2017-04-08 23:07:05