在過去幾年里,有各種關(guān)于“NoSQL商務(wù)智能”的短評和出版物。然而,我一直沒搞清楚它吸引人關(guān)注的到底是什么,我的疑問可以歸結(jié)為“你想從中得到什么東西?”最近,我將這個話題拋向了一些主流NoSQL公司。得到結(jié)果讓我感到更加困惑了。下面是我真正搞清楚的一些方面。
正如我不久前在一篇關(guān)于數(shù)據(jù)模型的文章中提到的,許多數(shù)據(jù)庫都可以看作是一些對的集合——特別是SQL和NoSQL數(shù)據(jù)庫。
1.在關(guān)系數(shù)據(jù)庫中,一條記錄就是一組對和一些特定且預(yù)定的名稱序列(例如,來自表定義)。而且,一條記錄通常有一個標(biāo)識碼(通常是前面的其中一個值)。
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ù)需要進(jìn)行轉(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匯總時所使用的層次相同,而且我很懷疑這兩個分類并沒有太多的重疊部分。
除了層次之外,我認(rèn)為有一些用例適合完全非扁平化的BI。例如,考慮下面的場景,現(xiàn)在它通常都采用NoSQL來實現(xiàn):
1.你的數(shù)據(jù)已經(jīng)多到無法保存了(可能是機(jī)器生成的數(shù)據(jù))。
2.所以你總是按時間片進(jìn)行匯總。
3.你還會有選擇性地保存細(xì)節(jié)信息,即那些出現(xiàn)時被認(rèn)為有一定特殊用處的數(shù)據(jù)。
面向表格的傳統(tǒng)BI工具很難正確實現(xiàn)這些數(shù)據(jù)的可視化。所以,最終可能需要借助于運(yùn)行在NoSQL數(shù)據(jù)存儲的面向NoSQL的BI工具。事件序列BI工具在操作得當(dāng)?shù)那疤嵯乱材芎芎玫靥幚矸潜馄交瘮?shù)據(jù)。也就是說,我不確定現(xiàn)在最好的事件序列所使用的實際數(shù)據(jù)結(jié)構(gòu)。
以上是我個人的一些見解,歡迎大家留言討論。