mysql 還是es MySQL 還是 ES

週末繼續閒扯

先問大家乙個問題，在涉及到系統架構或者技術選型時，通常會面臨很多選擇，如果讓你來做選型，你會選擇什麼方案，比如資料庫你會選什麼？

我這麼問其實是設有陷阱的，但凡脫離了實際業務場景談架構都是耍流氓。

開源資料庫產品近10年來百花齊放，10年前還是關係型資料庫的天下，因為他們有天然優勢，一通用，二保證了資料一致性，當然缺點也不少。

隨著網際網路的高速發展，業務也隨之變得複雜，資料量呈指數級增長，所以近年來誕生了很多非關係型資料庫，比如k-v型別的redis，文件資料庫 mongodb， elasticsearch，等等。

最近我遇到乙個問題就是某個業務資料量已經到了千萬級別，還在持續增長，因為資料庫用的是 mysql，在可以遇見的一段時間後，這個表將面臨資料查詢慢的效能瓶頸。

千萬級資料量當然不是簡單列加個索引就能解決問題的，畢竟重新建索引就是個非常緩慢的過程。

所以不得不做分表分庫處理，雖然mysql已經有很多成熟的分表分庫的中介軟體，但好像針對python的並不多。分表分庫麻煩，是垂直分還是水平分，根據什麼欄位來分，都是要考慮的問題，要改動的業務邏輯**也不少

這個時候mysql在擴充套件性方面就並沒有那些nosql靈活了，天然就是為分布式而生的mongodb，elasticsearch 就不會遇到這樣的問題，真遇到了瓶頸只要懟機器就行。

所以，最近準備把這塊業務遷移到elasticsearch。

雖然說 elasticsearch 是為了解決全文檢索問題誕生的，但毫不影響它用來做資料儲存，因為他本質上是乙個分布式資料庫。

用elasticsearch做資料儲存，這樣資料的擴充套件性問題也能得到很好解決，關鍵是使用非常靈活，不像操作mysql一樣，操作表結構麻煩的一逼，有時不得不停掉服務來公升級，而 elasticsearch 完全沒這樣的煩惱。

是不是一開始我就應該用elasticsearch來做資料儲存呢？這個就仁者見仁智者見智了。早期業務量沒那麼大，當然是怎麼簡單怎麼來，當前的架構能支撐未來一到兩年的發展就完全足夠了。誰知道能不能活過兩年呢？

好的架構都是演進過來的，不是悶頭設計出來的。