柴司的辦公室，就設在北京五環(huán)外一座普普通通的寫字樓里。在同一樓層里，還有其他十幾家同樣迷你的團隊，包括幾家電商公司。我們天天都能看到他們打包、點貨。

電商的每一筆訂單，都涉及到客戶的個人信息，產品信息，訂單信息，庫存情況，物流信息等等，最終匯總成一個龐大的數(shù)據庫。從客戶下單，到發(fā)貨、進貨，分析營銷推廣策略等.....全都要圍繞著這個數(shù)據庫來。

尤其在雙11、黑五這樣的營銷季，訂單暴漲，數(shù)據庫的一個故障，損失的就是實實在在的辛苦錢。

但當多年積累的數(shù)據擺在面前的時候，到底應該怎么管理、查詢？難道用Excel嗎？

為了演示這個問題，我們真的生成了100萬條數(shù)據，并趁著華為云數(shù)據庫雙11的活動，看看管理100萬條數(shù)據是怎樣一種體驗？

視頻版

↓↓ 看完這個視頻就知道了 ↓↓

↑↑ 信我，真的超級好看 ↑↑

圖文版

首先，當然不能用Excel.....

不少小企業(yè)在訂單數(shù)小，歷史數(shù)據不多的時候，會用本地數(shù)據庫。簡單來說，就是自己買服務器硬件，使用 MySQL 等數(shù)據庫軟件，花錢請專門的運維人員，從頭開始搭建一個數(shù)據庫系統(tǒng)，并焚香洗手沐浴更衣，祈禱它能7×24小時穩(wěn)定運行。

數(shù)據量小的時候，本地數(shù)據庫確實可以應付。但一旦遇到雙11和跨境電商的“黑五”這樣的營銷季，業(yè)務量暴漲，只要一次故障，就可能讓客戶剛下的訂單，和原本能賺到的錢，直接消失。

但如果花錢買更強的硬件，又要看著它們在非高峰期落灰閑置。

所以也有一些企業(yè)會買虛擬的云服務器，用來建立數(shù)據庫，也就是大家說的用ECS自建數(shù)據庫：這相當于把硬件外包了出去，但搭建數(shù)據庫的成本，包括運維人員的成本，還是得自己負擔。哪天運維大哥想喝酒擼串，其他人面對著復雜的數(shù)據庫頁面，只能一臉懵逼。

那云數(shù)據庫能解決這些問題嗎？

我們這次用的華為云提供的基于 MySQL 的關系型數(shù)據庫服務，也就是RDS for MySQL，來做個測試，看看它的性能有多強。

首先，我們要搭一個電商數(shù)據庫，并生成100 萬條數(shù)據。數(shù)據庫中要有客戶表，產品表，訂單表，以及付款，物流等等表格?？傊?，要盡可能模擬一個電商公司的真實運作。

之后，我們創(chuàng)建了一個 Python 腳本，用 Faker 庫隨機創(chuàng)建了 2 萬個虛擬用戶，以及15 萬條訂單，付款和物流數(shù)據。

在運行之后，數(shù)據庫中就出現(xiàn)了云南省哈爾濱市的王秀珍，和廣西西安市的丁海燕......這不重要，反正這 2 萬名隨機生成的虛擬用戶，只是我們測試道具罷了。

產品表里，我們也模擬了售價823.62元的小說，和僅售121塊錢的空調等爆款商品。

而且請注意，這些表之間有著復雜的關系：比如訂單表里面有customer_id關聯(lián)到用戶表里面的用戶id，付款表里有order_id關聯(lián)到訂單表。所以這類數(shù)據庫才叫“關系型數(shù)據庫”。

在創(chuàng)建完這八張表，一共近100萬條數(shù)據之后，我們就可以開始試試 RDS for MySQL 到底有幾把刷子了。

我們使用了華為云現(xiàn)在提供免費試用的單機版8核16G配置，只需要點兩下鼠標，選擇自己需要的配置就能直創(chuàng) 建數(shù)據庫，既開即用，相比于本地自建服務器的繁流程來說實在太簡單了～

因為我們已經用Python腳本設置好了數(shù)據，所以進入數(shù)據管理服務界面之后，能直接開始查詢。

我們先看看過去一個月內注冊的用戶，熱熱身：

結果耗時1ms......

那么提高一下難度：我們想看看每個用戶的購物總花費，并按照從高到低的順序給他們排序，以便于后續(xù)給土豪推奢侈品，那可以使用聚合函數(shù)來查詢：

你猜猜這次要多久？

答案是177ms，對于 RDS for MySQL 來說，依然是沒有流一滴汗。

那么我們繼續(xù)上難度：這次我們想要查詢所有客戶的最近一次訂單以及支付狀態(tài)，并按照訂單的時間順序，排序返回最近的50名下單客戶。這會涉及到多張表的JOIN操作，包括客戶表，訂單表和付款表：

結果我們看整個查詢時間也僅僅只有68ms，依然相當輕松。

那我們再試一些更復雜的業(yè)務邏輯：比如我們想查詢最近一個月內，每個商品類別的銷售總額，以便后續(xù)進貨。那這次的查詢時間是256ms。

