[レポート] ワークロードに応じた適切なデータベースを構築しよう #reinvent

はじめに

福岡のyoshihitohです。re:Invent 2018のセッション「Building with AWS Databases: Match Your Workload to the Right Database」についてレポートします。

セッション情報

セッション名

Building with AWS Databases: Match Your Workload to the Right Database

スピーカー

• Rick Houlihan - Principal Technologist, NoSQL

概要

原文の引用です。

We have recently seen some convergence of different database technologies. Many customers are evaluating heterogeneous migrations as their database needs have evolved or changed. Evaluating the best database to use for a job isn't as clear as it was ten years ago. We'll discuss the ideal use cases for relational and nonrelational data services, including Amazon ElastiCache for Redis, Amazon DynamoDB, Amazon Aurora, Amazon Neptune, and Amazon Redshift. This session digs into how to evaluate a new workload for the best managed database option. Please join us for a speaker meet-and-greet following this session at the Speaker Lounge (ARIA East, Level 1, Willow Lounge). The meet-and-greet starts 15 minutes after the session and runs for half an hour.

以降がセッション内容です。

ワークロードに応じた適切なデータベースを構築しよう

アジェンダ

• データベースワークロードの分類
• RDBMSをスケールさせるための伝統的なアプローチ
• どうやってNoSQLデータベースを比較するか
• AWS上のNoSQLの特性
• どのデータベースをいつ使うか

データベースのワークロード

• 操作
  • Online Transaction Processing (OLTP)
    • 最も一般的なタイプのアプリケーション
• 分析
  • Online Analytics Processing (OLAP)
    • BIやアドホックなデータ射影する
  • Decision Support Systems (DSS)
    • 長時間実行のクエリを組み合わせて射影する

ワークロードの大きさを決める

• 制限したスコープにおける問題は簡単に解決できる
  • 店内の在庫管理システムが必要
• 制限が無い場合は問題の解決が難しくなる
  • 世界中のマーケットにおけるトランザクション単位のイベントと取引の相関を知るため、根本原因の分析原人が欲しい

データベースの大きさを決める

過不足なく必要な容量を確保するのは難しい

RDBMSをスケールさせる

同様に難しい

RDBMSをシャーディングする

NoSQLデータベース

• 水平スケールのため、正規化をやめてシャード化する
• 無制限に近いスループットおよびストレージ

NoSQLのパーティションキー

• パーティションキーはアイテムを一意に識別する
• パーティションキーは順序の無いハッシュ値のインデクス
• スケールのためテーブルにパーティションを許可する

データのトライアングル - CAPについて

• C: Consistency (一貫性)
  • すべてのクライアントが常に同じデータの見え方になる
• A: Availability (可用性)
  • すべてのクライアントが常に読み書きできる
• P: Partition tolerance (パーティション耐性)
  • パーティションがネットワーク越しにあってもシステムが動作する

技術の採用と誇張の曲線

• 早期に採用した人の一部が搾取される
• 新しい技術を採用する場合はその流儀に従う
  • NoSQLの場合は正規化 + JOIN は避ける、など

AWSのデータベースと分析基盤

Amazon RDS

• マネージドなRDBMS
• 管理しやすい
• 非常に柔軟
• 可用性が高く耐久性も高い
• 高速

Amazon DynamoDB

• キーベースのNoSQLデータベース。ドキュメント型・カラム構造をサポートする
• 非常にスケーラブル
• 高速で一貫したパフォーマンス
• フルマネージdお
• 重要なビジネスに耐え得る信頼性

DynamoDBのスキーマ

主に以下の項目で構成する

• テーブル
• アイテム
  • パーティションキー
  • ソートキー
  • 属性

SQLとNoSQLのデザインパターン

NoSQLの場合は正規化しない

Amazon Neptune

• フルマネージドなグラフ型データベース
• 高速
• 高い信頼性
• 簡単
• オープン(な仕様)

用途

グラフのクエリ種別

• ノードクエリ (プライマリ)
  • グラフ内にどのエンティティが存在するか
• エッジクエリ (インデクス)
  • グラフのエンティティがどのような関連を持っているか
• ハイブリッドクエリ (探索型)
  • エンティティ間にどのような関連があるか

Amazon Redshift

• データウェアハウス
• 高速・強力かつ単純なデータウェアハウス
• 利用費が安い
• 大量に並行処理し、ペタバイト単位にスケールする

Amazon Athena

• インタラクティブに標準SQLクエリを実行してS3のデータを分析するサービス
• インフラの管理が不要で、データのロードも不要
• (Coming soon!) Glacierのアーカイブに対してクエリを実行できる

QLDB (プレビュー)

• フルマネージ型の元帳データベース
• アプリケーションデータのすべての変更を追跡・検証する

データベースのカテゴリ

目的のトライアングル - PIEについて

• P: Pattern Flexibility
  • ランダムアクセスやアドホックなクエリに対応しているか
• I: Infinite Scale
  • 制限なしに徐々に容量やスループットを増やすことができるか
• E: Efficiency
  • ワークロードに必要になるレイテンシで常に配信できるか

おわりに

目的に適したデータベースを選択しないと要件を満たしにくいので、セッションの内容を参考により良いデータベースを選択していきたいです！