amazon.com是服務(wù)于全球的在線電商，用戶在它的平臺(tái)上購買一件商品所需的時(shí)間不超過10秒凯正。它是如何陳列成千上萬件商品的同時(shí)毙玻，依然輸出穩(wěn)定的數(shù)據(jù)存取性能，從而提升全球用戶在購物過程中的體驗(yàn)廊散？對(duì)于這個(gè)問題的思考桑滩，將加深我們對(duì)數(shù)據(jù)庫系統(tǒng)的理解，進(jìn)而設(shè)計(jì)出優(yōu)良的數(shù)據(jù)服務(wù)允睹！本文將從Amazon的分類商品和推薦商品問題開始运准，揭示其背后的數(shù)據(jù)中心及其構(gòu)成往声。緊接著為遇到的問題進(jìn)行數(shù)據(jù)建模并分別使用MySQL，MongoDB戳吝，DynamoDB技術(shù)方案來解決這些問題浩销。每種技術(shù)方案都有其適用的場景，并體現(xiàn)在文中听哭，最終形成了一些判斷依據(jù)慢洋，用于決定選擇NoSQL還是SQL。

1.1 Amazon的分類商品與推薦商品所引發(fā)的思考

下圖是從amazon.com首頁截取的部分信息陆盘，主要包括 分類商品 與 推薦商品 普筹。

image

以上信息有一個(gè)特點(diǎn)：每一個(gè)大類中均包含多件商品。比如：推薦板塊中列舉了多件商品隘马；Ride electric類目下有多種商品太防。這些信息通常會(huì)存儲(chǔ)在中心服務(wù)器上，由數(shù)據(jù)庫系統(tǒng)管理酸员。當(dāng)用戶訪問amazon.com時(shí)蜒车，瀏覽器會(huì)向中心服務(wù)器獲取商品數(shù)據(jù)。整個(gè)過程如下圖所示：

image

通過上圖可知幔嗦，數(shù)據(jù)中心不僅需要存儲(chǔ)這些商品信息以及每件商品所屬的分類信息酿愧，還要提供獲取商品信息的方法。為了使數(shù)據(jù)中心具有數(shù)據(jù)存取的能力邀泉，往往需要引入數(shù)據(jù)庫系統(tǒng)（下圖藍(lán)色區(qū)域部分）嬉挡。這些系統(tǒng)不僅能夠存儲(chǔ)數(shù)據(jù)，也能夠查詢數(shù)據(jù)汇恤，通常運(yùn)行于多臺(tái)服務(wù)器庞钢。而這些服務(wù)器通過網(wǎng)線連接在一起，作為一個(gè)整體對(duì)外提供數(shù)據(jù)存取服務(wù)因谎。最終基括，數(shù)據(jù)中心的演化如下圖所示：

image

注意：以上只是一個(gè)簡化版的數(shù)據(jù)中心，現(xiàn)實(shí)情況是：amazon.com依賴于多個(gè)數(shù)據(jù)中心蓝角，每個(gè)國家都會(huì)有一個(gè)或多個(gè)數(shù)據(jù)中心（比如：美國阱穗，歐洲以及中國均有多個(gè)數(shù)據(jù)中心），每個(gè)數(shù)據(jù)中心都有大量的微服務(wù)支持著amazon.com使鹅。不同國家的用戶會(huì)直接訪問該國家的數(shù)據(jù)中心，這么做的好處是基于地理位置來降低訪問延時(shí)昌抠。以上簡化版的數(shù)據(jù)中心已經(jīng)足夠讓我們討論大多數(shù)amazon.com背后的數(shù)據(jù)服務(wù)了患朱，對(duì)于業(yè)務(wù)遍布全球的企業(yè)，多數(shù)據(jù)中心是必須考慮的炊苫。接下來裁厅，讓我們思考：使用數(shù)據(jù)庫系統(tǒng)存取這些商品信息時(shí)會(huì)遇到的問題冰沙。

首先將遇到問題是：當(dāng)數(shù)據(jù)量增多，超過現(xiàn)有的存儲(chǔ)能力時(shí)执虹，數(shù)據(jù)如何存儲(chǔ)拓挥？通常的做法是增加存儲(chǔ)空間，比如在每臺(tái)服務(wù)器上掛載多塊硬盤袋励。

