?作為地球上最堅硬的物質(zhì)，鉆石的用途令人驚訝地有限：鋸片、鉆頭、結(jié)婚戒指和其他工業(yè)應(yīng)用。

相比之下，自然界中較軟的金屬之一--鐵，可以被改造成無盡的應(yīng)用：最鋒利的刀片、最高的摩天大樓、最先進的汽車, 巨大的輪船，而且很快，如果埃隆-馬斯克是對的，就會有最有效的電動車電池。

換句話說，鐵之所以有令人難以置信的用處，是因為它既是剛性的又是柔性的。

同樣，數(shù)據(jù)庫只有在既嚴格又靈活的情況下才對今天的實時分析有用。

傳統(tǒng)的數(shù)據(jù)庫，由于其完全靈活的結(jié)構(gòu)，是很脆的。無模式的NoSQL數(shù)據(jù)庫也是如此，它們能夠攝取大量的數(shù)據(jù)，但在從這些數(shù)據(jù)中提取復(fù)雜的見解方面卻很差。

用戶個性化，自動庫存管理，智能運維和其他實時用例要求數(shù)據(jù)庫嚴格執(zhí)行模式，并擁有根據(jù)數(shù)據(jù)本身自動重新定義這些模式的靈活性。這滿足了現(xiàn)代分析的三個關(guān)鍵要求：

• 支持采集數(shù)據(jù)的規(guī)模和速度
• 支持靈活的模式，可以立即適應(yīng)流式數(shù)據(jù)的多樣性
• 支持快速、復(fù)雜的SQL查詢，需要嚴格的結(jié)構(gòu)或模式

昨天的模式：堅硬而脆弱

經(jīng)典的模式是關(guān)系型數(shù)據(jù)庫表：實體的行，例如人，以及這些實體的不同屬性（年齡或性別）的列。通常存儲在SQL語句中，模式還定義了數(shù)據(jù)庫中所有的表以及它們之間的關(guān)系。

傳統(tǒng)上，模式是嚴格執(zhí)行的。不符合預(yù)定屬性或數(shù)據(jù)類型的輸入數(shù)據(jù)會被數(shù)據(jù)庫自動拒絕，在其位置上存儲一個空值或完全跳過整個記錄。改變模式是很困難的，也是很少做的。公司小心翼翼地設(shè)計他們的ETL數(shù)據(jù)管道，以便與他們的模式保持一致（反之亦然）。

在過去，預(yù)先創(chuàng)建和嚴格執(zhí)行模式有很好的理由。SQL查詢更容易編寫。它們的運行速度也快了很多。最重要的是，嚴格的模式可以防止由不良或不匹配的數(shù)據(jù)造成的查詢錯誤。

然而，嚴格的、一成不變的模式在今天有著巨大的弊端。首先，現(xiàn)在的數(shù)據(jù)來源和類型比90年代多得多。他們中的許多人不能輕易地適應(yīng)相同的模式結(jié)構(gòu)。最值得注意的是實時事件流。流媒體和時間序列數(shù)據(jù)通常以經(jīng)常變化的半結(jié)構(gòu)化格式到達。隨著這些格式的改變，模式也必須改變。

其次，隨著業(yè)務(wù)條件的變化，公司不斷需要分析新的數(shù)據(jù)源，運行不同類型的分析--或者簡單地更新其數(shù)據(jù)類型或標簽。

這里有一個例子。當我在Fackbook的數(shù)據(jù)基礎(chǔ)設(shè)施團隊的時候，我們參與了一項雄心勃勃的計劃，名為"花蜜項目 "的用戶群正在爆炸性增長。"花蜜項目 "試圖用一套標準的屬性來記錄每個用戶的行為。在全球范圍內(nèi)實現(xiàn)這一模式的標準化，將使我們能夠在全球范圍內(nèi)分析趨勢并發(fā)現(xiàn)異常情況。經(jīng)過許多內(nèi)部辯論，我們的團隊同意在Hadoop中使用一個名為time_spent的列中的時間戳來存儲每個用戶事件，該列的分辨率為一秒。

在 "花蜜項目 "首次亮相后，我們向一組新的應(yīng)用程序開發(fā)人員展示了它。他們問的第一個問題是"你能把列的花費時間從秒改為毫秒嗎？"換句話說，他們隨口要求我們在Nectar項目推出后重建其模式的一個基本方面。

ETL管道可以使你所有的數(shù)據(jù)源都在同一個傳說中的屋頂下（這就是T，代表數(shù)據(jù)轉(zhuǎn)換的意思）。然而，ETL管道的設(shè)置、操作以及隨著數(shù)據(jù)來源和類型的變化而進行的手動更新都很耗時和昂貴。

靈活性的嘗試

嚴格的、一成不變的模式破壞了靈活性，而今天所有的公司都需要這種靈活性。一些數(shù)據(jù)庫制造商通過使用戶更容易手動修改他們的模式來應(yīng)對這個問題。不過，這也是一個沉重的代價。

使用SQL ALTER-TABLE命令改變模式需要大量的時間和處理能力，使你的數(shù)據(jù)庫長時間處于離線狀態(tài)。而且，一旦模式被更新，就很有可能在無意中破壞你的數(shù)據(jù)，使你的數(shù)據(jù)管道癱瘓。

以 PostgreSQL，是流行的交易型數(shù)據(jù)庫，許多公司也用它來做簡單的分析。為了正確攝取當今快速變化的事件流，PostgreSQL必須通過SQL中的手動ALTER-TABLE命令來改變其模式。這將鎖定數(shù)據(jù)庫表，并在ALTER-TABLE完成的時間內(nèi)凍結(jié)所有查詢和交易。據(jù)說，無論你的PostgreSQL表有多大，ALTER-TABLE都需要很長的時間。它還需要大量的CPU，并造成數(shù)據(jù)錯誤和下游應(yīng)用中斷的風險。

