關(guān)于Uber選擇MySQL的思考

在數(shù)據(jù)庫圈子,大家都知道今年uber干出來一件大事件,把postgresql切換到了mysql,當時社區(qū)里一陣喧嘩。事情已經(jīng)過去半年多了,這里我不想去和大家再次討論這兩個關(guān)系型數(shù)據(jù)庫那個更好。只是想帶著大家思考一下選擇的背后。

在該事件中,Uber提出來遷移的一個重要原因是:在大量更新的業(yè)務場景下PostgreSQL的IO方面有過多的開銷(主要是從存儲結(jié)構(gòu)上說明),對于使用SSD或是PCI-E卡的設備基本無法容忍寫放大,同時又提出了以下需求:

  • 需要有寫緩沖能力,萬一持久化到數(shù)據(jù)庫失敗時,仍可以稍后重試。

  • 需要通知下游依賴關(guān)系的方式,數(shù)據(jù)變更要能無損的通知出去。

  • 需要二級索引。

  • 系統(tǒng)要足夠健壯,可以支持7X24服務。

  • 最重要一點,需要SchemaLess的存儲支持

  • 要有能力通過增加服務器動態(tài)擴容。增加服務器不但要增加可用的硬盤容量,還要減少系統(tǒng)的響應時間。

Uber針對這些需求也和其它互聯(lián)網(wǎng)廠家一樣,嘗試過Cassandra, Riak,MongoDB,也想過自研,但最終選擇了MySQL作為存儲層。 這里反問一下: MySQL能滿足上面的需求嗎? 例如:

  • SchemaLess 存儲支持

  • 寫緩沖能力,較快的故障切換

  • 較好的擴容能力

大家的印象里第一條 Schemaless都可以把MySQL秒了,但從文章里看 Uber技術(shù)負責人:Jakob Thomsen 最終使用了MySQL做Schemaless存儲方案。我的神啊,大家沒看錯,沒看錯,就是使用的MySQL做的schemaless存儲方案。

帶著好奇心驅(qū)動,再來看一下MySQL,你會發(fā)現(xiàn)從MySQL 5.7 引入了兩個重量級的特性,正好符合Uber的需求:

  • DocumentStore

  • X-協(xié)議

下面分別說明一下:

DocumentStore

從MySQL 5.7后可以認為MySQL也開始NoSQL了,支持json類型,加入更多的json支持 。感受一下:

關(guān)于Uber選擇MySQL的思考

支持CRUD等傳統(tǒng)SQL操作。為了更好的支持NoSQL接口,在此基礎又推出了另一個重量級的協(xié)議:X-協(xié)議。以及圍繞著推出一堆的?mysqlsh ,各種程序的?Driver。如果你現(xiàn)在還不去了解,可能很快就Out嘍

X-協(xié)議
全新的協(xié)議, 減少交互開銷, 減少消息大小,支持管道處理,支持通知處理

對NoSQL支持更友好,更豐富的數(shù)據(jù)處理接口,考慮到數(shù)據(jù)Sharding實現(xiàn)
?更高速的Query響應

上面這兩個功能也是MySQL 8.0要重點發(fā)力的兩個功能。知識更新很快,如果還不知這兩個的特性的朋友,要抓緊時間更新一下知識了。MySQL開始要發(fā)威了,最近更新非常的快。

也正是這兩個特性,正好滿足Uber的需求,基于NoSQL接口存儲,底層數(shù)據(jù)保障使用MySQL的Replication復制(MySQL Group Replication馬上也GA了)。在NoSQL接口層很容易做到數(shù)據(jù)的拆分及路由設制,底層復制又較好的保證的數(shù)據(jù)可用安全性。

MySQL已經(jīng)不是當初的那個關(guān)系型數(shù)據(jù)庫了,現(xiàn)在有更多特性需要你去深入挖掘

以上就是關(guān)于Uber選擇MySQL的思考的內(nèi)容,更多相關(guān)內(nèi)容請關(guān)注PHP中文網(wǎng)(www.php.cn)!

? 版權(quán)聲明
THE END
喜歡就支持一下吧
點贊10 分享