其次侥啤，當(dāng)每秒訪問數(shù)據(jù)庫系統(tǒng)的次數(shù)增多時(shí)，如何確保數(shù)據(jù)庫系統(tǒng)是有能力提供服務(wù)的茬故？解決這個(gè)問題的做法是提供多臺(tái)服務(wù)器（每臺(tái)服務(wù)器中運(yùn)行著數(shù)據(jù)庫軟件）盖灸，并將數(shù)據(jù)切分成好幾份，再將每一份分配到不同的服務(wù)器上磺芭。

最后赁炎，如何確保一次性獲取完整的數(shù)據(jù)（比如一次性獲取Ride electric類目下的多種商品）？當(dāng)所有商品的數(shù)據(jù)集被切割成更小的集合散落在不同的服務(wù)器上時(shí)钾腺，會(huì)出現(xiàn)一種情況：相關(guān)聯(lián)的數(shù)據(jù)分布在不同的服務(wù)器上徙垫，為了獲取這些數(shù)據(jù)，則需要從不同的服務(wù)器中收集這些數(shù)據(jù)放棒，最終整合在一起松邪。這種方式存在一個(gè)問題：獲取相關(guān)聯(lián)的數(shù)據(jù)所需的時(shí)間變長了！因此為了減少獲取數(shù)據(jù)的時(shí)間哨查，則需要將相關(guān)聯(lián)的數(shù)據(jù)集中在一臺(tái)服務(wù)器上逗抑，以便一次性將這些關(guān)聯(lián)的數(shù)據(jù)從一臺(tái)服務(wù)器上取出，而不是多臺(tái)服務(wù)器寒亥。為了實(shí)現(xiàn)這一目標(biāo)邮府，則需要一些數(shù)據(jù)應(yīng)用的設(shè)計(jì)經(jīng)驗(yàn)。

除了以上提到的問題之外溉奕，還有其它一些常見的問題需要考慮：如何確保每個(gè)分區(qū)的數(shù)據(jù)有多個(gè)備份（replica）褂傀，以便該分區(qū)無法提供服務(wù)時(shí)，另外一個(gè)備份接替它的工作加勤？如何解決數(shù)據(jù)熱區(qū)的問題（比如一個(gè)熱銷商品被全球60億人在一秒之內(nèi)查看）仙辟？啟動(dòng)多少臺(tái)數(shù)據(jù)庫服務(wù)器以及如何監(jiān)控這些服務(wù)器的運(yùn)行狀態(tài)？如何備份數(shù)據(jù)鳄梅，以防人為失誤所導(dǎo)致的損失（比如刪除所有數(shù)據(jù)）叠国？如何確保數(shù)據(jù)中心的溫度是正常的，以便服務(wù)器能夠正常運(yùn)行戴尸？等等粟焊。雖然企業(yè)在起步階段不會(huì)遇到這些問題，但是隨著業(yè)務(wù)的增長，這些問題將會(huì)接踵而至项棠，等待你的是無窮無盡的問題悲雳。

如果你開始著手處理以上所有提到的問題，那么你會(huì)發(fā)現(xiàn)：需要大量有經(jīng)驗(yàn)的人才和時(shí)間以及金錢才能完成香追，而這種做法是非常糟糕的合瓢！好在，現(xiàn)有的云服務(wù)廠商透典，比如中國的阿里云晴楔，美國的AWS，Google Cloud以及Azure基本上解決了以上大多數(shù)問題掷匠！而我們只需要在其基礎(chǔ)之上解決一些與業(yè)務(wù)相關(guān)以及技術(shù)選型的問題滥崩。接下來，讓我們基于以上例子來分析有哪些業(yè)務(wù)問題需要解決讹语，然后選擇合適的技術(shù)來解決這些問題钙皮。

1.2 面臨的問題

擺在我們面前的問題有以下2點(diǎn)：

1. 作為用戶，我希望系統(tǒng)能根據(jù)歷史購買記錄來向我展示推薦商品的列表顽决，時(shí)間控制在1s以內(nèi)
2. 作為用戶短条，我希望系統(tǒng)為商品分類，并展示分類商品才菠，時(shí)間控制在1s以內(nèi)

