如何正確選擇開源數據庫？你須要這的5個技巧

你或許會遇到須要選擇合適的開源數據庫的狀況。但這不管對於開源方面的老手或是新手，都是一項艱鉅的任務。在過去的幾年中，採用開源技術的企業愈來愈多。面對這樣的趨勢，衆多開源應用公司都紛紛承諾本身提供的解決方案可以各類問題、適應各類負載。但這些承諾不能輕信，在開源應用上的選擇是重要而艱難的，尤爲是數據庫這種關鍵的應用。憑藉我在 Percona 和其它公司擔任 IT 專家的經驗，我很幸運可以指導其餘人在開源技術的選擇上作出正確的決策，由於須要考慮的重要因素太多了。但願經過這篇文章可以向你們分享這方面的一些技巧。

有一個明確的目標

這一點看似簡單，但在和不少人聊過 MySQL、MongoDB、PostgreSQL 以後，我以爲這一點纔是最重要的。面對繁雜的開源數據庫，更須要明確本身的目標。不管這個數據庫是做爲開發用的標準化數據庫後端，抑或是用於替換遺留代碼中的原有數據庫，這都是一個明確的目標。目標一旦肯定，就能夠集中精力與開源軟件的提供方商討更多細節了。

瞭解你的工做負載

儘管開源數據庫技術的功能愈來愈豐富，但這些新加入的功能都不太具備普適性。譬如 MongoDB 新增了事務的支持、MySQL 新增了 JSON 存儲的功能等等。目前開源數據庫的廣泛趨勢是不斷加入新的功能，但不少人的誤區卻在於沒有選擇最適合的工具來完成本身的工做 —— 這樣的人或許是一個自大的開發者，又或許是一個視野狹窄的主管 —— 最終致使公司業務上的損失。最致命的是，在業務初期，使用了不適合的工具每每也能夠順利地完成任務，但隨着業務的增加，很快就會到達瓶頸，儘管這個時候還能夠替換更合適的工具，但成本就比較高了。例如，若是你須要的是數據分析倉庫，關係數據庫可能不是一個適合的選擇；若是你處理事務的應用要求嚴格的數據完整性和一致性，就不要考慮 NoSQL 了。

不要從新發明輪子

在過去的數十年，開源數據庫技術迅速發展壯大。開源數據庫重新生，到受到質疑，再到受到承認，如今已經成爲不少企業生產環境的數據庫。企業再也不須要擔憂選擇開源數據庫技術會產生風險，由於開源數據庫一般都有活躍的社區，能夠爲愈來愈多的初創公司、中型企業甚至 500 強公司提供開源數據庫領域的支持和第三方工具。Battery Ventures 是一家專一於技術的投資公司，最近推出了一個用於跟蹤最受歡迎開源項目的 BOSS 指數 。它提供了對一些被普遍採用的開源項目和活躍的開源項目的詳細狀況。其中，數據庫技術毫無懸念地佔據了榜單的主導地位，在前十位之中佔了一半。這個 BOSS 指數對於剛接觸開源數據庫領域的人來講，這是一個很好的切入點。固然，開源技術的提供者也會針對不少常見的典型問題給出對應的解決方案。我認爲，你想要作的事情極可能已經有人解決過了。即便這些先行者的解決方案不必定徹底契合你的需求，但也能夠從他們成功或失敗的案例中根據你本身的需求修改得出合適的解決方案。若是你採用了一個最前沿的技術，這就是你探索的好機會了。若是你的工做負載恰好適合新的開源數據庫技術，放膽去嘗試吧。第一個吃螃蟹的人老是會獲得意外的挑戰和收穫。

先從簡單開始

你的數據庫實際上須要達到多少個 9 的可用性？對許多公司來講，「實現高可用性」僅僅只是一個模糊的目標。固然，最多見的答案都會是「它是關鍵應用，咱們不管多短的停機時間都是沒法忍受的」。數據庫環境越複雜，管理的難度就越大，成本也會越高。理論上你總能夠將數據庫的可用性提得更高，但代價將會是大大增長的管理難度和性能降低。因此，先從簡單開始，直到有須要時再逐步擴展。
例如，Booking.com 是一個有名的旅遊預訂網站。但少有人知的是，它使用 MySQL 做爲數據庫後端。 Booking.com 高級系統架構師 Nicolai Plum 曾經發表過一次演講，講述了他們公司使用 MySQL 數據庫的歷程。其中一個重點就是，在初始階段數據庫能夠被配置得很簡單，而後逐漸變得複雜。對於早期的數據庫需求，一個簡單的主從架構就足夠了，但隨着工做負載和數據量的增長，數據庫引入了負載均衡、多個讀取副本，還使用 Hadoop 進行分析。儘管如此，早期的架構仍然是很是簡單的。

有疑問，找專家

若是你仍然不肯定數據庫選擇的是否合適，能夠在論壇、網站或者與軟件的提供者處商討。研究各類開源數據庫是否知足本身的需求是一件頗有意義的事，由於總會發現你從不知道的技術。而開源社區就是分享這些信息的地方。
當你接觸到開源軟件和軟件提供者時，有一件重要的事情須要注意。不少公司都有開放的核心業務模式，鼓勵採用他們的數據庫軟件。你能夠只接受他們的部分建議和指導，而後用你本身的能力去研究和探索替代方案。

總結

選擇正確的開源數據庫是一個重要的過程。不少時候，人們都會在真正理解需求以前就作出決定，這是本末倒置的。