[音楽再生] RICKフーリハン：すべての権利。 皆さん、こんにちは。 私の名前はリックフーリハンです。 私はシニアプリンシパルよ AWSでのソリューションアーキテクト。 私はNoSQLのに焦点を当て、 DynamoDBの技術。 私が話をする今日ここにいますよ あなたそれらについて少し。 私の背景があります 主にデータ層です。 私は半分私の開発を過ごしました キャリアは、データベースを書きます データアクセス、ソリューション 様々なアプリケーションのため。 私は、クラウドの仮想化にしてきました 約20年間。 だからクラウドはクラウドになる前に、 我々は、ユーティリティ・コンピューティング、それを呼び出すために使用されます。 そしてアイデアは、それはようなものだました PG＆Eは、あなたが使用するもののために支払います。 今日は雲を呼び出します。 しかし、長年にわたって、私が働いてきました 企業のカップルのために あなたは、おそらく聞いたことがありません。 しかし、私は、技術のリストをまとめました 成果は、私はあなたが言うだろうと思います。 私は、クラウドシステムでは8特許を持っています 仮想化、マイクロプロセッサ設計、 複合イベント処理、 その他の分野にも。 そこで、これらの日、私はNoSQLのに主に焦点を当てます 技術と次世代 データベース。 そして、それは私がつもりだ何だ、一般 あなたに、今日の話をここに。 だから、あなたが期待できるもの このセッションから、 我々は簡単に通過します データ処理の履歴。 それは常にに便利です 我々はどこから来たのかを理解します 私たちがどこにあるか、なぜ我々がいます。 そして、私たちは少し話しましょう NoSQLの技術について少し 基本的な観点から。 我々はいくつかのになります DynamoDBの内部。 DynamoDBのは、AWSの何の味ではありません。 これは、完全に管理されていますし、 ホスト型のNoSQLソリューション。 そして、私たちはテーブルについて少し話しましょう 構造、APIは、データ型、インデックス、 及び内部の一部 そのDynamoDBの技術の。 私たちはデザインの一部になるでしょう パターンとベストプラクティス。 私たちはどのようにあなたの話をします いくつかのためにこの技術を使用します 今日のアプリケーションの。 そして、我々は、少し話をしましょう 進化や出現について プログラミングにおける新しいパラダイムの イベント駆動型アプリケーション どのようにDynamoDBのは、同様にその中で果たしています。 そして、私たちはあなたの少しを残しておきます 参照アーキテクチャの議論 私たちはいくつかのについて話すことができます 方法はあなたがDynamoDBのを使用することができます。 これが問題であるoff--したがって、最初 私は多くのデータベース何、である聞きます。 多くの人々は、彼らを考えます データベースが何であるかを知っています。 Googleのあなたの場合は、これを参照してくださいよ。 これは、保持されているデータの構造化されたセットです 特に一台のコンピュータで さまざまな方法でアクセス可能です。 私はそれが良いことだと仮定します 現代のデータベースの定義。 しかし、私はので、それを好きではありません それは物事のカップルを意味します。 それは以下の構造を意味しています。 そしてそれは、コンピュータ上にあることを意味します。 そして、データベースはしませんでした 常にコンピュータ上に存在します。 データベースは、実際には多くの方法で存在していました。 のだから、より良い定義 データベースには、このようなものです。 データベースが構成されています 管理、保存するためのメカニズム、 そして、の情報を取得します。 これはAbout.comからです。 だから私は本当にため、交渉をこれが好き リポジトリ中のデータベースについて、 のリポジトリ 情報、必ずしも コンピュータに座って何か。 そして歴史を通して、我々 常にコンピューターを持っていませんでした。 今、私は平均を求めるなら 開発者は、今日は何です データベースには、それは私が得る答えです。 どこか私はものを固執することができます。 右？ そして、それは本当です。 しかし、それは残念です。 データベースが本当にあるので 現代のアプリの基盤。 これは、財団の すべてのアプリケーションの。 そして、あなたはそれを構築する方法 データベース、あなたはどのように構造化 そのデータがどのようにを決定しようとしています あなたがスケールとしてアプリケーションが実行されます。 だから、私の仕事、今日の多く 何を扱っています ときに、開発者が起こります このアプローチを取ります そして余波を扱います その出願の 今元を超えてスケ​​ーリングされます 悪いデザインの意図と苦しみ。 だから、うまくいけば、ときに 今日歩いて、あなたはよ のツールのカップルを持っています あなたをしておこうあなたのベルト それらの同じ間違いを犯すから。 大丈夫。 それでは、少し説明しましょう データベース技術のタイムライン。 私は私が読んだと思います 記事ではないことずっと前に それはlines--に何かを言いました それは非常に詩的な声明です。 それは言っ歴史 データの処理であります ハイウォーターマークの完全な データ豊富なの。 OK。 今、私はそれが一種の真のだと思います。 しかし、私は実際にされているように見えます 履歴は実際に満たされています データ圧の高い透かしを持ちます。 のデータ・レートため 摂取がダウンすることはありません。 それだけ上がります。 そして、革新は場合に発生します 我々は、データの圧力を参照してくださいします あるデータ量であります 今のシステムに入ってくるインチ そして、それを処理することはできません 効率的に時間やコストのいずれかで。 我々が開始するとき、それはです データ圧力を見て。 だから私たちが見る時 最初のデータベース、この 私たちの耳の間であったものです。 私たちはすべてのそれを持って生まれています。 それは素敵なデータベースです。 これは、高可用性を持っています。 それは常にオンです。 あなたはいつもそれを得ることができます。 しかし、それは、単一のユーザーです。 私はあなたと私の考えを共有することはできません。 あなたは私の考えを得ることができません あなたがそれらをしたいとき。 そして、彼らのabilitiyはあまりよくないです。 私たちは物事を忘れます。 すべての今して、私たちの一つの葉 そして、別の存在に移り 私たちはすべてを失います それは、そのデータベースにありました。 だから、すべての良いことではありません。 そして、これは時間をかけてうまくいきました 私たちは一日に戻っていたとき 私たちは本当に知っているために必要なすべてがあるとき ここで我々は明日に行くつもりです またはどこに我々は最高の料理を収集します。 しかし、我々はとして成長し始めたとして、 文明と政府が開始しました 幸福に来て、と 企業は、進化し始めました 我々は、我々を実現するために始めました より少しを必要とするもの 私たちは私たちの頭の中に入れることができます。 大丈夫？ 私たちは、レコードのシステムを必要としていました。 私たちはできるストアデータであること場所を必要としていました。 だから我々は、文書を書き始め、 ライブラリやアーカイブを作成します。 私たちは開発を開始します システム元帳会計。 そして、元帳カウントのそのシステム 何世紀にもわたっ世界を走りました、 多分数千年として 我々は種類のポイントに成長しました ここで、そのデータの負荷が突破 これらのシステムの能力 それを含有することができるようにします。 そして、これは実際には1880年代に起こりました。 右？ 1880年米国国勢調査で。 これは本当にどこに回っています 近代的なデータ処理を指します。 これがポイントであります そのデータ量 それはによって収集されていました 米国政府は、ポイントになりました どこに処理するために8年かかりました。 さて、8 years--として あなたは、国勢調査を知っています 実行ごとに10 years--を、それはですので、 かなり明白その時点で我々 1890年の国勢調査を持って、 そのデータ量 処理することとしていました 政府がしました それそれ10年を超えて行きます 打ち上げ新しい国勢調査にかかるだろう。 これが問題でした。 だから男はハーマン命名します ホレリスが登場しました 彼はユニット・レコード・パンチを発明 カード、パンチカードリーダ、パンチカード タブ、および照合 この技術のためのメカニズム。 そして彼はその会社で形成されました 時間、他のカップルと一緒に、 実際になったの柱の一つ 我々が今日知っている小さな会社では、IBMと呼ばれます。 そこでIBMはもともとしていました データベース事業。 そして、それは彼らが何をしたか、本当にです。 彼らは、データ処理を行いました。 パンチの増殖ように カード、独創的なメカニズム それを活用することができるという ソートされた結果セットをポーリングする技術。 あなたはこの画像で見ることができます そこに我々はlittle--を持っています それは少しsmall--だが、あなたは見ることができます 非常に独創的な機械的なメカニズム 我々はパンチカードデッキを持っているところ。 そして、誰かの撮影 小さなねじ回し そして、を通してこだわっ スロットとそれを持ち上げます ことは、その試合を取得します ソート結果が設定します。 これは集合体です。 我々は、このすべての時間を行います コンピュータで、今日、 あなたは、データベースにそれを行う場所。 我々は右、それを手動で行うために使用しますか？ 人々はこれらの事を一緒に入れて。 そして、それは、増殖しました これらのパンチカード 我々は、データのドラムと呼ばれるものに データリール、紙テープ。 データ処理産業は取り プレイヤーピアノのレッスン。 背面のプレイヤーピアノ 世紀の変わり目 スロット付きの紙リールを使用するために使用 それを再生するためにどのキーを指示します。 だから技術が適応されました 最終的に、デジタルデータを格納します 彼らはそのデータを入れることができますので、 これらの紙テープリールへ。 今、その結果として、データ どのactually--ました あなたは、このデータを直接アクセスしました あなたがそれを保存された方法に依存。 だから私はテープにデータを置く場合、 私は直線的にデータにアクセスしていました。 私は、全体のロールしなければなりませんでした テープは、すべてのデータにアクセスします。 私はパンチのデータを置く場合 カードは、私はそれをアクセスすることができました もう少しランダムで ファッション、そうでないかもしれないとしてすぐに。 しかし、どのように、私たちには限界がありました 保存した方法に基づいてデータへのアクセス。 そして、これが問題でした 50年代に入ります。 繰り返しますが、私たちのようにそれを見始めることができます 処理するための新技術を開発 右側には、データを開きます 新たなソリューションのためにドア、 新しいプログラムのために、新しいです そのデータのためのアプリケーション。 そして実際に、ガバナンス その理由であったかもしれません なぜ我々は、これらのシステムの一部を開発しました。 しかし、ビジネスは急速になりました 進化の背後にあるドライバ 現代のデータベースのと 近代的なファイルシステム。 次の事だから 50年代に思い付きました ファイルシステムであり、 ランダム・アクセス・ストレージの開発。 これはきれいでした。 さて、突然、我々は我々を置くことができます どこでもこれらのハードドライブ上のファイル 我々は、ランダムにこのデータにアクセスすることができます。 我々はそれを解析することができます ファイルのうち情報。 そして、私たちは、世界のすべての解決しました データ処理に問題。 そして、それが続いた約20か 進化するまで30年 リレーショナルデータベースの、どの 世界は今、私たちを決めたときであります 敗北のリポジトリを持っている必要があります ファイル間でのデータのスプロール 我々が構築したシステム。右？ あまりにも多くで配布データが多すぎ 場所、データの重複排除、 およびストレージのコストは膨大でした。 70年代では、最も高価なリソース コンピュータが持っていたストレージがありました。 プロセッサがありました 固定費とみなします。 私はボックスを購入すると、 CPUは、いくつかの作業を行います。 これは、かどうかを紡績することになるだろう それは実際に働くかどうかです。 それは本当にサンクコストです。 しかし、何として私のコスト 事業はストレージです。 私は、次のディスクを購入する必要がある場合 月、それは私が支払う実質的なコストです。 その記憶装置は高価です。 今、私たち早送り40年 我々は、さまざまな問題を抱えています。 計算は今 最も高価なリソース。 ストレージは安いです。 私が意味する、私たちは上の任意の場所に行くことができます 雲と我々は安価なストレージを見つけることができます。 しかし、私は見つけることができないことは安い計算です。 今日の進化だから 技術、データベース技術の、 本当に周りに焦点を当てて 分散データベース 苦しむしません スケールの同じタイプ リレーショナルデータベースの限界。 私たちは、について少し話しましょう それは実際に何を意味するのか。 しかし、理由の一つと this--私たちの背後にあるドライバ データ圧力について話しました。 データ圧力は何かであります それは技術革新を駆動します。 そして、あなたはオーバー見れば 過去5年間、 これは、どのようなデータを示す図表であります 一般的な企業全体の負荷 過去5年間のように見えます。 そして、一般的な経験則 これらdays--あなたはGoogle--に行く場合 データの90％であること 今日保存し、それがありました 最後の2年以内に発生しました。 OK。 さて、これは新傾向ではありません。 これはされてい傾向であります 100年のため外出。 これまでハーマン・ホレリスので、 パンチカードを開発し、 我々は、データリポジトリを構築してきました そして驚異的な速度でデータを収集します。 だから、最後の100年間で、 私たちはこの傾向を見てきました。 それは変更するつもりはありません。 今後は、参照しようとしています この、そうでない場合は加速傾向。 そして、あなたはそれがどのように見えるかを見ることができます。 2010年の事業は、いずれかを持っていた場合 管理下のデータのテラバイト、 彼らがしていることを意味今日 データの6.5ペタバイトを管理します。 それが6500倍以上のデータです。 そして、私はこれを知っています。 私は毎日これらの事業で動作します。 五年前、私 企業に話だろう 誰が何の痛みについて私に話すだろう それは、数テラバイトのデータを管理することです。 そして、彼らは話だろう 私には私たちが見る方法について これはおそらく起こっていること ペタバイトまたは2であることを 数年以内です。 これらの同じ企業 私は会っている今日、 彼らはについて私に話しています 問題管理があったされています 十、データの20ペタバイト。 の爆発そう 業界内のデータ 巨大なを駆動しています より良いソリューションの必要があります。 そして、リレーショナルデータベースです ただ需要まで生きていません。 それで、線形があります データの圧力との相関関係 技術革新。 歴史は私たちを示しています この、その時間の経過とともに、 いつでもデータの量 それは、処理される必要があります システムの容量を超え 妥当な時間でそれを処理します または合理的なコストで、 その後、新技術 これらの問題を解決するために考案されています。 これらの新技術、 今度は、ドアを開けます 問題の別のセットに、どの でも、より多くのデータを収集しています。 今、私たちはこれを停止するつもりはありません。 右？ 私たちはこれを停止するつもりはありません。 なぜ？ あなたはすべてを知ることができないので 宇宙に知っておくべきです。 そして限り、私たちが生きてきたように、 人間の歴史の中で、 私たちは常により多くを知ることが牽引してきました。 だから、私たちが移動あらゆるインチのように思えます 科学的発見の道ダウン、 我々は、データの量を乗算しています 我々は指数関数的に処理する必要があること 我々は、より多くの、よりを発見として 生命の内部の仕組みについて、 宇宙がどのように機能するかについては、約 科学的発見を駆動します、 そして、本発明、その 今日はやっています。 データの量だけ 継続的に増加します。 だから、対処することができるという この問題は膨大です。 物事の1だから、 私たちはなぜNo​​SQLのように見えますか？ どのようにNoSQLのは、この問題を解決するのですか？ さて、リレーショナルデータベース、 構造化照会言語、 本当にの構造ですSQL-- これらの事database--リレーショナルです ストレージ用に最適化されています。 戻る70年代で、再び、 ディスクは高価です。 ストレージのプロビジョニング行使 企業内で終わることはありません。 知っている。 私はそれを住んでいました。 私はのためのストレージドライバを書きました enterprisedスーパーサーバ会社 バック90年代インチ そして、一番下の行は、別のものをラッキングされ ストレージアレイは、ただものでした 企業内のすべての日が起こりました。 そして、それは停止することはありません。 より高密度ストレージ、需要 高密度ストレージのため、 そして、より効率的なストレージのための それが停止することはありませんですdevices--。 そしてNoSQLのは素晴らしい技術です それは、データを正規化するためです。 これは、データを非複製します。 その構造内にデータを置きます すべてのアクセスパターンにとらわれないです。 複数のアプリケーションがそれを打つことができます SQLデータベース、アドホック・クエリを実行し、 彼ら形でデータを取得 そのワークロードのために処理する必要があります。 それは幻想的に聞こえます。 しかし、一番下の行は、任意のです システム、それはすべてのものにとらわれないだ場合、 それは何のために最適化されています。 OK？ そして、それは我々が何を得るのです リレーショナルデータベース。 これは、ストレージ用に最適化されています。 これは、正規化されたのです。 これは、リレーショナルです。 これは、アドホッククエリをサポートしています。 そして、それが垂直方向に拡大または縮小されます。 私は、大きなSQLデータベースを取得する必要がある場合 以上の強力なSQLデータベース、 私は鉄の大きな作品を買いに行きます。 OK？ 私は多くの顧客と働いてきました メジャーアップグレードをしてきたこと そのSQLインフラストラクチャ内のみ 半年後に見つけるために、 彼らは再び壁に当たっています。 また、OracleまたはMSSQLからの回答 または他の誰には大きなボックスを取得することです。 まあ遅かれ早かれ、あなたが購入することはできません 大きな箱、それが本当の問題です。 私たちは、実際に物事を変更する必要があります。 だからここで、これは動作しますか？ これは、オフラインに適しています 分析、OLAP型のワークロード。 SQLが属するところそしてそれは本当にです。 今、それは多くのオンラインで現在使用されています トランザクション処理型 アプリケーション。 そして、それは、単に正常に動作します 利用のいくつかのレベル、 しかし、それだけでスケールしません NoSQLのはない方法。 そして、私たちは少し話しましょう それがある理由について少し。 さて、NoSQLの、他方では、 複数の計算用に最適化されています。 OK？ それはにとらわれないではありません アクセスパターン。 我々は、デ正規化と呼んで 構造や階層構造。 リレーショナルデータベース内のデータがあります 複数のテーブルから一緒に参加しました 必要なビューを生成します。 NoSQLのデータベース内のデータ 文書内に格納されています 階層構造が含まれています。 通常であろうデータのすべて そのビューを生成するために一緒に結合 単一のドキュメントに保存されています。 そして、我々はについて少し話しましょう どのようにチャートのカップルで動作します。 しかし、ここでの考え方は、あなたが保存していることです これらのインスタンス化ビューなどのデータ。 OK？ あなたは、水平方向に拡張できます。 右？ 私は増加する必要がある場合 私のNoSQLクラスタのサイズ、 私は大きなボックスを取得する必要はありません。 私は別のボックスを取得します。 そして、私は、一緒にそれらをクラスタ化 私はそのデータをシャードすることができます。 私たちは、について少し話しましょう であるためには、どのようなシャーディングです そのデータベースを拡張することができます 複数の物理デバイス間 その障壁を取り除きます 垂直方向にスケーリングするために私を必要とします。 だから、それが本当にオンラインのために構築されています トランザクション処理とスケール。 大きな違いがあります ここでは、報告の間に、右？ レポーティング、私は知りません 質問は私がお願いするつもりです。 右？ 誰かからの場合Reporting-- 私のマーケティング部門 私の顧客の何をjust--したいです この特定の特性を持っている人 このday--に買った私にはわかりません 彼らが聞いてどのようなクエリつもりです。 だから私はとらわれないようにする必要があります。 今、オンラインで トランザクション・アプリケーション、 私が求めているものな質問を知っています。 私はのためのアプリケーションを構築しました 非常に特定のワークフロー。 OK？ だから私は、データを最適化する場合 そのワークフローをサポートするために格納します、 それは速くなるだろう。 そして、それはなぜなNoSQLことができます 本当に配信を高速化 サービスのこれらのタイプの。 大丈夫。 だから我々はに取得するつもりです ここで理論を少し。 そして、あなたのいくつか、あなたの目 少しロールバックする可能性があります。 しかし、私はそれを維持しようとするでしょう 私ができる限り高いレベル。 だから、あなたがプロジェクトにいる場合 経営陣は、あります 呼ばれる構造 制約の三角形。 OK。 制約のおもむくままの三角形 あなたはすべてのすべての時間を持つことはできません。 あなたのパイを持って、あまりにもそれを食べることはできません。 だから、プロジェクト管理で、その三角形 制約は、あなたはそれが安いことができますです あなたはそれが速いことができ、 またはあなたはそれが良いことができます。 2を選択してください。 あなたはすべての3つを持つことができませんので。 右？ OK。 だから、このことについて多くのことを聞きます。 これは、トリプル制約です トリプル制約の三角形、 または鉄の三角形がありますoftentimes-- あなたがプロジェクトマネージャに話をするとき、 彼らはこのことについて話しましょう​​。 さて、データベースが持っています 自分の鉄の三角形。 そして、データの鉄の三角形 我々はCAP定理と呼んでいます。 OK？ CAP定理のおもむきます どのようにデータベースが動作 非常に特定の条件の下で。 そして、我々は、約話しましょう その条件が何でありますか。 しかし、三角形の三点、 いわば、C、一貫性があります。 OK？ だからCAPで、一貫性がすべてのことを意味し データベースにアクセスできるクライアント 常に非常になります データの一貫性のあるビュー。 誰のつもりは二つの異なるものを参照してください。 OK？ 私は、データベースを参照してください場合は、 私は同じビューを見ています 見ている私のパートナーとして 同じデータベース。 それは一貫性です。 可用性があればということ オンラインデータベース、それに到達することができれば、 すべてのクライアントは常にその意志 読み書きができるように。 OK？ だから、すべてのクライアントは、 データベースを読み取ることができます 常にことが読み込まれます データとデータを書き込みます。 そして、その場合は、 それは、利用可能なシステムです。 そして、第三のポイントは何ですか 我々は分割耐性を呼び出します。 OK？ パーティション許容手段 システムがうまく機能しています 物理的なネットワークにもかかわらず、 ノード間のパーティション。 OK？ だから、クラスタ内のノードはできません お互いに話、何が起こりますか？ 大丈夫。 だから、リレーショナルデータベースchoose-- あなたは、これらのうちの2つを選ぶことができます。 OK。 だから、リレーショナルデータベースは、選択しました 一貫して利用できるようにします。 パーティションは、間に発生した場合 データストア内のDataNodes、 データベースがクラッシュします。 右？ それはちょうどダウン。 OK。 そして、これは彼らが持っている理由であります 大きな箱と一緒に成長します。 右？ no--通常、クラスタがありますので データベースには、それらの非常に多くありません それはそのように動作します。 しかし、ほとんどのデータベースの規模 垂直方向に単一のボックス内。 彼らがする必要があるため 一貫して利用できます。 パーティションが注入された場合、 あなたが選択をする必要があります。 あなたは間の選択をしなければなりません 一貫して利用可能です。 そして、それはのNoSQLデータベースは何をすべきかです。 大丈夫。 だからのNoSQLデータベースは、それを 2種類があります。 私たちは、それをよくhave-- 多くの種類があります、 しかし、それは、2つの基本的な付属しています 何をcharacteristics-- 我々は、CPデータベース、またはAを呼び出します 一貫してパーティション公差 システム。 これらの人は選択をするときに ノードは、互いとの接触を失います 我々はできるようにするつもりはありません 人々はそれ以上を書き込みます。 OK？ そのパーティションが削除されるまで、 書き込みアクセスがブロックされます。 それは、彼らが利用できないことを意味しています。 彼らは一貫しています。 我々はそれを見るとき パーティションは、それ自身を注入し、 我々は、今一致しています 我々はつもりはないので、 二つのデータの変更を可能にします 独立したパーティションの側面 お互い。 我々はする必要があります 通信を再確立 への更新前 データが許可されます。 OK？ 次の味わいは、APシステムであろうが、 または利用可能とパーティション トレランスシステム。 これらの人は気にしないでください。 右？ 取得任意のノード 我々はそれを取るよ、書きます。 だから、私は、データを複製しています 複数のノード。 これらのノードは、クライアントは、クライアントが来る取得します 、が言うには、私はいくつかのデータを書き込むつもりです。 ノードは、何の問題も言いません。 彼に次のノードを取得します 同じレコードの書き込み、 彼は何の問題も言わないだろう。 どこかバックバックエンドで、 そのデータが複製するだろう。 そして、誰かが実現するために起こっています、 おっと、彼らのシステムは、UH-ああ、理解するであろう、 2つの側部に更新があったです。 私たちは何をしますか？ そして、何彼らはその後、やっていることはあります 彼らが何かをします 彼らはそのデータ状態を解決することができます。 そして、我々は、約話しましょう 次のグラフです。 ここで指摘する事。 そして、私はあまりにも取得するつもりはありません このくらいに、このため、 深いデータ理論に入りました。 しかし、トランザクションがあります 枠組みこと リレーショナルシステムで実行されています 私は安全に更新を行うことができます データベース内の複数のエンティティへ。 そして、それらの更新が発生します 一度にすべてではない、またはまったく。 これはACIDトランザクションと呼ばれます。 OK？ ACIDは私たちに原子性、一貫性を与え、 分離、および耐久性。 OK？ それはすべて、アトミック、トランザクションの意味します 私の更新が発生するいずれか、またはそうではありません。 一貫性があることを意味 データベースは、常に意志 一貫させること 更新後の状態。 私は、データベースを残すことはありません アップデートを適用した後に悪い状態。 OK？ だから、それは少し違います CAPの整合性よりも。 CAPの一貫性は、すべての私のことを意味 クライアントは常にデータを見ることができます。 ACIDの一貫性があることを意味するとき トランザクションは、データの善を行っています。 私の関係は、すべて良いです。 私は親行を削除するつもりはありません そして、孤児の子供たちの束を残します 他のいくつかのテーブルです。 私は一貫してる場合はそれが起こることはできません 酸トランザクションインチ 単離は、そのトランザクションを意味します 常に次々に発生します。 データの最終結果 同じ状態になります それらのトランザクションかのように それは同時に発行されました シリアルに実行されました。 だから、同時実行です データベースで管理。 したがって、基本的に、私はインクリメントすることはできません 二つの操作と同じ値を2回 しかし、私はこの値に1を加えると言えば、 そして、2つのトランザクションが来ます 一つの、それをしよう 最初にそこに行きます もう一方の 後にそこに行きます。 そこで最後に、私は2つを追加しました。 あなたは私が何を意味するか参照してください？ OK。 耐久性は非常に簡単です。 ときトランザクション それはだ、認められています でもそこに行きます システムがクラッシュした場合。 そのシステムが復旧すると、その コミットされたトランザクション 実際にそこになるだろう。 だから、保証です ACIDトランザクションの。 それらはかなりいい保証されています データベースに持っています、 しかし、彼らはそのコストで来ます。 右？ 問題ため、 このフレームワークがあると データ内のパーティションが存在する場合 セットには、私は意思決定を行う必要があります。 私ができるようにする必要がありますするつもりです どちらか一方に更新されます。 そして、それが発生した場合、 その後、私はもう行きますよん 維持することができるようにします これらの特性。 彼らは一貫性がありません。 彼らは孤立されることはありません。 それが壊れるところです リレーショナルデータベースのため。 これが理由の関係であります データベースは垂直スケール。 一方、我々は持っています 基盤技術何と呼ばれています。 そして、これらは、あなたのNoSQLデータベースです。 大丈夫。 だから私たちは、CP、APデータベースを持っています。 そして、これらを使用すると、基本的に呼んでいるものです 最終的に利用可能な、柔らかい状態、 一致しています。 OK？ 基本的に利用できる、なぜなら 彼らは、パーティション寛容です。 彼らはいつもになります そこに、あります場合でも、 ノード間のネットワークパーティション。 私はノードに話すことができるなら、私はよ データを読み取ることができるようになるだろう。 OK？ 私はいつも書き込むことができない場合があります データ私は一貫性のあるプラットフォームだ場合。 しかし、私はデータを読み取ることができるようになります。 ソフトの状態を示し 私は、そのデータを読み取るときに、 それは、他のノードと同じではないかもしれません。 右側は、ノード上で発行された場合 クラスタ内の他のどこかに それが全体にレプリケートされていません まだクラスタ私はそのデータを読み込み、 その状態が一致しない場合があります。 しかし、それは次のようになります 最終的には一貫性のあります、 そのときの書き込みの意味 システムに対して行われ、 それは、ノード間で複製されます。 そして最終的には、その状態 順序にもたらされるだろう、 それは一貫性のある状態になります。 さて、CAP定理本当に 1つの条件のみで再生されます。 これが発生したときに条件があります。 いつでも、それが動作しているため 通常モード、何のパーティションがありません、 すべてが一貫して利用可能です。 あなただけのCAPを心配 私たちは、そのパーティションを持っているとき。 だから、それらはまれです。 しかし、ときにこれらのシステムがどのように反応しますか システムの種類を決定する発生 我々は、扱っています。 それでは、何を見てみましょう それは、APシステム用のように見えます。 OK？ APシステムは、2つの種類があります。 彼らはある味わいに来ます マスターマスター、100％、常に利用可能。 そして、彼らは来ます 他の味、と言います、 あなたは、私が心配するつもりだ知っています このパーティショニングの事について 実際のパーティションが発生したとき。 それ以外の場合は、一次があるように起こっています 権利を取るために起こっているノード。 OK？ カサンドラのようなもの、私たちはそうであれば。 カサンドラは、マスターになります マスター、私は任意のノードに書き込みをしてみましょう。 だから何が起こりますか？ だから私は、内のオブジェクトを持っています 2つのノードで存在するデータベース。 のは、そのオブジェクトSを呼ぶことにしましょう だから我々は、Sの状態を持っています 我々はいくつかの事業を展開しています Sに進行中であること。 カサンドラは、私がすることができます 複数のノードに書き込みます。 それでは、私が手にしましょう 2つのノードに複数のために書きます。 さて、何が起こってしまうです 私たちは、パーティショニングイベントことを呼び出します。 そこではないかもしれません 物理的なネットワークパーティション。 しかし、理由設計の システムのために、それはです 実際にはすぐに分割します 私は2つのノードに書込みを得るよう。 それは私を強制しないことです 1ノードを介してすべてを記述します。 私は2つのノードで書いています。 OK？ だから今、私は2つの状態を持っています。 OK？ 何が起こるだろう 遅かれ早かれあり、 複製イベントがあるように起こっています。 私たちがあるように起こっています これは、パーティションの回復と呼ばれます ここで、これらの二つであります 状態が一緒に戻ってきます アルゴリズムがあるように起こっています それは、データベース内で実行されます 何をするかを決定します。 OK？ デフォルトでは、最後の更新 ほとんどのAPシステムで勝利。 だから、通常あります デフォルトのアルゴリズム、何 彼らは、コールバックを呼び出します 機能、何か ときは、この条件に呼び出されます いくつかのロジックを実行するために検出され その競合を解決します。 OK？ デフォルトのコールバックとデフォルト ほとんどのAPデータベースのリゾルバ で、タイムスタンプが勝つかを推測。 これが最後の更新でした。 私はそこにその更新を置くつもりです。 私はこのレコードをダンプすることができます 回復ログにオフにダンプ ユーザーは、後で戻ってくることができるように そして、言って、ちょっと、衝突がありました。 何が起こった？ そして、あなたは、実際のレコードをダンプすることができます すべての衝突やロールバック そして、何が起こるかを参照してください。 さて、ユーザとして、あなたもすることができます そのコールバックにロジックを含みます。 だから、あなたはそれを変更することができます コー​​ルバックオペレーション。 あなたはちょっと、私が欲しい、と言うことができます このデータを修正します。 そして、私は試してみたいと これらの2つのレコードをマージします。 しかし、それはあなた次第です。 データベースはどのように認識していません デフォルトでそれを行います。ほとんどの時間、 唯一のデータベース 実行する方法を知っていることは言うが、 これは、最後のレコードでした。 それは、勝つために起こっている一つです そしてそれは私が置くつもりだ値です。 そのパーティションの回復したら そして、レプリケーションが発生し、 私たちは、私たちの状態を持っています あるSプライムは、今あります すべてのこれらのオブジェクトのマージ状態。 だから、APシステムは、これを持っています。 CPシステムは必要ありません このことを心配します。 すぐにパーティションが来るようので、 遊びに、彼らは服用を中止します 書き込みます。 OK？ だから、と非常に簡単です 一致しているに対処します ときに、更新を受け付けておりません。 CPシステムが行うとのことです。 大丈夫。 それでは、少し話をしましょう アクセス・パターンについて少し。 私たちはNoSQLのについて話すとき、それはです すべてのアクセスパターンについて。 さて、SQLは、アドホッククエリです。 これは、リレーショナル店です。 私たちは心配する必要はありません アクセスパターンについて。 私は非常に複雑なクエリを記述します。 これは、データを移行し、取得します。 それが、これは見えるものです 以下のように、正規化。 したがって、この特定の構造で、 我々は、製品カタログを見ています。 私は、製品の種類を持っています。 私は本を​​持っています。 私はアルバムを持っています。 私はビデオを持っています。 製品間の関係 これらの書籍のいずれか1つの、アルバム、 やビデオのテーブルは1：1です。 大丈夫？ 私は、製品IDを持っています、 そして、そのIDの対応 本、アルバム、またはビデオに。 OK？ 1の関係：それは1です これらの表の間で。 今、すべての彼らをbooks-- 持っているルートのプロパティです。 問題ない。 それは素晴らしいことです。 一対一の関係、私はすべてを取得します 私はその本を記述するために必要なデータ。 Albums--アルバムは、曲を持っています。 これは、我々は多くのものを呼んでいます。 すべてのアルバムは多くのトラックを持つことができます。 上のすべてのトラックにそう アルバムは、私が持っている可能性が この子テーブルの別のレコード。 だから、私は1つのレコードを作成します 私のアルバムテーブルインチ 私は複数のレコードを作成します トラックテーブルです。 一対多のリレーションシップ。 この関係は何ですか 我々は、多対多を呼び出します。 OK？ あなたは、俳優があり得ることを参照してください。 多くの映画の中で、多くのビデオ。 だから我々は何をすべきか、我々は、このマッピングを入れています それらの間のテーブル、それだけ 動画IDに俳優のIDをマップします。 今、私はジョインクエリを作成することができます 俳優の俳優ビデオを通じてビデオ、 そしてそれは私の素敵なリストを与えます すべてのムービーとすべての俳優 誰がその映画にありました。 OK。 だからここに私達は行きます。 一対一のトップレベルであります 関係;一対多、 トラックにアルバム。多対多。 それらは3トップレベルです 任意のデータベース内の関係。 あなたはどのようにそれらを知っている場合 関係は一緒に働きます、 あなたは多くのことを知っています すでにデータベースに関する。 だから、NoSQLのは少し異なる動作します。 それでは、何それ秒間について考えてみましょう すべての私のプロダクトを取りに行くためにのように見えます。 リレーショナルストアでは、I すべての私の製品を取得したいです すべての私のプロダクトのリストに。 これは、クエリの多くのです。 私はすべての私の本のためのクエリを得ました。 私はアルバムからの照会を得ました。 そして、私はすべての私の動画のクエリを得ました。 そして、私はそれを置くようになりました すべて一緒に、リスト内の そして、まで戻ってそれを提供します それを要求しているアプリケーション。 私の本を取得するには、私が参加します 製品および電子書籍。 私のアルバムを取得するには、私が参加するようになりました 製品、アルバム、およびトラック。 そして、私が持っている、自分の動画を取得します ビデオに製品に参加するには、 俳優ビデオを通じて参加、 そして、俳優をもたらします。 だから、3つのクエリです。 非常に複雑なクエリへ 1つの結果セットを組み立てます。 それは最適ではないのです。 我々は話をするときは、このためです データ構造について アクセスにとらわれないように構築 pattern--よく、それは素晴らしいことです。 そして、あなたは、これは本当に見ることができます 我々はデータを組織してきた方法を素敵。 そして、あなたは何を知っていますか？ 私は俳優のための1つのレコードを持っています。 カッコいい。 私はすべての俳優を重複排除しました、 私は私の関連付けを維持しました このマッピングテーブルです。 しかし、データを取得します アウト高価なものとなります。 私は、すべてのシステム上でのCPUを送っています 一緒に、これらのデータ構造体を接合します そのデータバックを引くことができるようにします。 だから、どのように私はそれを回避するのですか？ NoSQLのでは、についてです 集計ではなく、正規化。 だから我々は、我々がしたいと言いたいです アクセスパターンをサポートしています。 アクセスパターンの場合 アプリケーションへの、 私はすべての製品を取得する必要があります。 1つの表内のすべての製品を入れてみましょう。 私は1つのテーブルにすべての製品を置く場合、 私はすべての製品を選択することができます そのテーブルから、私はそれをすべて取得します。 さて、私はそれをどのように行うのですか？ まあのNoSQLに全くありません テーブルの構造。 私たちは、について少し話しましょう これはどのようにディナモDBに動作します。 しかし、あなたが同じを持っていません 属性と同じ特性 すべての単一の行で、一つ一つの中 あなたのような項目は、SQLテーブルで行います。 そして、何これは私を可能にします やることがたくさんあり​​ます そして、私は多くの柔軟性を与えます。 この特定の場合において、I 私の製品文書を持っています。 そして、この特定で たとえば、すべてのもの Productsテーブル内の文書があります。 そして、この本のための製品がかもしれません 本を指定する、タイプIDを持っています。 アプリケーション そのIDに切り替えることになります。 アプリケーション層で、私は行きますよ ああ、これは何のレコードタイプであると言うには？ ああ、それは本の記録です。 ブックレコードは、これらの特性を有しています。 私は本のオブジェクトを作成してみましょう。 だから私は埋めるつもりです この項目で予約するオブジェクト。 次の項目が付属しており、 このアイテムは何と言いますか？ さて、この項目はアルバムです。 ああ、私は全く違うのです そのための処理ルーチン、 なぜなら、それはアルバムです。 あなたは私が何を意味するか参照してください？ 私tier--だからアプリケーション ただ、すべてのこれらのレコードを選択します。 彼らはすべてに来て起動します。 彼らはすべての異なるタイプである可能性があります。 そして、それは、アプリケーションのロジックです それは、これらのタイプで切り替え それらをどのように処理するかを決定します。 繰り返しますが、私たちは最適化しています アクセスパターンのスキーマ。 我々はしてそれをやっています これらのテーブルを折りたたみます。 私たちは基本的に取っています これらの正規化された構造、 我々は構築しています 階層構造。 これらのレコードのそれぞれの内部 私は、アレイのプロパティを参照するつもりです。 アルバムは、このドキュメントの内部には、 私はトラックの配列を見ています。 これらのトラックは、今ではですbecome-- 基本的にこの子テーブルその 右ここでこの構造で存在しています。 だから、DynamoDBの中でこれを行うことができます。 あなたはMongoDBの中でこれを行うことができます。 あなたは、任意のNoSQLデータベースでこれを行うことができます。 これらのタイプを作成します 階層データ構造 あなたがデータを取得可能にします 非常に迅速になりましたので、私 準拠する必要はありません。 私はトラックに行を挿入すると テーブル、またはアルバム表に行、 私はそのスキーマに準拠する必要があります。 私は属性または持っている必要があります その表に定義されているプロパティ。 それらの一つ一つ、 私は、その行を挿入したとき。 それはNoSQLの中にケースではありません。 私は完全に異なることができます すべての文書のプロパティ 私はコレクションに挿入することを。 だから、非常に強力なメカニズム。 どのように、それは本当にです システムを最適化します。 今そのクエリため、代わりに これらのすべてのテーブルを結合します 半ダースのクエリを実行します 私は必要なデータを引き戻すためには、 私は1つのクエリを実行しています。 そして、私は反復です 結果セット全体。 それはあなたのアイデアを提供します NoSQLのパワーの。 私は種類の横にここに行くつもりです これについて少し話しています。 これは、より多くの一種であります マーケティングやtechnology-- 技術のマーケティング 議論のタイプ。 しかし、それは理解することが重要です 我々はトップを見れば理由 ここでこのチャートでは、 私たちが見ています 我々は呼んでいます 技術のハイプ曲線。 そして、これが意味します 新しいものが場に出ます。 人々は、それは素晴らしいことだと思います。 私はすべての問題を解決してきました。 これが最後かもしれません すべての、すべてにすべてのこと。 そして、彼らはそれを使用して起動します。 そして、彼らはこのようなものが動作しない、と言います。 これは適切ではありません。 古いものは良好でした。 そして、彼らはやってに戻ります 物事彼らがいた方法です。 そして、最終的に 彼らはあなたが何を知って、行きますか？ このようなものはそれほど悪くないです。 ああ、それはそれはどのように動作するかです。 そして、彼らはどのようにそれを把握したら 作品は、彼らが良くなって開始します。 そして、それについての面白いこと それはまで、回線の種類が何でありますか 我々は技術の採用のカーブを呼び出します。 だから私たちは何が起こるかであります 何らかの技術トリガ。 データベースの場合には、 それはデータ圧力です。 我々は、高水点について話しました 時間を通してデータ圧力の。 そのデータは、特定の圧力に達すると 点は、その技術トリガーです。 それはあまりにも高価になっています。 これは、データを処理するために時間がかかりすぎます。 私たちはより良いものが必要。 あなたはイノベーターを取得 そこに走り回って、 ソリューションです何かを見つけるためにしようとしています。 新しいアイデアは何ですか？ 最高の次は何です このことを行うための方法はありますか？ そして、彼らは何かを思い付きます。 そして、本当の痛みを持つ人々、 最先端でみんな、 それらはすべて、それを飛び越えてよ、 彼らは答えを必要とするので。 今どのような必然的にhappens--と それは、NoSQLの中で今起こっています。 私はすべての時間を参照してください。 必然的にされて何が起こります 人々は新しいツールの使用を開始 彼らは古いツールを使用したのと同じ方法です。 そして、彼らはそれを見つけます とてもうまく動作しません。 私は誰だった覚えていないこと 今日以前に話し。 しかし、それは、時のようです 削岩機が発明されました、 人々はそれを上にスイングしませんでした コンクリートを粉砕するために自分の頭。 しかし、それは何です 今日のNoSQLで起こって。 あなたはほとんどの店に歩いている場合、 彼らはNoSQLのショップになろうとしています。 彼らは何をやっています 彼らはのNoSQLを使用しています、 そして彼らはそれをロードしています リレーショナル・スキーマの完全な。 それはどのようなので 彼らは、データベースを設計します。 そして、彼らはなぜですが、迷っています それは非常にうまく行っていませんか？ 少年は、この事は悪臭を放ちます。 私はすべてを維持しなければなりませんでした それは、ない、のようなものですin--参加します。 ジョイン維持？ なぜあなたはデータに参加していますか？ あなたはのNoSQLのデータに加入しません。 あなたはそれを集約します。 これを回避したいのであれば、学びます このツールは、実際にあなたの前にどのように動作しますか それを使用して起動します。 新しいツールを試してみて、使用しないでください 古いツールを使用したのと同じ方法です。 あなたは悪い経験を持っているつもりです。 そして一つ一つの時間 それはこれが何であるかについてです。 私たちはここに来て起動すると、 人々は考え出したので、それはです ツールを使用する方法について説明します。 彼らはときに、同じことをしました リレーショナルデータベースが発明されました、 それらは、ファイルシステムを置き換えました。 彼らは、ファイルシステムを構築しようとしました リレーショナルデータベースと それは、人々が理解するものだからです。 それは動作しませんでした。 だから、ベストプラクティスを理解します あなたが作業している技術の 巨大です。 非常に重要。 だから我々は、DynamoDBのに取得するつもりです。 DynamoDBのは、AWSのです 完全に管理さNoSQLのプラットフォーム。 完全に管理さは何を意味するのでしょうか？ それはあなたがする必要がないことを意味します 本当に何も心配。 あなたが言う、来ます 私たちは、私はテーブルを必要としています。 これは、これだけの容量を必要とします。 あなたはボタンを押すと、我々の提供 シーンの背後にあるすべてのインフラストラクチャ。 今では膨大です。 あなたが話すときので、 データベースのスケーリングについて、 NoSQLのデータクラスタで スケール、ランニングペタバイト、 数百万を実行しています 秒あたりのトランザクション、 これらの事は、小さなクラスターではありません。 私たちは、インスタンスの数千人を話しています。 インスタンスの数千人の管理、 でも仮想インスタンス、 お尻の本当の痛みです。 私が意味する、毎回のANを考えます オペレーティング・システムのパッチが出てきます またはデータベースの新バージョン。 どういう意味ですか あなたに動作？ それはあなたが1200を得た意味します 更新する必要があるサーバー。 今でも自動化と、 それは長い時間がかかることがあります。 それは、多くのを引き起こす可能性があります 運用頭痛、 私は、サービスのダウン持っている可能性があるため。 私は、これらのデータベースを更新するように、私 青緑色の展開を行う可能性があります 私は半分私を展開し、アップグレードする場所 ノードは、その後、残りの半分をアップグレードします。 それらを降ろします。 だから、インフラストラクチャの管理 スケールは非常に痛いです。 そして、AWSはそれから、その痛みを取ります。 そして、のNoSQLデータベースができます 非常に痛みを伴うこと 彼らはスケールの方法のため。 水平スケール。 あなたは大きなNoSQLのを取得したい場合 データベースは、あなたがより多くのノードを購入します。 あなたが買うすべてのノードがあります 別の動作頭痛。 だから、他の誰かがあなたのためにそれをやらせます。 AWSはそれを行うことができます。 私たちは、ドキュメントキー値をサポートしています。 今、私たちはあまり行きませんでした 他のチャート上に。 異なるがたくさんあり​​ます NoSQLのの味。 彼らは得ることのすべての種類です この時点で一緒にmunged。 あなたは、DynamoDBのを見て、イエスと言うことができます 我々は、文書およびキー値の両方です この点を格納します。 そして、あなたは機能を主張することができます 他の上の1つの。 私には、これの多くは実際に6であります 半分他のダースの。 これらの技術の一つ一つがあります 細かい技術や細かいソリューション。 私はMongoDBのが優れているか、言わないだろう その後、ソファー、カサンドラより悪いです、 その後、ダイナモ、またはその逆。 私が意味する、これらは単なるオプションです。 これは、高速だし、です 任意のスケールで一致しています。 これが最大の一つであります あなたがAWSで得るボーナス。 DynamoDBのでは能力があります 低一桁を取得します 任意のスケールでのミリ秒の遅延。 すなわち、システムの設計目標でした。 そして、私たちはやっている顧客を持っています 秒あたりのトランザクション数百万。 今、私はそれらのいくつかを通過します ここ数分でケースを使用しています。 統合アクセスcontrol-- 我々は呼んで何を持っています アイデンティティアクセス管理、またはIAM。 これは、すべてのシステムに浸透し、 AWSが提供するすべてのサービス。 DynamoDBのも例外ではありません。 あなたはアクセスを制御することができます DynamoDBのテーブルへ。 すべてのAWSアカウントアクロスによって アクセスの役割と権限を定義します IAMインフラインチ そしてそれはの中の鍵と不可欠な要素です 私たちは、イベント駆動型プログラミングと呼びます。 さて、これは新しいパラダイムです。 観客は：どのように真のあなたの率です 偽陰性対陽性 お使いのアクセス制御システムに？ RICKフーリハン：真陽性 偽陰性対？ 聴衆：何を返します あなたが戻っすべきですか？ たまには対照的に、それ それが検証する必要がありますときには戻りませんか？ RICKフーリハン：私はあなたにそれを伝えることができませんでした。 いずれかの障害があるとすれば 全くその上で、 私が聞いている人いませんよ その特定の質問。 しかし、それは良い質問です。 私が知りたいであろう 私自身その、実際に。 だから、もう一度、新しいパラダイム イベント駆動型プログラミングです。 これは、あなたができるアイデアです 複雑なアプリケーションを展開すること 非常に、非常に高いスケールを操作することができます いかなるインフラなし。 任意の固定なし 一切インフラ。 そして、私たちは少し話しましょう それが私たちのように何を意味するかについて チャートの次のカップルに乗ります。 私たちがやる最初の事 私たちはテーブルについて話しましょう​​です。 ダイナモのためのAPIデータ型。 まず最初に、あなたはよ あなたがこれを見たときに気付きます、 あなたは、任意のデータベースに精通している場合、 データベースは、APIの実際には2つの種類があります 私はそれを呼び出すと思います。 またはAPIの二組。 それらの一つは次のようになります 管理API。 彼らはの世話をする事 データベースの機能。 ストレージエンジンの設定 セットアップとテーブルを追加。 データベース作成 カタログおよびインスタンス。 DynamoDBの中でこれらのthings--、あなた 非常に短い、短いリストを持っています。 だから、他のデータベースで、 あなたが数十を見るかもしれません コマンドの、行政の 設定するためのコマンド、 これらの追加オプション。 DynamoDBのではあるため、それらを必要としません あなたは我々が行う、システムを設定していません。 だから、あなたがする必要がある唯一のものです 私はどのようなサイズのテーブルが必要なのですか教えてください。 だから、非常に取得します コマンドの限定セット。 あなたは、作成、表の更新、テーブルを取得 表を削除し、表を説明してください。 それらは唯一のものです あなたはDynamoDBのために必要。 あなたは、ストレージを必要としません エンジン構成。 私は、レプリケーションを心配する必要はありません。 私はシャーディングを心配する必要はありません。 私は心配する必要はありません このようなもののいずれかについて。 私たちはあなたのためにそれをすべて行います。 だから、オーバーヘッドの膨大な量です それはちょうどあなたのプレートから持ち上げます。 その後、我々はCRUD演算子を持っています。 CRUDは私たちのものです データベースに呼び出します 作成、更新、演算子を削除します。 これらはあなたの一般的です データベース操作。 プット・アイテムのようなもの、アイテムを取得、更新 アイテムは、アイテムを削除し、バッチクエリ、スキャンします。 あなたは、テーブル全体をスキャンしたい場合。 テーブルからすべてのものを引き出します。 DynamoDBのについての素晴らしいことの一つ それは並列スキャンを可能にします。 だから、実際にどのように多くの私に知らせることができます あなたはそのスキャン上で実行するスレッド。 そして、我々はそれらのスレッドを実行することができます。 私たちは、それがアップスキャンスピンすることができます 複数のスレッド間 あなたは、テーブル全体をスキャンすることができます DynamoDBのには非常に、非常に迅速にスペース。 我々が持っている他のAPIです 私たちは私たちのストリームAPIを呼び出します。 我々はあまりにも話をするつもりはありません 今、この権利について多く。 私は後でいくつかのコンテンツを持っています この程度のデッキでの。 しかし、ストリームは本当にrunning--です 注文した時点と考えます パーティションの変更ログ。 起こっているすべて テーブルには、ストリーム上で表示されます。 すべてのテーブルに書き込みます ストリームに表示されます。 あなたは、そのストリームを読み込むことができ、 あなたはそれで物事を行うことができます。 私たちは何について話しましょう 物事の種類のあなた 複製のようなものをどう、 二次索引を作成します。 本当にクールのすべての種類 物事はあなたがそれを行うことができます。 データ型。 DynamoDBのでは、我々は両方のキーをサポート 値文書データのタイプ。 画面の左側に ここで、私たちは私たちの基本的なタイプを持っています。 キー値の型。 これらは文字列です、 数字、およびバイナリ。 だから3つの基本タイプ。 そして、あなたはそれらのセットを持つことができます。 NoSQLのについての素晴らしいことの一つは、 あなたは、プロパティとして配列を含めることができます。 そして、DynamoDBので、あなたは配列を含めることができます rootプロパティとしての基本的なタイプの。 そして、ドキュメントの種類があります。 どのように多くの人々JSONに精通していますか？ そんなにJSONに精通君たち？ これは、基本的にはJavaScriptのです オブジェクト、表記。 それはあなたが基本的にすることができます 階層構造を定義します。 あなたは上のJSON文書を保存することができます 共通のコンポーネントを使用してDynamoDBの 入手可能であるか、またはビルディングブロック ほとんどのプログラミング言語です。 あなたは、Javaを持っているのであれば、あなたがしています マップやリストを見ています。 私は、その領域のマップオブジェクトを作成することができます。 キーの値としてマップ プロパティとして格納されています。 そしてそれは、のリストを持っている可能性があります これらのプロパティ内の値。 あなたは、この複合体を保存することができます 階層構造 単一の属性として DynamoDBのアイテムの。 DynamoDBの内のテーブルだから、ほとんどのような NoSQLデータベース、テーブルは、アイテムを持っています。 MongoDBのではだろう これらの文書を呼び出します。 そして、それはカウチベースになります。 また、文書データベース。 あなたはこれらの文書を呼び出します。 ドキュメントまたはアイテムが属性を持っています。 属性が存在することができますか アイテムには存在しません。 DynamoDBのでは、あります 1つの必須属性。 ただ、リレーショナルデータベースのように、 あなたは、テーブルの主キーを持っています。 DynamoDBのは、我々はハッシュキーを呼んでいます。 ハッシュキーは一意である必要があります。 だから私は、ハッシュテーブルを定義するとき、 基本的に私が言っています すべての項目は、ハッシュキーを持っているということです。 そして、すべてのハッシュキーは一意でなければなりません。 すべての項目が定義されています その固有のハッシュキーによる。 一つだけ存在することができます。 これはOKですが、しばしば 人々が必要とするもの 彼らが望むのは、このハッシュです もう少しを行うためのキー よりちょうど一意の識別子です。 多くの場合、我々はそのハッシュキーを使用します トップレベルの集計バケットなど。 そして、我々はそれを行う方法があることにより、 我々はレンジキーを呼ん追加。 だから、それはハッシュだけだ場合 テーブルには、これは一意である必要があります。 それは、ハッシュと範囲テーブルの場合は、 ハッシュとレンジの組み合わせ 一意である必要があります。 したがって、この方法でそれについて考えます。 私は、フォーラムを持っている場合。 そしてフォームがトピックを持っている、それが持っています ポスト、それが応答を有しています。 だから私は、ハッシュを持っている可能性があります トピックIDであるキー、。 そして、私は範囲のキーを持っているかもしれませんが、 これは、応答IDです。 そのように私はすべてを取得したい場合 特定のトピックに対する応答、 私はハッシュを照会することができます。 私は私にすべてを与えるだけで言​​うことができます このハッシュを持つアイテム。 そして、私はすべての質問を取得するつもりです またはその特定のトピックを投稿してください。 これらのトップレベルの集計 非常に重要です。 彼らは主要なアクセスをサポート アプリケーションのパターン。 一般に、これを話します 私たちが何をしたいです。 私たちはそのtable--をしたいです あなたがテーブルをロードするように、 我々は、データを構造化したいです そのような方法で、テーブル内 アプリケーションは非常にできること すぐにこれらの結果を取得します。 そしてしばしばそれを行う方法です 我々としてこれらの集計を維持するために、 データを挿入します。 基本的に、我々は、データを分散しています 明るいバケツにそれが入って来ました。 レンジキーはme--ハッシュを許可 キーは平等でなければなりません。 私はハッシュを照会すると、私が言っています 私はこれを等しいハッシュを与えます。 私は範囲を照会すると、私 私に範囲を与えると言うことができます これは、任意の種類を使用しています 私たちはサポート豊富なオペレータ。 私はハッシュのためのすべてのアイテムを与えます。 、より大きい、それは同じです 未満、それはで始まるん、 これら2つの値の間に存在するのか？ だから、範囲クエリのこれらの種類は、 私たちは常に興味を持っていること。 今データに関する一つのこと、時 あなたはときに、データへのアクセスを見て あなたはそれがだ、データへのアクセス 常に集計について。 これは、レコードについて常にです それは、これに関連しています。 ここで私はすべてを与えるすべてthat's-- このクレジットカードの取引 先月のために。 それは集計です。 あなたが行うほとんどすべて データベースには、凝集のいくつかの種類です。 そのように定義することができることができること これらのバケット、あなたにこれらの範囲を与えます 照会できるようにする属性 これらの豊富なクエリは、多くのサポート 多くの、多くのアプリケーション・アクセス・パターン。 だから、他の事ハッシュキー それは私たちのメカニズムを与えています 周囲にデータを分散することができるようにします。 NoSQLデータベースが最適に動作 データが均等にあるとき クラスタ全体に分散。 どのように多くの人が理解しています ハッシュアルゴリズムと？ 私はハッシュとhashing--を言うとき ハッシュアルゴリズムのため 生成することができるという方法であります 任意の値からランダムな値。 この特定のケースでそう、 私たちが実行してハッシュアルゴリズムがベースのND 5です。 そして、私はIDを持っており、この場合 私のハッシュキーであり、Iは1、2、3を有しています。 私は、ハッシュアルゴリズムを実行すると、 それが戻ってくると言うために起こっています、 ウェル1は、2（b）に等しいです 3は、CDに等しい、48に等しいです。 これらは、すべての鍵空間に広がっています。 そして、なぜあなたはこれを行うのですか？ それは確かに私ができることになりますので 複数のノード間でレコードを置きます。 私はこれをやっている場合 増分、1、2、3。 そして、私はそのハッシュ範囲を有します この特定のケースで実行され、 小さなハッシュ空間、 それは00からFFまで実行され、 その後、レコードが入ってくるとしています それらは、1、2、3、4、5に行くつもり 6、7、8、9、10、11、12。 何が起こるのですか？ すべてのインサートは、同じノードに起こっています。 あなたは私が何を意味するか参照してください？ 私はスペースを分割するときので、 私は、全体でこれらのレコードを広めます 私は、私が言うつもりパーティション パーティション1は54に鍵空間0を持っています。 パーティション2は89から55です。 パーティション3はFFにAAです。 だから私は直線的にインクリメント使用している場合 IDは、あなたは何が起こっているかを見ることができます。 1、2、3、4、5、6、54までのすべての方法。 だから私は打撃だとして システムへの記録、 すべてが一つのノードに行くまで終了します。 それは良いことではありません。 それはアンチパターンです。 MongoDBの中で、彼らはこの問題を抱えています あなたはハッシュキーを使用しない場合。 MongoDBのはあなたのオプションを提供します キー値をハッシュ。 場合は、いつでも、それを行う必要があります あなたはインクリメントハッシュを使用しています MongoDBの中のキー、またはあなたがすることがあります 一つのノードにすべての書き込みを釘付け、 あなたが制限されます ひどくあなたの書き込みスループット。 聴衆：そのA9 169は10進数ではありますか？ RICKフーリハン：ええ、それはです どこかの周り。 A9、私は知りません。 あなたは私のバイナリを取得する必要があるだろう 小数計算します。 私の脳はそのように動作しません。 聴衆：だけで簡単に1 あなたのMongoのコメントの。 だから来るオブジェクトIDです ネイティブモンゴでそれを行いますか？ RICKフーリハン：それはそれをするのでしょうか？ あなたはそれを指定した場合。 MongoDBのを使用すると、オプションがあります。 あなたにはすべての文書をspecify--することができます MongoDBのは、アンダースコアのIDを持っている必要があります。 それは固有の値です。 MongoDBのでは指定することができます それをハッシュするかどうか。 彼らはただあなたにオプションを与えます。 あなたはそれがだことがわかっている場合 ランダム、問題ありません。 あなたはそれをする必要はありません。 あなたはそれがいることを、ランダムではないことがわかっている場合 それが増加していますし、ハッシュを行います。 今についての事 あなたはハッシュと、ハッシング value--これがあります なぜハッシュキーは常にあります ユニークなクエリ、私が変更したので、 値は、今私は範囲のクエリを実行することはできません。 私はこれがあると言うことはできません このまたはそれとの間、 ハッシュ値が起こっていないので 実際の値と等価であると。 ですから、そのハッシュ時 キー、それだけで平等です。 これはなぜDynamoDBのハッシュキーにあります クエリは、常に唯一の平等です。 だから今の範囲内のkey-- 私は、その範囲のキーを追加すると、 これらの範囲のキーレコードはすべてで来て、 それらが同じパーティションに格納されます。 そこで、彼らは簡単に、非常に迅速にしています これはハッシュであるので検索し、 これは範囲です。 そして、あなたはすべてを見ます 同じハッシュを持ちます 同じパーティション領域に格納されます。 あなたは助けるために、その範囲のキーを使用することができます その親に近いデータを検索します。 だから私は本当にここで何をやっていますか？ これは、多くの関係に一つです。 ハッシュキーとの関係 および範囲キーは、多くの1つです。 私は、複数のハッシュキーを持つことができます。 私は複数の範囲を持つことができます すべてのハッシュ・キー内のキー。 ハッシュは、親を定義し、 範囲は、子どもたちが定義されています。 だから、あなたが見ることができるアナログがここにあります リレーショナル構造との間に そして、同一の種類は NoSQLの中の構築。 人々はについて話します 非リレーショナルなどのNoSQL。 これは、非リレーショナルではありません。 データは常に関係を持っています。 それらの関係だけ 異なるモデル化されています。 それでは、少しお話しましょう 耐久性について少し。 あなたがDynamoDBのに書き込むときは、書き込み 常に三方が複製されます。 私たちは3 AZのを持っていることを意味します。 AZのは、利用可能ゾーンです。 あなたは空を考えることができます データセンターなどのゾーン またはデータセンターのコレクション。 これらのことは、地理的にあります 互いに分離 異なる断層帯全体で、全体の 電力網と氾濫原異なります。 1アリゾナ州の故障ではありません 別のダウン取るつもり。 彼らはまた、連結されています 一緒にダークファイバと。 それは、一つのサブをサポートしています1 AZS間のミリ秒の待ち時間。 だから、リアルタイムデータレプリケーション マルチAZSで可能。 そして、多くの場合、マルチAZ配備 高可用性の要件を満たします ほとんどの企業組織の。 だから、DynamoDBのが広がっています デフォルトでは3 AZS全体で。 私たちは、知識だけに書き込みを行っています これらの3つのノードの2が戻ってきたとき そして、言って、ええ、私はそれを得ました。 何故ですか？ 読み出し側に我々だけだから バックするときにデータを提供するつもり 我々は、2つのノードからそれを取得します。 私は全体で複製していた場合 3、私は、2から読んでいます 私は常に保証されています 少なくとも一つを有すること ものであると読み取ります データの最新のコピー。 それはDynamoDBのが一貫するものです。 今、あなたがオンに選択することができます これらの一貫性のあるオフ読み込みます。 その場合、私は言うつもりです、 私は1つのノードからのみ読み込まれます。 そして、私はそれが起こっているのを保証することはできません 最新のデータであることを。 書き込みがで来ているのであれば、 それは、まだレプリケートされていません あなたはそのコピーを取得するつもりです。 それが最終的に一貫した読み取りです。 そして、何それはあることは半分のコストです。 だから、これは考えるものです。 あなたはDynamoDBのを読んでいるとき、および あなたがリードキャパシティを設定しています ユニットは、あなたが最終的に選択した場合 一貫性は、それはかなり安いですが、読み込み、 それは、約半分のコストです。 そしてそれはあなたのお金を節約できます。 しかし、それはあなたの選択です。 あなたは読取り一貫性が必要な場合、または 最終的に一貫した読み取り。 それはあなたが選択することができるものです。 それでは、インデックスについてお話しましょう​​。 だから我々は、と述べました トップレベルの集計。 私たちは、ハッシュキーを持っているし、 我々はレンジキーを持っています。 それはすばらしい。 そして、それは、主テーブルの上に私です 1つのハッシュキーを持って、私は1つの範囲のキーを得ました。 どういう意味ですか？ 私は一つの属性を持っています 豊かなクエリを実行することができます。 これは、範囲のキーです。 その上で他の属性item-- 私はそれらの属性に基づいてフィルタすることができます。 しかし、私はそれのようなものを行うことができません 始まる、またはより大きい。 それ、どうやったら出来るの？ 私は、インデックスを作成します。 2つのタイプがあります DynamoDBの中のインデックス。 インデックスは実際にあります テーブルの別の図。 そして、ローカルセカンダリインデックス。 私たちが話しましょう​​最初のもの。 だから、地元のセカンダリが共存しています データと同じパーティションに。 そのようなものとして、それらは、上にあります 同じ物理ノード。 彼らは、私たちが一貫呼んでいます。 意味、彼らが認めるます テーブルと一緒に書き込み。 書き込みが入ってくる場合には、 私たちは、索引を介して書きます。 私たちは、テーブルまで書きますよ し、我々は認めます。 だから、一貫性のあります。 書き込みがされた後 テーブルから認め、 ことが保証されています ローカルセカンダリインデックス データの同じビジョンを持っています。 しかし、彼らができるようにあなたがやっていることです 別の範囲のキーを定義します。 同じハッシュを使用する必要があります 主テーブルとしてキー、 それらがされているために共存 同じパーティション、彼らは一貫しています。 しかし、私は、インデックスを作成することができます 異なる範囲のキーを使用して。 例えばだから、私はメーカーがあった場合 それは、生の部品表が入って来ていました。 そして、生の部品が入って来て、 彼らは、アセンブリ別に集計しています。 そしておそらく、リコールがあります。 このによって作られた任意の部分 この日付以降、メーカー、 私は私のラインからプルする必要があります。 私は、インデックスを回転することができます それは、探していることになります の日に集計 その特定の部分の製造。 だから私のトップレベルのテーブルがあった場合 すでにメーカーによってハッシュ化されました、 多分それは私が、部品IDに配置し、 そのテーブルからインデックスを作成することができます メーカーによってハッシュのように 製造日の範囲でした。 私が言うことができるとそのように、何も これらの日付の間に製造されました、 私はラインからプルする必要があります。 だから、ローカルセカンダリインデックスです。 これらの効果を有します あなたのハッシュキーのスペースが制限されます。 これらが共存しているため 同じストレージノード上で、 それらは、ハッシュキーを制限します 10ギガバイトのスペース。 DynamoDBの、下 テーブルは、パーティション化されます あなたのテーブルごとに10ギガバイト。 あなたは、データの10のライブを​​入れたとき、我々 【PHH]行き、私たちは別のノードを追加します。 我々は、LSIを分割しません 複数のパーティション間で。 我々は、テーブルを分割します。 しかし、我々は、LSIを分割しません。 だから、何か 理解することが重要 あなたは非常にやっている場合で、 非常に、非常に大規模な集計、 あなたが制限されることになるだろう あなたのLSI上の10ギガバイトまで。 その場合は、我々はできます グローバルセカンダリを使用しています。 グローバルセカンダリがあります 本当に別のテーブル。 彼らは完全にオフに存在します あなたの主テーブルの側。 そして、彼らは私が見つけることができ 全く異なる構造。 データが挿入されているように、それを考えます 2つの異なるテーブルに、構造化 二つの異なる方法です。 私は完全に定義することができます 異なるハッシュキー。 私は完全に定義することができます 異なる範囲のキー。 そして、私はこれを実行することができます 完全に独立。 実際のところ、私はしました 私の読み取り能力をプロビ​​ジョニング 私のための能力を書きます グローバルセカンダリインデックス 完全に独立して 私の主テーブルの。 私はそのインデックスを定義すると、私が言います それはどのくらいの読み取りおよび書き込み 容量は、それが使用することになるだろう。 そして、それは別のものです 私の主テーブルから。 今すぐインデックスの両方をするために私達を許可します ハッシュとレンジキーを定義するだけでなく、 しかし、彼らは私たちができるようにします 追加の値を投影します。 だから私は、インデックスを読み取るしたい場合は、 私はいくつかのデータセットを取得したいです、 私がメインに戻る必要はありません 表には、追加の属性を取得します。 私はそれらの追加を投影することができます テーブルに属性 アクセスパターンをサポートしています。 私たちは、おそらくいくつかの中に取得している知っています 本当に、雑草になっreally-- ここではこのようなもののいくつかの。 今私はこのうちドリフトするようになりました。 聴衆：[聞こえません] --tableキーがハッシュた意味しましたか？ オリジナルのハッシュ？ マルチスラット？ RICKフーリハン：はい。 はい。 基本的にはテーブルキー 戻ってアイテムを指しています。 そこでインデックスはバックへのポインタであります テーブルの上にオリジナルアイテム。 今、あなたは構築することを選択できます 唯一のテーブルキーを持つインデックス、 なしその他のプロパティ。 そして、なぜ私はそれを行うのでしょうか？ まあ、私は非常に大規模なアイテムを持っています。 私は実際には知っておく必要がありますwhich-- 私のアクセスパターンは、言うかもしれません どの項目は、このプロパティが含まれていますか？ アイテムを返す必要がないようにしてください。 私は知っている必要があります どの項目を含んでいます。 ですから、インデックスを構築することができます その唯一のテーブルキーを持っています。 しかし、それは主に何 データベース内のインデックスがためのものです。 それはすぐにできることのためです 、記録する特定 どの行、どの 表中の商品はあり 私が探しているプロパティ。 GSISので、どのように動作するのですか？ GSISは基本的に非同期です。 更新は、表に出たとき、 テーブルが非同期で更新されます あなたのGSISのすべて。 GSISがある理由はここにあります 最終的に一致しています。 これは、ことに注意することが重要です あなたはGSISを構築しているときに、 そしてあなたが作成している理解します aggregation--の別の次元 今のが良い例をしましょう ここメーカーです。 私は私が話をしているかもしれないと思います 医療機器メーカー。 医療機器メーカー しばしばシリアル化された部分があります。 入るパーツ 人工股関節置換すべて それらにほとんどのシリアル番号を持っています。 そして、彼らは何百万を持っている可能性があり、 部品の何百万と数十億 彼らは出荷するすべてのデバイスです。 まあ、それは下集約する必要があります 異なる寸法、すべての部分 アセンブリ内の、すべての 作られた部品 特定の行に、すべての 来パーツ 特定のメーカーからで 特定の日に。 そして、これらの集計時々 十億に立ち上がります。 だから私はいくつかのと協力 苦しんでいるこれらの人 彼らが作成しているため、 これらのとてつもなく大きい集計 そのセカンダリインデックスインチ 彼らは生の部分があるかもしれません ハッシュだけとして来るテーブル。 すべての部分は、固有のシリアル番号を持っています。 私はハッシュとしてシリアル番号を使用しています。 美しい。 私の生データテーブルが広がっています すべての鍵空間全体で。 じぶんの [？書きます ？] [？摂取は？]素晴らしいです。 私は大量のデータを取ります。 その後、彼らは何をすべきか、彼らはGSIを作成することです。 そして、私は私が確認する必要があり、あなたは何を知っている、と言います このメーカーのためのすべての部品。 さて、突然私はよ 億行を取って、 とにそれらを詰め込みます 1ノード、時のため 私はのように集約します ハッシュとしてメーカID、 範囲とし、部品番号、 その後、私は突然のすべて 何に億部品を置きます このメーカーは私を提供してきました。 それは多くを引き起こす可能性があります GSIへの圧力の、 再び、私は1つのノードを打っていますので。 私はこれらをすべて入れています 一つのノードに挿入します。 そして、それは本当の問題のユースケースです。 今、私は良いデザインを持って あなたはそれを避ける方法のためのパターン。 そして、それは問題の一つです 私はいつもと動作すること。 しかし、何が起こるかは、国土地理院のかもしれないです 十分な書き込み能力を持っていません すべてのそれらをプッシュすることができるようにします 単一のノードに行。 そして、何が起こるかは、その後で 一次、クライアントテーブル、 主テーブルが絞られます GSIは追いつくことができないからです。 だから私の挿入率はなります 主テーブルの上に落ちます 私のGSIは追いつくしようとします。 すべての権利、LSIの、国土地理院のように、 私はどちらを使うべきでしょうか？ 本LSIのは、一貫しています。 GSIのは、最終的に一致しています。 それがOKなら、私が使用することをお勧めします 国土地理院は、彼らがはるかに柔軟です。 本LSIのは、国土地理院のようにモデル化することができます。 そして、もしハッシュキーあたりのデータサイズで あなたのコレクションは、10ギガバイトを超えると、 その後、あなたはそれを使用したいとしています GSIそれだけでハードリミットだから。 すべての権利なので、スケーリング。 ディナモDBにおけるスループット、あなた 缶条項[聞こえません] テーブルへのスループット。 私たちは持っている顧客を持っています プロビジョニング60 billion-- 定期的に、600億の要求を行っています 万人以上の要求で実行されています 私たちのテーブルで毎秒。 いいえ、本当にあり どのくらいの理論的限界 そして、どのくらいの速テーブル ディナモDBに実行することができます。 いくつかのソフトがあります。 アカウントの制限 私たちはそこに置くこと あなたが夢中にしません。 あなたはより多くをしたい場合 その、問題ありません。 あなたは私たちを教えています。 私たちは、ダイヤルを上げます。 すべてのアカウントはいくつかのレベルに制限されています すべてのサービスで、ちょうどバットオフ だから人々は夢中にしないでください トラブルに自分自身を取得します。 サイズの制限はありません。 あなたは、任意の数を置くことができます テーブルの項目の。 アイテムのサイズは 400キロバイトそれぞれに制限され、 それは、アイテムの属性ではないだろう。 すべての属性の合計だから 400キロバイトに制限されています。 そして再び、私たちは持っています その小さなLSIの問題 ハッシュあたり10ギガバイトの制限付き。 対象：小数は、私が欠けています あなたは、それを私に言っていますis-- 聴衆：ああ、400キロバイト 項目ごとの最大サイズです。 だからアイテムはすべての属性を持っています。 だから、400 kは合計サイズです その項目の、400キロバイト。 すべての属性のだから、 組み合わせることで、すべてのデータ それはすべてのそれらの属性にです、 合計サイズにロールアップ、 現在、今日のアイテムの上限は400 Kです。 だから実現、再びスケーリング パーティショニングを通じ。 スループットがプロビジョニングされています 表レベルで。 そして、実際には2つのノブがあります。 私たちは能力を読んでいます 能力を記述します。 したがって、これらを調整します 互いに独立。 RCUの対策読み込み厳密に一致しています。 [OK]を、私は千をしたいと言っているので、もし RCUのものは、厳密に一致しています これらの読み取り一貫しています。 あなたは私が欲しいと言うなら 、最終的な一貫性のある読み取り あなたが提供することができます千 RCUのは、あなたが行っています 最終的に2000を取得します 一貫した読み取り。 そして、それらのための半額 最終的に読み込むに構成​​されています。 ここでも、調整 互いに独立。 そして、彼らはthroughput--を持っています あなたがRCUの100％を消費した場合、 あなたが影響を与えるつもりはありません あなたの権利の利用可能性。 そこで、彼らは完全にあります 互いに独立しました。 すべての権利なので、そのことの一つ 私は簡単にスロットリングされた言及しました。 スロットリングが悪いです。 スロットリングは悪い何もSQLを示していません。 我々は助けるためにできることがあります。 あなたはスロットリングを軽減 経験しています。 しかし、最善の解決策 これにのは見てみましょうです なぜなら、あなたがやっていることを見て、 ここで、プレイ中のアンチパターンがあります。 これらのこと、不均一のようなもの ワークロード、ホットキー、ホットパーティション。 私は特定のキースペースを打ちますよ 非常に難しいいくつかの特定の理由があります。 なぜ私はこれをやっていますか？ のはそれを把握しましょう​​。 私は寒さのデータと私のホット・データを混合しています。 私は私のテーブルが取得させますよ 巨大な、本当にあります データの一部だけ それは私には本当に面白いです。 そうのログデータのために、例えば、ロット 顧客は、彼らが毎日ログデータを取得します。 彼らは、ログデータの膨大な量を得ました。 あなただけのすべてのそのログをダンプしている場合 時間をかけて一つの大きなテーブルにデータ、 その表は、大規模な取得するつもりです。 しかし、私は本当に唯一の興味 過去24時間、過去7日間、 過去30日間。 時間のどんな窓 私が探しているに興味があること 私を悩ます、またはイベントのために 私には面白いイベント、 それは私が必要とするだけで、ウィンドウの時間です。 なぜ私は、10年を入れています テーブル内のログデータの価値は？ 何が原因であること テーブルの断片。 それは巨大な取得します。 それは広がる開始します 数千のノードを横断。 そして、あなたの能力以来 あなたがしている、非常に低いです 実際にそれぞれの上にレート制限 これらの個々のノードの一つ。 それでは、どのように見てみましょう 我々は、その表をロールオーバー行います。 私たちは、そのデータを少し管理するにはどうすればよいです 優れたこれらの問題を回避します。 そして、何それは次のように見えますか？ これは、それがどのように見えるかです。 これは悪いのNoSQLのように見えるものです。 私はここでホットキーを得ました。 あなたがこちら側に見てみると、 これらはすべて私のパーティションです。 私はここで16個のパーティションを持って この特定のデータベースに。 我々は、このすべての時間を行います。 私は顧客のためにすべての時間を、これを実行します。 これは、ヒートマップと呼ばれています。 ヒートマップは、あなたはどのようにしている私に指示 あなたの鍵空間をアクセスします。 そして、何これは私に言っていることです ある特定のハッシュがあること この男が好きなこと 非常に多く、彼はだから 本当に難しい、実際にそれを打ちます。 だから、青がいいです。 私達は青が好きです。 私たちは赤が好きではありません。 レッドの場合は圧力 100％になります。 100％が、今あなたが絞らことになるだろう。 だから、のような赤い線が表示されるたびに this--、それだけでディナモDB--ではありません すべてのNoSQLのデータベースは、この問題があります。 そのことができますアンチパターンがあります。 条件のこれらのタイプを駆動します。 私は何をすると私は顧客との仕事です これらの条件を緩和します。 そして、何それは次のように見えますか？ そして、これはほとんどを得ています ダイナモのDBスループットのうち、 それが本当になってきました NoSQLのうち最も。 これは、ダイナモに限定されるものではありません。 これはdefinitely--私です モンゴで働いていました。 私は多くのNoSQLのプラットフォームに精通していますよ。 一人一人は、これらのタイプを持っています ホットキーの問題。 任意のNoSQLのを最大限に活用するには データベース、特にダイナモDB、 あなたは、テーブルを作成したいです ここで、ハッシュキー要素が持ちます 個別の値の数が多いです、 カーディナリティの高いです。 それは私が書いていることを意味するので 異なるバケットの多くに。 私はより多くのバケツ やすく、に書き込みます 私はその書き込み負荷を分散するために午前または 複数のノード全体にロード読み、 私が持っていることになっている可能性が高いです テーブルの上に高スループット。 そして、私は値になりたいです 時間をかけて均等に要求 かつ均一としてランダムに可能な限り。 まあ、それは、一種の面白いです 私は本当にことができるので、 ユーザーは来るコントロール。 私たちが広がるのであれば、言えば十分 鍵空間全体で物事うち、 我々は、おそらくより良い形になるだろう。 特定があります 納期の量 あなたがつもりはないこと できる制御することができます。 しかし、それらは実際にあります 我々が持っている二次元、 スペース、アクセス均等 スプレッド、時間、要求 均等時間に離間到着します。 そして、これら二つの場合 条件が満たされています、 その後、それはそれは何です 以下のように見に行きます。 これは非常に良くあります。 ここでは本当に満足しています。 我々は非常にさえアクセスパターンを持っています。 うん、多分あなたは取得しています 少し圧力すべての今して、 何も本当にあまりにも広範囲。 だから、何回驚くべきことです 私は顧客と作業するとき、 大きな赤いでその最初のグラフ バーと、それはだすべてのこと醜い黄色 すべての場所の上に、我々 運動で片付けます 数ヶ月後に 再建築の、 彼らはまったく同じを実行しています 完全に同じ負荷でのワークロード。 そして、これは、それが今のように見ているものです。 それでは、あなたはNoSQLので得ることです 絶対にあるデータスキーマ アクセスパターンに縛ら。 そして、あなたはそのデータスキーマを最適化することができます そのアクセスパターンをサポートしています。 そうしない場合は、つもりです 問題のこれらの種類を表示するには これらのホットキーを持ちます。 聴衆：まあ、必然的にいくつかの場所 他のものよりも熱いことを行っています。 RICKフーリハン：常に。 常に。 ええ、私は常にある意味します A--して再度、あります 我々は介して取得しますいくつかのデザインパターン それはあなたが対処方法についてお話します これらの超大型集計しています。 私が意味する、私はそれらを持っているようになりました、 どのように我々はそれらに対処しますか？ 私はかなり良いユースケースを持って 我々はそのための話だろうと。 すべての権利、それでは、話をしましょう 今いくつかの顧客に関する。 これらの人はAdRollです。 あなたがしている場合、私は知りません AdRollに精通。 おそらく、それらを参照してください ブラウザ上でたくさん。 彼らはしている、広告再ターゲティングしています 最大の広告再ターゲティング事業 そこに。 彼らは通常、定期的に轢か 一日あたり600億のトランザクション。 彼らは百万を超えるやっています 秒あたりのトランザクション。 彼らは、非常に単純なテーブルを持っています 構造、最も忙しいテーブル。 それは基本的にはちょうど ハッシュキーは、クッキーです 範囲は、人口統計です カテゴリ、及びその後 第三の属性がスコアです。 だから我々はすべてにクッキーを持っています これらの人からの私達のブラウザ。 そして、あなたがに行くとき 商人の参加、 彼らは基本的には全体のあなたのスコア さまざまな人口統計学的範疇。 あなたがウェブサイトに行くときと 私はこのad--を見たいと言います または基本的にはthat--を言うことはありません しかし、あなたがウェブサイトに行くとき 彼らはあなたがこの広告を見たいと言います。 そして、彼らはAdRollからその広告を取りに行きます。 AdRollはそのテーブルの上にあなたを検索します。 彼らはあなたのクッキーを見つけます。 広告主は言って 彼らは、私は誰かをしたいです 誰が、中年です スポーツへの40歳の男性、。 そして、彼らはそれらの人口統計であなたのスコア 彼らはかどうかを判断 それはあなたのために良い広告です。 今、彼らはとのSLAを持っています その広告プロバイダ サブ10ミリ秒を提供します 一つ一つのリクエストに応じて応答。 そこで、彼らはこのためディナモDBを使用しています。 彼らは私たち当たっています 毎秒百万の要求。 彼らはすべての操作を行うことができるしています 検索、トリアージすべてそのデータ、 それが戻ってそれへのリンクを追加します 10ミリ秒未満で広告主。 それは実際にはかなり驚異的です 彼らが持っている実装。 これらの人はactually-- 人はこれらです。 私はそれがこれらの人だかはわかりません。 これらの人かもしれません。 基本的に私は、ノーus--語りました それが彼らだったとは思いません。 私はそれが他の誰かだったと思います。 私が働いていました 私に言った顧客 その今、彼らがしたこと ディナモDBに行って、彼らがしています 以下のためのスナックに多くのお金を費やし その開発チーム毎月 彼らは彼らのデータベースに費やすより。 だから、あなたを与えるだろう コスト削減のアイデア あなたがディナモDBに得ることができることをすることは巨大です。 すべての権利、dropcamの別の会社。 この男のようなものof--あなたが考える場合 モノのインターネットの、dropcam 基本的にインターネットセキュリティビデオです。 あなたはそこにカメラを置きます。 カメラが動き検出器を持っています。 誰かがやって来る、 キューポイントをトリガします。 カメラまでのしばらくの間、記録を開始します それは、もはや任意の動きを検出しません。 インターネット上でそのビデオを配置します。 Dropcamはある会社でした 基本的にはダイナモDBに切り替え 彼らが経験していたので、 巨大な成長の痛み。 そして、彼らは私たちに言いました、 突然データのペタバイト。 彼らは考えに彼らのサービスがありませんでした そう成功するだろう。 YouTubeのより詳細インバウンドビデオ これらの人が取得しているものです。 彼らはすべてを追跡するためにDynamoDBのを使用 すべてのビデオのキーポイント上のメタデータ。 そこで彼らは、彼らがプッシュS3バケットを持っています すべてのバイナリアーティファクトに。 そして、彼らが持っています ダイナモDBが記録します これらのS3の3つのオブジェクトに人々を指します。 彼らはビデオを見てする必要がある場合は、 彼らはディナモDBのレコードを検索してください。 彼らは、リンクをクリックします。 彼らは、S3からの映像をプルダウン。 だから、これはどのように見えるかのようなものです。 そして、これは彼らのチームからまっすぐです。 ディナモDBは彼らを低減 ビデオイベントの配達時間 5〜10秒。 古いリレーショナル店では、 彼らが行くと、実行する必要があるために使用されます 図のように、複数の複雑なクエリ ビデオは、プルダウンするためにどのアウト 50ミリ秒未満です。 だから、素晴らしい、驚くべきことです どのくらいのパフォーマンス あなたが最適化するときあなたが得ることができると あなたのチューニング基礎となるデータベース アクセスパターンをサポートしています。 Halfbrickは、これらの人、それは何ですか、 フルーツ忍者は、私は彼らのものだと思います。 ディナモDB上のすべての実行されていること。 そして、これらの人は、彼らは素晴らしいです 開発チーム、大きな発展 ショップ。 良くないOPSチーム。 彼らは多くを持っていませんでした 操作リソース。 彼らは維持しようと奮闘しました。 そのアプリケーションインフラアップ そして、実行しています。 彼らは私たちに来ました。 彼らは、ディナモのDBを見ました。 彼らは、それが私たちのためだ、と述べました。 彼らは全体を建て その上にアプリケーションフレームワーク。 ここではいくつかの本当に素晴らしいコメント 能力のチームから 今の建物に焦点を当てます ゲームではなく、 維持すること インフラ、これ 膨大な量になってきました 彼らのチームのためのオーバーヘッドの。 だから、これは何かでありますthat-- あなたはダイナモDBから取得する利益。 すべての権利、入ります ここではデータモデリング。 そして、我々はについて少し話をしました この一から一、多くの1つ、 そして、多くの種類の関係に多くの。 そして、どのようにあなたはダイナモでそれらを維持します。 ディナモDBでは、使用します インデックスは、一般的に言えば、 データを回転させます 他の1つのフレーバー。 ハッシュキー、レンジキー、およびインデックス。 この特に、 たとえば、ほとんどの州として ライセンスの要件を持っています 人ごとに1つの運転免許証。 あなたは、2つのドライバのを取得するために行くことができません ボストンの状態でライセンス。 私はテキサスでそれを行うことはできません。 それはそれは方法のようなものです。 それでDMVで、私たちは、ルックアップを持って、我々 運転免許証を見てみたいです 社会保障番号で。 私は、ユーザーの詳細を見てみたいです 運転免許証番号で。 だから我々は、そのユーザーのテーブルを持っている可能性があります シリアル番号でハッシュキーを有し、 または社会保障番号、および 様々な属性は、アイテムに定義されています。 今ではテーブルの上に私が そのGSIを定義することができます その周りに私が欲しいと言うことをフリップ ライセンス上のハッシュキーとその後 他のすべての項目。 今私は、クエリを実行し、検索する場合 任意の社会のためのライセンス番号 セキュリティ番号、私がすることができます メインテーブルを照会。 私は照会したいと私はしたい場合 社会保障を取得します 番号またはによって他の属性 ライセンス番号、私はGSIを照会することができます。 そのモデルは、その一つであります 1の関係に。 ただ、非常に単純なGSI、 周りの人のことを反転させます。 今、多くの約1話。 多くの一つは、基本的に あなたのハッシュ範囲キー。 私たちはこれで多くを得る場合には ユースケースは、監視データです。 モニタのデータは、定期的に来ます モノのインターネットのような間隔。 我々は常に、これらすべてを取得します レコードは、すべての時間に来て。 そして、私はすべての測定値を見つけたいです 特定の期間の間です。 それはでは非常に一般的クエリーです 監視インフラストラクチャ。 それについて移動方法が見つけることです シンプルなテーブル構造、一つのテーブル。 私は、デバイス測定テーブルを持っています デバイスIDのハッシュキーと。 そして、私は上の範囲のキーを持っています タイムスタンプ、またはこの場合には、叙事詩。 そして、それは私が複合体を実行することができます その範囲のキーに対するクエリ それらのレコードを返すこと その結果を基準とします 私が探していることを設定します。 そしてそれはその1を構築 多くの関係 使用してプライマリ・テーブルへ ハッシュキー、レンジキー構造。 だから、一種の構築されています ディナモDB内のテーブルへ。 私はハッシュを定義する場合 そして、範囲Tテーブル、私はよ 一対多の関係を定義します。 これは親子関係です。 のは、多くについてお話しましょう 多くの関係に。 この特定の例のために、 再び、我々はGSIのを使用しようとしています。 そしてのは、ゲームの話をしましょう 私は特定のユーザーを持っているシナリオ。 私はすべてのゲームを知りたいです 彼はのために登録されたかで遊んでいます。 そして、与えられたゲームのために、私 すべてのユーザーを検索します。 だから私はそれをどのように行うのですか？ 私は行くよ私のユーザーのゲームテーブル、 ユーザIDのハッシュキーを持っています そして、ゲームの範囲のキー。 したがって、ユーザーは、複数のゲームを持つことができます。 それは間の多くの関係に一つです ユーザーと彼が果たしているゲーム。 そしてGSIに、 私はその周りを反転します。 私は、ゲーム上でハッシュだろうと 私は、ユーザーに及ぶでしょう。 だから私はすべて取得したい場合 で、ゲームユーザーのプレイ、 私はメインテーブルを照会します。 私はすべてのユーザーを取得したい場合 それは特定のゲームをプレイしています、 私はGSIを照会。 だから、私たちはこれを行う方法を参照してください？ あなたはこれらのGSIはのサポートするために構築します ユースケースは、アプリケーション、アクセス パターン、アプリケーション。 私は上のクエリを実行する必要がある場合 この次元は、しましょう 私は、その次元のインデックスを作成します。 私はないと、私は気にしないでください。 また、ユースケースに応じて、私 インデックスまたは私はないかもしれないが必要な場合があります。 それは多くの単純なものなら、 主テーブルは問題ありません。 私はこれらの多くを行う必要がある場合 多くの、または私はものにいずれかの操作を実行する必要があり、 その後、多分私は必要なのですか 2番目のインデックスに。 だから、それはすべての依存します 私がやろうとしています 私は熟練した取得しようとしているもの。 おそらく、私も費やすつもりはありません 多くの時間のドキュメントの話。 これはおそらく、少しを取得し、 我々はに行く必要があるよりも深く。 それでは、少し話をしましょう 豊富なクエリ式について。 だからディナモDBに我々が持っています 創造する能力 我々は、投影式を呼んでいるもの。 投影式は単純です フィールドや値を選びます あなたが表示すること。 [OK]をので、私は選択を行います。 私はディナモDBに対してクエリを作ります。 そして、私は、ショーあなたは何を知っている、と言います 私唯一の5つ星レビュー この特定の製品のために。 だから、私が見てみたいすべてです。 私はすべて見たいと思っていません 行の他の属性、 私はちょうどこれを見たいと思っています。 ときにそれはちょうどSQLのようなものです セレクトスターやテーブルから言います、 あなたはすべてを取得。 私は、から選択名前を言うとき テーブルには、私は1つの属性のみを取得します。 これは、中のものと同じようなものです ディナモDBまたは他のNoSQLデータベース。 フィルタ式は、私ができるようにします 基本的にダウンして、結果セットを切りました。 だから私は、クエリを作成します。 クエリは、500項目に戻ってくることがあります。 しかし、私は唯一のアイテムが必要なこと これを言う属性を持ちます。 OK、それでは、これらの項目を除外しましょう それは、その特定のクエリと一致しません。 だから我々は、フィルター式を持っています。 フィルタ式缶 任意の属性上で実行します。 彼らは、範囲クエリを好きでいません。 レイズクエリは、より選択的です。 フィルタクエリは行くために私を必要とします 全体の結果は、設定および取得します 私はしたくないデータを切り開きます。 なぜそれが重要なのですか？ 私はそれをすべて読んでからです。 クエリでは、私が読んでするつもりだと それは、データについての巨人になるだろう。 そして私はするつもりです 私は必要なものを切り開きます。 そして、私は唯一切り開くだ場合 行のカップルは、それは大丈夫です。 それはとても非効率​​的ではありません。 しかし、私は全体の山を読んでいる場合 ただ一つのアイテムを切り開くためのデータ、 その後、私は良いことするつもりです 範囲クエリを使用してオフ、 それははるかに選択だからです。 それは私の多くを保存するために起こっています お金、私はその読み取りのために支払うため。 どこに戻ってくる結果 少なくなることがあり、その線を横切ります、 しかし私は、読み取りのために払っています。 それでは、どのように理解 あなたは、データを取得しています。 それはディナモDBには非常に重要です。 条件式、これは何ですか あなたはオプティミスティック・ロックを呼ぶかもしれません。 更新する場合は、存在する場合、またはこの値であれば 私が指定したものと同等です。 そして、私は上のタイムスタンプを持っている場合 レコードは、私がデータを読み取ることがあります。 私は、そのデータを変更する場合があります。 私はそれを書く行くかもしれません データベースへのデータバック。 誰かがレコードを変更した場合、 タイムスタンプが変更されている可能性があります。 そして、そのように私の条件付き 更新は、更新プログラムを言うことができます タイムスタンプは、これを等しい場合。 または更新が誰かため失敗します その間にレコードを更新しました。 それは我々が楽観的ロックと呼んでいるものです。 それはその人のこと で来て、それを変更することができ、 私はそれを検出するつもりです 私が戻ったときに書き込みます。 そして私は実際にそれを読むことができます データとは、ああ、彼はこれを変更し、言います。 私はそれを考慮して必要があります。 そして私は、私の中のデータを変更することができます 記録し、別の更新を適用します。 ですから、これらの増分をキャッチすることができます 時間の間に発生するアップデート データを読み取り、その 時間あなたはデータを書き込むことがあります。 聴衆：そしてフィルター 式は実際にはないことを意味 番号またはnot--で 【声を挟ん] RICKフーリハン：私はしません この中にあまりにも多くを得ます。 これは予約語です。 ポンドビューが予約されています ディナモDBのキーワード。 すべてのデータベースには、独自に確保しています あなたが使用することはできませんコレクションの名前。 ダイナモDB、あなたが指定した場合 これの前にポンド、 あなたは上記のそれらの名前を定義することができます。 これは参照される値です。 それはおそらくに対する最良の構文ではありません この議論のためにそこまで持っています、 それはいくつかのreal--に入ったので、 私が話をされていたであろうより より深いレベルでそのことについて。 しかし、これは可能性が、言えば十分 彼らはviews--クエリスキャンすること ポンドのビューが10以上です。 それはイエス、数値です。 必要に応じて、我々は約話すことができます 議論の後のそれ。 すべての権利、私たちはに取得しています ベストプラクティスでいくつかのシナリオ ここで、我々は話をするつもりです ここでいくつかのアプリについて。 ディナモDBのユースケースはどのようなものです。 デザインは何ですか ディナモDB内のパターン。 そして、最初のものは、我々がしようとしています 話モノのインターネットです。 私は推測of--だから我々は多くを得ます、 50％以上it--ものです インターネット上のトラフィックのこれらの日 実際のマシンによって生成され、 ない人間が自動化されたプロセス、。 私はこの事この事を意味しています あなたは、あなたのポケットに持ち歩きます どのくらいのデータそのものであること 実際にあなたなしで周り送ります それを知ることは絶対に素晴らしいです。 お住まいの地域の情報 あなたが行っているどのくらいの速について。 あなたは、Googleマップの作品はどのように思います 彼らは、トラフィックが何であるかを教えてくれたとき。 数百万人があるからだと 車を運転し、何百万人もの人々 送信された携帯電話との すべての場所で​​のデータのすべての時間を。 物事の1だから、 このタイプのデータについて それは、ログ、監視データ、入って来 データ、時系列データは、あるい 通常は興味深いです 少し時間のため。 この時間の後、それがです そう面白くありません。 だから私たちは聞かせていない、について話しました これらのテーブルは、際限なく大きくなります。 ここでの考え方は、多分私は24を持っていることです 私のホットテーブル内のイベントの価値は時間。 ホットテーブルがあることを行っていること 非常に高いレートでプロビジョニングされ、 それは大量のデータを取っているため。 これは、大量のデータを取っています で、私はそれをたくさん読んでいます。 私は、操作の多くを持っています そのデータに対して実行される問合せ。 24時間後、ねえ、あなた 私は気にしないものを、知っています。 私はロールので、多分すべての真夜中 新しいテーブルの上で、私のテーブル 私はこのテーブルをプロビジョニング解除します。 そして、私はRCUのを取るだろうと WCUのダウンのため、24時間後 私は多くを実行していません そのデータに対するクエリ。 だから私は、お金を節約するつもりです。 そしておそらく、30日後、私はしないでください でも、それがすべてを気にする必要があります。 私はWCUのを取ることができます 1までのすべての方法、 あなたが知っているので、それは何ですか に書き込まを取得するつもりはありません。 データは30日古いです。 それは変更されることはありません。 そしてそれは、読み取りに行くことはほとんどないです それでは、わずか10にまでそのRCUてみましょう。 そして、私はこれにお金のトンを節約しています データは、唯一の私のホット・データのために支払います。 だから、見て重要なことです あなたが時系列で見るとで データは、ボリュームに入ってきます。 これらは戦略です。 今、私はちょうどそれを聞かせでした すべて同じテーブルに行きます そしてちょうどそのテーブルが成長してみましょう。 結局、私はするつもりです パフォーマンスの問題を参照してください。 私は、アーカイブを開始する必要がありますするつもりです 表オフそのデータの一部、 ものではありません。 はるかに良いのをしてみましょう アプリケーションを設計 あなたは正しい、このように操作することができるようにします。 だから、それだけで自動です アプリケーションコードインチ 真夜中に毎晩 それは、テーブルをロールバックします。 たぶん私は必要なものをスライドさ データの24時間の窓。 その後、定期的に私はよ テーブルからデータを呼び出します。 私はそれをトリミングしてい cronジョブと私はそれを入れています これらの他のテーブルの上に、 あなたが必要とするものは何でも。 ロールオーバーが機能するのであれば、それは素晴らしいことです。 ない場合は、それをトリミング。 しかし、それでは、そのホット・データを保持してみましょう 離れて寒さのデータから。 それはあなたにたくさんのお金を節約できますし、 あなたのテーブルは、よりパフォーマンスにします。 だから、次のことは、我々が話しましょう 程度の製品カタログです。 製品カタログです かなり一般的なユースケース。 これは実際には非常に一般的なパターンです 私たちは、物事の様々な表示されますことを。 あなたを知って、Twitterのための たとえば、ホットつぶやき。 誰もが来ると そのツイートをつかみます。 製品カタログには、私は販売を得ました。 私は熱い販売を得ました。 私は7万の要求を持って 第二製品のために来て 私の製品カタログの中から説明。 我々は、小売でこれを参照してください。 操作はかなり。 それでは、どのよう我々はそれに対処するのですか？ それに対処する方法はありません。 すべての私のユーザーが見たいです データの同じ部分。 彼らは同時に、で来ています。 そして、彼らはすべての要求を作っています データの同じ部分のため。 これは私を与えることをホットキー、その大きな赤いです 我々は好きではない私のチャート上のストライプ。 そして、それはそれは次のようになります。 だから私の鍵空間全体に私が得ています セール商品に打た。 私はどこか他の何も得ていませんよ。 どのように私はこの問題を軽減するのですか？ まあ、我々はキャッシュでこれを軽減します。 キャッシュには、メモリ内、基本的に置きます データベースの前のパーティション。 我々は、管理しています [聞こえない]キャッシュ、どのように 独自のキャッシュを設定することができ、[聞こえません] キャッシュ [？ D、？]何をしたいです。 データベースの前でそれを置きます。 そして、その方法は、あなたは、そのデータを保存することができます そのキャッシュのもののホットキーをバックアップから 空間とキャッシュをお読みください。 そして、あなたのほとんどは読み込み このように探し始めます。 私はこれらすべてのキャッシュはここまでヒットしました 私はダウンしてここで起こって何も持って データベースが後ろに座っているので、 キャッシュと通ってくることはありません読み取ります。 私は中のデータを変更した場合 データベースには、私はキャッシュを更新する必要があります。 私たちは何かを使用することができます 以下のようなことを行うために蒸します。 そして、私はそれがどのように機能するかを説明します。 すべての権利、メッセージング。 メール、我々はすべての電子メールを使用しています。 これはかなり良い例です。 私たちは、メッセージテーブルのいくつかの並べ替えを持っています。 そして、我々は受信トレイと送信トレイを得ました。 これは、どのようなSQLがあるだろう その受信トレイを構築するように見えます。 私たちは、種類の同じ種類を使用します GSIの、GSIのを使用するための戦略の 私の受信トレイや送信トレイ私のために。 だから私は、生のメッセージが来ました 私のメッセージテーブルに。 そして、これへの最初のアプローチ 、[OK]を、たとえば、問題はないかもしれません。 私は生のメッセージを持っています。 [聞こえない]を来るメッセージ、 メッセージIDは、それは素晴らしいことです。 それは私の固有のハッシュです。 私は2つのGSIの、いずれかを作成するつもりです 私の受信トレイのために、私の送信ボックスに1つずつ。 そして、最初の事は私がやります 私は私のハッシュキーがあると言うだろうさ 受信者になるだろうと 私は日に手配するつもりです。 これは素晴らしいです。 私はここに私の素晴らしい眺めを得ました。 しかし、ほとんどの問題はここにあります。 そして、あなたはこの中に実行します リレーショナルデータベースにも。 彼らは、垂直パーティショニングと呼ばれます。 あなたは、あなたの大切なデータを保存しておきたいです 離れてあなたの小さなデータから。 私が得たので、その理由はなぜです 属性を取得するための項目を読んで行きます。 そして、私の体はここにすべての上にある場合は、 その後、ちょうどいくつかの項目を読み込みます 私の体の長さがある場合 256キロバイトそれぞれを平均化します、 数学はかなり醜い取得します。 だから私はデビッドの受信箱を読みたいと言います。 デビッドの受信トレイには50の項目があります。 平均値とサイズは256キロバイトです。 ここに私の変換比です RCUのために4キロバイトです。 [OK]を、のと一緒に行きましょう 最終的には一貫性のある読み取ります。 私はまだ1600 RCUの食べています ただダビデの受信トレイを読み取ります。 痛いです。 [OK]を、今のは、考えてみましょう アプリがどのように機能するかについて。 私は、電子メールアプリケーションにいる場合と、 私は、私の受信トレイで探しています そして、私はすべてのメッセージの本文を見て、 いいえ、私は要約で探しています。 私は、ヘッダーだけで探しています。 それでは、テーブル構造を構築してみましょう それは、より多くのようになります。 だからここの情報です 私のワークフローが必要であること。 それは私の受信トレイにGSIです。 これは、日付、送信者、 件名、およびその後 ポイントメッセージID、 バックメッセージテーブルに どこで私は体を得ることができます。 さて、これらのレコードのIDになります。 彼らは戻ってを指します ダイナモDBテーブル上のアイテムID。 すべてのインデックスは常にcreates-- いつものアイテムを持っています そのof--一部としてID インデックスが付いています。 大丈夫。 観客：それはそれを伝え、それが保存されていますか？ RICKフーリハン：はい、それは伝えます exactly--それはそれはまったく同じものです。 ここは私の再レコードがだと言います。 そして、それは私の再レコードに戻ってそれを指します。 その通りです。 [OK]を、今私の受信トレイは、 実際にはるかに小さいです。 そして、これは実際にはサポートしています メールアプリのワークフロー。 そこで、私の受信トレイは、私をクリックします。 私が一緒に行くと、私は、メッセージをクリックして、 私は体を取りに行く必要があるとき、それはです、 私はするつもりですので、 別のビューに移動します。 だから、MVCのタイプを考える場合 フレームワーク、モデル・ビュー・コントローラ。 モデルが含まれています データを見る必要があること コントローラはと相互に作用します。 私は、フレームを変更すると、時 私は視点を変え、 それはに戻ってもOKです サーバーとモデルを再作成します、 それは、ユーザーが期待するものだからです。 彼らは、ビューを変更すると、それは、いつです 我々は、データベースに戻ることができます。 そこで、電子メール、クリックします。 私は体を探しています。 往復。 体を取りに行きます。 私ははるかに少ないデータを読み取ります。 私はその遺体を読んでいます 彼がそれらを必要とするときダビデは必要。 そして、私は1600年に燃えていませんよ RCUのは、ちょうど彼の受信トレイを表示します。 だから今、この方法ですthat-- LSIやGSI--はごめんなさいこと、 国土地理院は、出て動作します。 我々は、受信者の私達のハッシュを持っています。 我々は、日付の範囲のキーを持っています。 そして、我々は投影の属性を持っています 我々は唯一のビューをサポートする必要があること。 私たちは、送信トレイのためにそれを回転させます。 送信者に対してハッシュ。 そして本質的には、我々が持っています とても素敵な、きれいな景色。 そして、それは我々ですbasically-- この素敵なメッセージを持っています ので、きれいに拡散されていますテーブル それはハッシュのみ、ハッシュ化されたメッセージIDです。 そして、我々は2つ​​のインデックスを持っています そのテーブルのオフに回転しています。 すべての権利なので、ここでのアイデアはないです ビッグデータとこの小さなデータを保存 一緒に。 垂直パーティション、 これらのテーブルを分割します。 データを読み出さないでくださいあなたがする必要はありません。 すべての権利、ゲーム。 我々は、すべてのゲームが好きです。 少なくとも私は、その後のゲームが好きです。 物事のいくつかそう 私たちはときに対処すること 我々は正しい、ゲームを考えていますか？ このごろゲーム、特にモバイル ゲームは、すべての思考についてです。 そして、私はここに回転するつもりです 少し離れてDynamoDBのから。 私はで持参するつもりです 議論の一部 一部の周りに 他のAWS技術。 しかし、ゲームについての考えは考えることです APIを使って複数の程度、なAPI、 一般的に、HTTPとJSONを話します。 それは一種の方法モバイルゲームです 彼らのバックエンドと対話します。 彼らは、JSONの投稿を行います。 彼らはデータを取得し、それがすべてです、 一般的に素敵なJSONのAPIで、話します。 友人を得るようなものは、取得します リーダーボード、データを交換します、 ユーザーがコンテンツを生成し、 システムまで押し戻し、 これらは、物事の種類があります 我々がやろうとしていること。 バイナリ資産データ、このデータ データベースに座っていない可能性があります。 これはに座る可能性があります オブジェクトストア、右？ しかし、データベースをしようとしています システムを語ってしまいます、 アプリケーションを伝えます どこにそれを得る行きます。 そして、必然的に、マルチプレイヤー サーバ、バックエンド・インフラストラクチャ、 高いために設計されました 可用性とスケーラビリティ。 したがって、これらは、我々はすべての欲しいものです ゲームインフラ今日インチ それでは、見てみましょう 何それは次のようになります。 、コアバックエンドを手に入れました 非常に簡単。 ここで使用してシステムを持っています 複数のアベイラビリティゾーン。 考えるbeing--として我々はAZSについて話しました それらの独立したデータセンターとして。 複数のデータセンター AZあたりが、それはOKですが、 ただ、個別のデータと考えます 地理的にあるセンター 障害を単離しました。 我々は、必要があるとしています カップルのEC2インスタンス。 我々は、必要があるとしています いくつかのバックエンドサーバー。 あなたは、従来ならたぶん場合 アーキテクチャ、我々はしています 私たちは、RDS呼ん使用して、 リレーショナルデータベースサービス。 MSSQL、MySQLのだろう、 またはそのような何か。 これは、多くのアプリケーションの方法です 今日設計されています。 さて、私たちは一緒に行きたいかもしれません 私たちはスケールアウト時にこれがあります。 我々は先に行くと、あげますよ そこまでS3バケット。 そして、そのS3バケットの代わりに、サービング 私たちのservers--からそれらのオブジェクトアップ 我々はそれを行うことができます。 あなたは、すべてのバイナリを置きます サーバー上のオブジェクト あなたは、これらのサーバーを使用することができます インスタンスは、そのデータアップにサービスを提供しています。 しかし、それはかなり高価です。 行うには良い方法は、先に行くとあります S3バケットにそれらのオブジェクトを置きます。 S3は、オブジェクトリポジトリです。 それはのために特別に構築されています 物事のこれらの種類を提供します。 そして、それらのクライアントが要求してみましょう 直接それらのオブジェクトバケットから、 サーバーの負荷を軽減。 だから我々は、ここでスケールアウトし始めています。 今、私たちは、世界中のユーザを得ました。 私は、ユーザーを得ました。 私は、ローカルコンテンツを持っている必要があります 右、これらのユーザーに近い位置？ 私はS3バケットを作成しました 私のソースリポジトリとして。 そして、私はフロントでそのよ CloudFrontの分布。 CloudFrontのは、CDとあります コンテンツ配信ネットワーク。 基本的には、指定したデータを取り込み そしてインターネット上でそれをすべてをキャッシュ ユーザーは、どこにでも持っていることができるように 非常に迅速な応答時 彼らはそれらのオブジェクトを要求します。 だから、あなたのアイデアを得ます。 あなたはこの種のすべてを活用しています ここでは、AWSの側面これを成し遂げるために。 そして最終的に、我々は投げます オートスケールグループインチ だから、私たちのAC2インスタンスが 私たちのゲームサーバーの、 彼らは忙しい取得するために始めると そして、忙しいと忙しいです、 彼らは別のものをスピンします 例えば、別のインスタンスをスピン、 別のインスタンスをスピン。 だから、技術AWSは、それを持っています あなたはパラメータを指定できます その周りにあなたのサーバーは成長します。 ですから、サーバのn個の数を持つことができます 任意の時点でそこに。 あなたの負荷が消えたかどうかを、彼らはよ シュリンク、数が縮小されます。 そして、負荷が戻ってきた場合、 それは弾性、出戻って成長します。 だから、これは素晴らしいです。 私たちは、EC2インスタンスの多くを持っています。 我々はキャッシュを置くことができます データベースのフロント、 試してみて、データベースを加速します。 次の圧力ポイント 一般的に、人々が見ます 彼らが使用してゲームをスケーリングされ リレーショナルデータベースシステム。 うわあ、データベース パフォーマンスはひどいです。 どのように我々はそれを改善するのですか？ それでは、パッティングしてみましょう その目の前でキャッシュ。 まあ、キャッシュが動作しません ゲームで非常に素晴らしい、右？ ゲームのために、書き込みが痛いです。 ゲームは非常に重い書き込みされています。 あなたがいるときにキャッシュが動作しません。 あなたは常にきたので、重い書きます キャッシュを更新するようになりました。 あなたはそれがだ、キャッシュを更新 キャッシングすることとは無関係。 それは実際には余分な作業です。 だから我々はここでどこに行きますか？ あなたは大きなボトルネックを持っています そこにデータベースインチ どこへ行くと場所 明らかに分割されます。 パーティショニングではありません あなたがいるときに行うのは簡単 リレーショナルデータベースを扱います。 リレーショナルデータベースを使用すると、しています 効果的に、管理を担当し、 鍵空間。 あなたはAとMの間でユーザーを言っています そこに行くNとZの間、ここに行きます。 そして、あなたは、スイッチングしています アプリケーション全体。 だから、扱っています このパーティション・データ・ソース。 あなたは、トランザクションの制約があります そのパーティションをまたがりません。 あなたはすべての種類を持っています あなたがしている散らかっ そこにダウンしようとして扱います スケールアウトに対処します より大きなインフラを構築。 それだけで何の楽しみません。 聴衆：だからと言っています ソースポイントを増加させることは高速化 プロセス？ RICKフーリハン：増やしますか？ 対象：ソースポイント。 RICKフーリハン：ソースポイント？ 対象者：情報から、 どこに情報がから来ていますか？ RICKフーリハン：いいえ 私は増加している何を言っています データストア内のパーティションの数 スループットを向上させることができます。 だから何がここで起こっているユーザであります ここまでEC2インスタンスに入ってきます、 よく、私は、ユーザーが必要な場合 それはMにですが、私はここに行きますよ。 NからPに、私はここに行きますよ。 PからZまで、私はここに行きますよ。 聴衆：OK、それらので、それらがあります すべての異なるノードに格納されていますか？ RICKフーリハン：はい。 これらの考えとして データの異なるサイロ。 だから、これを行うために抱えています。 あなたがやろうとしている場合 この、あなたがしようとしている場合 リレーショナルプラットフォームに拡張するために、 これは、あなたがやっていることです。 あなたは、データを取っているし、 あなたはそれを伐採しています。 そして、あなたはそれを越えて分割しています データベースの複数のインスタンス。 そして、あなたはすべてのことを管理しています アプリケーション層で。 それは楽しいん。 それでは、私たちは行きたいですか？ 我々は完全に管理DynamoDBのを、行ってみたいです、 NoSQLデータストア、規定のスループット。 私たちは、セカンダリインデックスを使用しています。 これは、基本的には、HTTP APIのだと ドキュメントのサポートが含まれています。 だから、心配する必要はありません そのパーティションのいずれかについて。 私たちはあなたのためにそれをすべて行います。 だから今、その代わりに、あなた ちょうどテーブルに書き込みます。 表がパーティション化する必要がある場合は、 それは舞台裏で行われます。 あなたは完全に絶縁されています 開発者としてそのから。 それではについてお話しましょう ユースケースの一部 我々は、ゲームで、共通に実行することを ゲームシナリオ、リーダーボード。 だから、ユーザーが入ってくるんです 彼らはしているBoardNames このユーザーのスコアに。 我々は、ユーザーIDにハッシュ化されるかもしれません し、我々はゲームの範囲を有します。 だから、すべてのユーザーが見たいです 彼が演奏されるすべてのゲーム 彼のすべてのトップスコア すべてのゲームを横断。 だから、彼の個人的なリーダーボードです。 今、私はで行きたいと私はget--たい 私はこれらの個人的なリーダーボードを得ます。 私は何をしたい取りに行くです すべてのユーザー全体のトップスコア。 だから私はそれをどのように行うのですか？ 私の記録は、上のハッシュ化されたとき ユーザーIDは、ゲームにありました、 よく私は先に行くつもりです そして、再構築は、国土地理院が作成し、 私はそのデータを再構築するつもりです。 今、私は上のハッシュするつもりです ゲームですBoardName、。 そして、私はトップスコアに及ぶするつもりです。 そして今、私は別のバケットを作成しました。 私は、同じテーブルを使用しています、 同じ項目のデータ。 しかし、私は与えバケツを作成しています 私のゲームによって、トップスコアの集計。 そして私は、そのテーブルを照会することができます その情報を取得します。 だから私は、最大そのクエリパターンを設定しました セカンダリインデックスでサポートされて。 今、彼らはBoardName並べ替えることができます とに応じて、TopScoreによってソート。 あなたが見ることができるので、これらは種類があります あなたがゲーム内で取得するユースケース。 私たちは、ゲームに入るもう一つの良いユースケース 賞を受賞し、誰が賞を受賞していますです。 そして、これは偉大なユースケースです 我々はまばらなインデックスを呼び出す場所。 スパースインデックスがあります 生成する機能 必ずしもないインデックス テーブルの上のすべての単一の項目が含まれています。 そして、なぜありませんか？ ためているのアトリビュート インデックスを作成すると、すべてのアイテムには存在しません。 この特にそう ケースを使用して、私が言っています、 あなたは何を、私はするつもりだ知っています 賞という属性を作成します。 そして、私はすべてのユーザーを与えるつもりです それは属性賞を持っています。 賞がある持っていないユーザー その属性を持っているつもりはありません。 だから私は作成したとき インデックス、ユーザーのみ 表示しようとしていること インデックスにアップされています 実際に賞を獲得しているもの。 だから、できるようにする素晴らしい方法です そのフィルタのインデックスを作成します そうでない非常に、非常に選択的です インデックスにテーブル全体を持っています。 だから我々はここで時間に少なくなっています。 私が先に行くと、スキップするつもりです アウトと、このシナリオをスキップします。 少し話about-- 聴衆：私は、簡単な質問を求めることができますか？ 一つは重い書くのですか？ RICKフーリハン：何ですか？ 観客は：重い書きます。 RICKフーリハン：重い書きます。 そうねぇ。 聴衆：またはそのされていません 何かすることができますだけ ほんの数秒での声？ RICKフーリハン：私たちは行きます 投票のシナリオによる。 それは悪いことではありません。 あなたたちは数分を持っていますか？ OK。 だから我々は、投票について話しましょう​​。 だから、リアルタイム投票、我々が持っています 投票のための要件。 要件は、我々が許可されていることです 一人一人は一度だけ投票します。 私たちは誰もができることがないようにしたいです 彼らの投票を変更することができます。 我々は、リアルタイム集計をしたいです そして、人口統計のための分析 我々はあることを行っていること サイト上でユーザーに示します。 このシナリオを考えます。 私たちは現実の多くの仕事 彼らはどこだテレビ番組 物事のこれらの正確な型をしています。 だから、シナリオを考えることができ、 私たちは何百万を持っています そこの十代の少女 自分の携帯電話で 投票し、投票し、 彼らは誰に投票 最も人気のあるであることがわかりました。 したがって、これらはのいくつかであります 我々は実行要件。 だから最初のテイク この問題を解決します 構築することであろう 非常に単純なアプリケーション。 だから私はこのアプリを持っています。 私はそこにいくつかの有権者を持っています。 彼らは、投票のアプリを打つ、でてきます。 私はいくつかの生の票テーブルを持っています 私はちょうどにそれらの票をダンプします。 私はいくつかの集計を持っています 票テーブルその 私の分析や人口統計を行います、 私たちはそこにこのすべてを入れます。 そして、これは素晴らしいです。 人生は素晴らしい。 生命の私たちがいることを知るまでは良いです 常に1つまたは2つあります 選挙で普及している人。 1つまたは2つのものがあります 人々は本当に気にしています。 そして、あなたはで投票している場合 スケール、私は突然のすべて の地獄を打っことになるだろう 2候補者は、1つまたは2つの候補者。 アイテムの非常に限られた数 人々が人気であることがわかりました。 これは良いデザインパターンではありません。 これは実際にあります 非常に悪いデザインパターン それが作成されますので、正確に何を我々 ホットキーであったについて話しました。 ホットキーは、我々は好きではないものです。 だから我々はそれをどのように解決するのですか？ そして実際に、この問題を解決する方法はあります これらの候補バケットを取ることによって、 各候補者のために我々が持っています、 我々は、ランダムな値を追加しようとしています、 私たちが知っている何か、ランダム 1と100の間の値、 100〜1,000、 または1〜1,000、 しかし、あなたがしたい多くのランダムな値 その候補の最後に追加します。 そして、私は本当に、次に何をしましたか？ 私はのように受験者IDを使用している場合 票を集計するバケット、 私はランダムを追加した場合 それの最後に数、 私が作成した今10バケット、 百バケット、千バケット 私は全体の投票を集計していています。 だから私は、何百万、何百万を持っています、 そして、数百万のレコードが入ってきます これらの候補のために、私は今、広がっています 候補A_1にもその投票 候補A_100を通じて、理由 投票が入ってくるたびに、 私はランダムに生成しています 1と100の間の値。 私はの終わりにそれを仮止めしてい 人のは、候補者に投票。 私はバケツにそれをダンプしています。 今裏面に、私が知っています 私は百バケツを持っています。 だから私は先に行くしたいとき そして、票を集計、 私はこれらすべてのバケットから読み込みます。 だから私は先に行くと、追加します。 そして私は、散乱を集めるん 私は外に出て、ちょっとと言う場合には、 あなたが知っている、この候補者のキー スペース百バケットの上にあります。 私はすべて収集するつもりです それらの百バケットから投票。 私は凝集するつもりです 彼らと私が言うつもりです、 候補Aは、今持っています xの総投票数。 今両方の書き込み クエリおよび読取り問合せ うまく分散されています 私は全体の書いているので、 私は、キーの数百を越え読んでいます。 私は書いていないことだし、 今つのキーを越え読書。 だから、偉大なパターンです。 これはおそらく実際には一つです 最も重要な設計の NoSQLの中のスケールのためのパターン。 あなたは、このタイプのを見ることができます すべての味のデザインパターン。 MongoDBは、DynamoDBの、それはしていません 問題は、我々はすべてこれをしなければなりません。 あなたが扱っているときので、 これらの巨大な集合体で、 あなたはへの道を把握する必要があり バケットを横断して広がります。 これは、あなたがそれを行う方法です。 すべての権利なので、どのような あなたが今やっています あなたは、読み取りをトレードオフしているされています 書き込みのスケーラビリティのためのコスト。 私の読み取りのコストは もう少し複雑な 私は読んでから行かなければなりません 百バケットの代わりに、1。 しかし、私は書くことができますよ。 そして、私のスループット、私の書き込み スループットは信じられないです。 だから、通常は貴重です DynamoDBのスケーリングするための技術、 またはそのことについては、NoSQLのデータベース。 だから我々はそれを拡張する方法を考え出しました。 そして、私たちはどのように考え出し 私たちのホットキーを排除します。 そして、これは素晴らしいです。 そして、私たちはこの素晴らしいシステムを得ました。 そして、それは私たちに非常に正しい投票を与えられています 我々は、レコード票デデュープを持っているので。 これは、DynamoDBのに組み込まれています。 私たちは、条件付きの権利について話しました。 有権者が入ってくる、プット テーブルの上に挿入、 彼らは有権者のIDで挿入し、 彼らは別の投票を挿入しようとすると、 私は、条件付き書き込みを行います。 これだけを書くと言います これが存在しない場合。 だから、すぐに私がいることを見るように その投票のテーブルを打ちます、 誰もがあることを行っていないです で彼らの票を置くことができます。 そして、それは素晴らしいです。 そして、我々はインクリメントしています 私たちの候補カウンター。 そして、私たちは私たちのやっています 人口統計とすべてのこと。 しかし、私の場合はどうなります アプリケーションが倒れ？ これで、すべての突然の投票 で来ている、と私 それらが処理取得しているかどうかを知りません 私の分析と人口統計へ もう。 そして、ときにアプリケーション アップ、どのように戻ってきます 私は投票が持っているもの地獄を知っていますか 処理され、どこで始めるのですか？ ときにこれは本当の問題です このタイプのシナリオを見て開始します。 そして、どのように我々はそれを解決するのですか？ 私たちは私たちでそれを解決 DynamoDBのストリームを呼び出します。 ストリームは、順序付けられた時間であり、 すべてのアクセスのパーティション変更ログ テーブルに、すべての書き込み 表へのアクセス。 に書かれているすべてのデータ テーブルには、ストリーム上で表示されます。 それは基本的に24時間の待ち行列です。 アイテムは、ストリームを打ちます、 彼らは、24時間のために生きます。 これらは、複数回読み出すことができます。 配信されることが保証 一度だけのストリームに、 n回を読み取ることができます。 あなたがしたいそうしかし、多くのプロセス そのデータを消費する、あなたはそれを消費することができます。 これは、すべての更新が表示されます。 すべての書き込みのみとなります ストリームを一度に表示されます。 だから、心配する必要はありません それを2回処理について 同じプロセスから。 これは厳密に項目ごとに注文しています。 我々は時間を言うとき 注文し、パーティション、 あなたは、ストリーム上でパーティションごとに表示されます。 あなたは順番にアイテム、更新を確認します。 我々は保証されません あなたがしているストリームに すべてのトランザクションを取得するつもり アイテム全体のためです。 それでストリームはべき等です。 我々はすべての冪等が何を意味するか知っていますか？ べき等は、あなたがそれを行うことができることを意味し オーバー、およびオーバー、何度も繰り返し。 結果は同じになるだろう。 ストリームは、冪等です しかし、彼らがしなければなりません 出発点から再生、 あなたが選択した場所、最後に、 またはそれらはなりません 同じ値です。 MongoDBのと同じこと。 MongoDBのは、構造を持っています 彼らはoplogを呼び出します。 それはまったく同じ構造です。 多くのNoSQLデータベース この構造を持っています。 彼らは物事を行うためにそれを使用 複製のような、これ まさに我々がストリームに何をすべきかです。 聴衆：たぶん 異端の質問が、あなた 等々ダウンやっアプリについて話しています。 ストリームは、することが保証されています おそらくダウンしたことがありませんか？ RICKフーリハン：うん、ストリーム ダウンしたことがないことが保証されています。 私たちは、インフラストラクチャを管理 後ろ。自動的にストリーム そのオートスケールグループで展開します。 私たちは少し通過します 何が起こるかについて少し。 私は、彼らがいないだと言うべきではありません ダウンしないように保証されています。 要素が保証されています ストリームに表示されます。 そして、ストリームがアクセスできるようになります。 だから何がダウンするか戻ってきます アップ、それは下に起こります。 それはOKですcovers--。 すべての権利、あなたが別の取得 画面オフビュータイプ。 にとって重要なビュータイプ 典型的には、それが何であったか、プログラマがありますか？ 私は、古いビューを取得します。 更新テーブルに当たる際には、よ ストリームに古いビューをプッシュ ので、データはアーカイブ、または変更することができます 制御、変更の識別、変更 管理。 それは後に今あるものを新しいイメージ、 ビューの別のタイプのUpdate、 得られる。 あなたは、新旧両方の画像を得ることができます。 たぶん私はそれらの両方をしたいです。 私はそれが何だったか見てみたいです。 私はそれがに変更内容を確認したいと思います。 私は、コンプライアンス・タイプを持っています 実行されるプロセスの。 それはそれを確認する必要があります これらのものは変更されたとき、 彼らは、ある範囲内だということ または特定のパラメータの範囲内。 そして多分私だけ 変更かを知る必要があります。 私が変更されどのような項目を気にしません。 私が知っている必要がありますする必要はありません どの属性が変更されました。 私はちょうどそれを知っている必要があります 項目がタッチされています。 したがって、これらは、ビューのタイプです あなたはストリームを降りること あなたはと対話することができます。 アプリケーションこと ストリームを消費し、 これは、これが動作する方法の一種です。 DynamoDBのクライアントがに尋ねます テーブルにデータをプッシュ。 ストリームは、私たちが破片を呼んでいるものに展開します。 シャードは、スケーリングされ 独立して、テーブルの。 彼らは完全にラインアップはありません あなたのテーブルのパーティションに。 そして理由はあります 彼らが並ぶので、 容量、現在の テーブルの容量。 彼らは彼らの中に展開します 独自のオートスケールグループ、 彼らは応じてスピンアウトを開始 で来ているどのように多くの書き込み時に、 どのように多くのreads--本当にそれだと、書いています。 どのreads--しかし、何もありません 多くの書き込みがでてきています。 そして背中に 最後に、我々は持っているものたち KCL、またはキネシスクライアント・ライブラリを呼び出します。 キネシスは、ストリームデータであります アマゾンからの加工技術。 そして、ストリームがその上に構築されています。 だから、KCLが有効に使用します ストリームを読み込むためのアプリケーション。 キネシスクライアントライブラリ実際に あなたのために労働者を管理します。 そしてそれはまた、いくつかの処理を行い 面白いもの。 これは、いくつかのテーブルを作成します。 あなたのDynamoDBの表領域内の どの項目を追跡します 処理されました。 したがって、この方法は、それがあれば、フォールバックしている場合 それが倒れると来て、取得します バック立ち上がって、それがどこで決定することができます それは、ストリームを処理していました。 ときにそれは非常に重要です レプリケーションの話をしています。 私は何を知っている必要があります データが処理されました。 どのようなデータを処理することがまだ。 だから、ストリームのKCLライブラリはなります あなたにその機能の多くを与えます。 これは、すべての家事の世話をします。 これはすべてのシャードのワーカーを立ち上がります。 これは、管理テーブルを作成します すべてのシャードのために、すべての労働者のために。 そして、これらの労働者の火のように、 彼らはそれらのテーブルを維持します あなたはこのレコードを知っています 読み込まれて処理されました。 そして、そのように処理する場合 、死んでオンラインに戻りました それが離陸したところ、それは権利を再開することができます。 だから我々はのためにこれを使用します クロス領域の複製。 顧客の多くは、する必要があります そのデータテーブルのデータまたは一部を移動させます 周りの異なる領域に。 9つの領域があります。 世界中の。 だから私need--があるかもしれません アジアでは、ユーザー、ユーザーが持っているかもしれません アメリカ合衆国東海岸インチ 彼らは、異なるデータを持っています 局所的に分散される必要があります。 そしておそらくユーザーがから飛びます 米国に渡ってアジア、 私は複製したいです 彼と彼のデータ。 彼は飛行機を降りるときに、彼が持っています 自分の携帯アプリを使用して良い経験。 あなたは、クロス領域を使用することができます これを行うには、レプリケーション・ライブラリ。 基本的に我々が持っています 二つの技術を提供しました。 一つは、あなたができるコンソールアプリケーションです 独自のEC2インスタンス上に立っています。 それは純粋な複製を実行します。 そして、我々はあなたのライブラリーを与えました。 あなたが構築するために使用できるライブラリ 独自のアプリケーションあなたの場合 それに狂気の事をしたいですdata-- フィルタは、その一部のみを複製します データの回転、に移動 別のテーブル、というようになど。 だから、それがどのように見えるかのようなものです。 DynamoDBのストリームであることができます 私たちはラムダと呼ぶものによって処理されます。 我々は、イベントについて少し言及しました 駆動型アプリケーション・アーキテクチャ。 ラムダは、の重要な構成要素です。 ラムダは、必要に応じて発生させたコードです 特定のイベントに応答しました。 これらのイベントの一つは、可能性があり ストリーム上に現れたレコード。 レコードがストリームに表示された場合は、 我々は、このJava関数を呼び出します。 まあ、これはJavaScript、およびラムダです Node.jsの、JavaやPythonは、サポートしています すぐにサポートします 他の言語にも。 そして、それは純粋なコードですが、言えば十分。 Javaでは書き込みは、クラスを定義します。 あなたは、ラムダにJARを押し上げ。 そして、あなたはどのクラスを指定します イベントに応答して呼び出します。 そしてラムダインフラ その後ろにそのコードを実行します。 このコードは、処理することができます ストリームオフ記録。 それはそれで望んで何かを行うことができます。 この特定の例では、すべて我々がいます 本当に属性をログに記録されてい。 しかし、これは単にコードです。 コー​​ドは右、何かを行うことができますか？ だから、そのデータを回転させることができます。 あなたは派生ビューを作成することができます。 それは文書構造だ場合、 あなたが構造を平らにすることができます。 あなたは、代替索引を作成することができます。 物事のすべての種類のことができます。 DynamoDBのストリームで行います。 そして実際に、それはそれは次のようになります。 ですから、それらの更新が入ってくる得ます。 彼らは文字列をオフに来ています。 これらは、ラムダ関数によって読み取らています。 彼らはデータを回転していて、 派生テーブルでそれを押し上げ、 変更の外部システムに通知します、 そして、ElastiCacheにデータをプッシュします。 我々はキャッシュを置く方法について話しました その販売のためのデータベースの前に シナリオ。 まあ何が起こるかの私 商品説明を更新？ まあ、私が持っていた場合にはラムダ この関数は、そのテーブル上で実行されています 私は商品説明を更新する場合、それはよ ストリームからレコードをピックアップし、 それはElastiCacheを更新します 新しいデータでインスタンス。 だから、たくさんのです 私たちは、ラムダをどうしますか。 これは、グルーコード、コネクタです。 そして、それは実際に提供します 起動する機能 非常に複雑なアプリケーションを実行するには 専用サーバーなし 本当にクールであるインフラ、。 それでは、戻って私たちに行きましょう リアルタイム投票アーキテクチャ。 これは新しいものであると私たちで改善 ストリームおよびKCLは、アプリケーションを可能にしました。 我々はできる、前と同じ 選挙の任意のスケールを処理します。 私たちはこれが好き。 私たちは、スキャッタギャザーをやっています 複数のバケットを横断。 私たちは楽観的ロックが起こってんです。 私たちは、有権者を保つことができます 彼らの票を変えるから。 彼らは一度だけ投票することができます。 これは素晴らしいです。 リアルタイムのフォールトトレランス、 今スケーラブル集約。 事は、それを上に落下した場合 自分自身を再起動する場所を知っています それがために復帰すると 私たちは、KCLのアプリを使用しています。 そして、我々はまた、それを使用することができます アウトデータをプッシュするKCLアプリケーション 他のために赤方偏移します アプリの分析、または使用 実行するには、Elastic MapReduceの リアルタイムストリーミング集計オフ そのデータの。 したがって、これらは私達のものです あまり話をしませんでした。 しかし、彼らは追加しています 来技術 あなたが探している時に負担します これらのタイプのシナリオで。 すべての権利、それは程度ですので、 DynamoDBのStreamsを使用した分析。 あなたは、デデュープを収集することができます データは、すべての種類を行います すてきなものの中で、集計データ メモリは、それらの派生テーブルを作成します。 それは巨大なユースケースです その顧客の多く ネストされたを取る、と関与しています これらのJSONドキュメントのプロパティ そして、追加の索引を作成します。 私たちは最後にしています。 私と一緒にベアリングをありがとうございました。 それではについてお話しましょう 参照アーキテクチャ。 DynamoDBのはそうの真ん中に座っています AWSインフラストラクチャの多く。 基本的にはそれをフックすることができます あなたが望むものまで。 アプリケーションは、ディナモには、使用して構築します ラムダ、ElastiCache、CloudSearch、 弾性に出てデータをプッシュ MapReduceの、DynamoDBのからのインポート・エクスポート S3では、ワークフローのすべての種類に。 しかし、おそらく最高 話をすること、 これが本当に何であります ときに我々は興味深いです イベント駆動型アプリケーションについて話しています。 これは一例です 社内プロジェクト 私たちが実際にいる場所を持っていること 調査結果を収集する出版。 電子メールのリンクでだから、 我々はそこよ、送り出します クリック言って少しリンクすること ここでは、調査に応答します。 そして、ときに人がクリック そのリンクは、何が起こります 彼らは安全なプルダウンであります S3からのHTML調査票。 何のサーバがありません。 これはただのS3オブジェクトです。 そのフォームは、アップします ブラウザにアップロードします。 これは、バックボーンを持っています。 これは、複雑なJavaScriptを持っています それが実行していること。 だから、非常に豊富なアプリケーションです クライアントのブラウザで実行されています。 彼らはないしていることを知りません バックエンドサーバとの対話。 この時点で、すべてのブラウザです。 彼らはどのように結果を公開 我々は、Amazon APIゲートウェイを呼び出します。 APIゲートウェイは、単にウェブAPIです あなたが定義してフックアップすることができ あなたが好きなの。 この特定のケースでは、我々はしています ラムダ関数にフックアップ。 だから私のPOST操作は、 なしサーバーと起こっ。 基本的にはそのAPIゲートウェイが座っています。 それは人々まで、私は何も費用はかかりません 右、それに投稿を開始！ ラムダ関数はそこに座っています。 までそしてそれは私に何も費用はかかりません 人々はそれを打つ開始します。 だから、ボリュームとして、見ることができます 電荷が来たとき​​に増加し、それはです。 私は、サーバー7/24を実行していませんよ。 だから私は、フォームを引きます ダウンバケットのうち、 私は、APIを介して投稿します ラムダ関数にゲートウェイ。 そして、ラムダ この関数は、あなたが知っている、と言います 私はいくつかのPIIs、いくつかを持っているもの、 個人情報 これらの応答インチ 私は、ユーザーからのコメントを得ました。 私は、電子メールアドレスを持っています。 私は、ユーザ名を持っています。 私はこれをオフに分割してみましょう。 私はいくつかを生成するつもりです このレコードオフメタデータ。 そして、私はプッシュするつもりです DynamoDBの中にメタデータ。 そして、私はすべてのデータを暗号化することができ 私がしたい場合やDynamoDBの中にそれを押してください。 しかし、それはこの中で、私のために簡単です 先に発言権を行くために、ケースを使用し、 私は生のデータをプッシュするつもりです 暗号化されたS3バケットへ。 だから私は、S3サーバ側に建てられた使用します 暗号化とAmazonのキー管理 サービス私はその鍵を持っているように、 定期的に回転させることができ、 私は、そのPIIデータを保護することができます この全体のワークフローの一部として。 だから私は何をしましたか？ 私はちょうど全体を展開してきました アプリケーション、および私は、サーバーを持っていません。 だから何のイベントアプリケーションを駆動させます アーキテクチャは、あなたのために行います。 今、あなたが考える場合 this--ためのユースケース 私たちは、私が話している他の顧客を持っています この正確なアーキテクチャの人に 驚異的に大規模なキャンペーンを実行し、誰が 私のああ、このを見ていきます。 今、彼らができるので、 基本的にはそこにそれを押し出します、 そのキャンペーンはただ座ってみましょう それが起動し、ないまで 図を心配する必要はあり インフラの種類 それをサポートするためにそこになるだろう。 そして、できるだけ早く そのキャンペーンが行われ、 それは、インフラストラクチャのようなものです ちょうどすぐに消えます 実際にそこにあるため 何のインフラストラクチャではありません。 これは、ラムダに座っているだけのコードです。 これは、DynamoDBのに座っているだけのデータです。 それは素晴らしい方法です アプリケーションを構築することができます。 聴衆：だから、もっとあります それは場合よりもはかないです それは、実際のサーバー上に格納された場合はどうなりますか？ RICKフーリハン：もちろんです。 そのサーバインスタンスので、 7/24でなければなりません。 それはのために利用可能である必要があります に対応する誰か。 さて、どうなったと思いますか？ S3は7/24可能です。 S3は常に応答します。 そして、S3は非常に、非常に良いです オブジェクトを提供しました。 これらのオブジェクトは、HTMLファイル、またはすることができます JavaScriptファイル、または何でもしたいです。 あなたは非常にリッチなWebアプリケーションを実行することができます S3バケットのうち、人々が行います。 そして、そのためには、ここでアイデアです 道から離れて取得することです 我々はそれについて考えるために使用されます。 我々は、すべてで考えるために使用 サーバおよびホストの観点から。 それはもうそのことについてではありません。 これは、コードとしてのインフラについてです。 クラウドにコードを展開し、 雲があなたのためにそれを実行してみましょう。 そしてそれは、AWSがやろうとしているものです。 聴衆：真ん中にだからあなたの金の箱 APIのゲートウェイは、サーバーのようではありません その代わりjust--です RICKフーリハン：あなたが考えることができます そのサーバファサードとして。 それはすべてが、それは、HTTPを取るよです 要求し、別のプロセスにマッピングします。 それはそれがないすべてです。 そして、この場合には、我々は、マッピングしています それラムダ関数に。 すべての権利なので、それは私が得たすべてです。 ありがとうございます。 それは有り難いです。 私たちは時間をかけて少ししたい知っています。 そして、うまくいけば、あなたたちは持って 情報の少し 今日は離れて取ることができます。 私が行った場合私は謝罪します あなたの頭の一部の上に、 しかしの良いたくさんあり​​ます 基本的な基礎知識 私はあなたのために非常に価値があると思います。 だから、私を持ってくれてありがとう。 [拍手] 聴衆：[聞こえません] あなたが言っていたときであります あなたが事を通過しなければなりませんでした 最初から最後まで 正しい値を取得します 同じ値か、 どのようにでしょう値 [聞こえない]場合は変更します。 RICKフーリハン：ああ、冪等？ 値がどのように変化するでしょうか？ まあ、私は実行しなかった場合ので、 最後に、それはすべての方法、 私は変更のか分かりません ラストマイルで行われました。 それはあることを行っていません 私が見たものと同じデータ。 聴衆：ああ、そうちょうどあなた 入力全体をもらっていません。 RICKフーリハン：右。 あなたは最初から行かなければなりません 最後に、それです 整合性のとれた状態になるだろう。 クール。 聴衆：だから、私たちを示したDynamoDBの ドキュメントまたはキー値を行うことができます。 そして、私たちは多くの時間を費やし ハッシュと方法とキー値 それを周りに反転します。 あなたは、これらの表を見ると、ということです 文書のアプローチを残し？ RICKフーリハン：私はないでしょう それを残すと言います。 聴衆：彼らはthe--から分離しました RICKフーリハン：文書に アプローチ、DynamoDBの中のドキュメントタイプ ちょうど別の属性として考えますさ。 これは、含まれている属性です 階層データ構造。 そしてクエリで、 あなたは、プロパティを使用することができます オブジェクトの表記を使用して、それらのオブジェクトの。 だから私は、ネストされた上でフィルタリングすることができます JSONドキュメントのプロパティ。 聴衆：だからいつでも私 文書のアプローチを行い、 私は、ソートのtabular--に到着することができます 聴衆：もちろんです。 聴衆：--indexesと あなただけのについて話しましたもの。 RICKフーリハン：うん、 インデックスとすべてのこと、 ときにインデックスを作成します JSONのプロパティ、 我々はそれを行う必要があるだろう方法がある場合 あなたはJSONオブジェクトまたは文書を挿入 ダイナモに、あなたは、ストリームを使用します。 ストリームは、入力を読んでいました。 あなたは、JSONを取得したいです オブジェクトと[OK]を言うだろう、 私はインデックスを作成するプロパティは、何ですか？ あなたは、派生テーブルを作成します。 今では、それが今の仕組みです。 私たちはインデックスにあなたを許可しません 直接これらのプロパティ。 聴衆：あなたの文書をTabularizing。 RICKフーリハン：その通り、平坦化 それは、まさに、それをtabularizing。 それはあなたがそれを行うものです。 観客は：ありがとうございます。 RICKフーリハン：うん、 絶対に、あなたに感謝。 聴衆：だから、それは一種のです モンゴはRedisのの分類器のを満たしています。 RICKフーリハン：うん、 それはそのような多くのです。 それはそれのための適切な説明です。 クール。