以上問題有很多茸时，分為前端和后端以及數(shù)據(jù)端，這里要討論的焦點(diǎn)主要集中在 數(shù)據(jù)端赋访。為了解決以上2個(gè)問題可都，我們需要對(duì)其進(jìn)行數(shù)據(jù)建模-數(shù)據(jù)建模是指將現(xiàn)實(shí)世界中的問題抽象成數(shù)據(jù)實(shí)體（data entity）并建立數(shù)據(jù)實(shí)體之間的關(guān)系，最終通過計(jì)算機(jī)來表示蚓耽。

通過問題的描述可知渠牲，共有4個(gè)數(shù)據(jù)實(shí)體，它們分別是：用戶（User）步悠，商品（Product）签杈，推薦物（Recommend）以及商品分類（Category），以及3個(gè)關(guān)系鼎兽，它們分別是：用戶與推薦商品的關(guān)系答姥，推薦物與商品的關(guān)系和商品分類與商品的關(guān)系。整個(gè)數(shù)據(jù)實(shí)體以及其之間的關(guān)系可以通過下圖抽象出來：

image

上圖實(shí)體之間的連線代表它們之間的關(guān)系谚咬，其中1:*的含義是只1對(duì)0或1對(duì)多鹦付。比如一個(gè)用戶可以有0，1序宦，或者多個(gè)推薦商品睁壁。

對(duì)面臨的問題建立數(shù)據(jù)模型之后背苦，接下來需要考慮的問題是：技術(shù)選型互捌。

1.3 技術(shù)選型

在軟件行業(yè)里潘明，專門針對(duì)數(shù)據(jù)存儲(chǔ)與查詢的數(shù)據(jù)庫系統(tǒng)有很多，主要分為2大陣營秕噪，它們分別是SQL和NoSQL钳降。典型的SQL產(chǎn)品有：MySQL，SQL Server腌巾，PostgreSQL等等遂填，而NoSQL的產(chǎn)品有：MongoDB，CouchDB澈蝙，Dynamo吓坚，DynamoDB等等。每種類型的數(shù)據(jù)庫都有其適用的場景灯荧，沒有一個(gè)數(shù)據(jù)庫能夠解決所有問題礁击，常見的做法是將這些數(shù)據(jù)庫整合在一起來提供一套數(shù)據(jù)庫系統(tǒng)解決方案。比如SQL數(shù)據(jù)庫產(chǎn)品就特別適合OLAP類型（數(shù)據(jù)分析）的業(yè)務(wù)逗载，而NoSQL則適合于OLTP類型（線上交易或即時(shí)交互）的業(yè)務(wù)哆窿。比如amazon.com的后臺(tái)數(shù)據(jù)系統(tǒng)的構(gòu)成主要分為3大部分，它們分別是：

1. 由NoSQL數(shù)據(jù)庫系統(tǒng)組成厉斟，并提供在線交易支持的數(shù)據(jù)服務(wù)
2. 由SQL數(shù)據(jù)庫系統(tǒng)組成挚躯，并為公司內(nèi)部提供數(shù)據(jù)分析服務(wù)（ETL）
3. 大數(shù)據(jù)平臺(tái)，比如由Hadoop擦秽，Spark等框架提供的大數(shù)據(jù)服務(wù)

我們所面臨的業(yè)務(wù)問題屬于OLTP類型码荔，因此接下來的內(nèi)容將圍繞OLTP類型的業(yè)務(wù)問題展開。在展開過程中感挥，我們首先考慮使用SQL數(shù)據(jù)庫系統(tǒng)來解決問題缩搅，然后分析這種方法能夠帶來哪些好處以及什么時(shí)候能使用它。除此之外链快，我們也會(huì)分析使用這種方法在哪些條件下會(huì)遇到瓶頸以及如何使用NoSQL來解決所遇到的問題誉己。其次，我們會(huì)分析NoSQL是如何消除這些瓶頸以及需要為之付出的代價(jià)域蜗。最后巨双，我們將解釋為什么使用DynamoDB而不是其它NoSQL數(shù)據(jù)庫系統(tǒng)。以上提出的第2霉祸，3點(diǎn)雖然不屬于本文討論的范圍筑累，但是它們在現(xiàn)代互聯(lián)網(wǎng)企業(yè)中依舊占有一席之地，只不過這些問題會(huì)隨著企業(yè)的發(fā)展而漸漸浮出水面丝蹭！

