MySQL現在是一個更好的NoSQL解決方案。我們這樣說是因為在存儲 鍵/值(key/value) 之類資料時, MySQL 具有性能、易用性和穩定性方面的優勢。MySQL引擎穩定可靠，并且社群和官方支援良好，有非常豐富的線上資料, 涵蓋了各種操作、故障排查,複制以及各種使用模式等方面。基于這個原因, MySQL比起新興的NoSQL引擎具有很大優勢。
近年來,NoSQL引擎已成為主流。許多開發者将NoSQL引擎(包括: MongoDB, Cassandra, Redis, 和 Hadoop等)視為最優解，同時不贊成使用舊的 SQL 引擎。
選擇NoSQL資料庫通常是因為炒作,或者是認為關系資料庫解決不了和NoSQL相關的事。普通工程師在選擇資料庫時往往會忽視營運成本,穩定性和成熟度等問題。更多關于各種NoSQL(以及SQL)引擎的差別,以及局限性等方面的問題，請參考 Aphyr 上的 Jepsen專欄文章。
本文将闡釋為什麼用MySQL存儲 鍵/值 資料比大多數專用NoSQL引擎更适合的原因,并提供相應的指導步驟。
Wix 網站的解決方案
當使用者通路Wix上的某個網站頁面時, 浏覽器會向Wix網站伺服器發送一個HTTP請求。不管是自定義域名(例如,
cncounter.com
)還是免費的Wix二級域名(如:
user.wix.com/site
)。伺服器需要通過查詢鍵/值對來将URL請求解析為相應的站點。在下面的讨論中我們将URL視為 route(路由)。
routes
表用來将網址解析為 site 對象。因為網站可能有多個路由, 是以是多對一的關系(many to one, N:1)。找到網站以後, 程式就加載它。site 對象機構比較複雜, 包括兩個子對象清單 —— 網站使用的不同服務。下面是示例對象模型, 假設使用标準SQL資料庫和規範化表結構:
當更新 site時, 如果使用傳統的範式模型來更新多個表, 需要用事務(transaction)來保證資料的一緻性(data consistency)。(注意,事務使用資料庫級别的鎖(DB-level lock),這會阻止并發寫操作,有時也會影響相關表的并發讀操作。) 使用這種模型, 可能需要在每個表中設定一個序列鍵(serial key),并使用外鍵，以及為 routes 表的 URL 字段建立索引。
但是,使用範式設計會碰到很多問題:
- 鎖限制了對表的通路, 是以在高吞吐量情景下會嚴重影響性能。
- 讀取一個對象需要使用多條SQL語句(此處是4條), 或者使用 join (這又會受延遲影響)。
- 系列鍵的生成使用了鎖, 限制了寫吞吐量。
在MySQL或者其他SQL引擎中, 并發情況和吞吐量問題都是大量出現的。因為這些缺點,實際上在存儲 鍵/值對形式的資料時,很多開發者都傾向于使用 NoSQL 解決方案, 為了提供更好的吞吐量和并發性能, 而犧牲一些 穩定性(stability)、一緻性(consistency)、和可用性(availability)。
在 Wix, 我們發現 MySQL 作為鍵/值存儲使用時，比起作為關系資料模型時要強悍得多, 也比大多數NoSQL引擎要優秀很多。僅僅是使用MySQL作為NoSQL引擎,我們的現有系統在擴充性/吞吐量/并發/延遲等名額上都可以媲美任何NoSQL引擎。下面是一些資料:
- 跨三個資料中心的結構 (active-active-active setup, 三活)。
- 吞吐量在 200,000 RPM 數量級。
- routes 表的記錄在 1億 數量級, 占用空間為 10 GB級。
- sites 表的記錄在 1億數量級,存儲空間 200 GB以上。
- 平均讀取延遲在 1.0 -1.5毫秒之間(事實上,同一資料中心是 0.2 - 0.3 毫秒)。
請注意，在大多數 鍵/值 引擎中, 1.0 毫秒左右的延遲都是卓越的,包括開源的和基于雲的! 而我們是用MySQL實作的(MySQL被認為是标準的SQL引擎)。
表結構如下:
CREATE TABLE `routes` (
`route` varchar(255) NOT NULL,
`site_id` varchar(50) NOT NULL,
`last_update_date` bigint NOT NULL,
PRIMARY KEY (`route`),
KEY (`site_id`)
)
CREATE TABLE `sites` (
`site_id` varchar(50) NOT NULL,
`owner_id` varchar(50) NOT NULL,
`schema_version` varchar(10) NOT NULL DEFAULT '1.0',
`site_data` text NOT NULL,
`last_update_date` bigint NOT NULL,
PRIMARY KEY (`site_id`)
) /*ENGINE=InnoDB DEFAULT CHARSET=utf8
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=16*/;
所有不需要作為查詢條件的字段都已經合并到單個 blob 字段中(site_data text 字段)。其中包含了 sub-obj 記錄,以及 site 對象自身的其他屬性域。也請注意,這裡沒有使用自增序列鍵;相反,我們使用
varchar(50)
來存儲用戶端生成的 GUID 值。
下面是我們使用的查詢語句, 具有高吞吐量和低延遲特性:
select * from sites where site_id = (
select site_id from routes where route = ?
)
首先通過唯一索引查詢 routes 表,這隻傳回一個結果。然後通過主鍵查找 site, 也隻有一條記錄。嵌套查詢文法確定 2個SQL查詢卻隻需一次資料庫互動。
結果前面提到了, 在高流量和高更新率的情況下, 保持在平均 ~1毫秒左右 的性能。雖然沒有使用事務，但 update 是半事務性質的(semi-transactional)。這是因為, 先輸入一個 site, 但在輸入 route 記錄之前，都不會查詢到相關的記錄。是以如果我們先輸入 site, 再輸入 route, 依然能確定資料一緻性狀态, 即使在 sites 表中有很多孤兒資料的情況下。
MySQL當做 NoSQL引擎使用指南
通過上面的例子(以及Wix的其他類似情景), 我們精心制作了一份用MySQL作為NoSQL引擎的經驗指南。
最主要的是要記住, 使用MySQL作為NoSQL引擎時要避免資料庫鎖(DB locks)以及複雜的查詢。
- 不使用事務,因為會導緻鎖(locks)。相反, 應該使用應用層事務(applicative transactions)。
- 不使用序列鍵(serial key)。序列鍵會導緻鎖以及引起複雜的 active-active 配置。
- 使用用戶端生成的唯一鍵(client-generated unique keys)。我們使用的是 GUID。
設計資料庫時,進行查詢優化時還有如下要點:
- 不要使用範式(Do not normalize)。
- 隻存儲有索引的字段。如果某個字段不需要索引, 那麼将其存儲在 blob/text 字段中(如JSON或XML)。
- 不要使用外鍵(foreign key)。
- 必須允許讀取單行資料。
- 不準執行 alter 指令。表的 alter 指令會導緻鎖以及當機。如果不得不這樣做, 應該使用動态遷移(live migrations)。
在查詢資料時:
- 使用主鍵(primary key)和索引(index)作為條件來查詢.
- 不要使用 join.
- 不要使用聚合函數(aggregation).
- 隻在副本(replica)中執行繁重的查詢(housekeeping queries), 比如商業智能(BI), 資料研究(data exploration)等操作, 盡量不要在主庫(master database)上執行.
我們準備在另一篇部落格中深入介紹實時遷移(live migrations)和應用層事務(applicative transactions)。
總結
本文最主要的目的是讓你認識 MySQL 的新特性。将 MySQL 作為NoSQL引擎是很棒的, 雖然MySQL不是專為NoSQL設計的。文中展示了如何使用 MySQL 代替專用 NoSQL引擎來存儲 鍵/值(key/value) 資訊。
在 Wix , 儲存鍵/值資訊(等情況下)會選擇MySQL引擎, 原因是其易于使用和操作, 并且MySQL強大的生态系統。另外,比起多數NoSQL引擎來說,在延遲(latency)、吞吐量(throughput)和并發性(concurrency)等名額(metrics)上MySQL并不遜色。
原文連結: http://engineering.wix.com/2015/12/10/scaling-to-100m-mysql-is-a-better-nosql/
原文日前: 2015年12月10日
翻譯日期: 2015年12月27日
作者: 鐵錨 http://blog.csdn.net/renfufei