今天小編分享的健康經驗：管理100萬條數據是怎樣一種體驗？華為雲RDS有多強？，歡迎閱讀。
柴司的辦公室，就設在北京五環外一座普普通通的寫字樓裡。在同一樓層裡，還有其他十幾家同樣迷你的團隊，包括幾家電商公司。我們天天都能看到他們打包、點貨。
電商的每一筆訂單，都涉及到客戶的個人信息，產品信息，訂單信息，庫存情況，物流信息等等，最終匯總成一個龐大的數據庫。從客戶下單，到發貨、進貨，分析營銷推廣策略等 ..... 全都要圍繞着這個數據庫來。
尤其在雙 11、黑五這樣的營銷季，訂單暴漲，數據庫的一個故障，損失的就是實實在在的辛苦錢。
但當多年積累的數據擺在面前的時候，到底應該怎麼管理、查詢？難道用 Excel 嗎？
為了演示這個問題，我們真的生成了100 萬條數據，并趁着華為雲數據庫雙 11 的活動，看看管理 100 萬條數據是怎樣一種體驗？
視頻版
↓↓ 看完這個視頻就知道了 ↓↓
↑↑ 信我，真的超級好看 ↑↑
圖文版
首先，當然不能用 Excel.....
不少小企業在訂單數小，歷史數據不多的時候，會用本地數據庫。簡單來說，就是自己買伺服器硬體，使用 MySQL 等數據庫軟體，花錢請專門的運維人員，從頭開始搭建一個數據庫系統，并焚香洗手沐浴更衣，祈禱它能 7 × 24 小時穩定運行。
數據量小的時候，本地數據庫确實可以應付。但一旦遇到雙 11 和跨境電商的 " 黑五 " 這樣的營銷季，業務量暴漲，只要一次故障，就可能讓客戶剛下的訂單，和原本能賺到的錢，直接消失。
但如果花錢買更強的硬體，又要看着它們在非高峰期落灰閒置。
所以也有一些企業會買虛拟的雲伺服器，用來建立數據庫，也就是大家說的用 ECS 自建數據庫：這相當于把硬體外包了出去，但搭建數據庫的成本，包括運維人員的成本，還是得自己負擔。哪天運維大哥想喝酒撸串，其他人面對着復雜的數據庫頁面，只能一臉懵逼。
那雲數據庫能解決這些問題嗎？
我們這次用的華為雲提供的基于 MySQL 的關系型數據庫服務，也就是 RDS for MySQL，來做個測試，看看它的性能有多強。
首先，我們要搭一個電商數據庫，并生成 100 萬條數據。數據庫中要有客戶表，產品表，訂單表，以及付款，物流等等表格。總之，要盡可能模拟一個電商公司的真實運作。
之後，我們創建了一個 Python 腳本，用 Faker 庫随機創建了 2 萬個虛拟用戶，以及 15 萬條訂單，付款和物流數據。
在運行之後，數據庫中就出現了雲南省哈爾濱市的王秀珍，和廣西西安市的丁海燕 ...... 這不重要，反正這 2 萬名随機生成的虛拟用戶，只是我們測試道具罷了。
產品表裡，我們也模拟了售價 823.62 元的小說，和僅售 121 塊錢的空調等爆款商品。
而且請注意，這些表之間有着復雜的關系：比如訂單表裡面有 customer_id 關聯到用戶表裡面的用戶 id，付款表裡有 order_id 關聯到訂單表。所以這類數據庫才叫 "關系型數據庫"。
在創建完這八張表，一共近 100 萬條數據之後，我們就可以開始試試 RDS for MySQL 到底有幾把刷子了。
我們使用了華為雲現在提供免費試用的單機版 8 核 16G 配置，只需要點兩下滑鼠，選擇自己需要的配置就能直創建數據庫，既開即用，相比于本地自建伺服器的繁流程來說實在太簡單了～
因為我們已經用 Python 腳本設定好了數據，所以進入數據管理服務界面之後，能直接開始查詢。
我們先看看過去一個月内注冊的用戶，熱熱身：
結果耗時1ms......
那麼提高一下難度：我們想看看每個用戶的購物總花費，并按照從高到低的順序給他們排序，以便于後續給土豪推奢侈品，那可以使用聚合函數來查詢：
你猜猜這次要多久？
答案是 177ms，對于 RDS for MySQL 來說，依然是沒有流一滴汗。
那麼我們繼續上難度：這次我們想要查詢所有客戶的最近一次訂單以及支付狀态，并按照訂單的時間順序，排序返回最近的 50 名下單客戶。這會涉及到多張表的 JOIN 操作，包括客戶表，訂單表和付款表：
結果我們看整個查詢時間也僅僅只有 68ms，依然相當輕松。
那我們再試一些更復雜的業務邏輯：比如我們想查詢最近一個月内，每個商品類别的銷售總額，以便後續進貨。那這次的查詢時間是 256ms。
接着我們查詢了平均訂單金額高于所有訂單平均值的客戶，還是篩選土豪。這要先計算出所有用戶的平均訂單金額，然後再從所有用戶中篩選出訂單金額大于這個數的人。整個查詢時間也僅僅只有 37ms。
看起來這些任務實在難不倒 RDS for MySQL，我們讓測試同學施展畢生所學，來點狠的考驗。
我們想根據消費總額，先找出最有錢的前 10 名客戶，并定位他們最常購買的產品類别，方便後續針對性地服務好大客戶。那這個查詢會涉及多張表大量的 JOIN 操作。結果呢，也只花了 209ms 就完成了查詢。
除了照顧大客戶，我們還想看看那些已經很久沒來下單的非活躍用戶。我們可以把最近下單時間超過六個月的客戶定義為非活躍客戶，然後看看他們和活躍用戶相比，對業務的貢獻有多大區别。這次的查詢時間是 235ms。
在這個擁有接近 100 萬條數據的數據庫裡，我們用光了關于數據庫查詢的畢生所學。但所有復雜的查詢操作，用時也從來沒有超過 0.5 秒，不服不行。
最後我們的測試同學瘋狂了：他把之前用的一個查詢封裝成一個函數，然後連續調用它 100 次，可以看到即便這麼復雜的查詢連續執行 100 次，用時也僅有 18 秒， CPU 利用率只有 2% 出頭，也就跟我們筆記型電腦待機時的狀态差不多。
除了這些查詢測試以外，我們也用性能壓測工具 sysbench 對數據庫做了測試，這是在設定為 64 線程的測試結果。這裡的 TPS 代表每秒執行的事務量，QPS 代表每秒的查詢數量。可以看到平均 TPS 為 677，QPS 更是達到 1.3 萬左右，足以看出數據庫對于高并發場景的性能優勢。
而且，我們這裡用的只是試用配置，在華為的數據庫性能白皮書裡，還列出了不同 CPU 和内存搭配的性能測試結果，在其測試場景下，TPS 和 QPS 分别能夠實現最高 6400 和 12.9 萬的恐怖成績。
當然，性能只是雲數據庫服務的一方面而已。對于數據庫服務來說，穩定、安全也至關重要。
我們可以在 RDS 的雲服務監控詳情這裡，看到數據庫各項的指标監控，并及時收到異常告警。而且還可以根據業務需求，自定義告警規則。
而且很多時候，這些告警都用不着你自己來處理：比如擔心磁盤空間不足，那可以在實例的頁面選擇磁盤自動擴容，自動化運維，不用勞煩正在喝酒撸串的運維大哥。
這也是 RDS for MySQL 相對于本地數據庫的另一種優勢：不管是性能，還是存儲等不夠用，那都可以随時随地根據實際需求變更擴容，成本低，彈性強。
此外，華為雲 RDS for MySQL 還采取了多部署架構和容災方案，确保數據庫随時可用、且可恢復到任意時間節點。
你可以通過自動備份功能，方便地備份和恢復數據，不用擔心數據丢失帶來意外損失。
所以相比于自建數據庫來說，RDS for MySQL 提供的不光是更強的性能，還有更彈性、穩定、省心的體驗。
當然，一些小團隊可能覺得 RDS for MySQL 這麼強的性能目前還用不上。那可以考慮更輕量級的 Flexus 雲數據庫 RDS：
它同樣提供了開箱即用的體驗，也支持數據擴容，備份等功能。性價比很高，很适合中小企業與個人開發者。
我們也幫你體驗過了，它在性能也很夠用。而且可以無縫更新到标準版 RDS for MySQL，不用擔心未來業務增長之後出現瓶頸——這一點很重要，雖然我們是小團隊，但出來混，誰還不懷着一個做大做強的夢想呢？
如果你有需要的話，可以看看華為雙 11 期間的雲數據庫專場，趕一波新客專享優惠。
最後，同樣作為一家小團隊，我們深知大家都面對着類似的問題：我們财力和人手有限，只能把資源集中在主業上。其他的事情，最好能交給簡單、高效、穩定、性價比高的外部服務來解決。而不是投入大量成本，慢慢摸索，從 0 搭建。
從這個意義上來說，每家小公司，都高度依賴一個健全、完善的商業基礎設施體系。高速的互聯網、便捷的物流、廣泛覆蓋的通訊、協作工具，以及我們今天介紹的，穩定、易用、可靠的雲服務等等加在一起，才共同構成了這一基礎設施。
它們就像水和電一樣，略顯枯燥，容易被忽視，但卻真實地支持了無數企業和員工的發展與成長。希望中國未來的商業基礎設施能越築越牢。
下期見！
