數據庫的封閉性

發布時間:2019-02-20 分類:數據蔣堂 Tag:,,

我們知道,數據庫的數據處理能力是封閉的。所謂封閉性,這里是指要被數據庫計算和處理的數據,必須事先裝入數據庫之內,數據在數據庫內部還是外部是很明確的。

數據庫一般有OLTP和OLAP兩個用途。對于OLTP業務來講,因為要保證數據的一致性,而一致性只有在一個確定的范圍內談論才有意義,這樣就自然就會帶來封閉性:數據庫系統將保證也只負責數據庫內部的數據的一致性。

如果不關注OLTP業務,只關心OLAP業務時,數據庫在邏輯上可以被理解成為數據倉庫,而這樣的數據倉庫也順便繼承了這個封閉性。


數據庫的名字中有個“庫”字,即使不考慮OLTP業務,也會讓人覺得它是個以存儲為主要目的的產品。其實不然,在實際應用中,特別是在大數據場景下,數據庫有相當多的作用是計算,對于OLAP業務幾乎可以說是全部,其存儲經常也是為了計算服務的。因為數據庫的計算能力還不錯,遠遠超過大多數其它軟件產品,所以人們經常會為了計算目標而部署數據庫。

但是,一個以計算為主要任務的產品,沒必要綁定封閉性這樣的特點。


計算能力的封閉性有什么壞處呢?

一個典型的現象就是ETL經常被做成ELT甚至LET。ETL中的E和T這兩步事實上也是某種計算,如果計算能力被封閉到數據庫之內的話,我們就只能先把數據裝入庫中才能計算了,因為無法計算庫外的數據。然而ETL過程中的原始數據常常并不在庫內,或者至少不在這個用于計算的數據庫中,也可能存在于多個數據庫??傊?,都需要先做個同庫動作之后才能再計算。

有點多此一舉!

數據庫的封閉性,相當于城市有個城墻,數據要進出也必須通過數據庫的城門,過程中還要進行一些檢查。對于OLTP業務,為了保證一致性,這些檢查是有必要的,但也會損失數據庫的IO效率,而這對于ETL這類業務幾乎沒有意義,只是浪費時間而已。

當代應用中多樣性的數據源越來越普遍,經常有來自外部服務的數據。如果為了計算這些數據而先把它們轉入數據庫中,也是非常累贅的。臨時轉入的效率很低(因為數據庫的IO成本高),很可能跟不上訪問需求,而定時批量轉入又很難獲得最新的數據,同樣影響計算結果的實時性。


那么,我們把計算能力從數據庫中剝離出來,作為獨立的計算引擎提供,讓數據(倉)庫只負責存儲,是不是就可以了?

不依賴于數據庫的計算能力確實很必要,這樣是可以解決上述的ELT/LET和多數據源問題,但這還不夠。

數據庫風格的計算常常是數據密集型的,其性能和存儲機制密切相關。把計算能力剝離,只能是讓計算可以進行,但并不能保證足夠快。在關注計算性能的場景下,特定的存儲方案仍然是必要的。

還是要回到計算封閉的老路?

不必。

要獲得高性能,是要關注數據存儲,但只要設定專門的存儲格式即可,并不需要做個“庫”把數據裝起來。一個開放的計算引擎,可以計算任何來源的數據。如果數據能夠以約定的方式存儲,那么可以獲得更高性能的計算效率,僅此而已。計算時并不需要關心數據是不是屬于某個“庫”,“數據倉庫”(如果還用這個名詞的話)可以發展成沒有庫、只有數據的組織形式。

現代城市不必再有城墻!

更多《數據蔣堂》文章
广西快乐十分