選擇 NoSQL 數據庫需要考慮的 10 個問題

#1：您是否準備好接受開發人員/系統管理員的培訓成本？

如果你是一家成熟的IT軟件開發公司，那么你很有可能已經有了熟悉SQL的人。這個組不僅包括開發人員，還包括數據庫管理員（DBA）。

除非您打算為新的NOSQL項目進行招聘，否則將會有對現有開發人員和DBA的培訓成本。額外的培訓也可能會延長項目交付日期。

一種簡單的思考方式是：

計算您的團隊成員（開發人員和DBA）擁有關系數據庫技術的總年數。

計算出通過培訓或新招聘獲得經驗相同NoSQL經驗年數的成本。

最后，弄清楚你從這個成本中得到了什么。你的投資回報率？

在這個特定的項目中，這個團隊的開發人員以前都沒有NoSQL經驗，但是有大量的SQL Server經驗。使用NoSQL解決方案在培訓中增加了大約1個sprint，當然，這也是由于缺乏經驗和設計上的失誤。

#2：您的數據事務是基于什么？或者，您需要什么級別的事務支持？

如果您的系統需要ACID屬性，那么您最好還是堅持使用RDBMS解決方案。否則，您將花費大量的時間試圖在您的應用程序/業務邏輯層復制ACID保證，并且您可能仍然沒有RDBMS解決方案那么高效。

#3: 您需要Web/高可伸縮性嗎？

總是在先計算出您需要什么樣的可伸縮性。在這個特殊的例子中，我們正在為微軟內部游戲工作室構建系統。

有10到15個游戲工作室正在考慮中——這取決于有多少注冊用戶使用這個系統

每個工作室最多有3-5個活躍的游戲標題。

每個游戲標題為三個環境存儲遙測模式——開發、預生產（PPE）和生產

對于每個標題，將會有2-5個數據科學家同時修改游戲標題數據

每一個標題事件都有大約50 KB的max事件數據

我們被要求存儲所有的版本——我們估計這個數字是1000除以一個標題的生命周期

有了以上粗略的估計，我們就可以計算并發性和存儲需求：

總并發數 = 工作室數量 * 標題數量每工作室 * 用戶數量每標題

=? 15 * 5 * 5 =?375 并發用戶

最大存儲 =??工作室數量 * 標題數量每工作室 * 環境數量 * 事件存儲大小每版本* 需要存儲的版本數

= 15 * 5 * 3 * 50 KB * 1000 = 11250000 KB =?11.25 GB最大存儲

SQL Azure支持1024個并發打開連接，并且能夠很容易地支持并發需求。另外，在考慮云計算時，11.25 GB實際上是一個非常小的數字。

這個系統并不是下一個FaceBook或必應——那么NoSQL的路線真的值得嗎？

#4：NoSQL解決方案真的能幫你省錢嗎？

在紙面上，Azure表存儲是一種更便宜的選擇，因為它的每Gb數據僅為美分，而SQL Azure則在此期間收取大約5美元的數據。

但是因為我們系統的存儲空間不會超過12 GB——這真的很重要嗎？每月60美元是我們在同一個系統上花30分鐘寫代碼的錢。

因此，在決定使用NoSQL僅僅是因為它的單位成本更低之前，先弄清楚節省下來的錢是否占了預算的很大一部分。

#5：你需要吸引風險投資嗎？

有趣的是，硅谷對NoSQL有偏見。這是因為感覺上NoSQL被認為具有內在的可伸縮性，并且RDBMS被認為是不可伸縮的。記住，關鍵字是“感覺上”！

這種可擴展性的感覺可能會讓投資者相信，你的軟件正處于正確的軌道上，準備好接受大規模的采用，從而吸引他們的投資資金。

許多NoSQL公司本身就是風投公司，這也給他們帶來了積極的偏見。

最后，圍繞“NoSQL”的所有營銷活動都有助于推動投資者對你的產品的正面情緒。

#6：你是在雇傭創業精神的人嗎？

如果你打算雇傭創業精神的人，他們中的很多人可能已經有NoSQL的知識了。

然而，如果你不在一個主要的科技中心，那么獲得這些人才的機會就很少了。您所在的區域可能有一個現成的RDBMS開發人員池——試圖在這樣的區域中招募NoSQL工程師和DBA可能會延遲項目交付日期，并且由于供應需求曲線，也會花費您更多的錢。

我的建議是與你的招聘機構/人力資源部門合作，對開發者進行市場調查，并將其納入你的技術選擇中。

#7：你的客戶在下游使用什么技術？

考慮這樣一個場景：您向客戶交付分析數據。您正在使用NoSQL來存儲分析數據。然而，您的一個客戶決定堅持使用基于SQL的報告系統。

這對你來說意味著什么？

這意味著您現在需要將所有NoSQL數據轉換為SQL格式，并通過Azure數據工廠等服務將其向下推到客戶的SQL數據庫。這是您需要承擔額外的開發和運營成本。如果您的所有下游客戶都在使用SQL，那么您需要認真地考慮是否使用NoSQL和做所有這些昂貴的數據轉換對您的系統有意義嗎？

#8：對于你的產品，可用性是否勝過一致性？

如果你正在建立一個像Facebook newsfeed這樣的系統，你可能會希望這個系統是高可用性的，并且是最終一致。

另一方面，如果您正在構建一個銀行系統（或者像我們的案例那樣的模式存儲），您可能希望支持強一致性，并放棄高可用性。

無論采用哪種方式，您都應該首先考慮CAP定理的含義，然后決定您的系統是否需要SQL或NoSQL解決方案。

#9：您是否預期對數據庫模式進行大量更改？

如果您期望對數據庫模式進行大量更改，就像移動應用程序、實時分析、內容管理系統等經常發生的情況一樣，那么NoSQL解決方案可能就是一種方法。

您可以使用一個分區方案，它允許您以一種比大多數SQL數據庫允許的更方便的方式更新您的數據庫模式。

#10：你想用NoSQL來獲得個人的充實/滿足嗎？

請不要這樣做！

我曾見過一些人，他們只是迷戀于學習一個NoSQL系統，并將其放入他們的簡歷中。這并沒有什么錯——我對NoSQL技術也很著迷。

但是，請不要讓這成為選擇技術堆棧背后的驅動因素（有意識的或下意識的）。如果你愿意的話，你可以在自己的時間里學習。

誰贏得了數據庫戰爭？

坦率地說 – 沒有哪個玩家能贏者通吃!

在很多情況下，您可能需要SQL和NoSQL技術在同一系統中并存。 例如，如果您正在構建像Instagram這樣的照片共享應用程序，則您的照片可能位于NoSQL數據庫中，而您的登錄/ ACL信息可能位于SQL數據庫中。

---------------------------------------

本文轉自無鰭的魚博客51CTO博客

NoSQL數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。