NewSQL數(shù)據(jù)庫也面臨同樣的問題。 CockroachDB 承諾在線改變Schema具有零停機時間。然而，Cockroach警告說不要一次做超過一個模式的改變。它也強烈警告不要在交易中改變模式。就像PostgreSQL一樣，CockroachDB的所有模式改變都必須由用戶手動完成。因此，CockroachDB的模式遠沒有表面上那么靈活。而且，數(shù)據(jù)錯誤和數(shù)據(jù)停機的風險也同樣存在。

NoSQL來拯救？

其他制造商發(fā)布的NoSQL數(shù)據(jù)庫大大放松了模式，或者完全放棄了模式。

這種激進的設(shè)計選擇使NoSQL數(shù)據(jù)庫--文檔數(shù)據(jù)庫、鍵值存儲、面向列的數(shù)據(jù)庫和圖形數(shù)據(jù)庫--非常適合將各種類型的海量數(shù)據(jù)存儲在一起，無論是結(jié)構(gòu)化、半結(jié)構(gòu)化還是多態(tài)化的數(shù)據(jù)。

Data lakes建立在NoSQL數(shù)據(jù)庫（如Hadoop）上的數(shù)據(jù)湖是混合類型的擴展數(shù)據(jù)存儲庫的最好例子。NoSQL數(shù)據(jù)庫在檢索大量數(shù)據(jù)和運行簡單查詢方面也很迅速。

然而，輕量級/非輕量級模式數(shù)據(jù)庫確實存在弊端。

雖然查找和簡單的查詢可以是快速和簡單的，但復(fù)雜的嵌套的和必須返回精確答案的查詢往往運行緩慢，而且難以創(chuàng)建。這是由于缺乏SQL支持，以及他們傾向于對索引和其他查詢優(yōu)化的支持不力。復(fù)雜的查詢甚至更有可能超時而不返回結(jié)果，這是因為NoSQL的過于寬松的數(shù)據(jù)一致性模型。修復(fù)和重新運行查詢是一件浪費時間的麻煩事。而當涉及到云計算和開發(fā)人員時，這意味著浪費金錢。

以作為Hadoop堆棧一部分的Hive分析數(shù)據(jù)庫為例。Hive確實支持靈活的模式，但很粗略。當它遇到不適合整齊地放入現(xiàn)有表格和數(shù)據(jù)庫的半結(jié)構(gòu)化數(shù)據(jù)時，它只是將數(shù)據(jù)存儲為一個 JSON-like blob，這可以保持數(shù)據(jù)的完整性。然而，在查詢時，Blobs需要首先被反序列化，這是一個緩慢而低效的過程。

或者采取亞馬遜DynamoDB為例，它使用的是無模式的鍵值存儲。DynamoDB在讀取特定記錄時速度超快。多記錄查詢往往要慢得多，盡管建立二級索引可以幫助。更大的問題是，DynamoDB不支持任何JOIN或任何其他復(fù)雜查詢。

嚴格和靈活模式的正確方法

然而，有一個成功的數(shù)據(jù)庫公式，它融合了NoSQL的靈活可擴展性和SQL的準確性和可靠性，同時又加入了云原生基礎(chǔ)設(shè)施的低操作簡單性。

Rockset是一個建立在RocksDB鍵值存儲之上的實時分析平臺。像其他NoSQL數(shù)據(jù)庫一樣，Rockset具有高度的可擴展性、靈活性和快速寫入數(shù)據(jù)的能力。但與SQL關(guān)系型數(shù)據(jù)庫一樣，Rockset也有嚴格的模式優(yōu)勢。強數(shù)據(jù)類型和高度的數(shù)據(jù)一致性，再加上我們的自動和高效的 Converged Indexing這些優(yōu)勢與我們的自動和高效的數(shù)據(jù)庫相結(jié)合，確保你的復(fù)雜的SQL查詢是快速的。

Rockset自動生成Schema通過檢查數(shù)據(jù)的字段和數(shù)據(jù)類型，因為它是存儲的。而且Rockset可以處理扔給它的任何類型的數(shù)據(jù)，包括。

• 具有深度嵌套數(shù)組和對象的JSON數(shù)據(jù)，以及混合數(shù)據(jù)類型和稀疏字段
• 實時事件流，隨著時間的推移不斷增加新的字段
• 來自新數(shù)據(jù)源的新數(shù)據(jù)類型

支持無模式攝入和融合索引，使Rockset能夠通過消除對上游數(shù)據(jù)轉(zhuǎn)換的需求來減少數(shù)據(jù)延遲。

Rockset還有其他優(yōu)化功能，以減少存儲成本和加速查詢。對于每條記錄的每一個字段，Rockset都會存儲數(shù)據(jù)類型。這最大限度地提高了查詢性能和減少了錯誤。而且，我們通過一個叫做字段互換的功能有效地做到了這一點，與無模式的基于JSON的文檔數(shù)據(jù)庫相比，例如，所需的存儲量最多可減少30%。

Rockset使用了一種叫做類型提升的東西來減少查詢的處理時間。具有相同類型的相鄰項目可以將其類型信息提升到適用于整個項目集，而不是存儲在列表中的每一個單獨的項目。這使得矢量的CPU指令能夠快速處理整個項目集。這個實現(xiàn)--連同我們的 Converged Index?--使Rockset查詢能夠像具有剛性模式的數(shù)據(jù)庫一樣快速運行，而不會產(chǎn)生額外的計算。

一些NoSQL數(shù)據(jù)庫的制造商聲稱只有他們能支持靈活的模式。 這不是真的，而且是Rockset等現(xiàn)代產(chǎn)品正在打破的一個神話。?