與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