如果你一直在使用數據庫，你就會知道NoSQL是熱門話題。主要是因為NoSQL在很大程度上填補了SQL相當難以填補的空白。傳統上，SQL數據庫的成本往往很高，從其只能垂直擴展，到數據庫還沒做出來就需要對模式進行大量的設計。因此，NoSQL就是為了對抗SQL而開發的，它可以水平擴展，也不需要使用Schema，但是是不是真的不需要Schema呢？本來就來探討一下。

NoSQL和Schemas

對于很多剛進入NoSQL的人來說，他們會被 "不需要SQL "和 "無Schema "這樣的流行語所吸引，但卻往往看不到森林中的樹木。雖然NoSQL確實是作為對SQL的回應而產生的，但它并不是作為一種替代，而是作為一種增強和補充的方式。更具體地說，這種無模式意味著NoSQL是非常靈活的，可以用大量不同的NoSQL數據模型來存儲數據。

不過這并不意味著NoSQL不能使用Schema，畢竟，NoSQL的數據可以是丑陋的、隨機的、混亂的、無限重復的（SQL是專門為了路由出重復的數據而做的，而NoSQL沒有）。因此，除非整個流水線只由計算機處理（不會的，因為數據科學并不完美），否則有一個Schema肯定是有用的。

為NoSQL設計Schema

由于NoSQL非常適合擴展性，所以在方案設計上主要考慮的可能是數據模型的可擴展性和性能。特別強調優化數據訪問，而數據訪問最終往往會非常依賴查詢。因此，NoSQL中的Schema設計重點是規劃專門配合工作流的鍵和索引，以便快速高效。

當然，選擇主鍵或決定哪些字段應該被索引有幾種方法。對于這一點，你一定要考慮用戶是如何處理或將要處理數據的。回顧以前的查詢可以給你一個很好的提示，讓你知道用戶日常是如何使用數據庫的，并很好地作為一個啟動點。這種查詢驅動的設計一般至少需要包含業務數據實體、用戶需求和規范，最后是所述用戶的查詢Schema（如果存在此類數據）。

為你的數據庫編寫完美的代碼

一旦你有了這些基本的成分，你就可以開始設計模式了，一個很好的起點就是設計NoSQL數據庫的自定義、類似表的結構。對于這一步，重要的是要在編寫一個服務于單一功能的代碼和可以滿足多個功能的代碼之間找到一個平衡點。畢竟，即使是NoSQL，幫助降低開銷也是很重要的一步。

最后一點需要對數據進行去正常化，因為這對任何NoSQL Schema設計都是必不可少的。雖然這不一定是一門精確的科學，但兩種最好的方法是通過引用或嵌入來實現數據的去正常化。這樣就可以實現1:1、1:N或M-N關系等核心設計模式。

特定主鍵 

在確定了這些之后，下一步就是設計主鍵。但是因為每個NoSQL數據庫的架構都是不同的，了解每個架構如何實現其主鍵是這一步的根本，所以這里就不詳細解釋了。最后，你需要設計索引，和上面的步驟類似，根據你使用的NoSQL數據庫不同，它的差別很大。盡管如此，有幾個設計概念你應該考慮。

創建一個合并的屬性列表作為查詢的謂詞，可以幫助你設計更高效的索引。當然，你應該避免創建過于細化的索引，因為那只會降低效率。

對于上面的觀點，只有當數組中的所有屬性都需要時，才應該設計數組索引。如果你計劃進行索引，保持數組大小最小化是至關重要的（在數據類型復雜的索引上應避免使用特殊索引）。

編輯NoSQL Schemas

鑒于NoSQL的靈活性傾向，對Schema進行更改是很容易的，而且基本上會導致終身設計和實現Schema更改的過程。這在剛開始的時候聽起來可能是個苦差事，但最終當你在幾年后意識到需要做一個非常重要的改變時，就會變得很好。NoSQL在沒有Schema的情況下單獨離開往往會導致無政府狀態，因此創建某種形式的Schema是有用的。你不必這樣做，特別是對于小規模的應用，但不要以為走NoSQL路線就可以不用創建Schema了。

關于慧都數倉建模大師

慧都數倉建模大師能夠快速、高效地幫助客戶搭建數據倉庫供企業決策分析之用。滿足數據需求效率、數據質量、擴展性、面向主題等特點。基于企業的業務目標，進行數據理解、數據準備、數據建模，最后進行評價和部署，真正實現數據驅動業務決策。更多詳情，請。