在過去幾年里，有各種關(guān)于“NoSQL商務(wù)智能”的短評和出版物。然而，我一直沒搞清楚它吸引人關(guān)注的到底是什么，我的疑問可以歸結(jié)為“你想從中得到什么東西?”最近，我將這個話題拋向了一些主流NoSQL公司。得到結(jié)果讓我感到更加困惑了。下面是我真正搞清楚的一些方面。

[[136462]]

正如我不久前在一篇關(guān)于數(shù)據(jù)模型的文章中提到的，許多數(shù)據(jù)庫都可以看作是一些對的集合——特別是SQL和NoSQL數(shù)據(jù)庫。

1.在關(guān)系數(shù)據(jù)庫中，一條記錄就是一組對和一些特定且預(yù)定的名稱序列(例如，來自表定義)。而且，一條記錄通常有一個標識碼(通常是前面的其中一個值)。

2.與之類似的可以稱為結(jié)構(gòu)化文檔存儲(如JSON或XML)，它們的區(qū)別在于各個文檔所包含的名稱序列可能各不相同。而且，通常這些名稱之間存在一種層次關(guān)系。

3.為此，像Cassandra或HBase這樣的“寬列”NoSQL存儲很大程度上可以視為一種結(jié)構(gòu)化文檔存儲，盡管它們有不同的性能優(yōu)化、特性及不同類型的DML(Data Manipulation Language)。

因此，NoSQL數(shù)據(jù)通?？梢钥醋魇且粋€表或一組表，但是：

• 1.NoSQL數(shù)據(jù)庫很可能有更多的空值。
• 2.如果單純轉(zhuǎn)換為關(guān)系型結(jié)構(gòu)，NoSQL數(shù)據(jù)庫可能會出現(xiàn)重復(fù)值。因此完整轉(zhuǎn)換時可能需要用到額外的數(shù)據(jù)表。

如果能夠編寫腳本提取NoSQL數(shù)據(jù)庫，然后根據(jù)需要進行轉(zhuǎn)換或匯總，那么也可以直接完成數(shù)據(jù)處理。但是，如果一定要使用一些交互界面來實現(xiàn)，則有一定的難度。順便指出的是，前面這種情況只適用于BI和ETL(Extract/Transform/Load)。事實上，我曾經(jīng)和多個人談?wù)撨^合并BI和 ETL的話題，而且他們可能有理由這樣做。

另一些問題出現(xiàn)在性能方面。許多NoSQL系統(tǒng)都使用了索引，因此也有一些過濾功能。其中一些(如MongoDB)還有匯總框架。所以，如果有了數(shù)據(jù)，也有了BI工具、ETL工具或ODBC/JDBC驅(qū)動程序，那么你有沒有利用這些現(xiàn)成的功能呢?或者說，你是否只是選擇做一些最簡單和最緩慢的事情，即提取數(shù)據(jù)，然后在其他位置處理這些數(shù)據(jù)?這些問題的答案現(xiàn)在還沒有定論，至多還處于尋找過程中。

既然明確了NoSQL數(shù)據(jù)結(jié)構(gòu)會給BI帶來問題，那么我們來看看有什么解決方法。是否有一些方法能讓它們真正發(fā)揮作用呢?我想說的是“NoSQL數(shù)據(jù)通常都采用層次結(jié)構(gòu)，而層次非常適合向上匯總/向下分析。”但是，描述NoSQL數(shù)據(jù)的層次并不一定與BI匯總時所使用的層次相同，而且我很懷疑這兩個分類并沒有太多的重疊部分。

除了層次之外，我認為有一些用例適合完全非扁平化的BI。例如，考慮下面的場景，現(xiàn)在它通常都采用NoSQL來實現(xiàn)：

• 1.你的數(shù)據(jù)已經(jīng)多到無法保存了(可能是機器生成的數(shù)據(jù))。
• 2.所以你總是按時間片進行匯總。
• 3.你還會有選擇性地保存細節(jié)信息，即那些出現(xiàn)時被認為有一定特殊用處的數(shù)據(jù)。

面向表格的傳統(tǒng)BI工具很難正確實現(xiàn)這些數(shù)據(jù)的可視化。所以，最終可能需要借助于運行在NoSQL數(shù)據(jù)存儲的面向NoSQL的BI工具。事件序列BI工具在操作得當?shù)那疤嵯乱材芎芎玫靥幚矸潜馄交瘮?shù)據(jù)。也就是說，我不確定現(xiàn)在***的事件序列所使用的實際數(shù)據(jù)結(jié)構(gòu)。

以上是我個人的一些見解，歡迎大家留言討論。