在資料庫圈子，大家都知道今年uber幹出來一件大事件，把postgresql切換到了mysql，當時社群裡一陣喧嘩。事情已經過去半年多了，這裡我不想去和大家再次討論這兩個關係型資料庫那個更好。只是想帶著大家思考一下選擇的背後。
在該事件中，uber提出來遷移的乙個重要原因是：在大量更新的業務場景下postgresql的io方面有過多的開銷(主要是從儲存結構上說明)，對於使用ssd或是pci-e卡的裝置基本無法容忍寫放大，同時又提出了以下需求：需要有寫緩衝能力，萬一持久化到資料庫失敗時，仍可以稍後重試。
需要通知下游依賴關係的方式，資料變更要能無損的通知出去。
需要二級索引。
系統要足夠健壯，可以支援7x24服務。
最重要一點，需要schemaless的儲存支援
要有能力通過增加伺服器動態擴容。增加伺服器不但要增加可用的硬碟容量，還要減少系統的響應時間。
uber針對這些需求也和其它網際網路廠家一樣，嘗試過cassandra， riak，mongodb，也想過自研，但最終選擇了mysql作為儲存層。 這裡反問一下： mysql能滿足上面的需求嗎？ 例如：schemaless 儲存支援
寫緩衝能力，較快的故障切換
較好的擴容能力
大家的印象裡第一條 schemaless都可以把mysql秒了，但從文章裡看 uber技術負責人：jakob thomsen 最終使用了mysql做schemaless儲存方案。我的神啊，大家沒看錯，沒看錯，就是使用的mysql做的schemaless儲存方案。
帶著好奇心驅動，再來看一下mysql，你會發現從mysql 5.7 引入了兩個重量級的特性，正好符合uber的需求：documentstore
x-協議
下面分別說明一下：
支援crud等傳統sql操作。為了更好的支援nosql介面,在此基礎又推出了另乙個重量級的協議:x-協議。以及圍繞著推出一堆的 mysqlsh ,各種程式的 driver。如果你現在還不去了解,可能很快就out嘍
x-協議
全新的協議, 減少互動開銷， 減少訊息大小，支援管道處理，支援通知處理
對nosql支援更友好，更豐富的資料處理介面，考慮到資料sharding實現
更高速的query響應
上面這兩個功能也是mysql 8.0要重點發力的兩個功能。知識更新很快，如果還不知這兩個的特性的朋友，要抓緊時間更新一下知識了。mysql開始要發威了，最近更新非常的快。
也正是這兩個特性，正好滿足uber的需求，基於nosql介面儲存，底層資料保障使用mysql的replication複製(mysql group replication馬上也ga了)。在nosql介面層很容易做到資料的拆分及路由設制，底層複製又較好的保證的資料可用安全性。
mysql已經不是當初的那個關係型資料庫了,現在有更多特性需要你去深入挖掘
關於考勤資料的思考（MySQL）
最近考勤系統老是出錯，不知道公司考勤是怎麼做的。因為自己對mysql用的也不多，這裡根據自己的想法參考了別人的部落格，加上自己的驗證。學到了一些收穫，在這裡記下來。考勤系統最關心的是簽到與簽退，這裡簽到是第一次打卡的時間，簽退是最後一次打卡的時間。這麼做記錄會不全面，不推薦，只做驗證用 這裡我們不關...
關於針對iOS 7開發的幾點思考
閱讀器ios 7開發 作為一名ios 開發者，在對ios 7公升級更新應用的之前，除了扁平化的設計，充分利用ios 7的新功能外，還有哪些地方是我們應該想到的？2.很多裝置仍不支援ios 7。ipod touch系列只有ipod touch 5支援ios 7,而不少使用者還在使用第一代ipad，ip...
關於MySQL字符集架構的思考
隨著各種多位元組字符集的廣泛應用，而在軟體開發裡人數比例非常高的操英文的程式設計師對多位元組字元並不是很了解，這是最近幾年很多漏洞都是多位元組引起的乙個原 因。本文作者就mysql 的字符集架構作用談了自己的看法。最近幾個月，我每次用mysql，幾乎都會想 mysql現在如此層次分明的字符集架構作用...