接著我們查詢了平均訂單金額高于所有訂單平均值的客戶，還是篩選土豪。這要先計算出所有用戶的平均訂單金額，然后再從所有用戶中篩選出訂單金額大于這個數(shù)的人。整個查詢時間也僅僅只有37ms。

看起來這些任務實在難不倒 RDS for MySQL，我們讓測試同學施展畢生所學，來點狠的考驗。

我們想根據消費總額，先找出最有錢的前 10 名客戶，并定位他們最常購買的產品類別，方便后續(xù)針對性地服務好大客戶。那這個查詢會涉及多張表大量的JOIN操作。結果呢，也只花了209ms就完成了查詢。

除了照顧大客戶，我們還想看看那些已經很久沒來下單的非活躍用戶。我們可以把最近下單時間超過六個月的客戶定義為非活躍客戶，然后看看他們和活躍用戶相比，對業(yè)務的貢獻有多大區(qū)別。這次的查詢時間是235ms。

在這個擁有接近100萬條數(shù)據的數(shù)據庫里，我們用光了關于數(shù)據庫查詢的畢生所學。但所有復雜的查詢操作，用時也從來沒有超過0.5秒，不服不行。

最后我們的測試同學瘋狂了：他把之前用的一個查詢封裝成一個函數(shù)，然后連續(xù)調用它 100 次，可以看到即便這么復雜的查詢連續(xù)執(zhí)行100次，用時也僅有18 秒， CPU 利用率只有2% 出頭，也就跟我們筆記本電腦待機時的狀態(tài)差不多。

除了這些查詢測試以外，我們也用性能壓測工具sysbench對數(shù)據庫做了測試，這是在設置為64線程的測試結果。這里的TPS代表每秒執(zhí)行的事務量，QPS代表每秒的查詢數(shù)量?？梢钥吹?strong>平均TPS為677，QPS更是達到1.3萬左右，足以看出數(shù)據庫對于高并發(fā)場景的性能優(yōu)勢。

而且，我們這里用的只是試用配置，在華為的數(shù)據庫性能白皮書里，還列出了不同CPU和內存搭配的性能測試結果，在其測試場景下，TPS和QPS分別能夠實現(xiàn)最高6400和12.9萬的恐怖成績。

當然，性能只是云數(shù)據庫服務的一方面而已。對于數(shù)據庫服務來說，穩(wěn)定、安全也至關重要。

我們可以在 RDS 的云服務監(jiān)控詳情這里，看到數(shù)據庫各項的指標監(jiān)控，并及時收到異常告警。而且還可以根據業(yè)務需求，自定義告警規(guī)則。

而且很多時候，這些告警都用不著你自己來處理：比如擔心磁盤空間不足，那可以在實例的頁面選擇磁盤自動擴容，自動化運維，不用勞煩正在喝酒擼串的運維大哥。

這也是RDS for MySQL 相對于本地數(shù)據庫的另一種優(yōu)勢：不管是性能，還是存儲等不夠用，那都可以隨時隨地根據實際需求變更擴容，成本低，彈性強。

此外，華為云RDS for MySQL還采取了多部署架構和容災方案，確保數(shù)據庫隨時可用、且可恢復到任意時間節(jié)點。

你可以通過自動備份功能，方便地備份和恢復數(shù)據，不用擔心數(shù)據丟失帶來意外損失。

所以相比于自建數(shù)據庫來說，RDS for MySQL 提供的不光是更強的性能，還有更彈性、穩(wěn)定、省心的體驗。

當然，一些小團隊可能覺得 RDS for MySQL 這么強的性能目前還用不上。那可以考慮更輕量級的 Flexus 云數(shù)據庫RDS：

它同樣提供了開箱即用的體驗，也支持數(shù)據擴容，備份等功能。性價比很高，很適合中小企業(yè)與個人開發(fā)者。

我們也幫你體驗過了，它在性能也很夠用。而且可以無縫升級到標準版RDS for MySQL，不用擔心未來業(yè)務增長之后出現(xiàn)瓶頸——這一點很重要，雖然我們是小團隊，但出來混，誰還不懷著一個做大做強的夢想呢？

如果你有需要的話，可以看看華為雙11期間的云數(shù)據庫專場，趕一波新客專享優(yōu)惠。

最后，同樣作為一家小團隊，我們深知大家都面對著類似的問題：我們財力和人手有限，只能把資源集中在主業(yè)上。其他的事情，最好能交給簡單、高效、穩(wěn)定、性價比高的外部服務來解決。而不是投入大量成本，慢慢摸索，從0搭建。

從這個意義上來說，每家小公司，都高度依賴一個健全、完善的商業(yè)基礎設施體系。高速的互聯(lián)網、便捷的物流、廣泛覆蓋的通訊、協(xié)作工具，以及我們今天介紹的，穩(wěn)定、易用、可靠的云服務等等加在一起，才共同構成了這一基礎設施。

它們就像水和電一樣，略顯枯燥，容易被忽視，但卻真實地支持了無數(shù)企業(yè)和員工的發(fā)展與成長。希望中國未來的商業(yè)基礎設施能越筑越牢。

下期見！