歡迎光臨
每天分享高質量文章

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

英文:Deb Haldar,翻譯:開源中國

www.oschina.net/translate/10-questions-to-ask-yourself-before-choosing-a-nosql-database

原文:http://www.acodersjourney.com/2018/09/10-questions-to-ask-yourself-before-choosing-a-nosql-database/

那麼我為什麼要寫這篇文章呢?


是因為我認為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資料庫中。


●編號425,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

Web開發

更多推薦18個技術類微信公眾號

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

赞(0)

分享創造快樂