為什麼實時分析既需要NoSQL的靈活性，又需要SQL系統的嚴格模式？

作為地球上最堅硬的物質，鑽石的用途令人驚訝地有限：鋸片、鑽頭、結婚戒指和其他工業應用。

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

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

同樣，資料庫只有在既嚴格又靈活的情況下才對今天的實時分析有用。

傳統的資料庫，由於其完全靈活的結構，是很脆的。無模式的NoSQL資料庫也是如此，它們能夠攝取大量的資料，但在從這些資料中提取複雜的見解方面卻很差。

使用者個性化，自動庫存管理，智慧運維和其他實時用例要求資料庫嚴格執行模式，並擁有根據資料本身自動重新定義這些模式的靈活性。這滿足了現代分析的三個關鍵要求。

支援採集資料的規模和速度

支援靈活的模式，可以立即適應流式資料的多樣性

支援快速、複雜的SQL查詢，需要嚴格的結構或模式

◆ 昨天的模式。堅硬而脆弱

經典的模式是關係型資料庫表：實體的行，例如人，以及這些實體的不同屬性(年齡或性別)的列。通常儲存在SQL語句中，模式還定義了資料庫中所有的表以及它們之間的關係。

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

在過去，預先建立和嚴格執行模式有很好的理由。SQL查詢更容易編寫。它們的執行速度也快了很多。最重要的是，嚴格的模式可以防止由不良或不匹配的資料造成的查詢錯誤。

然而，嚴格的、一成不變的模式在今天有著巨大的弊端。首先，現在的資料來源和型別比90年代多得多。他們中的許多人不能輕易地適應相同的模式結構。最值得注意的是實時事件流。流媒體和時間序列資料通常以經常變化的半結構化格式到達。隨著這些格式的改變，模式也必須改變。

其次，隨著業務條件的變化，公司不斷需要分析新的資料來源，執行不同型別的分析--或者簡單地更新其資料型別或標籤。

這裡有一個例子。當我在Fackbook的資料基礎設施團隊的時候，我們參與了一項雄心勃勃的計劃，名為"花蜜專案 "的使用者群正在爆炸性增長。"花蜜專案 "試圖用一套標準的屬性來記錄每個使用者的行為。在全球範圍內實現這一模式的標準化，將使我們能夠在全球範圍內分析趨勢並發現異常情況。經過許多內部辯論，我們的團隊同意在Hadoop中使用一個名為time_spent的列中的時間戳來儲存每個使用者事件，該列的解析度為一秒。

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

ETL管道可以使你所有的資料來源都在同一個傳說中的屋頂下(這就是T，代表資料轉換的意思)。然而，ETL管道的設定、操作以及隨著資料來源和型別的變化而進行的手動更新都很耗時和昂貴。

◆ 靈活性的嘗試

嚴格的、一成不變的模式破壞了靈活性，而今天所有的公司都需要這種靈活性。一些資料庫製造商透過使使用者更容易手動修改他們的模式來應對這個問題。不過，這也是一個沉重的代價。

使用SQL ALTER-TABLE命令改變模式需要大量的時間和處理能力，使你的資料庫長時間處於離線狀態。而且，一旦模式被更新，就很有可能在無意中破壞你的資料，使你的資料管道癱瘓。

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

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

◆ NoSQL來拯救?

其他製造商釋出的NoSQL資料庫大大放鬆了模式，或者完全放棄了模式。

這種激進的設計選擇使NoSQL資料庫--文件資料庫、鍵值儲存、面向列的資料庫和圖形資料庫--非常適合將各種型別的海量資料儲存在一起，無論是結構化、半結構化還是多型化的資料。

Data lakes建立在NoSQL資料庫(如Hadoop)上的資料湖是混合型別的擴充套件資料儲存庫的最好例子。NoSQL資料庫在檢索大量資料和執行簡單查詢方面也很迅速。

然而，輕量級/非輕量級模式資料庫確實存在弊端。

雖然查詢和簡單的查詢可以是快速和簡單的，但複雜的巢狀的和必須返回精確答案的查詢往往執行緩慢，而且難以建立。這是由於缺乏SQL支援，以及他們傾向於對索引和其他查詢最佳化的支援不力。複雜的查詢甚至更有可能超時而不返回結果，這是因為NoSQL的過於寬鬆的資料一致性模型。修復和重新執行查詢是一件浪費時間的麻煩事。而當涉及到雲端計算和開發人員時，這意味著浪費金錢。

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

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

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

然而，有一個成功的資料庫公式，它融合了NoSQL的靈活可擴充套件性和SQL的準確性和可靠性，同時又加入了雲原生基礎設施的低操作簡單性。

Rockset是一個建立在RocksDB鍵值儲存之上的實時分析平臺。像其他NoSQL資料庫一樣，Rockset具有高度的可擴充套件性、靈活性和快速寫入資料的能力。但與SQL關係型資料庫一樣，Rockset也有嚴格的模式優勢。強資料型別和高度的資料一致性，再加上我們的自動和高效的 Converged Indexing這些優勢與我們的自動和高效的資料庫相結合，確保你的複雜的SQL查詢是快速的。

Rockset自動生成Schema透過檢查資料的欄位和資料型別，因為它是儲存的。而且Rockset可以處理扔給它的任何型別的資料，包括。

具有深度巢狀陣列和物件的JSON資料，以及混合資料型別和稀疏欄位

實時事件流，隨著時間的推移不斷增加新的欄位

來自新資料來源的新資料型別

支援無模式攝入和融合索引，使Rockset能夠透過消除對上游資料轉換的需求來減少資料延遲。

Rockset還有其他最佳化功能，以減少儲存成本和加速查詢。對於每條記錄的每一個欄位，Rockset都會儲存資料型別。這最大限度地提高了查詢效能和減少了錯誤。而且，我們透過一個叫做欄位互換的功能有效地做到了這一點，與無模式的基於JSON的文件資料庫相比，例如，所需的儲存量最多可減少30%。

Rockset使用了一種叫做型別提升的東西來減少查詢的處理時間。具有相同型別的相鄰專案可以將其型別資訊提升到適用於整個專案集，而不是儲存在列表中的每一個單獨的專案。這使得向量的CPU指令能夠快速處理整個專案集。這個實現--連同我們的 Converged Index™--使Rockset查詢能夠像具有剛性模式的資料庫一樣快速執行，而不會產生額外的計算。

一些NoSQL資料庫的製造商聲稱只有他們能支援靈活的模式。 這不是真的，而且是Rockset等現代產品正在打破的一個神話。