【編者按】隨著互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的發(fā)展戴而，各個(gè)機(jī)構(gòu)都需要支撐遠(yuǎn)超過以往的數(shù)據(jù)。而在這個(gè)需求的刺激下翩蘸，IT 領(lǐng)域出現(xiàn)了大量數(shù)據(jù)處理技術(shù)所意，其中之一就是 NoSQL 。靈活的數(shù)據(jù)類型催首，高效的處理能力扶踊，讓 NoSQL 已占據(jù)數(shù)據(jù)管理系統(tǒng)的一席之地，比如人氣 NoSQL 數(shù)據(jù)庫 MongoDB郎任。然而在 Wix 工程實(shí)踐中秧耗，他們發(fā)現(xiàn)，大量場(chǎng)景中其實(shí)并不需 要 NoSQL舶治，反而成熟的 RDBMS 更具效益分井，比如 MySQL胶台。下面一起看 Wix 工程主管 Aviran Mordo 的分享，本文系 OneAPM 工程師翻譯杂抽。

開發(fā)人員選擇 NoSQL 數(shù)據(jù)庫一般都是根據(jù)主觀臆斷诈唬，或者“關(guān)系型數(shù)據(jù)庫性能不如 NoSQL 數(shù)據(jù)庫”這個(gè)錯(cuò)誤的理念。此外缩麸，在做數(shù)據(jù)庫選型時(shí)铸磅，開發(fā)人員往往還忽視了運(yùn)維上的開銷。實(shí)際上根據(jù) Wix 的實(shí)踐發(fā)現(xiàn)杭朱，大部分情況下都不必去選擇 NoSQL 數(shù)據(jù)庫阅仔，而且如果使用得當(dāng)?shù)脑挘琈ySQL 也可以是一個(gè)優(yōu)秀的 NoSQL 數(shù)據(jù)庫弧械。

在可擴(kuò)展系統(tǒng)構(gòu)建時(shí)八酒，一個(gè)很重要的考量是使用的技術(shù)是否成熟，選擇成熟的技術(shù)意味著出錯(cuò)時(shí)能夠迅速恢復(fù)刃唐。當(dāng)然羞迷，開發(fā)者也可以在項(xiàng)目中使用最新最牛的 NoSQL 數(shù)據(jù)庫，而這個(gè)數(shù)據(jù)庫在理論上也可以良好地運(yùn)行画饥，然而在生產(chǎn)環(huán)境中出現(xiàn)了問題恢復(fù)需要多久衔瓮？技術(shù)上已有的知識(shí)和經(jīng)驗(yàn)積累對(duì)于問題緩解至關(guān)重要，當(dāng)然這個(gè)積累也包括了 Google 可以搜索到的內(nèi)容抖甘。相比之下热鞍，關(guān)系型數(shù)據(jù)庫已經(jīng)存在了超過四十年，業(yè)界對(duì)于關(guān)系型數(shù)據(jù)庫的維護(hù)也積累了大量的經(jīng)驗(yàn)衔彻∞背瑁基于這些考慮，在新項(xiàng)目做技術(shù)選型時(shí)通常會(huì)選擇 MySQL艰额，而不是 NoSQL 數(shù)據(jù)庫澄港，除非 NoSQL 真的有非常非常明顯的優(yōu)勢(shì)，比如數(shù)據(jù)量太大就不適合使用 MySQL悴晰。

必須承認(rèn) MySQL 也有自己的問題慢睡。在大規(guī)模系統(tǒng)中使用的話可能會(huì)碰到性能上的問題。為實(shí)現(xiàn) MySQL 性能的最優(yōu)化铡溪，這里總結(jié)了幾條經(jīng)驗(yàn)，其中之一是避免數(shù)據(jù)庫級(jí)別的事務(wù)泪喊。因?yàn)槭聞?wù)需要數(shù)據(jù)庫采用鎖來實(shí)現(xiàn)棕硫，從而會(huì)影響數(shù)據(jù)庫性能。通常情況下會(huì)使用邏輯應(yīng)用程序級(jí)的鎖來 替換袒啼，從而減少負(fù)載并獲得一個(gè)更好的性能哈扮。

舉個(gè)例子纬纪，以發(fā)票結(jié)構(gòu)為例。如果某個(gè)發(fā)票有多個(gè)行項(xiàng)目滑肉，取代在單事務(wù)將所有行項(xiàng)目寫入包各，這里更應(yīng)該在非事務(wù)情況下逐行寫入。在所有行全部寫入數(shù)據(jù)庫后靶庙，這里還會(huì)寫入一個(gè)首記錄问畅，它包含了指向所有行項(xiàng)目 ID 的指針。這樣一來六荒，如果所有行中有一行寫入失敗护姆，那么這行的首記錄就會(huì)不存在，從而整個(gè)事務(wù)失敗掏击。這么做雖然可能會(huì)造成一些垃圾記錄卵皂，但在存儲(chǔ)介質(zhì)如此便宜的今天這顯然不是什么大問題，而這些垃圾記錄也可以做定期刪除砚亭。

下面也中介了一些 MySQL 實(shí)踐經(jīng)驗(yàn)：

不要使用 joins 查詢灯变，只做主鍵或者索引查詢。
不要使用自增主鍵因?yàn)闀?huì)有鎖捅膘，取而代之柒凉，使用客戶端生成鍵，比如 GUIDs篓跛。同時(shí)膝捞，如果你使用主主備份，自增鍵還可能會(huì)沖突愧沟，因此你需要為每個(gè)實(shí)例都定制鍵的范圍蔬咬。
沒有索引的字段通通刪掉或者使用 JSON 集合成單一字段。
在 Wix沐寺，MySQL 經(jīng)常會(huì)被當(dāng)做鍵值存儲(chǔ)林艘，比如在一列中儲(chǔ)存 JSON 對(duì)象，從而在不改變數(shù)據(jù)庫模式下對(duì)數(shù)據(jù)結(jié)構(gòu)模式進(jìn)行擴(kuò)展混坞。在 MySQL 中狐援，使用主鍵讀取也很快，Wix 就通過這個(gè)方式獲得了亞毫秒級(jí)的讀取速度究孕，完全可以支撐整個(gè)使用場(chǎng)景啥酱。基于以上這些原因厨诸，MySQL 完全可以看作一個(gè)符合 ACID 原則的 NoSQL 數(shù)據(jù)庫镶殷。至于數(shù)據(jù)庫的大小，一個(gè) MySQL 實(shí)例支持幾億條數(shù)據(jù)是沒什么問題的微酬。

關(guān)系型數(shù)據(jù)庫的一個(gè)鮮明的優(yōu)勢(shì)是不用考慮最終一致性绘趋，而這個(gè)在 NoSQL 數(shù)據(jù)庫中并不是原生支持的颤陶。本文也不是貶低 NoSQL，因?yàn)殛P(guān)系型數(shù)據(jù)庫已有限制也非常多：嚴(yán)格的數(shù)據(jù)結(jié)構(gòu)和大小限制陷遮。這里只是想提醒開發(fā)人員滓走，在選擇新技術(shù)時(shí)不要忽視運(yùn)維成本。

原文鏈接：MySQL is a Great NoSQL Database

OneAPM 是應(yīng)用性能管理領(lǐng)域的新興領(lǐng)軍企業(yè)帽馋，能幫助企業(yè)用戶和開發(fā)者輕松實(shí)現(xiàn)：緩慢的程序代碼和 SQL 語句的實(shí)時(shí)抓取搅方。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方博客茬斧。