OLTP=(Online transaction processing)慢宗，是指線上交易活動(dòng)的處理，比如電商，社交網(wǎng)絡(luò)镜沽，搜索引擎等屬于這類問題敏晤。這類活動(dòng)有一個(gè)特征：低延時(shí)。

OLAP=(Online analytical processing)缅茉，是指線上分析的處理嘴脾，比如BI系統(tǒng)，市場分析蔬墩，銷售報(bào)告等與數(shù)據(jù)分析與挖掘相關(guān)的日常問題均屬于這類問題译打。這類活動(dòng)有一個(gè)特征：在海量數(shù)據(jù)里讀取一小部分?jǐn)?shù)據(jù)來生成報(bào)告，進(jìn)而分析業(yè)務(wù)活動(dòng)拇颅。

首先奏司，讓我們看看 使用SQL數(shù)據(jù)庫系統(tǒng) 解決之前所提到的2個(gè)業(yè)務(wù)問題的情況。成熟的SQL數(shù)據(jù)庫系統(tǒng)有很多樟插，這里我們選用MySQL來解決以上提出的問題韵洋。接下來提到的方法同樣適用于其它數(shù)據(jù)庫系統(tǒng)。使用MySQL的前提條件是創(chuàng)建Schema岸夯，如圖 1.4所示麻献。該Schema里包含了4張表，每張表對(duì)應(yīng)現(xiàn)實(shí)問題中的一個(gè)數(shù)據(jù)實(shí)體猜扮，比如"users"表代表用戶實(shí)體勉吻，表中的每一行代表一個(gè)具體的用戶，該表能容納多個(gè)不同的用戶旅赢。

為了處理獲取某個(gè)用戶的推薦列表的請求齿桃，MySQL數(shù)據(jù)庫需要執(zhí)行以下步驟：

1. 從表"users"中找到該用戶所對(duì)應(yīng)的行，拿到user_id
2. 根據(jù)user_id到表"recommends"中找到所有與user_id相等的行
3. 遍歷步驟2返回的結(jié)果煮盼，根據(jù)每一行數(shù)據(jù)中的product_id從表"products"中取出詳細(xì)的商品信息
4. 將1短纵，2，3步獲得的數(shù)據(jù)打包成一個(gè)整體返回給請求端（比如瀏覽器）

為了處理獲取分類商品的請求僵控，MySQL數(shù)據(jù)庫需要執(zhí)行以下步驟：

1. 從表"categories"獲取商品分類條目
2. 根據(jù)每一個(gè)條目的category_id到表"products"中獲取屬于該條目的商品
3. 將類目信息與該類目下的商品打包在一起香到，并返回給請求端（比如瀏覽器）

到目前為止，這個(gè)技術(shù)選型完美地解決了以上2個(gè)問題报破。用戶能在1s之內(nèi)獲取分類商品和推薦商品悠就；修改表"products"中的產(chǎn)品信息會(huì)及時(shí)作用到其它表，比如表"recommends"充易；每張表一一對(duì)應(yīng)了現(xiàn)實(shí)問題的數(shù)據(jù)實(shí)體梗脾，將現(xiàn)實(shí)問題中的邏輯關(guān)系保留下來；每張表的數(shù)據(jù)類型是一致的盹靴，使得分析表中的數(shù)據(jù)變得容易了許多炸茧。除此之外瑞妇，如果未來有新的業(yè)務(wù)需求（比如用戶可以對(duì)每件商品進(jìn)行評(píng)價(jià)），那么我們只需要在原來的Schema中添加新的表（比如新添表"comments"）便能應(yīng)對(duì)這些變化梭冠！

