| 你或許會遇到需要選擇合適的開源數據庫的情況。但這無論對於開源方面的老手或是新手，都是一項艱鉅的任務。希望通過這篇文章能夠向大家分享這方面的一些技巧。 |
你或許會遇到需要選擇合適的開源數據庫的情況。但這無論對於開源方面的老手或是新手，都是一項艱鉅的任務。在過去的幾年中，採用開源技術的企業越來越多。面對這樣的趨勢，衆多開源應用公司都紛紛承諾自己提供的解決方案能夠各種問題、適應各種負載。但這些承諾不能輕信，在開源應用上的選擇是重要而艱難的，尤其是數據庫這種關鍵的應用。憑藉我在 Percona 和其它公司擔任 IT 專家的經驗，我很幸運能夠指導其他人在開源技術的選擇上做出正確的決策，因爲需要考慮的重要因素太多了。希望通過這篇文章能夠向大家分享這方面的一些技巧。
有一個明確的目標
這一點看似簡單，但在和很多人聊過 MySQL、MongoDB、PostgreSQL 之後，我覺得這一點纔是最重要的。面對繁雜的開源數據庫，更需要明確自己的目標。無論這個數據庫是作爲開發用的標準化數據庫後端，抑或是用於替換遺留代碼中的原有數據庫，這都是一個明確的目標。目標一旦確定，就可以集中精力與開源軟件的提供方商討更多細節了。
瞭解你的工作負載
儘管開源數據庫技術的功能越來越豐富，但這些新加入的功能都不太具有普適性。譬如 MongoDB 新增了事務的支持、MySQL 新增了 JSON 存儲的功能等等。目前開源數據庫的普遍趨勢是不斷加入新的功能，但很多人的誤區卻在於沒有選擇最適合的工具來完成自己的工作 —— 這樣的人或許是一個自大的開發者，又或許是一個視野狹窄的主管 —— 最終導致公司業務上的損失。最致命的是，在業務初期，使用了不適合的工具往往也可以順利地完成任務，但隨着業務的增長，很快就會到達瓶頸，儘管這個時候還可以替換更合適的工具，但成本就比較高了。例如，如果你需要的是數據分析倉庫，關係數據庫可能不是一個適合的選擇；如果你處理事務的應用要求嚴格的數據完整性和一致性，就不要考慮 NoSQL 了。
不要重新發明輪子
在過去的數十年，開源數據庫技術迅速發展壯大。開源數據庫從新生，到受到質疑，再到受到認可，現在已經成爲很多企業生產環境的數據庫。企業不再需要擔心選擇開源數據庫技術會產生風險，因爲開源數據庫通常都有活躍的社區，可以爲越來越多的初創公司、中型企業甚至 500 強公司提供開源數據庫領域的支持和第三方工具。Battery Ventures 是一家專注於技術的投資公司，最近推出了一個用於跟蹤最受歡迎開源項目的 BOSS 指數 。它提供了對一些被廣泛採用的開源項目和活躍的開源項目的詳細情況。其中，數據庫技術毫無懸念地佔據了榜單的主導地位，在前十位之中佔了一半。這個 BOSS 指數對於剛接觸開源數據庫領域的人來說，這是一個很好的切入點。當然，開源技術的提供者也會針對很多常見的典型問題給出對應的解決方案。我認爲，你想要做的事情很可能已經有人解決過了。即使這些先行者的解決方案不一定完全契合你的需求，但也可以從他們成功或失敗的案例中根據你自己的需求修改得出合適的解決方案。如果你採用了一個最前沿的技術，這就是你探索的好機會了。如果你的工作負載剛好適合新的開源數據庫技術，放膽去嘗試吧。第一個吃螃蟹的人總是會得到意外的挑戰和收穫。
先從簡單開始
你的數據庫實際上需要達到多少個 9 的可用性？對許多公司來說，“實現高可用性”僅僅只是一個模糊的目標。當然，最常見的答案都會是“它是關鍵應用，我們無論多短的停機時間都是無法忍受的”。數據庫環境越複雜，管理的難度就越大，成本也會越高。理論上你總可以將數據庫的可用性提得更高，但代價將會是大大增加的管理難度和性能下降。所以，先從簡單開始，直到有需要時再逐步擴展。
例如，Booking.com 是一個有名的旅遊預訂網站。但少有人知的是，它使用 MySQL 作爲數據庫後端。 Booking.com 高級系統架構師 Nicolai Plum 曾經發表過一次演講，講述了他們公司使用 MySQL 數據庫的歷程。其中一個重點就是，在初始階段數據庫可以被配置得很簡單，然後逐漸變得複雜。對於早期的數據庫需求，一個簡單的主從架構就足夠了，但隨着工作負載和數據量的增加，數據庫引入了負載均衡、多個讀取副本，還使用 Hadoop 進行分析。儘管如此，早期的架構仍然是非常簡單的。
有疑問，找專家
如果你仍然不確定數據庫選擇的是否合適，可以在論壇、網站或者與軟件的提供者處商討。研究各種開源數據庫是否滿足自己的需求是一件很有意義的事，因爲總會發現你從不知道的技術。而開源社區就是分享這些信息的地方。
當你接觸到開源軟件和軟件提供者時，有一件重要的事情需要注意。很多公司都有開放的核心業務模式，鼓勵採用他們的數據庫軟件。你可以只接受他們的部分建議和指導，然後用你自己的能力去研究和探索替代方案。
總結
選擇正確的開源數據庫是一個重要的過程。很多時候，人們都會在真正理解需求之前就做出決定，這是本末倒置的。