在資料庫圈子，大家都知道今年Uber幹出來一件大事件，把PostgreSQL切換到了MySQL，當時社群裡一陣喧嘩。事情已經過去半年多了，這裡我不想去跟大家再討論這兩個關係型資料庫那個比較好。只是想帶著大家思考選擇的背後。
在該事件中，Uber提出來遷移的一個重要原因是：在大量更新的業務場景下PostgreSQL的IO方面有過多的開銷（主要是從存儲結構上說明），對於使用SSD或是PCI- E卡的裝置基本上無法容忍寫入放大，同時又提出了以下需求：
需要有寫入緩衝能力，萬一持久化到資料庫失敗時，仍可以稍後再試。
需要通知下游依賴關係的方式，資料變更要能無損的通知出去。
需要二級索引。
系統要夠健壯，可以支援7X24服務。
最重要一點，需要SchemaLess的儲存支援
要有能力透過增加伺服器動態擴容。增加伺服器不但要增加可用的硬碟容量，還要減少系統的回應時間。
Uber針對這些需求也和其它互聯網廠家一樣，嘗試過Cassandra， Riak，MongoDB，也想過自研，但最終選擇了MySQL作為儲存層。 這裡反問一下： MySQL能滿足上面的需求嗎？ 例如：
SchemaLess 儲存支援
寫緩衝能力，較快的故障切換
較好的擴容能力
SQLSQL
但從文章看Uber技術負責人：Jakob Thomsen 最後使用了MySQL做Schemaless儲存方案。我的神啊，大家沒看錯，沒看錯，就是使用的MySQL做的schemaless儲存方案。DocumentStore
從MySQL 5.7後可以認為MySQL也開始NoSQL了，支援json類型，加入更多的json支援。感受一下：
支援CRUD等傳統SQL操作。為了更好的支援NoSQL介面,在此基礎又推出了另一個重量級的協定:X-協定。以及圍繞著推出一堆的 mysqlsh ,各種程式的 Driver。如果你現在還不了解,可能很快就Out嘍
X-協議
全新的協議, 減少交互開銷， 減少消息大小，支持管道處理，支持通知處理
對NoSQL支持更友好，更豐富的資料處理接口，考慮到資料Sharding實作
上面這兩個功能也是MySQL 8.0要重點發力的兩個功能。知識更新很快，如果還不知這兩個的特性的朋友，要抓緊時間更新一下知識了。 MySQL開始要發威了，最近更新非常的快。
也正是這兩個特性，正好滿足Uber的需求，基於NoSQL介面存儲，底層資料保障使用MySQL的Replication複製（MySQL Group Replication馬上也GA了）。在NoSQL介面層很容易做到資料的分割及路由設制，底層複製又較好的保證的資料可用安全性。
MySQL已經不是當初的那個關係型資料庫了,現在有更多特性需要你去深入挖掘
以上就是關於Uber選擇MySQL的思考的內容，更多相關內容請關注PHP中文網（www .php.cn）！