注意：想要獲得以上好處的前提條件是：數(shù)據(jù)庫存儲(chǔ)的數(shù)據(jù)量不多辕狰，以及所有數(shù)據(jù)都在一臺(tái)服務(wù)器上。往往一家企業(yè)在起步階段就滿足了這個(gè)條件妈嘹，因此剛剛起步的企業(yè)經(jīng)常會(huì)使用SQL數(shù)據(jù)庫系統(tǒng)來搭建數(shù)據(jù)服務(wù)柳琢。使用SQL數(shù)據(jù)庫不僅能應(yīng)對(duì)業(yè)務(wù)變化绍妨，而且只需要管理一臺(tái)服務(wù)器润脸，消除了運(yùn)維的負(fù)擔(dān)。除此之外他去，開發(fā)者能很快上手SQL數(shù)據(jù)庫系統(tǒng)毙驯，對(duì)應(yīng)的學(xué)習(xí)資料也遍布網(wǎng)絡(luò)，遇到問題也能及時(shí)得到社區(qū)反饋灾测！開發(fā)者只需要根據(jù)問題來定義表爆价，然后未來需要獲取某些數(shù)據(jù)時(shí)跪但，則只需要借助SQL語句來整合多張表的數(shù)據(jù)渺氧。這種模式的特征是：先根據(jù)存儲(chǔ)來數(shù)據(jù)建模泡仗，未來需要數(shù)據(jù)時(shí)甸各，再通過SQL語句進(jìn)行整合浸锨。SQL中這種基于存儲(chǔ)優(yōu)化的設(shè)計(jì)理念顯然不符合計(jì)算優(yōu)化的應(yīng)用場景欣尼，尤其是當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)變多時(shí)（比如超過100TBs）率碾。

數(shù)據(jù)變多將引發(fā)一個(gè)致命的問題：查詢時(shí)間變長了矩动。假設(shè)等限，每一張表均有10億行數(shù)據(jù)爸吮，那么對(duì)于處理獲取某個(gè)用戶的推薦列表的請求的問題，則需要查詢3張表望门，它們分別是："users"形娇，"recommends"，"products"筹误，每張表的查詢時(shí)間隨著數(shù)據(jù)量的增多而變長桐早，最終導(dǎo)致相同的查詢語句，其執(zhí)行過程所需的時(shí)間是不穩(wěn)定的厨剪。如果你的業(yè)務(wù)場景要求隨著數(shù)據(jù)量增多依然需要提供穩(wěn)定的查詢性能哄酝，那么這種基于SQL數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)服務(wù)顯然不是一個(gè)可行的解決方案。為了解決這個(gè)問題丽惶，一個(gè)可行的思路是：將龐大的數(shù)據(jù)進(jìn)行分區(qū)炫七，并將相關(guān)聯(lián)的數(shù)據(jù)放在一起，位于同一臺(tái)服務(wù)器上钾唬，然后根據(jù)請求的信息直接到那臺(tái)服務(wù)器上獲取數(shù)據(jù)万哪。實(shí)現(xiàn)這種思路的數(shù)據(jù)庫系統(tǒng)就是NoSQL侠驯，它要求開發(fā)者提前想好查詢數(shù)據(jù)的模式，并找到關(guān)聯(lián)數(shù)據(jù)奕巍。接下來吟策，讓我們看看如何使用NoSQL數(shù)據(jù)庫系統(tǒng)來解決我們的問題。

使用NoSQL數(shù)據(jù)庫系統(tǒng)之前需要認(rèn)真考慮業(yè)務(wù)問題所涉及的數(shù)據(jù)查詢和存儲(chǔ)模式的止。假設(shè)檩坚，我們使用MongoDB數(shù)據(jù)庫，所面對(duì)的數(shù)據(jù)量是100TBs以上诅福，數(shù)據(jù)模型依然如圖 1.4所示匾委。為了保持?jǐn)?shù)據(jù)讀寫性能，則需要設(shè)計(jì)一種方法氓润，讓關(guān)聯(lián)的數(shù)據(jù)集中在一起赂乐，并且每一個(gè)關(guān)聯(lián)的數(shù)據(jù)集 均勻分布 在不同的服務(wù)器上。接下來咖气，讓我們基于遇到的問題來體現(xiàn)這種設(shè)計(jì)思路挨措。

下面是從問題中提煉出來的數(shù)據(jù)存取模式：

1. 獲取某個(gè)用戶的推薦列表
2. 獲取某個(gè)類目下的所有商品
3. 添加一件商品
4. 添加一個(gè)商品分類
5. 向某個(gè)用戶添加一個(gè)推薦

