>> [音樂播放]
RICK霍利漢：好吧。
嗨，大家好。
我的名字是里克霍利漢。
我是一名高級主管 解決方案架構師，AWS。
我注重的NoSQL和 DynamoDB技術。
今天我在這裡談 你對那些一點點。
>> 我的背景是 主要是在數據層。
我花了一半的發展 職業生涯編寫數據庫，
數據訪問，溶液 用於各種應用。
我一直在雲計算的虛擬化 了約20年。
所以在雲計算是雲計算， 我們習慣稱之為效用計算。
並且想法，它像 PG＆E公司，你付出你用什麼。
今天，我們把它叫做雲計算。
>> 但這些年來，我一直在 一對夫婦的公司
你可能從來沒有聽說過。
但我已經編制技術列表 成就，我猜你會說。
我有8項專利中的雲系統 虛擬化，微處理器設計，
複雜事件處理， 和其他領域。
>> 因此，這些天，我主要關注的NoSQL 技術和下一代
數據庫。
而這一般是什麼我要去 今天在這裡和你談論。
所以，你可以期待什麼 從本次會議，
我們將通過一個簡短的 數據處理的歷史。
它總是有幫助的 了解我們來自哪裡
為什麼我們是我們在哪裡。
我們將談一點 關於NoSQL的技術位
從基本面的角度來看。
>> 我們將進入一些 在DynamoDB內部。
DynamoDB是AWS的沒有味道。
這是一個全面的管理和 託管的NoSQL解決方案。
我們將談論表一點點 結構，應用程序接口，數據類型，索引
和一些的內部的 那DynamoDB技術。
我們將進入一些設計 模式和最佳實踐。
我們將談論如何 使用這種技術對一些
當今的應用程序。
然後我們將討論一點點 關於進化或出現
在規劃一個新範例 所謂的事件驅動應用程序
和DynamoDB在如何發揮為好。
我們將離開你的一點點 一個參考架構的討論
所以我們可以談一些 該方法可以使用​​DynamoDB。
>> 所以，首先off--這是個問題 我聽到了很多的，什麼是數據庫。
很多人認為他們 知道數據庫是什麼。
如果谷歌，你會看到這一點。
這是一個數據的持有結構化集合 在計算機中，特別是那種
是以各種方式進行訪問。
我想這是一個很好的 定義一個現代化的數據庫。
但我不喜歡它，因為 這意味著兩件事情。
這意味著結構。
而這意味著，它是在計算機上。
和數據庫沒有 總的計算機上存在。
數據庫確實存在在許多方面。
>> 一個如此美好的定義 數據庫是這樣的。
數據庫是一個有組織的 機制，用於存儲，管理，
和檢索信息。
這是從About.com。
所以，我喜歡這個，因為它確實會談 有關數據庫是一個存儲庫，
一庫 信息，不一定
一些坐在一台電腦上。
縱觀歷史，我們 並不總是有電腦。
>> 現在，如果我問的平均 開發商現在有什麼
一個數據庫，這是我得到的答案。
某處我可以堅持的東西。
對？
而且這是真的。
但很不幸。
因為數據庫是真的 現代的應用程序的基礎。
這是基礎 每一個應用程序。
以及如何構建 數據庫，如何構建
該數據是要規定如何那 當你擴展的應用程序執行。
>> 所以很多今天我的工作 正在處理什麼
發生在開發商 採取這種方法
和善後處理 的應用程序的那個
現在擴展超出了原有的 意圖和患糟糕的設計。
所以希望當你 今天走開，你會
有一對夫婦的工具 你的腰帶，留住你
作出這些同樣的錯誤。
好吧。
所以，讓我們來談談一點點 數據庫技術的時間軸。
我想，我讀了 文章不是很久以前
了，說什麼的lines-- 這是一個非常詩意的語句。
它說歷史 數據的處理是
滿高的水印 數據豐富。
好。
現在，我想這是種真實的。
但事實上，我考慮的是作為 歷史上竟湧起
數據壓力的高水位。
由於數據速率 食入不降。
它僅上升。
>> 創新發生在 我們看到的數據壓力，這
是數據的是量 現在在進入系統。
並且它不能被處理 有效地無論是在時間或成本。
而當我們開始的 看數據的壓力。
>> 所以，當我們在看 第一個數據庫，這
是的，這就是一個我們的耳朵之間。
我們都出生吧。
這是一個不錯的數據庫。
它具有高可用性。
它總是上。
你總是可以得到它。
>> 但它的單個用戶。
我不能和你分享我的想法。
你不能讓我的思緒 當你想要他們。
而他們的abilitiy也不是那麼好。
我們忘事。
時不時地，我們的一員葉 並移動到另一個存在
我們失去了一切 這是在該數據庫中。
所以，這不是所有的好。
>> 而這種行之有效隨著時間的推移 當我們回到了一天
當我們真正需要知道的是， 我們去哪兒去明天
或者我們收集的最佳食品。
但是，當我們開始成長為一個 文明與政府開始
就應運而生，並 企業開始演變，
我們開始意識到我們 需要比多一點什麼
我們可以把我們的頭。
好吧？
>> 我們需要記錄系統。
我們需要的地方能夠存儲數據。
因此，我們開始起草文件， 建立圖書館和檔案館。
我們開始開發 系統中的總賬會計。
而總賬計數該系統 跑了世界上許多世紀以來，
甚至可能數千年的 我們種增長到如此地步
其中，該數據負載超過 這些系統的能力
要能包含它。
>> 而這實際上是發生在19世紀80年代。
對？
在1880年美國人口普查。
這是真的，其中的轉折 指向現代數據處理。
這是在點 數據的所述量
當時正在收集由 美國政府到了點
它歷時八年來處理。
>> 現在，八years--作為 你知道，普查
每隔10 years--所以它的 很明顯，按時間，我們
拿到了1890年的人口普查， 的數據量即
將要被處理的 政府是
要超過10年，它 將採取推出新的人口普查。
這是一個問題。
>> 所以，一個人叫赫爾曼 霍爾瑞斯來了
他發明了單位記錄打卡 卡，打孔卡讀卡器，打卡
製表，並整理 該機制這一技術。
而且，他形成於該公司 時間，連同其他幾個，
居然成了一個支柱之一 小公司，我們今天所知道所謂的IBM。
>> 因此，IBM最初是在 該數據庫業務。
而這也確實是他們做到了。
他們做數據處理。
>> 既然這麼衝的擴散 卡，一個巧妙的機制
對能夠利用該 技術查詢排序結果集。
您可以在這張圖片看到 在那裡，我們有一個little--
這是一個有點small--但你可以看到 一個非常巧妙的機械裝置
我們有一個打卡甲板。
而別人的回吐 一個小螺絲刀
並通過粘 插槽和提升起來
拿到那場比賽，那 排序的結果集。
>> 這是一個聚集。
我們做這一切的時候 今天在計算機中，
在這裡你在數據庫中做到這一點。
我們用手工做的，對不對？
人們把這些東西放在一起。
而正是這氾濫 這些穿孔卡片
到此謂數據鼓 和數據捲軸，紙帶。
>> 數據處理產業佔 從玩家鋼琴一節課。
玩家鋼琴回 世紀之交
以前用紙捲用槽 就告訴它播放的按鍵。
因此，該技術被改編 最終存儲數字數據，
因為他們可以把這些數據 到那些紙膠帶捲軸。
>> 現在，作為其結果，數據 被actually--如何
您訪問這些數據是直接 取決於你如何保存它。
所以，如果我把數據在磁帶上， 我有線性訪問數據。
我不得不推出全 磁帶訪問所有的數據。
如果我把數據衝 卡，我可以訪問它
中多了幾分隨意 時尚，也許還不如快。
>> 但也有如何的限制，我們 訪問基於如何被存儲的數據。
所以這是一個問題 進入上世紀50年代。
同樣，我們可以開始看到，作為我們 開發新技術來處理
數據吧，它打開了 門新的解決方案，
對於新方案，新 應用這些數據。
真的，治理 可能是原因
為什麼我們開發了一些系統。
但企業迅速成為 進化背後的驅動程序
現代數據庫和 現代文件系統。
>> 所以，接下來的事情， 想出了在上世紀50年代
是文件系統和 發展的隨機存取存儲器。
這是美麗的。
現在，所有的突發性，我們可以把我們的 文件的任何地方對這些硬盤
我們可以隨意訪問這些數據。
我們可以分析 信息出來的文件。
我們解決了世界上所有的 問題的數據處理。
>> 而這持續了大約20或 30年，直到演變
關係數據庫，其中的 是當世決定，我們現在
需要有失敗的存儲庫 數據在文件中的蔓延
我們已經建立的系統。對？
分佈在太多太多的數據 的地方，重複刪除的數據，
和儲存的成本是巨大的。
>> 在上世紀70年代，最昂貴的資源 該計算機具有被存儲。
該處理器是 看作是一個固定的成本。
當我買了盒， 該CPU做一些工作。
這將是紡是否 它的實際工作或沒有。
這的確是一個沉沒成本。
>> 但是，花了我作為一個 企業是存儲。
如果我要購買更多的磁盤旁邊 一個月，這是我付出真正的代價。
和該存儲是昂貴的。
>> 現在我們快進40年 我們有一個不同的問題。
該計算是現在 最昂貴的資源。
存儲很便宜。
我的意思是，我們可以去任何地方的 雲，我們可以找到便宜的存儲。
但我不能找到便宜的計算。
>> 所以今天的演變 數據庫技術的技術，
真是重點圍​​繞 分佈式數據庫
不患 同類型規模
關係數據庫的局限性。
我們將談論一點點 什麼實際意義。
>> 但其原因之一，並 this--我們後面的司機
談到數據的壓力。
數據壓力是什麼 驅動創新。
而如果你過 過去五年中，
這是一個圖表的什麼數據 在整個企業一般負載
看起來在過去的五年。
>> 而一般的經驗法則 這些days--如果你去Google--
是90％以上的數據的 我們今天存儲，這是
在過去兩年內產生。
好。
現在，這是不是一個趨勢，這是新的。
這是一個已經有趨勢 走出去100年。
自從赫爾曼·霍爾瑞斯 開發了打卡，
我們已經建立數據倉庫 並收集數據以驚人的速度。
>> 因此，在過去的100年裡， 我們已經看到了這一趨勢。
這是不會改變的。
展望未來，我們將看到 此，如果不是加速的趨勢。
你可以看到是什麼樣子。
>> 如果在2010年的業務有一個 在管理數據的TB級，
今天，這意味著他們 管理數據的6.5千兆字節。
這就是6500倍的數據。
我知道這一點。
我每天都在與這些企業的合作。
五年前，我 會跟公司
誰也和我談什麼是痛苦 它是管理TB的數據。
他們會聊 給我介紹我們如何看待
這很可能會 是一個PB的兩
在幾年。
>> 這些公司 今天我帶會議，
而且他們跟我談了 問題是有其管理
幾十，20 PB的數據。
這樣的爆炸 在行業數據
正推動著巨大 需要更好的解決方案。
和關係數據庫是 只是不辜負需求。
>> 所以有一個線性 數據壓力之間的相關性
和技術創新。
歷史告訴我們 此，隨著時間的推移，
每當數據量 需要被處理
超過系統的容量 處理它在合理的時間
或以合理的成本， 那麼新技術
被發明，以解決這些問題。
這些新技術， 反過來，開門
到另一組的問題，這 正在收集更多的數據。
>> 現在，我們不是要阻止這一切。
對？
我們不是要阻止這一切。
為什麼？
因為你不可能什麼都知道 有知道的宇宙。
而只要我們還活著， 在整個人類歷史上，
我們一直推動知道更多。
>> 因此，它似乎是我們把每一寸 向下科學發現之路，
我們相乘的數據量 我們需要成倍處理
因為我們發現越來越多的多 生活的內部運作，
關於宇宙是如何工作的，約 推動科學發現，
並且本發明那 我們正在做的今天。
的數據量只是 不斷增加。
所以能夠應對 這個問題是巨大的。
>> 所以的事情之一 我們來看看作為NoSQL的原因？
怎樣的NoSQL解決這個問題？
好了，關係型數據庫， 結構化查詢語言，
SQL--這是真正的一個結構 關係型數據庫 - 這些東西都是
對存儲進行優化。
>> 早在上世紀70年代，同樣， 磁盤是昂貴的。
存儲的提供鍛煉 在企業中是永無止境的。
我知道。
我住吧。
我寫的存儲驅動程序的 enterprised超級服務器公司
早在20世紀90年代。
而底線是費盡另一 存儲陣列只是一些
每天都在發生企業。
它從來沒有停止過。
高密度的存儲需求 對於高密度存儲，
和更有效的存儲 devices--它從來沒有停止過。
>> 和NoSQL是一項偉大的技術 因為它標準化的數據。
它進行重複數據刪除的數據。
它把數據的結構 是不可知的每一個訪問模式。
多個應用程序可以打的 SQL數據庫，運行即席查詢，
並獲得形狀數據，他們 需要處理的工作負載。
這聽起來太棒了。
但底線是與任何 系統，如果它是不可知的一切，
它是優化了什麼。
好不好？
>> 這就是我們用得到 的關係數據庫。
這對存儲進行優化。
這是標準化的。
它的關係。
它支持即席查詢。
而且它和它垂直縮放。
>> 如果我需要一個更大的SQL數據庫 或更強大的SQL數據庫，
我去買一個更大的一塊鐵。
好不好？
我曾與很多客戶合作 對已通過重大升級
在他們的SQL基礎設施只 找到了6個月後，
他們再次碰壁。
而從Oracle或MSSQL答案 或其他人是獲得更大的箱子。
那麼早晚，你可以不買 大框，這是真正的問題。
我們需要真正改變的東西。
那麼，這會起作用？
它可以很好地用於離線 分析，OLAP類型的工作負載。
這是真正的地方SQL所屬。
現在，它今天使用的許多網上 事務處理型
應用程序。
和它的作品只是罰款 利用某種程度的，
但它不能按比例 是的NoSQL的方式做。
我們將談一點 為什麼這是位。
>> 現在，NoSQL的，另一方面， 為計算更加優化。
好不好？
它不是不可知 訪問模式。
就是我們所說的反規範化 結構或分層結構。
在關係數據庫中的數據是 從多個表連接在一起
產生你所需要的視圖。
在一個的NoSQL數據庫中的數據 存儲在文檔
包含的層次結構。
的所有數據的那些通常是 連接在一起來產生視圖
存儲在一個單一的文件。
我們將談論一點點 如何在一對夫婦圖表的作品。
>> 但這裡的想法是，你存儲 你的數據，因為這些實例化的看法。
好不好？
你進行水平擴展。
對？
如果我需要增加 我的NoSQL簇的大小，
我並不需要獲得一個更大的框。
我得到另一個盒子。
而我那些聚集在一起， 我可以分片數據。
我們要談點 分片是什麼，是
能夠擴展該數據庫 在多個物理設備
並取出屏障 要求我垂直擴展。
>> 因此，它的真正建立在線 事務處理和規模。
有一個很大的區別 在這裡報告的，對不對？
報告，我不知道 我要去問題要問。
對？
Reporting--如果有人從 我的營銷部門
要just--有多少我的客戶 有這種特殊的特性誰
買了這個day--我不知道 什麼查詢他們會問。
所以，我需要無關。
>> 現在，在網上 事務性應用，
我知道是什麼問題，我在問。
我構建的應用程序進行 一個非常具體的工作流程。
好不好？
所以，如果我優化數據 存儲以支持該工作流，
這將更快。
這就是為什麼NoSQL的可 真正加速交付
這些類型的服務。
好吧。
>> 所以，我們要進入 理論一點點在這裡。
而有些人，你的眼睛 可能回退一點點。
但我會盡量保持 為高電平，我可以。
所以，如果你是在項目 管理，有
一個結構稱為 三角形的約束。
好。
的約束決定了三角 你不能擁有一切所有的時間。
不能有你的蛋糕和熊掌兼得。
因此，在項目管理，即三角形 約束條件是，你可以擁有它便宜，
你可以把它速度快， 或者你可以擁有不錯的。
選擇兩種。
因為你不能有三個。
對？
好。
>> 所以你聽到這個有很多。
這是一個三重約束， 三重約束的三角形，
或者鐵三角是oftentimes-- 當你跟項目經理，
他們會談論這個。
現在，數據庫有 自己的鐵三角。
和數據的鐵三角 就是我們所說的CAP定理。
好不好？
>> CAP定理使然 如何數據庫操作
下一個非常特定的條件。
我們將談論 這是什麼狀況。
但是這三個點的三角形， 可以這麼說，是C，一致性。
好不好？
因此，在CAP，一致性意味著所有 誰可以訪問數據庫客戶端
總會有一個非常 數據一致的看法。
沒有人會看到兩種不同的東西。
好不好？
如果我看到的數據庫， 我看到了同樣的觀點
作為我的夥伴誰看到 相同的數據庫。
這是一致性。
>> 狀況意味著如果 數據庫聯機，如果能夠達到，
所有客戶端永遠 能夠讀取和寫入。
好不好？
所以，每一個客戶端 可以讀取數據庫
隨時都可以讀 數據和寫數據。
如果是這樣的話， 它是一個可用的系統。
>> 而第三點是什麼 我們稱之為分區容忍性。
好不好？
分區容忍性手段 該系統運行良好
儘管物理網絡 節點之間的分區。
好不好？
因此，集群中的節點無法 互相交談，會發生什麼？
好吧。
>> 因此，關係數據庫choose-- 你可以選擇其中的兩個。
好。
因此，關係數據庫選擇 要一致，可用。
如果從分區情況 所述的DataNodes在數據存儲，
數據庫崩潰。
對？
它只是下降。
好。
>> 這就是為什麼他們有 成長與大箱子。
對？
因為有no--通常，群集 數據庫，有沒有很多人
該操作的方式。
但是，大多數數據庫規模 垂直在一個盒子。
因為他們需要 一致的和可用的。
如果分區是被注入， 那麼你就必須做出選擇。
你必須做出的選擇 是一致的和可用的。
>> 這就是NoSQL數據庫做。
好吧。
因此，一個NoSQL數據庫，它 有兩種形式。
我們have--好，它 有許多種，
但它有兩個基本 characteristics--什麼
我們所說的CP數據庫，或 一致和分區容忍性
系統。
這些人做出選擇，當 節點失去彼此接觸，
我們不會允許 人寫了。
好不好？
>> 在此之前，分區被刪除， 寫訪問被阻止。
這意味著它們無法使用。
他們是一致的。
當我們看到， 分區自身注入，
我們現在一致， 因為我們不打算
以允許在兩個數據改變 分區獨立地側
的對方。
我們必須 重建通信
任何更新之前， 該數據是允許的。
好不好？
>> 接下來味將是一個AP系統， 或可用，分區
容忍系統。
這些傢伙不關心。
對？
這得到了所有節點 寫，我們要了。
所以我複製我的數據 跨多個節點。
這些節點獲得一個客戶端，客戶端進入 在說，我會寫一些數據。
節點說，沒問題。
節點旁邊的他得到 在相同的記錄寫入，
他會說沒問題。
後面的某個地方在後端， 這些數據是怎麼回事進行複製。
然後誰家去實現， 呃，哦，他們的系統將實現，嗯，哦，
還有的是一個更新兩個方面。
我們做什麼？
而他們做的又是什麼 他們做的一些東西，
使他們能夠解決數據狀態。
我們將談論 即下圖研究。
>> 事情在這裡指出。
而且我不會太 多到這一點，因為這
進入深層數據的理論。
但是，有一個交易 框架
運行在一個關係系統， 可以讓我放心地進行更新
到數據庫中的多個實體。
而會發生這些更新 一次全部或根本沒有。
這就是所謂的ACID事務。
好不好？
>> ACID給了我們原子性，一致性， 隔離性和持久性。
好不好？
這意味著原子，交易，所有的 我的更新要么發生，或者他們不這樣做。
一致性是指 該數據庫將始終
被帶入一個一致 更新後的狀態。
我永遠不會離開的數據庫 應用更新後的狀態不好。
好不好？
>> 所以這是一個有點不同 比CAP的一致性。
CAP一致性意味著所有的 客戶端可以隨時查看數據。
酸一致性意味著當 交易的完成，數據的好。
我的關係都不錯。
我不打算刪除父行 並留下了一堆孤兒的
在一些其他表。
如果我是一致的，不能發生 在酸事務。
>> 隔離是指交易 總會發生一個接一個。
數據的最終結果 將是相同的狀態
彷彿這些交易 這是同時發布
被串行執行。
所以這是並發 控制在數據庫中。
所以基本上，我不能遞增 相同的值兩次，兩次手術。
>> 但如果我說加1，這個值， 而兩筆交易進來
並嘗試做到這一點，一個人的 去到那裡的第一
而另一個的 會後到那裡。
所以，最後，我添加了兩個。
你明白我的意思嗎？
好。
>> 耐用性是非常簡單的。
當交易 是公認的，這是
去那裡連 如果系統崩潰。
當該系統恢復，這 交易的承諾
實際上是要在那裡。
所以這是保證 的ACID事務。
這些都是相當不錯的保證 有上的數據庫，
但他們付出了代價。
對？
>> 因為這個問題 與此框架
如果在該數據的分區 集，我必須做出決定。
我將不得不讓 在一側或其他更新。
如果出現這種情況， 然後，我不再去
要能保持 這些特點。
他們將不相符。
它們不會被分離。
這是它打破了 對於關係數據庫。
這是什麼原因關係 數據庫垂直縮放。
>> 另一方面，我們有 什麼叫做基礎技術。
而這些都是你的NoSQL數據庫。
好吧。
因此，我們有我們的CP，AP數據庫。
而這些都是你所謂的基本 可用軟狀態，最終
是一致的。
好不好？
>> 基本上用的，因為 他們是分區寬容。
他們將永遠是 還有，即使有
節點之間的網絡分區。
如果我可以跟一個節點，我 將能夠讀取數據。
好不好？
我可能並不總是能夠寫 數據，如果我是一個統一的平台。
不過，我就可以讀取數據。
>> 軟狀態指示 當我讀到的數據，
它可能不是相同的其他節點。
如果權利是一個節點上發出 別的地方的集群中
現在也沒有跨越複製 集群然而，當我讀到的數據，
這種狀態可能會不一致。
然而，這將是 最終一致性，
這意味著當一個寫 建立到系統中，
將各個節點進行複製。
而最終，該狀態 將納入秩序，
並且這將是一致的狀態。
>> 現在，CAP定理真 只播放的一個條件。
這條件是當這種情況發生。
因為每當它在工作 正常模式下，沒有分區，
一切的一致和可用。
你只擔心CAP 當我們有這個分區。
因此，這些都是罕見的。
但是，系統如何反應時，這些 發生聽寫系統的是什麼類型的
我們正在處理。
>> 因此，讓我們來看看什麼 這看起來像AP系統。
好不好？
AP系統有兩種形式。
他們進來的味道，是一個 法師，100％，始終可用。
他們進來 其他的味道，它說，
你知道嗎，我會擔心 這個分區的事情
當實際的分區發生。
否則，將是主要的 節點誰去承擔的權利。
好不好？
>> 因此，如果我們像卡桑德拉。
卡桑德拉將是一個主 主人，讓我寫給任何節點。
所以會發生什麼？
所以，我在一個對象 數據庫上存在兩個節點。
讓我們把這個對象S. 因此，我們有狀態S.
我們有一些操作 S上是持續的。
卡桑德拉讓我 寫入多個節點。
所以我們可以說我得到一個 寫為s到兩個節點。
那麼，最終發生的是 我們稱之為分區事件。
可能沒有一個 物理網絡分區。
但由於設計的 該系統的，它的
實際上，一旦分割 因為我得到兩個節點的寫入。
這不是逼著我 通過一個節點寫全。
我正在寫在兩個節點上。
好不好？
>> 所以，現在我有兩個狀態。
好不好？
這是怎麼回事發生 是遲早的事情，
還有的將是一個複製的事件。
還有的將是我們 稱為分區恢復，這
正是這兩個 國一起回來
還有的將是一個算法 在運行數據庫內，
決定該怎麼做。
好不好？
默認情況下，最後更新 勝在大多數AP系統。
所以，通常有一種 默認的算法，是什麼
他們所謂的回調 功能，這東西
將被調用時，這種情況 檢測來執行一些邏輯
解決這一矛盾。
好不好？
默認的回調和默認 解析器在大多數AP數據庫
是，你猜怎麼著，時間戳獲勝。
這是最後更新。
我打算把該更新在那裡。
我可以轉儲這個紀錄，我 傾倒出來，放入恢復日誌
這樣，用戶可以稍後再回來 並說，哎，有一個​​碰撞。
發生了什麼？
而實際上你可以轉儲紀錄 所有的衝突和回滾
看看會發生什麼。
>> 現在，作為一個用戶，你也可以 包括邏輯到該回調。
所以，你可以更改 回調操作。
你可以說，嘿，我想 要補救此​​數據。
我想嘗試 合併這兩個記錄。
但是，這取決於你。
該數據庫不知道如何 這樣做，默認情況下。大部分時間，
唯一的數據庫 知道如何做的是說，
這一次是最後一個記錄。
這是一個的要贏， 這就是價值，我打算把。
一旦分區恢復 和複製時，
我們有我們的狀態， 現在的黃金，這是
所有這些對象的合併狀態。
所以AP系統都沒有了。
CP系統不需要 擔心這一點。
因為一旦一個分區來 發揮作用，他們只是停止服用
寫道。
好不好？
所以這是很容易 處理是一致的
當你不接受任何更新。
這是與CP系統一樣。
好吧。
>> 因此，讓我們談一點 關於訪問模式位。
當我們談論的NoSQL，這是 所有關於訪問模式。
現在，SQL是臨時性的，查詢。
這是關係存儲。
我們不必擔心 關於訪問模式。
我寫了一個非常複雜的查詢。
它去和獲取數據。
這就是這個樣子 像，規範化。
>> 因此，在這個特定的結構中， 我們正在尋找一個產品目錄。
我有不同類型的產品。
我有書。
我的專輯。
我有錄像。
產品之間的關係 和這些書，相冊中任一項
和視頻表是1：1。
好吧？
我有一個產品ID， 該ID對應
到一本書，一張專輯，或視頻。
好不好？
這是一個1：1的關係 跨越這些表。
>> 現在，books--他們所 已經是根的屬性。
沒問題。
那很棒。
一比一的關係，我得到的所有 數據我需要來形容這本書。
Albums--專輯有軌道。
這就是我們所說的一對多。
每一張專輯可以有許多曲目。
因此，對於每個軌道上 這張專輯，我可以有
在此子表再創歷史新高。
所以，我創建了一個記錄 在我的相冊表。
我創建了多個記錄 在磁跡的表。
一個一對多的關係。
>> 這種關係是什麼 我們稱之為多到很多。
好不好？
你看，演員可能是 在許多電影，許多影片。
所以我們要做的就是，我們把這個映射 這間表，它只是
映射演員ID到視頻ID。
現在，我可以創建一個查詢聯接 通過演員的視頻演員的影片，
它給了我一個很好的列表 所有的電影和所有演員
誰在那部電影。
>> 好。
所以在這裡我們去。
一對一的是頂層 關係; 1對多，
專輯曲目;多對許多。
這些是三個頂級 在任何數據庫之間的關係。
如果你知道如何將這些 關係共同努力，
那麼你知道了很多 有關數據庫了。
所以NoSQL的工作原理有點不同。
讓我們想想一秒鐘是什麼 看起來像去讓我所有的產品。
>> 在關係店裡，我 想要得到我的所有產品
對所有我的產品清單。
這是一個很大的查詢。
我得到了我所有的書的查詢。
我從我的專輯的查詢。
而我得到了我所有的影片的查詢。
我得把它 一起以列表
全心全意它備份到 應用程序正在請求它。
>> 為了得到我的書，我加盟 產品和書籍。
為了讓我的專輯，我得到了加盟 產品，專輯，和跟踪。
而讓我的影片，我有 加入產品以視頻，
參加過演員影片， 並帶來了演員。
所以，這三個查詢。
非常複雜的查詢到 組裝一個結果集。
>> 這是不理想。
這就是為什麼當我們談論 有關的數據結構那
建要不可知的訪問 pattern--好這是偉大的。
而且你可以看到這是真的 漂亮的我們如何組織數據。
你知道嗎？
我只有一個記錄一個演員。
>> 這很酷。
我重複數據刪除所有的演員， 我保持我的協會
在這個映射表。
然而，獲取數據 出變得昂貴。
我送了CPU遍布系統 加入這些數據結構一起
能夠拉該回數據。
>> 那麼，如何解決呢？
在NoSQL的它是關於 聚集，不歸。
因此，我們希望說，我們要 支持訪問模式。
當訪問模式 該應用程序，
我需要讓我的所有產品。
讓我們把所有的產品在一個表中。
如果我把所有的產品在一個表中， 我可以選擇所有產品
從該表中，我得到這一切。
那麼怎麼辦呢？
那麼在NoSQL的有沒有 結構的表。
我們將談論一點點 這是如何工作的迪納摩DB。
但你不必相同 屬性和相同屬性
在每一個單排，在每一個 項目，就像你在一個SQL表做。
而這是什麼可以讓我 做了很多的事情
並給我一個很大的靈活性。
在這種特殊情況下，我 有我的產品文檔。
並在這個特定 例如，一切
在產品表的文檔。
而該產品的一本書可能 有一個類型ID，指定一本書。
和應用程序 將交換機上的ID。
>> 在應用層，我要去 要說哦，什麼記錄類型是什麼？
哦，這是一本記錄。
書中記載有這些屬性。
讓我創建一本書的對象。
所以，我要補 本書的對象與此項目。
下一個項目來了， 說，這是什麼項目？
嗯，這項目是一個專輯。
呵呵，我得到了一個完全不同的 對於處理程序，
因為它是一個專輯。
你明白我的意思嗎？
>> 因此，應用程序tier--我 只需選擇所有這些記錄。
他們都開始進入。
他們可以是各種不同類型。
而且它的應用程序的邏輯 跨越這些類型的交換機
並決定如何處理它們。
>> 再次，所以我們優化 架構的訪問模式。
我們正在做它用 折疊這些表。
我們基本上採取 這些標準化結構，
我們正在建設 分層結構。
裡面的這些記錄每一個 我要去看看數組屬性。
>> 本文檔的專輯裡面， 我看到軌道的數組。
這些曲目現在become--它 基本上這孩子表
存在這裡在這種結構。
所以，你可以在DynamoDB做到這一點。
你可以在MongoDB中做到這一點。
您可以在任何NoSQL數據庫做到這一點。
創建這些類型的 分層數據結構
允許您檢索數據 很快，因為現在的我
不必符合。
當我插入一行到曲目 表或一行到相冊表，
我必須符合該模式。
我必須有屬性或 這是該表定義的屬性。
他們每個人， 當我插入該行。
這不是在NoSQL的情況。
>> 我可以有完全不同的 每一個文件的屬性
我插入到集合。
因此，非常強大的機制。
這真是你如何 優化系統。
因為現在該查詢，而不是 在加入所有這些表
並執行半打查詢 給拉了回來，我需要的數據，
我執行一個查詢。
而我遍歷 橫跨設置的結果。
它給你的想法 對NoSQL的權力。
我要去那種橫著走這裡 並且說一下這個問題。
這是比較厚道的 營銷或技術 -
技術的營銷 類型的討論。
但是，要了解是很重要 因為如果我們看一下頂
這裡這個圖， 我們看什麼
就是我們所說的 技術炒作曲線。
而這是什麼意思是 新的東西來發揮作用。
人們認為這是偉大的。
我已經解決了我所有的問題。
>> 這可能是端 一切，將所有的一切。
他們開始使用它。
他們說，這東西不能正常工作。
這是不對的。
舊的東西是更好的。
他們回去做 事情他們的方式。
並最終 他們走了，你知道嗎？
這東西並沒有那麼糟糕。
噢，那是它是如何工作。
一旦他們弄清楚它是如何 作品中，他們開始越來越好。
>> 而關於它的有趣的事情 是，它種行到什麼
我們所說的技術採用曲線。
所以會發生什麼是我們必須 某種技術的觸發。
在數據庫的情況下， 它的數據的壓力。
我們談到了高水點 在整個時間數據的壓力。
當這些數據的壓力達到一定 點，這是一個技術的觸發。
>> 它變得太昂貴了。
它需要很長時間才能處理數據。
我們需要更好的東西。
你得到的創新者 在那裡跑來跑去，
試圖找出解決的辦法。
有什麼新的想法？
>> 什麼是下一個最好的 辦法做這件事情？
他們拿出的東西。
而人與真正的痛苦， 球員在最前沿，
他們會跳一切都結束吧， 因為他們需要一個答案。
現在什麼必然happens--和 它的發生，現在在NoSQL的。
我看到這一切的時候。
>> 什麼必然發生的事情是 人們開始使用新的工具
同樣的方式，他們所使用的舊工具。
他們發現它 不工作這麼好。
我不記得我是誰 談論今天早些時候。
但是，這就像，當 手持式鑿岩機的發明，
人沒盪過來 他們的頭粉碎的混凝土。
>> 但是，這是什麼 與NoSQL的今天發生的事情。
如果你走在大部分商店， 他們正試圖成為NoSQL的商店。
他們在做什麼是 他們使用的NoSQL，
他們正在加載 完整的關係架構。
因為這是怎麼 他們設計的數據庫。
他們想知道，為什麼 它不是表現非常好？
男孩，這個東西很臭。
我必須保持我的所有 加入in--這就像，不，不。
保持連接？
你為什麼要加盟的數據？
你不加入數據的NoSQL。
你可以將它。
>> 所以，如果你想避免這種情況，學習 該工具前，你是如何工作的實際
開始使用它。
不要嘗試使用新工具 您使用的舊工具一樣。
你將有一個不愉快的經歷。
而每一次 那這是怎麼回事。
當我們開始來了這裡， 這是因為人想通了
如何使用工具。
>> 他們也做了同樣的事情時， 關係數據庫被發明，
他們被替換的文件系統。
他們試圖建立文件系統 關係型數據庫
因為這是人的理解。
它沒有工作。
因此，了解最佳實踐 該技術的你正在使用
是巨大的。
很重要。
>> 所以，我們要進入DynamoDB。
DynamoDB是AWS的 全託管的NoSQL平台。
什麼是全管理是什麼意思？
這意味著你不需要 真擔心什麼。
>> 你進來，你告訴 我們，我需要一個表。
它需要這麼多的能力。
你打的按鈕，我們提供 台前幕後的所有基礎設施。
既然是巨大的。
>> 因為當你說話 關於縮放的數據庫，
NoSQL的數據群集在 規模，運行PB級，
運行數百萬 每秒事務數
這些東西都不是小群。
我們所說的數以千計的實例。
管理實例十萬， 即使是虛擬的情況下，
在屁股真正的痛苦。
我的意思是，想想每次 操作系統補丁出來
或數據庫的新版本。
這意味著什麼 你在操作？
這意味著你有1200 需要服務器進行更新。
現在，即使有自動化， 這會花費很長的時間。
這可能會導致大量的 運營頭痛，
因為我可能會服務了。
>> 當我更新這些數據庫，我 可能會做藍綠部署
我的部署和升級一半的 節點，然後再升級的另一半。
把這些下來。
所以，管理基礎設施 規模巨大的痛苦。
而AWS採取痛苦出來。
和NoSQL數據庫可以 是非常痛苦的
由於它們的尺寸的方式。
>> 橫向擴展。
如果你想獲得更大的NoSQL 數據庫，你買更多的節點。
你買的每一個節點 另一運營頭痛。
因此，讓別人為你做的。
AWS可以做到這一點。
>> 我們支持文件鍵值。
現在，我們沒去太多 到另一個圖表上。
有很多的不同 NoSQL的口味。
他們都是那種獲得的 在這一點上被改寫的一起。
你可以看一下DynamoDB和說的話， 我們都是一個文檔和密鑰值
存儲了這一點。
你可以說功能 的一個在另一個之上。
對我來說，有很多這真的是6 二分之一的其他的一打。
這些技術的每一個是一個 FINE技術和罰款的解決方案。
我不會說MongoDB是好還是 不是沙發，然後卡桑德拉糟糕的是，
然後迪納摩，反之亦然。
我的意思是，這些只是選擇。
>> 它速度快，它的 在任何程度上是一致的。
因此，這是一個最大的 獎金你得到AWS。
隨著DynamoDB是一種能力 得到一個低個位數
毫秒的延遲在任何程度。
這是該系統的設計目標。
我們有在做客戶 每秒數百萬的交易。
>> 現在，我會去通過一些那些 在幾分鐘後在這裡使用的情況。
綜合接入control-- 我們有我們所說的
身份訪問管理，或IAM。
它滲透在每一個系統， 每一個服務，AWS提供。
DynamoDB也不例外。
您可以控制​​訪問 到DynamoDB表。
在所有您的AWS賬戶通過 定義訪問角色和權限
在IAM的基礎設施。
>> 它是在一個關鍵和​​不可或缺的組成部分 我們所說的事件驅動編程。
現在，這是一個新的範例。
>> 聽眾：怎麼你的速度真 陽性與假陰性
您的訪問控制系統？
RICK霍利漢：真陽性 與假陰性？
聽眾：返回什麼 你應該回來？
相對於曾經在一段時間它 不返回時，應驗證？
>> RICK霍利漢：我不能告訴你。
如果有任何故障 凡上，
我不是問的人 特定的問題。
但是，這是一個很好的問題。
我會很好奇，想知道 我自己，其實。
>> 所以還是那句話，新範式 是事件驅動編程。
這是想法，你可以 部署複雜的應用程序
可以操作一個非常，非常高檔次 對此不承擔任何基礎設施。
沒有任何固定 基礎設施的任何責任。
我們將討論一點點 關於這意味著什麼，因為我們
坐上去接下來的幾個圖表。
>> 我們要做的第一件事情 是我們將討論表。
API數據類型的發電機。
的第一件事情，你會 當你看到這個通知，
如果你熟悉的任何數據庫， 數據庫有真正兩種的API
我會調用它。
兩套API的。
其中之一是 管理API。
>> 他們照顧的事情 數據庫的功能。
配置存儲引擎， 設置和添加表。
創建數據庫 目錄和實例。
這些things--在DynamoDB，您 有很短，短列表。
>> 因此，在其他的數據庫， 您可能會看到幾十個
對命令的管理， 命令，用於配置
這些附加選項。
在DynamoDB你不需要這些，因為 您不配置該系統，我們做的。
所以，你需要做的唯一事情是 告訴我，我需要什麼尺寸的表。
所以，你得到一個非常 有限的命令集。
>> 你得到一個創建表更新，表， 刪除表，並說明表。
這些都是唯一的東西 你需要DynamoDB。
你並不需要一個存儲 發動機配置。
我並不需要擔心複製。
我不需要擔心分片。
>> 我不需要擔心 任何有關這東西。
我們做這一切為您服務。
所以這是一個龐大的開銷 這只是抬離你的盤子。
然後我們有CRUD操作。
CRUD的東西我們 在數據庫的調用
創建，更新，刪除操作。
這些都是您共同 數據庫操作。
比如像放項目，拿到項目，更新 項目，刪除項目，批量查詢，掃描。
如果要掃描整個表。
拉一切假表。
一個關於DynamoDB的好東西 是它允許並行掃描。
所以，你其實可以讓我知道有多少 要在該掃描運行的線程。
我們可以運行這些線程。
我們可以旋轉的掃描最多 在多個線程
這樣你就可以掃描整個表 空間非常，非常迅速DynamoDB。
>> 其他的API，我們已經是 我們所說的流API。
我們不會說太多 很多關於這個現在。
我有一些內容以後 在關於此的甲板。
但流確實是一個running-- 把它作為時間排序
和分區更改日誌。
一切發生的事情上 該表顯示了向上的流中。
>> 每個寫表 顯示出來的流。
你可以讀到流， 你可以做的事情吧。
我們將談論什麼 類型的東西你
做的事情一樣複製， 創建二級指標。
各種很酷的 事情你可以與事。
>> 數據類型。
在DynamoDB，我們支持關鍵 值和文件數據的類型。
在屏幕的左手側 在這裡，我們有我們的基本類型。
關鍵值類型。
這些都是字符串， 數字和二進制文件。
>> 因此，只要三種基本類型。
然後你就可以擁有集的那些。
的好東西一個關於NoSQL的是 你可以包含數組作為屬性。
並與DynamoDB可以包含數組 基本類型為root屬性。
>> 然後還有的文檔類型。
有多少人熟悉的JSON？
你們熟悉JSON這麼多？
它基本上是JavaScript的， 對象，符號。
它可以讓你基本 限定的分層結構。
>> 您可以存儲一個JSON文件 使用DynamoDB通用組件
或者可構建塊 在大多數編程語言。
所以，如果你有Java中，你 在地圖和列表。
我可以創建對象的區域地圖。
的地圖作為鍵值 存儲為屬性。
以及它可能具有的列表 這些屬性中值。
您可以將這種複雜 層次結構
作為一個單獨的屬性 的DynamoDB項目。
>> 因此，在DynamoDB表中，最喜歡的 NoSQL數據庫，表中有一個項目。
在MongoDB中，你會 調用這些文件。
而這將是沙發​​基地。
另外一個數據庫文件。
你叫這些文檔。
文檔或項目有屬性。
屬性可以存在或 該項目不存在。
在DynamoDB，有 一個強制屬性。
就像在關係數據庫中， 你對表的主鍵。
>> DynamoDB有我們所謂的哈希鍵。
哈希鍵必須是唯一的。
所以，當我定義了一個哈希表， 基本上我在說什麼
是每一個項目都會有一個哈希鍵。
而每一個哈希鍵必須是唯一的。
>> 每個項目的定義 由唯一的哈希鍵。
還有只能有一個。
這是正常的，但通常情況下 人們需要什麼
是他們要的就是這個哈希 關鍵的做多一點點
比僅僅是一個唯一標識。
通常情況下，我們希望使用哈希鍵 作為頂級聚集桶。
而我們做到這一點的方法是 加入我們所說的一系列關鍵。
>> 所以，如果它只是一個哈希 表，這必須是唯一的。
如果它是一個哈希和範圍表中， 散列和範圍的組合
必須是唯一的。
所以，想想這樣的看法。
如果我有一個論壇。
而形式有主題，有 張貼，它有反應。
>> 所以，我可能有一個哈希 關鍵，這是主題ID。
我可能有一個範圍的關鍵， 這是響應標識。
這樣，如果我想獲得的所有 針對特定主題的響應，
我可以查詢的哈希值。
我只能說給我所有 具有此散列的項目。
而且我會得到每一個問題 或發布針對特定主題。
這些頂級聚合 是非常重要的。
它們支持的主要接入 應用程序的模式。
一般說來，本 就是我們想要做的。
我們希望有table-- 當你裝載表，
我們要構造數據 表以這樣的方式內
應用程序可以很 快速檢索這些結果。
而通常情況下做到這一點的方法是 維持這些聚合，因為我們
插入的數據。
基本上，我們將數據分散 成亮鬥，因為它的用武之地。
>> 範圍鍵允許我 - 哈希 密鑰必須平等。
當我查詢哈希，我不得不說 給我一個哈希值，等於這一點。
當我查詢的範圍，我 可以說，給我一個範圍
即使用任何種類的 我們支持豐富的運營商。
給我的所有項目的哈希值。
是它等於，大於， 小於，它首先，
它這兩個值之間存在嗎？
所以這些類型的範圍查詢 我們總是感興趣的
現在有一件事有關數據時， 你看看訪問數據時，
您訪問的數據，它的 總是關於聚合。
它總是對記錄 那些與此有關。
給我這裡的一切that's--所有 在這張信用卡的交易
在過去的一個月。
這是一個聚集。
>> 幾乎所有的東西，你在做 數據庫是某種聚集。
所以能夠能夠定義 這些桶和給你這些範圍
屬性能夠查詢上， 這些豐富的查詢支持很多，
很多很多的應用程序的訪問模式。
>> 所以其他的事情散列鍵 做的是它給了我們一個機制
要能夠圍繞擴展數據。
NoSQL數據庫工作最好 當數據是均勻
分佈在整個群集。
有多少人熟悉 與散列算法？
當我說哈希和hashing-- 因為散列算法
是具有能夠產生一個方式 一個隨機值從任何給定值。
因此，在這種特定的情況下，該 我們運行的hash算法是ND 5為主。
>> 如果我有一個ID，這 是我的散列鍵，我有1，2，3。
當我運行的散列算法， 它要回來說，
還有1等於7B，2 等於48，3等於CD。
他們都在關鍵的空間傳播。
你們為什麼這樣做？
因為這可以確保我能 把跨多個節點的記錄。
>> 如果我這樣做 遞增，1，2，3。
我有一個哈希值範圍 運行在這種特殊情況下，
小散的空間， 從00運行到FF，
然後記錄將要進來 和他們要去1，2，3，4，5，
6，7，8，9，10，11，12。
怎麼了？
每個刀片將相同的節點。
你明白我的意思嗎？
>> 因為當我分裂了空間， 我對面傳播這些記錄，
我的分區，我會說 分區1具有密鑰空間為0〜54。
分區2為55〜89。
分區3是AA到FF。
所以，如果我使用線性遞增 的ID，你可以看到發生了什麼。
1，2，3，4，5，6，所有一直到54。
所以當我錘打 記錄到系統中，
一切都結束了要去一個節點。
>> 這不好。
這是一個反模式。
在MongoDB中，他們有這樣的問題 如果你不使用哈希鍵。
MongoDB的讓您選擇 的散列鍵值。
你應該總是這樣做，如果 你使用的是遞增的散列
在MongoDB中鍵，或者你會 釘每​​寫一個節點，
你將被限制 你寫吞吐量嚴重。
>> 聽眾：那是A9十進制169？
>> RICK霍利亨：是的，這 周圍某處有。
A9，我不知道。
你必須讓我的二進制 十進制計算器。
我的大腦不能這樣的。
聽眾：只需一個快速 你蒙戈的意見。
那麼，自帶的對象ID 與本地蒙戈做到這一點？
RICK霍利漢：是否做到這一點？
如果指定了它。
隨著MongoDB中，您可以選擇。
您可以在specify--每個文檔 MongoDB中必須有一個下劃線標識。
這是獨特的價值。
>> 在MongoDB中，你可以指定 是否哈希與否。
他們只是給你的選項。
如果你知道它的 隨機的，沒有問題。
你不需要這麼做。
如果你知道，這不是隨機的，那 它遞增，然後做的哈希值。
>> 現在的事兒 散列，一旦你哈希
一個value--並且這是 為什麼哈希鍵總是
獨特的查詢，因為我已​​經改變了 值，現在我不能做一個範圍查詢。
我不能說這是 之間的這樣或那樣的，
因為散列值是不會 為等同於實際值。
當你的哈希因此， 關鍵的，它只是平等。
這就是為什麼在DynamoDB散列鍵 查詢是永遠只有平等。
>> 所以，現在在一個範圍內key-- 當我再補充一點範圍的關鍵，
這些範圍內的密鑰記錄所有進來 它們會存儲在同一個分區。
因此，他們都非常迅速，輕鬆地 檢索因為這是散列，
這是的範圍內。
而你看到的一切 具有相同散列
獲取存儲在同一分區的空間。
您可以使用該範圍內的關鍵，以幫助 找到你的數據接近其父母。
那麼，我真的在這裡做什麼？
這是一個一對多的關係。
散列關鍵字之間的關係 和範圍的關鍵是一對多。
我可以有多個哈希鍵。
我只可以有多個範圍 每一個哈希鍵中鍵。
>> 散列定義父， 範圍界定的孩子。
所以，你可以看到有模擬這裡 關係結構之間
與同類型的 構建在NoSQL的。
人們談論 NoSQL的作為非關係。
這不是非關係。
數據總是有關係。
這些關係只是 建模不同。
讓我們來談談一點點 有關耐久性位。
當你寫DynamoDB，寫 總是三通複製。
這意味著我們有三個AZ的。
AZ的是可用性區域。
你可以把可用性 區作為數據中心
數據中心或集合。
這些東西在地理上 相互隔離
在不同的斷裂帶，跨越 不同的電網和洪氾區。
在一個AZ的故障不 要拿下另一個。
它們也與 加上暗光纖。
它支持一個子1 AZS之間毫秒的延遲。
因此，實時數據複製 能夠在多AZS。
>> 而通常情況下多AZ部署 滿足高可用性要求
大多數企業組織。
因此，DynamoDB分佈 跨越三個AZS默認。
我們只是要知道寫 當兩個這三個節點回來
並說，是啊，我知道了。
這是為什麼？
因為在讀取方面，我們是唯一的 想給你的數據回來時，
我們從兩個節點得到它。
>> 如果我複製跨越 三，我從兩個閱讀，
我總是保證 到具有至少一個
這些讀取是 數據的最新副本。
這是什麼使得DynamoDB是一致的。
現在，您可以選擇打開 那些持續讀了。
在這種情況下，我會說， 我只從一個節點讀取。
我不能保證它會 為最新的數據。
>> 因此，如果寫入進來的， 它沒有複製的呢，
你會得到該副本。
這是一個最終一致的讀取。
而那是什麼是成本的一​​半。
因此，這是值得思考的問題。
當你讀出DynamoDB和 你設置你的閱讀能力
單位，如果你選擇最終 持續讀，這是一個很大便宜，
它的大約一半的成本。
>> 因此，這可以節省你的錢。
但是，這是你的選擇。
如果你想有一個一致的讀或 一個最終一致的讀取。
在這個時候，你可以選擇。
>> 讓我們來談談指標。
因此，我們提到， 頂層聚集。
我們有散列鍵，以及 我們有一系列的鍵。
這很好。
而這對主表，我 得到了一個散列鍵，我得到了一個範圍的關鍵。
>> 這意味著什麼？
我有一個屬性，我 可以運行針對豐富的查詢。
它的範圍鍵。
上item--的其他屬性 我可以過濾這些屬性。
但我不能做這樣的事情，它 開始，或大於。
>> 我怎麼做？
我創建一個索引。
有兩種類型的 索引DynamoDB。
索引是真的 表中的另一視圖。
而當地的二級指標。
>> 第一個我們要談論的話題。
因此，當地的次級的共存 在同一個分區中的數據。
正因為如此，它們是上 在相同的物理節點。
他們就是我們所說的是一致的。
含義，它們將確認 隨著表的寫入。
當寫入進來， 我們將通過編寫索引。
我們會寫上去的表， 然後我們會承認。
所以，這是一致的。
一旦寫一直 從表中確認，
它保證了 本地二級索引
將數據的相同的願景。
但是，它們允許你做的是 定義替代的範圍鍵。
>> 必須使用相同的哈希 鍵作為主表，
因為它們共同位於 同一分區，他們是一致的。
不過，我可以創建一個索引 不同範圍的鍵。
因此，舉例來說，如果我有一個製造商 這有一個毛坯件表進入。
而原零件進來， 它們是由組裝聚集。
也許有一個召回。
>> 是由這一點，任何部分 在此日期後生產，
我需要從我行拉。
我可以旋轉索引 這將是好看，
聚集上的日期 生產的特定部分。
所以，如果我的最高水平桌子 已經哈希製造商，
也許是被安排在一部分ID，我 可以創建一個索引關閉該表
散列的製造商和 排列在生產日期。
而這種方式，我可以說，任何 在這些日期間生產，
我需要從線上拉。
所以這是一個當地的二級指標。
>> 這些具有的效果 限制你的散列鍵的空間。
因為它們共存 在相同的存儲節點上，
它們限制了混雜鍵 空間10千兆字節。
DynamoDB，下 表，將分區
你的表每10千兆字節。
當你把10演唱會的數據中，我們 去[PHH]，我們添加另一個節點。
>> 我們不會分開的LSI 在多個分區。
我們將拆表。
但我們不會分開的LSI。
所以這件事情 重要的是了解
就是如果你做的很， 非常，非常大的聚合，
那麼你將被限制 到10千兆字節您的LSI。
>> 如果是這樣的話，我們可以 使用全局二級。
全球次級是 真正另一個表。
它們的存在完全脫落到 主表的一側。
他們讓我找到了 完全不同的結構。
因此認為它是被插入數據 成兩個不同的表，構成
兩種不同的方式。
>> 我可以定義一個完全 不同的哈希鍵。
我可以定義一個完全 不同範圍的關鍵。
我可以運行此 完全獨立。
作為事實上，我已經 置備我讀能力
寫能力為我 全球二級指標
完全獨立 我的主表。
如果我定義的索引，我告訴 它有多大的讀寫
能力它會使用。
>> 並且，它獨立 從我的主表。
現在，這兩個指標可以讓我們 不僅界定哈希和範圍鍵，
但他們讓我們 項目附加值。
所以，如果我想讀出的指數， 我希望得到一些數據集，
我並不需要返回到主 表，以獲得附加的屬性。
我可以投射這些附加 屬性到表
以支持訪問模式。
我知道，我們很可能進入一些 真的，really--漸入雜草
這裡的一些這方面的東西。
現在，我得到漂出了這一點。
>> 聽眾：[聽不清] --table關鍵的意思是一個哈希？
原來的哈希？
多縫？
>> RICK霍利漢：是的。
是。
該表重點基本 指回的項目。
因此，一個索引是一個指針回 原項目在桌子上。
現在你可以選擇建立一個 索引，只有具有表鍵，
並沒有其他屬性。
為什麼會這麼做？
好吧，也許我有非常大的項目。
>> 我真的只需要知道which-- 我的訪問模式可能會說，
該項目包含這個屬性？
不需要回報的項目。
我只需要知道 該項目包含它。
所以，你可以建立索引 只有具有表鍵。
>> 但是，這主要是什麼 在數據庫中的索引是。
這對於能夠快速 確定哪些記錄，
哪些行，這 表中的項具有
我正在尋找的屬性。
>> GSIS，所以它們如何工作？
GSIS基本上是異步的。
更新進入表， 表然後異步更新
所有的GSIS的。
這就是為什麼GSIS是 最終一致。
>> 重要的是要注意的是 當你建立GSIS，
你明白你創造 的aggregation--另一個層面
現在讓我們說一個很好的例子 這裡是一個製造商。
我想我可能已經談 醫療設備製造商。
醫療設備製造商 常常有序號的部分。
要插入的部分 髖關節置換所有
對他們一點序列號。
他們可以有百萬， 百萬千萬件
在所有的，他們出貨的設備。
那麼，他們需要在匯總 不同的尺寸，所有的份
在裝配中，所有的 所做的部分
在某一行，所有 附帶的配件
在從某一製造商 在特定日期。
而這些聚合有時 起床到數十億美元。
>> 所以，我的一些工作 這些人誰是痛苦
因為他們正在創建 這些極大的相聚合
在他們的二級指標。
他們可能有一個毛坯件 表來作為唯一的哈希值。
每個部分都有一個唯一的序列號。
我用的序列號作為散列。
這很漂亮。
我的原始數據表被擴展 所有在整個密鑰空間。
我的[？寫 ？] [？攝入？]是真棒。
我採取了很多的數據。
然後，他們所做的事情是他們創造一個GSI。
我說，你知道嗎，我需要看 所有的所有零件的製造商。
好了，突然我 採取十億行，
而他們的東西到 一個節點，因為當
我合計為 製造商ID為亂碼，
和零件號為的範圍內， 那麼所有的突然我
把一個十億分率成什麼樣 這家製造商已交付了我。
>> 這可能會導致很多 對在GSI壓力，
再次，因為我罵一個節點。
我把所有這些 插入到一個節點。
這是一個真正的問題用例。
現在，我得到了一個很好的設計 圖案你如何避免這種情況。
這就是問題之一 我一直工作著。
但會發生什麼，是GSI可能 沒有足夠的寫容量
為能推動所有這些 行到一個節點。
而會發生什麼，然後是 伯，客戶表，
主表將被節流 因為GSI跟不上。
所以，我的插入率 落在主表
我的GSI試圖跟上。
>> 好吧，那麼GSI的，LSI的， 我應該使用哪一個？
LSI公司是一致的。
GSI的是最終一致性。
如果沒關係，我建議使用 GSI，他們更靈活。
LSI的可以模擬為一個GSI。
並且如果在每個散列密鑰的數據大小 您的收藏超過10千兆字節，
那麼你會希望使用 GSI，因為它只是一個硬性限制。
>> 好吧，那麼縮放。
吞吐量迪納摩DB，你 可以提供[聽不清]
吞吐量到表中。
我們已經有客戶 供應60 billion--
在做60個十億的要求，定期 超過一萬個請求運行
每秒在餐桌上。
確實沒有 理論極限多少
以及如何快速表 可以迪納摩DB運行。
還有一些軟 在您的帳戶限額
我們擺在那裡讓 你不發瘋。
如果你想比 即，不是一個問題。
你來告訴我們。
我們將調高轉盤。
>> 每個帳戶被限制在一定程度 在每一個服務，就在蝙蝠
所以人們不發瘋 讓自己陷入麻煩。
沒有限制的大小。
你可以把任何數量 桌子上的物品。
一個項目的大小是 限於每400千字節，
這將是項目沒有屬性。
所以所有屬性的總和 被限制為400千字節。
再然後，我們有 那個小LSI問題
每個哈希的10 GB的限制。
聽眾：小數目，我失踪 你告訴我，那is--
聽眾：哦，400千字節 每件的最大尺寸。
因此，一個項目具有所有屬性。
所以400 k是總大小 該項目，400千字節。
因此，所有的屬性 結合時，所有的數據
這是在所有的這些屬性， 卷成總大小，
目前今天的項目限制為400ķ。
所以再次擴展，實現了 通過分區。
吞吐量是供應 在表級別。
還有的實際上是兩個旋鈕。
我們閱讀能力 和寫的能力。
>> 因此，這些被調整 彼此獨立。
RCU的措施，嚴格一致的讀取。
好了，如果你說我要1000 RCU的那些都是嚴格一致，
這些都是一致的讀取。
如果你說我想 最終一致性讀取，
你可以提供1000 RCU的，你要去
得到2000最終 持續讀。
而一半的價格對於那些 最終由在讀。
>> 再次，調整 彼此獨立。
他們有throughput-- 如果你消耗你的RCU的100％，
你不會衝擊 可用性你的權利。
因此，他們是完全 相互獨立的。
好了，所以的事情之一 我簡要地提到了節流。
節流是壞的。
節流表示不好沒有SQL。
有些事情我們可以做些什麼來幫助 你減輕限制你
正在經歷。
但最好的解決方案 這就是讓我們
一看你在做什麼，因為 有一個反模式在這裡打球。
>> 這些東西，這樣的事情不統一 工作負載，熱鍵，熱分區。
我打一個特定的密鑰空間 很難對一些特殊的原因。
我為什麼這樣做呢？
讓我們明白這一點。
我在我的混合熱數據冷數據。
我讓我的表得到 巨大的，但有真
數據只有某個子集 這真的對我有意思。
因此，對於日誌數據，例如，很多 客戶，他們得到每天記錄數據。
他們獲得了大量的日誌數據。
>> 如果你只是傾倒所有的日誌 數據整合到一個大表，隨著時間的推移
該表會得到巨大的。
但我真的只關心 過去24小時，過去七天，
在過去30天。
時間無論窗口 我很感興趣，期待
對於困擾我，或者事件 該事件也同樣吸引了我，
這是唯一的窗口時間，我需要。
那麼，為什麼我把10年 值得在表日誌數據？
是什麼引起的 表中的片段。
>> 它得到巨大的。
它開始鋪開 在成千上萬的節點。
而且，由於你的能力 這麼低，你
實際上率每個限制 其中的一個單獨的節點。
因此，讓我們開始考慮如何 這樣做，我們在推出該表。
如何管理這些數據一點點 更好地避免這些問題。
又是什麼樣子？
這是什麼樣子。
這是不好的NoSQL的樣子。
>> 我這裡有一個快捷鍵。
如果你看看在這裡邊， 這些都是我的分區。
我有16個分區在這裡 在這個特定的數據庫。
我們做這一切的時候。
我運行這個客戶所有的時間。
這就是所謂的熱圖。
熱圖告訴我，你怎麼是 訪問您的密鑰空間。
而這是什麼告訴我是 這有一個特定的哈希
這傢伙喜歡的 非常多的，因為他是
打它真的，真的很難。
>> 因此，藍色是不錯的。
我們喜歡藍色。
我們不喜歡紅色。
紅的，其中的壓力 得到高達100％。
100％，現在你將要節流。
所以每當你看到任何紅色線條狀 this--，它不只​​是迪納摩DB--
每一個NoSQL數據庫有這個問題。
有反模式，可以 驅動這些類型的條件。
我做的是我與客戶合作 為緩解這些條件。
>> 又是什麼樣子？
這是獲得最多 出迪納摩DB吞吐量，
但它真的越來越 最出的NoSQL的。
這不限於發電機。
這是definitely--我 曾經工作在蒙戈。
我熟悉很多NoSQL的平台。
每個人心中都有這些類型的 熱鍵問題。
為了充分利用任何對NoSQL 數據庫，特別是迪納摩DB，
要創建表 其中，哈希鍵元素
大量不同的值， 高度的基數。
因為這意味著我在寫 以許多不同的桶。
>> 越桶我 寫入，就越有可能
我傳播的寫入負載或 讀取加載到多個節點，
更可能的，我有一個 在桌子上的高吞吐量。
然後我想的值是 要求相當均勻地隨著時間的推移
並均勻地隨機越好。
嗯，這是一種有趣的， 因為我真的不能
當用戶來控制。
所以，我只想說，如果我們傳播 東西橫跨密鑰空間，
我們很可能會在更好的形狀。
>> 有一定的 準時交貨量
那你不會 要能夠控制。
但是，這些都是真的 兩個維度，我們有，
空間，獲得均勻 傳播，時間，請求
抵達的均勻間​​隔的時間。
如果這兩個 條件得到了滿足，
那麼這就是它的 將會是什麼樣的。
這是更漂亮。
我們真的很高興在這裡。
我們有一個非常均勻的訪問模式。
是的，也許你得到一個 小的壓力飄飛，
但沒有什麼太廣泛。
所以，這是驚人的多少倍， 當我與客戶合作，
即先用大紅色的曲線圖 酒吧和所有的醜陋的黃色是
所有的地方，我們 獲得與行使完成
經過幾個月 重新架構，
他們正在運行完全相同的 工作量在完全相同的負載。
而這也正是它看起來像現在。
所以你得到的NoSQL什麼是 數據模式是絕對
綁在訪問模式。
>> 你可以優化數據模式 支持這種訪問模式。
如果不這樣做，那麼你會 看到這些類型的問題
這些熱鍵。
>> 聽眾：嗯，難免有些地方 將要比其他熱。
>> RICK霍利漢：始終。
總是。
是的，我的意思是總有 A--並再次，有
一些設計模式，我們會獲得通過 這將談談你是如何處理
與這些超級大聚合。
我的意思是，我有他們， 我們該如何處理？
我有一個很好的用例 我們將討論有關這一點。
>> 好吧，讓我們的談話 一些客戶現在。
這些傢伙是AdRoll。
我不知道，如果你 熟悉AdRoll。
你可能看到他們 很多在瀏覽器上。
他們的廣告重新定位，他們 最大的廣告重新定位業務
在那裡。
他們通常定期碾過 每日起60十億的交易。
他們正在做的過萬 每秒事務。
他們有一個非常簡單的表 結構，最繁忙的表。
它基本上只是一個 哈希關鍵是餅乾，
的範圍是人口統計 類別，然後
第三屬性是得分。
>> 因此，我們每個人都有餅乾 我們的瀏覽器，從這些傢伙。
而當你去 參與商戶，
他們基本上橫跨得分您 不同的人口統計類別。
當你去一個網站， 你說我想看看這個ad--
或者基本上你不說that-- 但是當你去網站
他們說你要看到這個廣告。
他們去得到AdRoll該廣告。
AdRoll看你在他們的桌子。
他們發現你的cookie。
廣告商告訴 他們，我希望有人
誰是人到中年， 40歲的男子，進入運動。
而且他們得分，你在那些人口 和他們決定是否
這是一個很好的廣告給你。
>> 現在，他們有一個SLA 他們的廣告商
提供分10毫秒 在響應每一個請求。
因此，他們使用的是DB迪納摩此。
他們打了我們一個 每秒百萬的請求。
他們能夠做到所有的 查找，分流所有的數據，
並獲得附加的鏈接回到那個 廣告主在10毫秒。
這真的很驚人 實現他們有。
>> 這些傢伙actually-- 難道這些傢伙。
我不知道這是否是這些傢伙。
可能是這些傢伙。
主要講述us--沒有，我 不要認為這是他們。
我認為這是別人。
我正與一個 客戶的告訴我
現在，他們已經 去迪納摩DB，他們
零食的花費更多的錢 他們的開發團隊每個月都會
比他們在自己的數據庫中度過。
因此，它會給你一個 節約成本的想法
您可以在迪納摩DB獲得巨大。
好吧，dropcam是另一家公司。
這些傢伙是一種of--如果你認為 對物聯網，dropcam
基本上是互聯網安全的視頻。
你把你的相機在那裡。
相機有一個運動檢測器。
有人走來， 觸發提示點。
相機開始記錄了一段時間，直到 它沒有檢測到任何運動了。
提出該視頻在互聯網上。
>> Dropcam是一個公司，是 基本切換到發電機DB
因為他們遇到 巨大的成長的煩惱。
而他們告訴我們， 突然PB的數據。
他們不知道他們的服務 會如此成功。
比YouTube上更多的入站視頻 正是這些傢伙讓。
他們使用DynamoDB跟踪所有的 元數據對所有的視頻關鍵點。
>> 因此，他們有他們推S3桶 所有二進制神器之中。
然後，他們有 迪納摩DB記載，
指人們對這些S3三個對象。
當他們需要看視頻， 他們期待在迪納摩DB中的記錄。
他們點擊鏈接。
他們拉下從S3的視頻。
所以這是什麼樣的這個樣子。
這是直接從他們的隊伍。
>> 迪納摩DB降低其 交貨期為視頻事件
從5到10秒。
在他們的老關係存儲， 他們曾經有去執行
多重複雜的查詢圖 哪些視頻拉下，
到小於50毫秒。
所以，這是驚人的，令人驚嘆 多少性能
您可以在優化得到和 你調的基礎數據庫
以支持訪問模式。
Halfbrick，這些傢伙，它是什麼， 水果忍者我想是他們的事。
這對迪納摩DB所有運行。
而這些人，他們是一支偉大 開發團隊，大發展
店。
>> 沒有一個良好的老年退休金計劃的團隊。
他們沒有很多 經營資源。
他們都在努力試圖保持 他們的應用基礎架構起來
並運行。
他們來找我們。
他們看著那個迪納摩DB。
他們說，這是對我們來說。
他們建立了自己的全 應用程序框架就可以了。
這裡一些非常好的意見 從球隊在自己的能力
目前重點建設 遊戲和不
具有保持 基礎設施，這
正在成為一個巨大的量 開銷為自己的球隊。
所以，這是後話that--的 受益您從迪納摩DB得到。
>> 好了，進入 這裡的數據建模。
我們談了一些有關 這一對一，一對多，
和許多許多類型的關係。
你如何保持那些迪納摩。
在迪納摩數據庫，我們使用 索引，一般來說，
旋轉從數據 一種口味到其他。
哈希鍵，範圍鍵和索引。
>> 在這個特定的 例如，大多數州
有一個許可要求的 只有一個司機的每人執照。
你不能去拿到兩司機 許可在波士頓的狀態。
我不能在得克薩斯州做。
這是一種事情是這樣的。
所以在DMV，我們查找，我們 要查找駕照
由社會安全號碼。
我想查找用戶的詳細信息 通過駕照號碼。
>> 所以，我們可能有一個用戶的表 對序列號的散列密鑰，
或社會安全號碼，和 各種屬性的項目定義。
現在，該表上的我 可以定義一個GSI的
翻轉周圍，說我想 上牌照，然後哈希鍵
所有其他項目。
現在，如果我想查詢，並找到 對於任何給定的社會許可證號
安全號碼，我可以 查詢主表。
>> 如果我要查詢，我想 得到社保
數或由其他屬性 許可證號，我可以查詢GSI。
這種模式是一個 以一對一的關係。
只是一個很簡單的GSI， 圍繞翻轉那些東西。
現在，說說一對多。
一對多基本上是 您的哈希範圍的關鍵。
當我們獲得了很多與此 用例是監控數據。
監測數據來自定期 間隔，如物聯網。
我們總是得到所有這些 記錄進來所有的時間。
>> 我想找到所有的讀數 之間的特定時間段。
這是一個非常常見的查詢 監測基礎設施。
大老遠跑到大約是找到一個 簡單的表結構，一個表。
我有一個設備測量表 上的裝置ID的散列密鑰。
而我對一系列關鍵 時間戳，或在此情況下，紫裝。
並允許我執行複雜 針對該範圍鍵查詢
並返回這些記錄中 是相對於結果
設置我正在尋找。
它建立一個 一對多的關係
到使用的主表 散列鍵，範圍鍵結構。
>> 所以這是一種建 到表中迪納摩DB。
當我定義一個哈希 和範圍T台，我
定義一個一對多的關係。
這是一個父子關係。
>> 讓我們來談談多 許多關係。
並為這個特定實例中， 再次，我們將使用GSI的。
而讓我們來談談遊戲 場景：我有一個特定的用戶。
我想找出所有的遊戲 他的註冊或播放。
並對於給定的遊戲，我 想找到的所有用戶。
那麼，如何做到這一點？
我的用戶的遊戲桌，我要去 以具有用戶ID的散列鍵
而遊戲的範圍鍵。
>> 所以一個用戶可以有多個遊戲。
這是一個一個的一對多關係 用戶與他扮演的遊戲。
然後在GSI， 我會翻轉周圍。
我將哈希的遊戲 我將範圍的用戶。
所以，如果我想獲得的所有 遊戲用戶的演奏中，
我會查詢主表。
如果我想要得到所有用戶 這是在玩特定的遊戲，
我查詢了GSI。
所以你看我們是如何做到這一點？
您構建這些GSI的支持 使用的情況下，該應用程序中，訪問
圖案，該應用程序。
>> 如果我需要查詢有關 這個維度，讓
我創建該維度的索引。
如果我不這樣做，我不關心。
並根據使用的情況下，我 可能需要索引或我可能不是。
如果它是一個簡單的一對多， 主表是好的。
如果我需要做這麼多，以 很多的，還是我需要做一個的，
那麼也許我確實需要 到第二索引。
因此，一切都取決於 我想要做的
我試圖讓成就什麼。
>> 也許我不會花太多 很多時間談論的文件。
這得到了一點點，也許， 更深的比我們需要進入。
讓我們來談談一點點 關於豐富的查詢表達式。
因此，在迪納摩DB，我們有 創造能力
我們所說的投影表達式。
投影表達式是簡單 採摘田野或值
要顯示。
好了，我做一個選擇。
我做對迪納摩數據庫的查詢。
我說，你知道嗎，秀 我唯一​​的五星級評價
此特定產品。
所以，這就是我所希望看到的。
我不希望看到所有的 該行的其他屬性，
我只是想看看這個。
這就像在SQL中，當您 說選擇星或表，
你得到的一切。
當我說從選擇名稱 桌子，我只得到一個屬性。
它在同樣的事情 迪納摩DB或其他NoSQL數據庫。
過濾器表達式讓我 基本上切斷結果定了下來。
所以，我做一個查詢。
查詢可能會回來與500個項目。
但我只想要項 有一個屬性，說這一點。
好了，讓我們過濾掉這些項目 那些特定的查詢不匹配。
因此，我們有過濾器表達式。
>> 過濾器表達式可以 在任何屬性上運行。
他們不喜歡的範圍查詢。
提高查詢是更有選擇性。
過濾器的查詢要求我去 得到的整個結果來設定，然後
能開出，我不想要的數據。
這是為什麼重要？
因為我讀了這一切。
在查詢中，我會閱讀和 這將是一個關於數據的巨人。
然後我要去 能開出什麼，我需要。
如果我只是雕刻出 幾排的，那麼這就是確定。
它不是那麼低效。
>> 但是，如果我讀一大堆的 數據，只是開拓出一個項目，
然後我會更好 關閉使用範圍查詢，
因為它更具有選擇性。
這將節省我很多 錢，因為我付出相應的代價讀。
如果這一回來的結果 跨越這線可能會更小，
但我付出的讀取。
因此，了解 你得到的數據。
這是在迪納摩DB非常重要的。
>> 條件表達式，這就是 你可以稱之為樂觀鎖。
更新如果不存在，或者這個值 相當於什麼我指定。
如果我有一個時間戳 記錄，我可能會讀取數據。
我可能會改變這些數據。
我可能會寫的 數據回數據庫。
如果有人改變了紀錄， 時間戳可能已經改變。
而這樣我的條件 更新可以說更新
如果時間戳等於此。
否則更新會失敗，因為有人 更新的同時記錄。
>> 這就是我們所說的樂觀鎖定。
這意味著，有人 可以進來並改變它，
我要去檢測到它 當我回去寫。
然後，我其實可以讀到 數據和說，哦，他改變了這一點。
我需要考慮到這一點。
我可以在更改數據我 記錄和應用其他更新。
所以，你可以捕捉那些增量 的時間之間發生的更新
你讀出的數據和 時間你可能會寫入數據。
>> 聽眾：和過濾器 表達其實就是不
在數量或不是 -
>> [插入VOICES]
RICK霍利漢：我不會 得到太多到這一點。
這是一個保留關鍵字。
英鎊觀點是保留 關鍵字迪納摩DB。
每個數據庫都有自己的保留 名稱的集合不能使用。
迪納摩DB，如果您指定 一斤在這方面，
你可以定義那些名字了上面。
這是一個參考價值。
這可能不是最好的語法 最多有此討論，
因為它進入一些real-- 我會一直談論更多
關於在更深的層次。
>> 但我只想說，這可能 要查詢掃描他們views--
也不英鎊的觀點是大於10。
這是一個數值，是的。
如果你想要，我們可以談 該討論之後。
好吧，讓我們進入 在最佳實踐某些情況下
我們要討論在哪裡 這裡的一些應用程序。
什麼是用例迪納摩DB。
什麼是設計 模式在迪納摩DB。
>> 而第一個我們要 談的是物聯網。
因此，我們得到了很多of--我猜， 什麼是它 - 50％以上的
在互聯網上，這些天的交通 實際上是由機器生成的，
自動化過程，而不是由人類。
我的意思是這件事這件事， 你攜帶在你的口袋裡，
多少數據，這一件事是 實際發送身邊沒有你
知道這絕對是驚人的。
您的位置信息 有關如何快，你要去的地方。
您如何看待谷歌地圖工程 當他們告訴你的業務是什麼。
這是因為有百萬， 數以百萬計的人駕車去
與手機，發送 數據遍布的地方所有的時間。
所以的事情之一 關於這種類型的數據
進來，監測數據，日誌 數據，時間序列數據，是它
通常只有有趣 為一點點時間。
該時間後，它的 沒那麼有趣。
所以我們講了，別讓 這些表成長過程中沒有界限。
這裡的想法是，也許我已經得到了24 時間的價值在我的熱表的事件。
而這熱表將是 置備以非常高的速度，
因為它採取了大量的數據。
它採取了大量的數據 在和我讀了很多。
我有很多的操作 針對該數據運行查詢。
>> 24小時後哎，你 知道嗎，我不在乎。
所以，也許每一個半夜，我滾 我的表到一個新表
我取消置備此表。
我會採取RCU年代和 WCU的下降，因為24小時後
我沒有運行盡可能多 查詢針對該數據。
所以，我要省錢。
也許30天我不知道 甚至需要關心這一切。
我可以採取WCU的 下一個所有的方式，
因為你知道，這是 永遠不會得到寫入。
該數據是30天。
它永遠不會改變。
>> 這幾乎永遠不會得到閱讀， 所以我們就採取RCU下降到10。
而且我節省了此一噸的錢 數據，並且只支付我的熱數據。
所以這是看最重要的事情 在當你看一個時間序列
數據傳來的體積。
這些策略。
現在，我可能就讓它 都去同一個表
只是讓該表增長。
最後，我要 看性能問題。
我將不得不開始存檔 某些數據從表中的，
什麼不是。
>> 讓我們更好 設計應用程序
這樣就可以正確運行這種方式。
所以它只是自動 在應用程序代碼。
在午夜每晚 它推出的表。
也許我需要的是一個滑動 的24小時的數據窗口。
然後定期我 主叫關表數據。
我有一個修整它 cron作業，我把它
到這些其他表， 無論你需要什麼。
因此，如果一個過渡工作，這是偉大的。
如果不是，修剪。
但是，讓我們保持這種熱點數據 遠離你的感冒數據。
它會為您節省大量的金錢和 讓你的表的更多的表演。
因此，接下來的事情再說吧 的是產品目錄。
產品目錄是 很常見的情況。
這其實是一個很常見的模式 我們會看到各種各樣的東西。
你知道，Twitter的 例如，熱鳴叫。
每個人都來了， 抓住了鳴叫。
產品目錄，我得到了銷售。
我得到了熱銷。
我每70000請求 第二次來的產品
說明我的產品目錄。
我們認為，這對零售業 操作頗有幾分。
那麼，我們如何同解決？
有沒有辦法來面對這一切。
我所有的用戶希望看到的 相同的數據塊。
他們的到來，同時。
而且他們都發出請求 對於相同的數據。
這給了我，熱鍵，那大紅色的 條紋我的圖表，我們不喜歡。
這就是那個樣子。
所以，在我的密鑰空間我越來越 敲定在售項目。
我越來越沒有任何其他地方。
>> 我該如何解決這個問題？
好了，我們有緩存緩解這一點。
緩存，你把基本的內存 分區中的數據庫的前面。
我們已成功 [聽不清]緩存，你怎麼
可以設置自己的緩存，[聽不清] 緩存[？任何你想要的研發，？]。
端起在數據庫的前面。
而這種方式，你可以存儲數據 從這些熱鍵在高速緩存
空間，並通過高速緩存中讀取。
>> 然後大部分的閱讀 開始看這個樣子。
我把所有這些緩存命中在這裡 我沒有什麼事情到這裡
因為數據庫是坐在後面的 高速緩存和讀取永遠不會通過。
如果我更改數據 數據庫，我必須更新緩存。
我們可以使用的東西 像蒸做到這一點。
我會解釋如何工作的。
好吧，短信。
電子郵件，大家都用電子郵件。
>> 這是一個非常好的例子。
我們已經有了某種信息表。
而我們得到的收件箱和發件箱。
這就是在SQL將 看樣訂做的收件箱。
我們那種使用同一種 策略使用GSI公司，GSI公司的
我的收件箱和發件箱我。
所以我就生的消息來了 到我的信息表。
而第一種方式這 也許，說好，沒問題。
我有原始消息。
消息來了[聽不清] 消息ID，這是偉大的。
這是我唯一的哈希。
我要創建兩個GSI的一 我的收件箱，一個是我的發件箱。
而第一件事我會做 是，我會說我的哈希鍵
將成為收件人和 我會安排的日期。
這是夢幻般的。
我得到了我很好的觀點在這裡。
但是有一個小問題在這裡。
你碰到這 關係型數據庫以及。
他們所謂的垂直分區。
你要保持你的大數據 遠離你的小數據。
>> 而原因是因為我得 去閱讀的項目來獲得屬性。
如果我的身體都在這裡， 然後讀就幾件
如果我的身體長度 平均每256千字節，
數學變得相當難看。
所以說，我想讀大衛的收件箱。
大衛的收件箱中有50個項目。
的平均值和大小為256千字節。
這是我的轉化率 對於RCU的為四字節。
>> 好吧，讓我們一起去 最終一致性讀取。
我還在吃1600 RCU的 只是看大衛的收件箱。
哎喲。
好了，現在讓我們想想 有關如何應用程序的工作原理。
如果我在一個電子郵件應用程序， 我看著我的收件箱，
我期待在每封郵件的正文， 沒有，我在看的摘要。
我看只有頭。
因此，讓我們建立一個表結構 看起來更像。
>> 因此，這裡的信息 我的工作流程需求。
這是在我的收件箱GSI。
它的日期，發送者， 這個問題，然後
消息ID，它指向 回郵件表
在那裡我能得到身體。
那麼，這些將是記錄ID。
他們將指向回 項ID在迪納摩數據庫表。
各項指標始終creates-- 總是具有項
ID為部分of--的 自帶的索引。
>> 好吧。
聽眾：它告訴它在那裡的存儲？
RICK霍利亨：是的，它告訴 exactly--這也正是它的作用。
它說，這是我重新備案。
它會指出這回我重新備案。
究竟。
好了，現在我的收件箱 實際上要小得多。
而這實際上支持 的電子郵件應用程序中的工作流程。
所以我的收件箱，我點擊。
我走，我點擊了郵件， 這時候我需要去獲得身體，
因為我要去 去一個不同的看法。
所以，如果你想MVC類型 框架，模型視圖控制器。
>> 該模型包含 數據的視圖需要
和控制器相互作用。
當我改變幀，當 予改變的角度來看，
它是確定返回到 服務器和重新填充模型，
因為這是用戶期望的結果。
當他們改變看法，這是當 我們可以回到數據庫。
所以電子郵件，請單擊。
我在找屍體。
往返。
去拿身體。
>> 我讀少了很多數據。
我只是讀體的 當他需要他們大衛需求。
我也不會在1600年燒毀 RCU的只是為了顯示他的收件箱。
所以，現在that--這是方法 該LSI或GSI--我很抱歉，
GSI，將制定。
我們有我們的哈希收件人。
我們已經得到的日期範圍鍵。
而且我們已經得到了預期的屬性 我們只需要支持這樣的觀點。
>> 我們旋轉，對於發件箱。
散列發件人。
和在本質上，我們有 非常漂亮，乾淨的看法。
而且這basically--我們 有這個漂亮的消息
表正在被很好地傳播，因為 它的哈希只，散列消息ID。
而且我們有兩個指標是 被旋轉關閉該表。
好了，所以這裡的想法是不 保持大數據和這個小數據
一起。
垂直分區， 這些分區表。
不要讀數據，你就不必。
好吧，遊戲。
我們都喜歡的遊戲。
至少我很喜歡遊戲的話。
因此，一些事 我們處理的時候
我們正在考慮的遊戲，對不對？
遊戲這些天，特別是移動 遊戲，是所有關於思維。
而且我要在這裡一個旋轉 點點遠離DynamoDB。
我要引進 一些討論
周圍的一些的 其他AWS技術。
>> 但是對遊戲的想法是想 關於原料藥方面，API的是，
一般來說，HTTP和JSON。
這是怎麼手機遊戲樣的 與後端進行交互。
他們這樣做的JSON張貼。
他們得到的數據，它的一切， 一般來說，在漂亮的JSON API的。
>> 事情是得到朋友，得到 領先榜，交換數據，
用戶生成的內容， 推送至系統，
這些類型的東西 我們要做的。
二進制資產數據，該數據 可能不坐在數據庫中。
這可能在坐 對象存儲，對不對？
但數據庫將會 最終告知系統，
告訴應用程序 哪裡去得到它。
不可避免地，多人 服務器，後端基礎設施，
而專為高 可用性和可擴展性。
因此，這些都是事情，我們都希望 在當今遊戲的基礎設施。
>> 因此，讓我們一起來看看 是什麼樣子。
有一個核心的後端， 非常簡單。
我們這裡有一個系統 多個可用區。
我們談到AZS作為being--認為 它們作為獨立的數據中心。
一個以上的數據中心 按AZ，不過沒關係，
只是把它們作為單獨的數據 中心在地理上
和故障隔離。
>> 我們將有一個 夫婦EC2實例。
我們將有 一些後端服務器。
也許，如果你是一個傳統的 架構，我們
使用我們所說的RDS， 關係數據庫的服務。
可能是MSSQL，MySQL的， 或類似的東西。
這是這樣一個大量的應用 設計的今天。
>> 嗯，我們可能要一起去 這是當我們向外擴展。
我們將繼續前進，把 在S3存儲在那裡。
這S3存儲桶，而不是服務 從我們的servers--這些對象
我們能做到這一點。
你把你所有的二進制 在服務器上的對象
您可以使用這些服務器 實例來服務這些數據了。
但是，這是相當昂貴的。
>> 更好的辦法是繼續前進， 把這些對象在S3存儲桶。
S3是一個對象存儲庫。
它內置專 提供了這些類型的東西。
而讓這些客戶端請求 直接從這些對象桶，
卸載的服務器。
所以我們開始在這裡進行擴展。
>> 現在我們得到的用戶遍布世界各地。
我得到了用戶。
我需要在本地有內容 靠近這些用戶，對不對？
我創建了一個S3桶 作為我的源代碼庫。
我會前，與 在CloudFront的分佈。
>> CloudFront的是CD和 內容分發網絡。
基本上，它需要你指定的數據， 並將其緩存所有在互聯網上
讓用戶隨處都可以有 一個非常快速的響應時，
他們要求這些對象。
>> 所以，你得到一個想法。
有種你充分利用所有的 AWS的方面這裡完成這件事。
而最終，我們拋出 在自動伸縮群。
因此，我們的AC2實例 我們的遊戲服務器，
當他們開始變得繁忙 和越來越忙，
他們只會旋轉另一 例如，旋轉另一個實例，
旋另一個實例。
因此，該技術具有自動氣象站，它 允許您指定的參數
圍繞您的服務器將增長。
所以，你可以擁有服務器的n個 在那裡，在任何給定的時間。
如果你的負載消失了，他們會 收縮，這一數字將縮小。
並且如果負載回來， 它會重新生長出來，彈性。
>> 因此，這看起來不錯。
我們有很多的EC2實例。
我們可以把緩存 數據庫的前面，
嘗試並加速數據庫。
下一個壓力點 一般人看到
是他們使用的是擴展遊戲 關係數據庫系統。
老天，數據庫 性能是可怕的。
我們怎麼改進呢？
讓我們嘗試把 緩存在這一方面。
>> 那麼，高速緩存不起作用 如此之大的遊戲，對不對？
對於遊戲，寫作是痛苦的。
遊戲非常寫沉重。
當你緩存不起作用 因為你一直寫重
得更新緩存。
您更新緩存，它的 不相關被緩存。
它實際上只是額外的工作。
>> 所以，我們去哪裡嗎？
你已經有了一個很大的瓶頸 那裡在數據庫中。
而且去的地方 明明是分區。
分區是不是 易當你做
處理關係數據庫。
關係數據庫，你 負責管理，有效的，
密鑰空間。
你說A和M之間的用戶 去這裡，與N和Z去那裡。
而你切換 整個應用程序。
所以，你正在處理 這個分區的數據源。
你有交易限制 不跨越分區。
你有各種各樣的 混亂，你是
對付那裡努力 處理向外擴展
，建設大型基礎設施。
這只是沒有樂趣。
>> 聽眾：所以你是說 越來越多的源點加快
這個過程？
RICK霍利漢：增加？
聽眾：源點。
RICK霍利漢：源點？
聽眾：從信息， 其中的信息是從哪裡來的？
RICK霍利漢：沒有。
我想說的是增加 分區中的數據存儲數
提高吞吐量。
因此，這裡發生了什麼是用戶 進入EC2實例在這裡，
好吧，如果我需要一個用戶 這是A至M，我會去這裡。
從氮磷，我會去這裡。
從P到Z，我會去這裡。
>> 聽眾：好，那所以這些都是 所有存儲在不同的節點？
>> RICK霍利漢：是的。
想到這些作為 不同的孤島的數據。
所以你必須做到這一點。
如果你正在試圖做的 這一點，如果你想
在大規模的關係平台， 這是你在做什麼。
你服用的數據和 你砍倒它。
而你分區它跨越 該數據庫的多個實例。
而你管理所有的 在應用程序層。
這是沒有樂趣。
那我們要到哪裡去？
我們想去DynamoDB，全面管理， 的NoSQL數據存儲，提供的吞吐量。
我們使用二級指標。
它基本上是HTTP API和 包括文檔支持。
所以你不必擔心 有關的任何分區。
我們做這一切為您服務。
所以，現在，而是你 只寫表。
如果該表需要被分割， 這種情況發生在幕後。
你完全絕緣 從作為一個開發者。
因此，讓我們來談談 一些用例
我們碰到的遊戲，共同 遊戲場景，領先榜。
所以，你有用戶進來， 說他們是BoardNames
對，分數為這個用戶。
我們可能會被散列的用戶名， 然後，我們有一系列的遊戲。
因此，每一個用戶希望看到 所有他玩遊戲
和所有他的最高得分 在所有的遊戲。
所以這是他個人的排行榜。
>> 現在，我要進去，我想get-- 所以我得到這些個人排行榜。
我想要做的就是去得到 最高分在所有用戶。
那麼，如何做到這一點？
當我的紀錄被散列上 用戶ID，排列在遊戲中，
嗯，我要繼續前進 和重組，建立一個GSI，
而我要重組這些數據。
>> 現在，我要哈希的 BoardName，這是遊戲。
而我要去範圍的最高分。
而現在我已經創造了不同的桶。
我使用的是同一個表， 相同的項目的數據。
但我創建一個水桶，讓 我最高分通過遊戲的集合。
>> 我還可以查詢該表 要獲得這些信息。
所以，我給自己定了查詢模式最多 通過輔助索引的支持。
現在，他們可以通過BoardName進行排序 和分類TopScore，視。
所以你可以看到，這些類型 的使用，你在遊戲中獲得的情況。
另一個很好的使用情況下，我們在遊戲中獲得 為獎勵和誰是獲獎。
這是一個偉大的使用情況 在這裡我們稱之為稀疏的索引。
稀疏索引是 能夠產生
這不一定索引 包含在表中的每一個項目。
為什麼不呢？
因為這是作為屬性 索引並沒有對每一個項目存在。
>> 所以在這個特定 使用的情況下，我是說，
你知道嗎，我要去 創建一個名為獎的屬性。
我想給每個用戶 具有該屬性的獎勵。
用戶沒有獎項 不會有屬性。
所以，當我創建了 索引，用戶只能
所要顯示 在索引是
那些實際上已經贏得了獎項。
所以這是一個偉大的方式，能夠 創建過濾索引的
是非常，非常有選擇性的不 必須索引整個表。
>> 因此，我們越來越低的時間在這裡。
我要繼續前進，跳躍 出來，跳過此方案。
說一下about--
>> 聽眾：我能問一個簡單的問題？
一個是寫重？
RICK霍利漢：是什麼？
聽眾：寫沉重。
RICK霍利漢：寫沉重。
讓我看看。
>> 聽眾：或者是不 東西，你可以只
聲音在幾秒鐘的事？
RICK霍利漢：我們去 通過投票的情景。
這並不是說不好。
難道你們有幾分鐘？
好。
>> 因此，我們將討論表決。
因此，實時投票，我們有 要求進行投票。
要求是我們讓 每個人只能投票一次。
我們希望任何人能夠 改變他們的投票。
我們希望實時聚合 並分析了人口統計學
我們正在將是 顯示在網站上的用戶。
>> 想想這個場景。
我們的工作很多現實 電視節目，其中他們
做這些事確切類型。
所以，你能想到的情景， 我們有億萬
十幾歲的女孩有 與他們的移動電話
和投票，以及投票和 對於無論他們是誰投票
發現是最流行的。
因此，這些都是一些 要求我們冒了出來。
>> 這樣一來，先來 在解決這一問題的
將建立一個 非常簡單的應用程序。
所以，我有這個程序。
我有一些選民在那裡。
他們來了，他們打的表決程序。
我有一些原始的投票表 我就拋售這些選票成。
我有一些匯總 投票表
會盡我的分析和人口統計數據， 我們會把這一切都在那裡。
>> 這是偉大的。
生活很好。
生活的好，直到我們發現， 總有一兩個
人是流行的選舉。
只有一個或兩件事情 人們真正關心的。
如果你在投票 規模，突然我
將被錘擊這個鬼 兩個候選人，一個或兩個候選人。
項目的數量非常有限 人們發現很受歡迎。
>> 這不是一個很好的設計模式。
這實際上是一個 非常糟糕的設計模式
因為它創造正是我們 談到這是熱鍵。
熱鍵是一些我們不喜歡的。
>> 那麼，我們如何解決這個問題？
真的，來解決這個問題的方法是 通過採取這些候選桶
並為我們每一位候選人， 我們要添加一個隨機值，
東西我們知道，隨機 1和100之間的值，
介於100和1000， 或者一個與1​​000之間，
然而，要隨機值 追加到該候選人的結束。
>> 而且還我真的做了什麼呢？
如果我使用的候選者ID為 鬥到總票數，
如果我添加了一個隨機的 號的該端，
我創建了現在的10桶，一 百桶，千桶
我正在聚集跨越票。
>> 所以，我有幾百萬，數以百萬計， 數以百萬計的記錄進來
對於這些候選人，我現在蔓延 這些票對候選A_1
通過候選A_100，因為 每次投進來，
我生成一個隨機的 1和100之間的值。
我這套結上的結束 候選人的人的投票支持。
我為之傾倒成桶。
>> 現在，在背，我知道 我得到了一百桶。
所以，當我要先走 和聚合票，
我從所有這些水桶閱讀。
所以，我繼續和補充。
然後我做了分散收集 我走到哪裡出來說，嘿，
你知道嗎，這個應聘者的關鍵 空間是百餘桶。
我要收集所有 投票從這些百桶。
我要匯總 他們，我會說，
候選人A目前擁有 x的總投票數。
>> 現在，無論是寫 查詢和讀查詢
是很好的分佈 因為我正在寫跨越
而我在讀在數百鍵。
我不寫， 跨越一個關鍵看現在。
所以這是一個偉大的格局。
>> 這實際上可能是1 的最重要的設計
圖案中的NoSQL規模。
你會看到這種類型的 設計模式在每一種滋味。
MongoDB中，DynamoDB，它不 事，我們都必須做到這一點。
因為當你處理 這些巨大的聚合，
你必須想出一個辦法來 它們分佈橫跨桶。
因此，這是你做的方式。
好吧，那又怎樣 你現在正在做的
是你的交易已讀 成本寫的可擴展性。
我讀的成本 有點複雜
我必須去從讀 百水桶而不是一個。
但我能寫。
而我的吞吐量，我寫 吞吐量是不可思議的。
因此，它通常是一個有價值的 技術縮放DynamoDB，
或與此有關的任何的NoSQL數據庫。
所以我們想出如何去衡量它。
而我們盤算如何 消除我們的熱鍵。
這是夢幻般的。
而我們得到了這個漂亮的系統。
而且它給了我們非常正確的投票 因為我們有記錄的投票重複數據刪除。
它的建成DynamoDB。
我們談到條件的權利。
>> 當選民進來，看跌期權 插入在桌子上，
他們與他們的選民身份插入， 如果他們試圖插入另一張選票，
我做了有條件的寫操作。
只說寫這個 如果這不存在。
所以，當我看到， 該票的打表，
沒有人會是 能夠把他們的選票研究。
這是夢幻般的。
我們正在遞增 我們的候選人計數器。
我們正在做我們的 人口和一切。
但是，如果發生了我 應用倒下？
現在突然票 都進來，我
不知道，如果他們要處理 在我的分析和人口統計學
了。
而當該應用程序 回來了，怎麼
地獄做我知道什麼票都有 被處理，我從哪裡開始？
>> 因此，這是一個真正的問題，當你 先來了解一下這種類型的場景。
我們如何解決呢？
我們解決它與我們 致電DynamoDB流。
流是一個時間排序和 每個分區的訪問權限更改日誌
表中，每一個寫 對表的訪問。
這是寫的任何數據 表顯示上的流。
>> 它基本上是24小時的隊列。
項目打流， 他們生活24小時。
它們可被讀取多次。
保證被傳送 只有一次到流，
可以讀取n次。
然而，如此眾多的進程要 消費數據，你可以使用它。
它會出現每次更新。
每寫只會 一旦出現流上。
所以你不必擔心 約兩倍的處理它
從同樣的過程。
>> 它的每個項目嚴格有序。
當我們說時間 有序和分區，
每個分區你會看到在流。
您將看到訂單項，更新。
我們不保證 對，你是流
要得到每一筆交易 在整個項目的順序。
>> 所以流是冪等。
難道我們都知道冪等意思？
冪等的意味著你可以做到這一點 過來，過來，一遍又一遍。
結果將是相同的。
>> 流是冪等， 但他們必須是
從起點開始發揮， 無論你選擇，到最後，
否則將不會導致 在相同的值。
>> 同樣的事情用MongoDB的。
MongoDB中有一個結構 他們所謂的OPLOG。
它是完全相同的結構。
很多NoSQL數據庫 有這樣的結構。
他們用它做的事情 像複製，這
正是我們做流。
聽眾：也許 異端的問題，但你
談談應用程序做下來的等等。
現流保證 永遠不可能往下走？
RICK霍利亨：是啊，小溪 都保證不會跌的。
我們管理基礎架構 背後。自動流
部署在他們的自動縮放組。
我們將通過一個小 會發生什麼位。
>> 我不應該說他們不 保證再也不去了。
元素都保證 出現在流中。
並且流將是可訪問的。
那麼，下山或回來 了，這種情況下。
這covers--沒關係。
好吧，讓您得到不同 視圖類型關閉屏幕。
這是很重要的一個視圖類型 程序員通常是，是什麼？
我得到的舊觀點。
當更新打表，它會 推舊視圖到流
這樣的數據可以存檔，或改變 控制，改變識別，變更
管理。
>> 新的圖像，它現在以後有什麼 更新，這是另一種類型的視圖
你可以得到。
你可以得到舊的和新的圖像。
也許我想他們兩個。
我想看看是什麼東西。
我想看看它改成。
>> 我有一個符合型 過程中運行。
它需要驗證 當這些情況發生變化，
他們是在一定限度內 或某些參數內。
>> 然後，也許我只 需要知道發生了什麼變化。
我不在乎什麼項目改變。
我並不需要需要知道 什麼屬性改變。
我只需要知道， 該項目被感動。
因此，這些都是意見類型 你下車流
並可以與之交互。
>> 該應用程序 消耗流，
這是一種這樣的工作方式。
DynamoDB客戶要求 推數據的表。
流部署在我們所說的碎片。
碎片縮放 獨立的表。
他們不用排隊完全 你的表的分區。
而之所以說是 因為他們排隊
向的能力，當前的 表中的容量。
>> 他們部署在其 自己的自動伸縮群，
他們開始分拆視 有多少寫操作都進來，
有多少reads--說實在的，寫的。
有沒有reads--但如何 很多寫操作進入。
>> 然後在回 為此，我們有我們
調用KCL，或室壁運動客戶端庫。
室壁運動是一個數據流 加工技術從亞馬遜。
而流是建立在。
>> 所以你用KCL啟用 程序讀取數據流。
實際上室壁運動客戶端庫 管理人員為您服務。
而且它也做了一些 有趣的東西。
它會創建一些表了 在您的DynamoDB表
跟踪哪些項 已經被處理。
於是就這樣，如果它落在後面，如果 它屬於過去，來，並得到
站在後面時，它可確定 是它在處理流。
>> 這是非常重要的，當 你在談論複製。
我需要知道什麼 數據被處理
和哪些數據尚未處理。
所以KCL庫流將 給你很多的功能。
它負責所有的家務。
它代表了一個工人，每碎片。
它創建一個管理表 每一個碎片，對每一個工人。
而那些工人火， 他們認為這些表
所以你知道這個紀錄 被讀取並處理。
然後，如果處理這樣 死了，回來上網，
它可以恢復正確的地方起飛。
>> 因此，我們使用它進行 跨區域複製。
很多客戶有需要 移動數據的數據表或部分
各地不同的區域。
有九個區域 世界各地。
所以有可能是一個need--我 可能有用戶在亞洲，用戶
在美國的東海岸。
它們具有不同的數據 需要在本地分佈。
也許用戶哪些航班從 亞洲轉移到美國，
我想複製 他的數據與他。
所以，當他下飛機，他有 用他的手機應用程序，一個很好的經驗。
>> 您可以使用跨區域 複製庫做到這一點。
基本上，我們有 提供兩種技術。
一個人的控制台應用程序，你可以 站起來對自己的EC2實例。
它運行純粹的複製。
然後我們給你的庫。
該庫，你可以用它來打造 你自己的應用程序，如果你
想要做瘋狂的事情與數據 - 過濾器，複製的只是其中的一部分，
旋轉數據，將其移動到 不同的表，等等，等等。
所以這是一種什麼樣子。
>> DynamoDB流可 通過我們所說的LAMBDA處理。
我們提到的事件一點點 驅動的應用程序架構。
LAMBDA是一個關鍵組成部分。
LAMBDA是觸發按需代碼 響應於特定的事件。
一這些事件可能是一個 記錄出現在流。
如果記錄出現在流， 我們會打電話給這個Java功能。
那麼，這是JavaScript的，和Lambda 支持Node.js的，使用Java，Python，
並即將支持 其他語言。
而我只想說，這是純粹的代碼。
寫在Java中，你定義一個類。
你推JAR成LAMBDA。
然後你指定的類 響應於該事件來調用。
然後拉姆達基礎設施 後面將要運行的代碼。
>> 該代碼可以處理 關閉流記錄。
它可以做任何它想做的。
在這個特殊的例子中，所有我們 真正做的是記錄的屬性。
但是，這只是代碼。
代碼可以做任何事情，對不對？
>> 所以，你可以旋轉的數據。
您可以創建一個衍生觀點。
如果它是一個文檔結構， 你可以扁平化的結構。
您可以創建備選索引。
各種東西，你可以 做的DynamoDB流。
>> 真的，這是什麼樣子。
所以，你得到這些更新進入。
他們來了斷弦。
他們的lambda函數讀取。
他們正在旋轉的數據和 推它在衍生表，
通知變更外部系統， 並且將數據推入ElastiCache。
>> 我們談到了如何把緩存 在數據庫中的正面為銷售
場景。
那麼會發生什麼，如果我 更新項目的描述？
好吧，如果我有一個LAMBDA 在該表上運行的功能，
如果我更新項目的描述，它會 拿起記錄過流，
它會更新ElastiCache 實例與新的數據。
所以這是一個很大的 我們做什麼用LAMBDA。
這是膠水代碼，連接器。
它實際上給 發射能力
並運行非常複雜的應用程序 無需專用服務器
基礎設施，這是真的很酷。
>> 因此，讓我們回到我們 實時投票架構。
這是新的和改進我們的 流和KCL功能的應用程序。
和以前一樣，我們可以 處理任何規模的選舉。
我們喜歡這一點。
我們做了分散雲集 在多個水桶。
我們有樂觀鎖怎麼回事。
我們可以保持我們的選民 從改變他們的投票。
他們只能投票一次。
這是夢幻般的。
實時容錯能力， 現在可伸縮的聚合。
如果事情翻倒， 知道在哪裡可以自己重新啟動
當它回來了，因為 我們使用了KCL應用程序。
然後我們還可以使用 KCL應用程序將數據推出
到紅移其他 應用程序的分析，或使用
該彈性MapReduce運行 實時流聚合斷
的該數據。
>> 因此，這些事情我們 還沒有談到太多。
但他們更多 技術，來
如果你正在尋找熊 在這些類型的方案。
>> 好了，所以這是有關 分析與DynamoDB流。
你可以收集重複數據刪除 數據，做各種
好看的東西，在匯總數據 內存，創建這些派生表。
這是一個巨大的用例 那很多客戶
正在參與，以嵌套 這些JSON文件屬性
和創建附加的索引。
>> 我們在最後。
感謝您的軸承和我在一起。
因此，讓我們來談談 參考架構。
DynamoDB坐在這麼中間 大部分的AWS基礎設施。
基本上，你可以把它掛 高達任何你想要的。
使用內置的應用迪納摩包括 LAMBDA，ElastiCache，CloudSearch，
該數據推伸到彈性 MapReduce的，從DynamoDB進出口
進入S3，各種工作流程。
但可能是最好的 事情談，
這是真的 有趣的是，當我們
談論事件驅動的應用程序。
>> 這是一個例子 內部項目
我們已經在這裡我們實際上 發布收集的調查結果。
因此，在一封電子郵件中鏈接 我們送出去，以後還有
是一個小環節說點擊 這裡以應對調查。
而當一個人點擊 這個鏈接，會發生什麼情況
是他們拉下安全 從S3 HTML調查表。
有沒有服務器。
這僅僅是一個S3對象。
>> 這種形式的出現， 在瀏覽器中加載了。
它有骨幹。
它有複雜的JavaScript 它的運行。
所以這是非常豐富的應用程序 在客戶端的瀏覽器中運行。
他們不知道，他們不是 與後端服務器進行交互。
在這一點上，它的所有的瀏覽器。
>> 他們公佈的結果是什麼 我們所說的亞馬遜API網關。
API網關是一個簡單的網絡API 你可以定義和掛鉤
到任何你想要的。
在這種特殊情況下，我們 迷上了一個lambda函數。
>> 所以我的POST操作 發生的事情沒有服務器。
基本上，該API網關坐在那裡。
它花費了我什麼，直到人 開始張貼到它，對嗎？
lambda函數只是坐在那裡。
它花了我什麼，直到 人們開始打它。
所以你可以看到，作為卷 增加，這時候的費用來。
我沒有運行的服務器7/24。
>> 所以，我拉的形式 淘汰下來的水桶，
我通過API發布 網關到lambda函數。
然後拉姆達 功能說，你知道
什麼，我有一些PIIS，一些 個人身份信息
在這些反應。
我的意見，從用戶的到來。
我有電子郵件地址。
我已經得到了用戶名。
>> 讓我分裂這一關。
我要產生一些 元數據關閉此記錄。
而我要去推 元數據到DynamoDB。
而且我可以加密所有數據 並將其推入DynamoDB，如果我想要的。
但它更容易對我來說，在這 使用的情況下，繼續前進的發言權，
我要推的原始數據 進入加密的S3桶。
所以我用建在S3服務器端 加密和亞馬遜的密鑰管理
服務讓我有一個鍵 可以在一個固定的間隔轉動，
我可以保護PII數據 因為這整個工作流程的一部分。
>> 所以我做了什麼？
我剛剛部署一個整體 應用程序，我沒有任何服務器。
那麼，什麼樣的事件驅動應用程序 建築為你做。
>> 現在，如果你仔細想想 該用例this--
我們還有其他的客戶我說 到這個確切的架構誰
運行驚人的大戰役，誰 在看這個去，噢，我的。
因為現在，他們可以 基本上推在那裡，
讓這樣的活動只是坐在 在那裡，直到它啟動，而不是
不用擔心無花果約 什麼樣的基礎設施
將是那裡支持它。
然後盡快 該活動完成後，
它就像基礎設施 只是馬上消失
因為實在 沒有基礎設施。
就這麼坐在LAMBDA只是代碼。
這是坐落在DynamoDB僅僅是數據。
這是一個了不起的方式 來構建應用程序。
>> 聽眾：那麼，這更 短暫的比起來，
如果它被存儲實際的服務器上？
>> RICK霍利漢：當然。
由於該服務器實例 將必須是一個7/24。
它必須是可用於 有人回應。
那麼你猜怎麼著？
S3提供7/24。
S3總是響應。
而S3是非常，非常好 在煮好的對象。
這些對象可以是HTML文件，或 你想要的JavaScript文件，或什麼的。
您可以運行非常豐富的網絡應用 從S3桶，而人呢。
>> 所以這就是這裡的想法 是擺脫的方式
我們曾經考慮一下。
我們都曾經以為在 術語服務器和主機。
這不是這個問題了。
這是關於基礎設施的代碼。
部署代碼到雲 讓雲中運行它。
而這正是AWS正在努力做的事情。
>> 聽眾：所以你的金盒中間 的API網關不是服務器狀，
反而是just--
>> RICK霍利漢：你能想到的 它作為服務器的門面。
所有這是它會採取一個HTTP 請求，並將其映射到另一個進程。
這就是它。
在這種情況下，我們正在映射 它以一個lambda函數。
好了，所以這是我的一切。
非常感謝。
我很感激​​。
我知道我們想隨著時間的推移一點點。
並希望你們了 信息一點點
你今天可以帶走。
我很抱歉，如果我去 一下自己的頭，
但有一個好很多 基本的基礎知識
我想對你非常有價值的。
所以，謝謝你邀請我。
[掌聲]
聽眾：[聽不清] 是當你在說什麼
你必須要經歷的事情 從開始到結束
以獲得正確的價值觀 或相同的值，
如何將這些值 改變，如果[聽不清]。
>> RICK霍利亨：哦，等冪？
如何將這些值的變化？
好了，因為如果我沒有跑 這一切的方式來結束，
那麼我不知道什麼樣的變化 在最後一英里發了言。
它不會是 相同的數據，我所看到的。
聽眾：哦，所以你只要 還沒有得到整個輸入。
RICK霍利漢：對。
你必須從一開始走 向端，然後它的
將是一個一致的狀態。
涼。
>> 聽眾：所以你給我們DynamoDB 可以做文檔或鍵值。
我們花了很多時間對 有井和方式鍵值
翻轉它周圍。
當你看著那些表，是 留下的文件的方法嗎？
>> RICK霍利漢：我不會 說離開它後面。
>> 聽眾：他們從the--分離
>> RICK霍利漢：隨著文檔 方法，在DynamoDB文檔類型
只是所認為的另一個屬性。
它是一個包含一個屬性 分層數據結構。
然後在查詢 您可以使用屬性
使用對象標記這些對象。
所以，我可以過濾嵌套 在JSON文件的屬性。
聽眾：所以，任何時候我 做一個文檔的方法，
我有點可以到達tabular--
聽眾：當然。
聽眾：--indexes和 你剛才講的事情。
RICK霍利亨：是的， 索引和所有這一切，
你想索引的時候 JSON的性能，
我們不得不這樣做的方式是，如果 你插入一個JSON對象或文檔
進入迪納摩，您可以使用流。
流會讀取輸入。
你會得到的JSON 對象，你會說OK，
什麼是我想要索引的屬性？
>> 您創建一個衍生表。
現在，這是它的工作原理，現在的方式。
我們不會讓你指數 直接這些屬性。
>> 聽眾：Tabularizing您的文件。
>> RICK霍利亨：沒錯，壓扁 它，tabularizing它，沒錯。
這就是你用它做。
>> 聽眾：謝謝。
>> RICK霍利亨：是的， 絕對的，謝謝你。
聽眾：所以它是一種 蒙戈滿足Redis的分類器。
>> RICK霍利亨：是啊， 這是一個很多這樣的。
這是一個很好的說明了它。
涼。