如果你一直在使用數據庫，你就會知道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了。關於慧都數倉建模大師

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

相關文章