為了存儲(chǔ)用戶，商品崩溪，商品分類以及推薦信息浅役，則需要在MongoDB中創(chuàng)建一個(gè)collection，所有的實(shí)體信息均存儲(chǔ)在這個(gè)collection里伶唯，這一點(diǎn)與SQL的做法（通過4張表來分別存儲(chǔ)）不一樣觉既。為了讓某類實(shí)體（比如用戶）均勻分布在不同的服務(wù)器上，那么我們需要根據(jù)一個(gè)隨機(jī)的字段（比如用戶的user_id）來實(shí)現(xiàn)抵怎。為了讓相關(guān)數(shù)據(jù)（比如某個(gè)用戶的推薦列表）集中在一起奋救，則需要使用一個(gè)字段（比如所有推薦的商品都包含了相同的user_id）來將關(guān)聯(lián)的數(shù)據(jù)集中在一起》刺瑁基于這些規(guī)則尝艘，我們很快能得到以下數(shù)據(jù)分布的collection。

image

通過上圖可知姿染，每一條數(shù)據(jù)均通過一個(gè)document來記錄背亥，比如用戶名為"slzheng"的用戶為user document。Node1和Node2分別是2臺(tái)服務(wù)器悬赏，category為book的document與product id為110和247的document連續(xù)存儲(chǔ)于Node2的磁盤上狡汉，這是由shard_key和sort_key來決定的。為了一次性返回推薦商品列表闽颇，我們在recommend document里內(nèi)置了product信息盾戴，這違背了SQL的第二范式原則，但是換來了更好的查詢性能兵多。有了這些基礎(chǔ)尖啡，瀏覽器查詢這些數(shù)據(jù)的具體過程如下：

1. 瀏覽器準(zhǔn)備查詢條件：比如user_id=123橄仆，前4個(gè)商品分類，將這些信息發(fā)送到數(shù)據(jù)中心
2. 分解器將這個(gè)查詢條件分解成2個(gè)請求：user_id=123和前4個(gè)商品分類衅斩，并分別發(fā)送到Node1和Node2
3. Node1和Node2將結(jié)果返回盆顾，由分解器將分類商品和推薦商品組合在一起，最終返回給瀏覽器

注意:分解器實(shí)際上是運(yùn)行在數(shù)據(jù)中心的服務(wù)器（如下圖所示）畏梆，上面運(yùn)行的應(yīng)用主要是分解來自瀏覽器的請求您宪。通過這種辦法，瀏覽器的響應(yīng)延時(shí)最終由Node1和Node2中最遲返回的節(jié)點(diǎn)決定（如下圖所示）奠涌。

image

引入MongoDB能解決存取數(shù)據(jù)的性能問題宪巨，這是因?yàn)槲覀冎罃?shù)據(jù)存取的模式，并根據(jù)這些存取模式來設(shè)計(jì)數(shù)據(jù)庫的關(guān)鍵字以及數(shù)據(jù)的關(guān)聯(lián)性铣猩。這種方式最終會(huì)將所有關(guān)聯(lián)的數(shù)據(jù)集中在一起揖铜，以便一次性獲取。而使用SQL數(shù)據(jù)庫則不需要提前想好這些關(guān)鍵字达皿，不需要知道數(shù)據(jù)的關(guān)聯(lián)性，只需要定義實(shí)體贿肩，以后需要某些關(guān)聯(lián)的數(shù)據(jù)時(shí)則只需要執(zhí)行SQL語句來獲取峦椰。

當(dāng)然，為了使用MongoDB或者SQL數(shù)據(jù)庫汰规，依然需要很多有經(jīng)驗(yàn)的人員投入汤功，他們一方面要根據(jù)業(yè)務(wù)場景構(gòu)思數(shù)據(jù)存取模式，另外一方面還得安裝溜哮，部署滔金，集群MongoDB節(jié)點(diǎn)。這些與業(yè)務(wù)無關(guān)的運(yùn)維工作將消耗公司部分資源茂嗓，因此為了擺脫這種運(yùn)維上的限制AWS推出了DynamoDB服務(wù)餐茵。

最后，讓我們看看 使用DynamoDB 的情況述吸。與MongoDB類似忿族，DynamoDB能夠處理大量數(shù)據(jù)的同時(shí)輸出穩(wěn)定的數(shù)據(jù)存取性能，不同的是蝌矛，DynamoDB的安裝道批，部署以及集群完全由AWS來負(fù)責(zé)。作為開發(fā)者入撒，你要做的只需要根據(jù)業(yè)務(wù)場景來設(shè)計(jì)數(shù)據(jù)庫隆豹，以及根據(jù)業(yè)務(wù)的流量來啟動(dòng)對(duì)應(yīng)的讀寫能力！由于使用DynamoDB設(shè)計(jì)數(shù)據(jù)庫的思路類似于之前的MongoDB所做的設(shè)計(jì)茅逮，因此這里省略詳細(xì)的設(shè)計(jì)過程璃赡。更多關(guān)于DynamoDB的設(shè)計(jì)原則將在后續(xù)章節(jié)中陸陸續(xù)續(xù)展開簿煌。

