那麼我爲什麼要寫這篇文章呢?
是因爲我認爲NoSQL解決方案不如RDBMS解決方案嗎?當然不!
是因爲我專注於SQL的做事方式，而不想陷入一種相對較新的技術的不確定性嗎?不，也不是!事實上，我非常興奮地學習和使用各種分佈式數據庫提供的設施。
那我爲什麼要寫這個?
原因很簡單——幾年前，我見證了設計一個爲遙測事件提供模式管理設施的系統。事實證明，這比最初計劃的要昂貴得多。爲什麼呢?因爲選擇了錯誤的數據庫解決方案。
這個系統的一個要求是確保模式編輯是一致的，並且模式的最新版本被顯示給每個模式編輯器。它還應該支持併發編輯。
此外，同時訪問這個系統的用戶數量永遠不會超過幾百個。存儲的數據量不會是Tb級——最多幾百Gb。
因此，如果我們考慮了CAP定理的權衡，那麼選擇應該是顯而易見的——使用RDBMS。這樣做的好處是支持系統的一致性和事務支持需求。
相反，選擇了NoSQL數據庫(Azure表存儲)來進行原型設計。這一選擇的官方原因是，它使原型設計更快，並提供了更大的靈活性，同時更新了單個遙測事件的模式。與Azure SQL相比，Azure表存儲的低成本被認爲是另一個原因。
快進5個月……
該系統開始經歷許多關於維護CRUD操作完整性的問題。設計用來處理事務的瘦應用程序邏輯層已經不再那麼薄了。升級和向後兼容性的故事開始變得更加複雜。
由於受到許多其他問題的困擾，工程師們又回到了繪圖板——這次是用Azure SQL替換存儲層!我不記得具體的細節，但是這個改變增加了大約40%的額外時間和成本。
管理層很不高興，這個項目幾乎被砍掉了。但是團隊的工程師們非常優秀，他們能夠完成這個項目，儘管有了一些延遲和最初的錯誤的技術決定。
這個項目有一個圓滿的結局——但它也可能不是這樣的。事實上，很多內部項目都被關閉了，因爲他們不能在承諾的日期範圍內交付承諾的功能。
那麼，您如何知道NoSQL解決方案適合您的下一個軟件項目呢?首先問問你自己和你的團隊這十個問題：
#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數據庫中。
大連專業×××醫院 http://hnyy.01ny.cn/
大連打胎醫院 http://www.120dlbh.com/
大連看婦科哪裏好 http://www.0411bh.com/