データベースの使い分けを考える
TRANSCRIPT
データベースの使い分けを考える
クラスメソッド株式会社データインテグレーション部
甲木 洋介
#gbfukuoka
classmethod.jp 1
2017/2/11 合同勉強会 in 福岡
自己紹介
• 甲木 洋介(かつき ようすけ)
• id: yokatsuki
• クラスメソッド株式会社データインテグレーション(DI)部所属
• AWS上でデータ分析基盤の提案と技術検証、構築を担当
• 丸星ラーメンと立花うどん
classmethod.jp 2
Developers.IO
classmethod.jp 3
クラスメソッド 採用応募フォームホームページ(classmethod.jp) → 画面一番下スクロール
→ 「採用のお問い合わせ」
4
簡単です是非
classmethod.jp 5
本セッションの内容
選択肢が増えたデータベース、DBMSの
使い分けを考えてみる
検索キーワードは黄色
※だいたい個人の感想です
classmethod.jp 6
データベースの用途
• データ保存
– 一瞬から10年
• データ操作(加工)
– 分析対象の抽出
– 別のデータと合成
• それぞれのDBMSには得手/不得手がある
classmethod.jp 7
結論
• 機能の重複は増えてきたが、「何にでも合う」DBMSはない
• データの寿命で選ぶ
• データの柔らかさで選ぶ
• 扱うデータ量で選ぶ
• 性能だけでは選ばない
classmethod.jp 8
データの寿命で選ぶ(短寿命)
• 「RDBMSは超巨大なグローバル変数」という解釈
• memcached、Redisの延長上
• 高速(オンメモリ)
• 柔軟なデータ構造
• トランザクション管理の必要性低
• NoSQL DBMS
classmethod.jp 9
Amazon DynamoDB
• AWS提供のマネージドNoSQL DB
• 低レイテンシ、大量アクセス重視
classmethod.jp 10
データの寿命で選ぶ(長寿命)
• 長期間のデータは安さと汎用性重視
• アクセスログ、ユーザ購買履歴
• 現物保管、しかし直接参照しない
• データレイクという考え方
• AWSの場合はS3 → GlacierそれをRedshiftやEMRへ
classmethod.jp 11
データレイク
• 生データを「とりあえず全部」保存
• 後で必要な構造に加工、抽出
• クラウドサービスの登場(ストレージ価格の定価)により実現
classmethod.jp 12
Amazon Athena
• S3のファイルに直接SQL
• 従量課金(1TBあたり$5)
• 同時5クエリ、動作時間30分などの制限
classmethod.jp 13
データの柔らかさで選ぶ
• データの項目数や型が決まっているか
• RDB or KVS(Key-Valueストア)
• 格納されたデータの活用法を考慮
– 「とりあえずKVS」は危険
classmethod.jp 14
カラム型データベース
• 基本はRDB
– テーブル
– SQL
• アプライアンス製品が多い
• スケールアウトできるものが多い
• 集計処理に強み
• トランザクション処理は得意ではない
classmethod.jp 15
Amazon Redshift
• マネージドデータウェアハウス製品
• スケールアップ、スケールアップ両方で性能向上可能
classmethod.jp 16
データ量で選ぶ
• RDBMS or Hadoopエコシステム
• 目標時間内に処理完了の為にスケールアウトによる力技が有利
• 費用、管理性で判断
classmethod.jp 17
Amazon EMR
• マネージドHadoopフレームワーク
classmethod.jp 18
性能で選ぶ？
• 「◯◯が速いと聞いたので…」• 機能、特性を考えず、
性能だけで選ぶと問題が起きやすい• アカン例
– Redshiftでレコードアクセス• アーキテクチャ上苦手
– 一台のMySQLで巨大集計• 速度を上げるのに苦労
– Cassandraで長期間保存• 保存コストがかかる
classmethod.jp 19
性能で選ぶ？
• DBMS高速化の仕組みを事前に把握使える高速化機能があるか？
– スケールアップ(CPU、メモリ追加)
– スケールアウト(マシン追加)
– キャッシュ
– インデックス
– 分散キー
classmethod.jp 20
まとめ
• 機能の重複は増えてきたが、「何にでも合う」DBMSはない
• データの寿命で選ぶ
• データの柔らかさで選ぶ
• 扱うデータ量で選ぶ
• 性能だけでは選ばない
• マネージドサービス最強
classmethod.jp 21