1.4 選擇NoSQL還是SQL？

上節(jié)內(nèi)容分別使用了3種數(shù)據(jù)庫（MySQL鉴吹，MongoDB姨伟，DynamoDB）來解決我們面臨的問題，每一種方法都有其優(yōu)點(diǎn)和缺點(diǎn)豆励，以及對(duì)應(yīng)的應(yīng)用場景夺荒。下面，讓我們根據(jù)一些條件來判斷什么時(shí)候應(yīng)該用MySQL良蒸，什么時(shí)候應(yīng)該用MongoDB技扼，什么時(shí)候應(yīng)該用DynamoDB？這些數(shù)據(jù)庫有時(shí)甚至需要結(jié)合在一起解決不同的問題嫩痰。

如果以下任一條件滿足剿吻，則可以考慮使用MySQL或者其它SQL數(shù)據(jù)庫：

• 處理OLAP類型的業(yè)務(wù)問題
• 對(duì)于業(yè)務(wù)不熟悉，數(shù)據(jù)量不大的場景
• 對(duì)查詢存取性能沒有要求的應(yīng)用場景
• 多個(gè)本地應(yīng)用交換數(shù)據(jù)的場景

如果以下條件同時(shí)滿足串纺，則可以考慮使用DynamoDB數(shù)據(jù)庫：

• 處理OLTP類型的業(yè)務(wù)問題
• 要求高性能的數(shù)據(jù)存取能力
• 無須運(yùn)維
• 要求對(duì)數(shù)據(jù)加密
• 企業(yè)擁有清晰的業(yè)務(wù)模式丽旅，而且正在快速增長

如果以下條件同時(shí)滿足，則可以考慮使用MongoDB：

• 處理OLTP類型的業(yè)務(wù)問題
• 需要開源的且高性能的數(shù)據(jù)庫系統(tǒng)纺棺，以便未來能根據(jù)業(yè)務(wù)場景來修改數(shù)據(jù)庫
• 需要在自己的數(shù)據(jù)中心搭建MongoDB集群
• 擁有一批擅長MongoDB的專業(yè)人才和運(yùn)維人才

對(duì)于有清晰業(yè)務(wù)模式的企業(yè)榄笙，以及能夠預(yù)計(jì)到其業(yè)務(wù)模式將會(huì)帶來大規(guī)模的用戶，那么這類企業(yè)應(yīng)該考慮使用DynamoDB作為其數(shù)據(jù)服務(wù)的技術(shù)支持祷蝌。要想使DynamoDB助力企業(yè)發(fā)展茅撞，則還需了解如何正確使用DynamoDB，這部分的內(nèi)容將在下一節(jié)展開巨朦。

對(duì)于需要了解DynamoDB基礎(chǔ)知識(shí)的讀者米丘，可以到DynamoDB學(xué)習(xí)指南。那里包含了大量關(guān)于DynamoDB的基礎(chǔ)知識(shí)糊啡，它們從最基本的概念講起拄查，什么是DynamoDB；如何在本地電腦上安裝一個(gè)DynamoDB悔橄，以便讀者能在本地實(shí)踐靶累。緊接著，介紹了關(guān)于單項(xiàng)數(shù)據(jù)以及多項(xiàng)數(shù)據(jù)的操作癣疟，這些操作有DeleteItem挣柬，UpdateItem，PutItem睛挚，Query和Scan邪蛔。在這個(gè)過程中還應(yīng)用了條件表達(dá)式，比如Filter表達(dá)式扎狱。除了一些基礎(chǔ)知識(shí)之外侧到，還包括一些有用的例子勃教，比如如何在DynamoDB中表示層級(jí)結(jié)構(gòu)的數(shù)據(jù)，如何在DynamoDB中實(shí)現(xiàn)一個(gè)冠軍榜來展示Top 3的數(shù)據(jù)匠抗。