天天看點

SQL vs NoSQL:如何選擇?

在前一篇文章中,我們讨論了 sql 與 nosql 資料庫之間基本的差別。接下來,我們我們将應用我們在特定場景中的知識來确定最佳的選擇。

回顧一下:

sql 資料庫:

nosql 資料庫

sql 資料庫是一個理想的項目,确定好了需求和健壯的資料的完整性是至關重要的。nosql 資料庫是無關理想,不确定的或者不斷變化的資料需求 ,在速度和可伸縮性上更重要。 簡單的術語:

一些項目要精準的符合。如果你有較淺的話,任何一種選擇都是可行的,或者自然的非規範資料。但是請注意這些簡化示例場景與全面的概括!你比我更了解你的項目,我不建議切換從sql到nosql或反之亦然,除非它提供了可觀的效益。這是你的選擇。在項目的開始要考慮利弊,你不能出錯。

讓我們重新發明輪子,實作一個基于sql的通訊錄系統。我們最初接觸表的時候,天真的定義以下字段:

問題一: 很少人隻有一個電話号碼。我們可能需要至少三個号碼:一個座機,一個行動電話,一個工作電話。但是有多少個号碼無關緊要——有些人、有些地方需要更多。讓我們建立一個單獨的 telephone 表,這樣的話他們想要多少聯系人都可以。這也讓我們的資料标準化了——我們不需要沒有号碼的聯系人顯示為null。

問題二:email位址有同樣的問題,是以我們也建立一個類似的 email 表:

問題三:我們可能不想輸入一個(地理位置的)位址,或者我們想輸入多個位址,工作地,家裡,度假住所等。是以我們需要一個新的 address 表:

我們原來的 contact 表簡化成:

太棒了——我們有了一個能存放任意聯系人的任意多個電話号碼,email 位址和住址的标準化資料庫。不幸的是……

我們沒有考慮到聯系人的中間名字、出生日期、公司或職位。我們添加多少字段都沒關系,我們很快會受到更新的需求要添加備注、紀念日、關系狀态、社交媒體賬号、内腿測量值、最喜歡的奶酪類型等字段。預測所有選項是不可能的,是以我們可能需要一個 otherdata 表,用來處理名字-值對。

對開發者或者系統管理者來說,檢查資料庫并不容易。程式邏輯會變得更慢、更複雜,因為利用單個 select 和多個 join 語句查詢聯系人資料不太實際。(你可以這麼做,但是結果可能需要包含 telephone,email,和 address字段的每一種組合:如果有個聯系人有三個電話号碼,五個email位址和兩個住址,那麼sql查詢将會産生30條結果。) 最後,全文搜尋很困難。如果有人輸入字元串"sitepoint",我們必須檢查所有的表,看看它是否為聯系人名字、電話、email或者住址的一部分,并且需要做相應的排序。如果你用過wordpress的搜尋功能,你就會明白這有多虐心。

我們的聯系人資料關注的是人。他們難以預測,在不同的時間有不同的需求。使用nosql資料庫,聯系人清單将會從中受益。資料庫将一個聯系人的所有資料存儲在一個單獨的文檔裡的contacts 集合裡。

在這個例子裡,我們沒有存儲聯系人的頭銜或者性别,我們還添加了一些資料,而這些資料不需要應用到任何其他聯系人。沒關系——我們的nosql資料庫不會介意,我們還可以随意添加或移除字段。

由于聯系人資料在單獨的文檔裡,我們可以用一條查詢語句擷取一部分或全部資訊。全文搜尋也變得簡單;在mongodb裡,我們可以這樣定義 contact 中的所有文本字段的索引:

然後執行全文搜尋:

社交網絡可能使用類似的聯系人資料存儲,但是它會根據功能集合擴充,比如關系鍊、狀态更新、發送消息和”贊“。這些功能可能會根據使用者需求來實作或者移除——無法預測它們會怎樣演進。

另外:

nosql看來是個好的方案。它允許我們快速地實作存儲不同類型資料的功能。例如,可以用單個文檔裡的 status 集合替換所有使用者的過時的狀态更新。

文檔可能會變得很長,但我們可以擷取數組的子集,比如最近的更新。每個使用者的所有的曆史狀态記錄都能被快速搜尋到。

現在假設我們想在釋出更新的時候引入表情符号選擇。這涉及到給 update 數組裡的新記錄添加圖引用。不像 sql 存儲,沒必要把之前消息裡的表情符号置為 null——我們的程式邏輯可以顯示預設圖檔或者沒有圖檔,如果沒有設定表情符号的話。

考慮一個監控倉庫貨物的系統。我們需要記錄:

我們的資料需求:

通用的物品資訊,比如包裝數量、尺寸和顔色等可被存儲,但這些是我們可以識别并應用到任何物品上的離散資料。我們不太可能關注細節,例如筆記本處理器速度或者智能手機的電池壽命。

最小化出錯的可能是必要的。我們不能讓物品憑空消失或者移到已經有别的物品存放的位置。

簡單來說,我們在記錄物品從一個實體區域到另一個實體區域的轉移——或者從a位置移走,放到b位置。這是同一個動作的兩次更新。

我們需要一個具備強制資料完整性和事務支援的健壯存儲系統。(目前)隻有 sql 資料庫滿足這些需求。

我希望這些場景有所幫助,但是每個項目是不同的,最終,你需要做出自己的決定。(雖然,我們開發人員擅長于證明我們的技術選擇,不管他們有多好!)

最好的建議:顯露你自己盡可能多的技術。這些知識可以讓你對sql或者nosql做出一個理性和情感上公正的判斷。祝您好運。