RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)

7,014 views

Published on

2013年11月11日の勉強会@LIG社で発表した際の資料です。

Published in: Technology

RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)

  1. 1. RDBとKVSとの上手な付き合い方 株式会社トライフォート 大谷 祐司 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  2. 2. 自己紹介 ・山口県出身の33歳 ・2013年4月にトライフォート入社。 ・サーバーサイド開発チームの責任者。 ・車とプログラミングを愛しています。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  3. 3. 自己紹介 ソーシャル業界に飛び込んで約8ヶ月。 それまでは、ネット広告関連の比較的固い開 発を行っていました。 今ではすっかりソーシャルに染まっています。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  4. 4. 今日のテーマ RDBとKVSとの上手な付き合い方 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  5. 5. ところで、 皆さんKVS使ってますか? Copyright © 2013 TriFort, Inc. All Rights Reserved.
  6. 6. KVSについてのおさらい データに対応する一意のキーを設定し、 ペアで保存するDB。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  7. 7. KVSについてのおさらい KVS Keyを指定して Valueを取得する Value key Value key Copyright © 2013 TriFort, Inc. All Rights Reserved. key Value
  8. 8. 今日お話すること KVSとRDBをどうやって使うと、 どんな問題解決ができるのか。 AWSの採用で注目されているRedisを例 にお話します。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  9. 9. KVSは主に、データアクセスにおける パフォーマンスの問題を解決できます。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  10. 10. KVSが速い3つのポイント ・インメモリー ・シンプルな処理 ・イベント駆動アーキテクチャ Copyright © 2013 TriFort, Inc. All Rights Reserved.
  11. 11. KVSが速い3つのポイント ・インメモリー ・シンプルな処理 ・イベント駆動アーキテクチャ Copyright © 2013 TriFort, Inc. All Rights Reserved.
  12. 12. 問題:メモリとHDDはどれくらいの速 度差があるでしょうか? Copyright © 2013 TriFort, Inc. All Rights Reserved.
  13. 13. 答え:10万〜100万倍 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  14. 14. 高いパフォーマンス 全てのデータセットをメモリ内に読み込む 高速なデータアクセスを実現 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  15. 15. KVSが速い3つのポイント ・インメモリー ・シンプルな処理 ・イベント駆動アーキテクチャ Copyright © 2013 TriFort, Inc. All Rights Reserved.
  16. 16. 一般的なRDBのSELECTクエリ実行 ① プロセスを作成する ② SQLを解析する ③ 該当の行をロックする ④ HDDから値を取得する ⑤ ロックを解除する ⑥ 値を返す ※分かりやすいように単純化しています。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  17. 17. KVSから値を取得する処理 ① コマンドを解読 ② メモリから値を取得する ③ 値を返す →シンプルに素早く動作します。 ※分かりやすいように単純化しています。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  18. 18. KVSが速い3つのポイント ・インメモリー ・シンプルな処理 ・イベント駆動アーキテクチャ Copyright © 2013 TriFort, Inc. All Rights Reserved.
  19. 19. イベント駆動アーキテクチャ 命令をトリガにプロセスを立ち上げるのではなく、 予め待機しているプロセスが命令を処理します。 プロセス生成は時間がかかるのです。 ※スレッドを立ち上げるRDBも存在します。 プロセス プログラムコード プロセスの情報 データ Copyright © 2013 TriFort, Inc. All Rights Reserved.
  20. 20. イベント駆動アーキテクチャ ボクシングに例えるなら、 RDB : パンチが来たらそれからグローブを付けて殴り返す。 KVS : ファイティングポーズをとっておき、いつでも 殴り返せるようにしておく というイメージです。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  21. 21. シングルスレッド Redisはシングルスレッドで動作します。 一般的なRDBのように複数の処理を並列で行う事は不可能です。 必然的に、全てのデータ操作は排他的になります。 コマンド コマンド コマンド コマンド Copyright © 2013 TriFort, Inc. All Rights Reserved. 1スレッドで 順番に処理 Redis
  22. 22. これらのポイントから、 KVSは高速なデータアクセス を実現します。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  23. 23. KVSの良い点を上げましたが、 もちろん弱点もあります。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  24. 24. KVSの弱点 ・ディスク容量 ・クラッシュセーフでない ・取得時の集計/ソートに弱い Copyright © 2013 TriFort, Inc. All Rights Reserved.
  25. 25. KVSの弱点 ・ディスク容量 ・クラッシュセーフでない ・取得時の集計/ソートに弱い Copyright © 2013 TriFort, Inc. All Rights Reserved.
  26. 26. メモリにデータを保存するので、大容量を 保存する事が難しくなってきます。 ①ハードウェア的なメモリの上限 ②コスト的なデメリット という要因があります。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  27. 27. ①ハードウェア的なメモリの上限 一般的な16スロットサーバの場合、 16G × 16 = 256G 程度が、メモリの上限になります。 ※実際はOSがメモリを使うので、もっと少なくなります。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  28. 28. ①ハードウェア的なメモリの上限 データのバックアップを行う場合には、 使用できる量がその半分程度になります。 バックアップ実行時に、保存データと同 じサイズのメモリを使用します。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  29. 29. ②コスト的なデメリット 16G × 16 = 256Gのメモリは、 約43万円にもなります。 安価になったとはいえ、まだまだ 値が張ります。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  30. 30. KVSの弱点 ・ディスク容量 ・クラッシュセーフでない ・取得時の集計/ソートに弱い Copyright © 2013 TriFort, Inc. All Rights Reserved.
  31. 31. メモリにデータを保存しているので、 マシンを再起動すると全て消失してし まいます。 バックアップ/リカバリ方法が用意され ていますが、まだRDBの方が信頼性が 高いと言われています。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  32. 32. データ永続化(バックアップ) ①SAVE/BGSAVE ⇒DBのフルダンプ(RDB = Redis DataBase)を作成。 SAVE/BGSAVE 全データ Redis Copyright © 2013 TriFort, Inc. All Rights Reserved. RDB
  33. 33. データ永続化(バックアップ) ②AOF(Append Only File) ⇒コマンド実行ログ。ここからデータ復元可能。 コマンド コマンド Redis Copyright © 2013 TriFort, Inc. All Rights Reserved. AOF
  34. 34. KVSの弱点 ・ディスク容量 ・クラッシュセーフでない ・取得時の集計/ソートに弱い Copyright © 2013 TriFort, Inc. All Rights Reserved.
  35. 35. 値の集計/ソート/計算などの柔軟な操作が できない。 アプリケーション側で実装する必要があ ります。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  36. 36. SQLなら簡単な操作も、アプリケーション 側で実装する必要があります。 ソート order by 集計 group by 件数 count() 合計 sum() フィルタ where YY = ZZ 結合 join Copyright © 2013 TriFort, Inc. All Rights Reserved.
  37. 37. 結論 異なる特徴を持っているRDBとKVS。 補完し合う事で多くの問題解決ができます。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  38. 38. RDBとKVSをどのように共存させる? Copyright © 2013 TriFort, Inc. All Rights Reserved.
  39. 39. RDBの値をKVSに保持する方法 ・RDBのレコードをそのままセット ・RDBのレコードを結合/加工してセット ・レコードの統計情報をセット 等があります。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  40. 40. RDBのレコードをそのままセット Copyright © 2013 TriFort, Inc. All Rights Reserved.
  41. 41. RDBのレコードをそのままセット 【メリット】 ・RDB→KVSのキャッシュ処理をシンプルに実装できる。 ・値をKVSから取得してもRDBから取得しても、 同じように扱う事ができる。 ・データ更新時のRDB→KVSのキャッシュを簡単に行える。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  42. 42. RDBのレコードをそのままセット 【注意点】 ・データの持ち方によっては、KVSへのアクセス回数が増える。 (レコードを補完するデータを取得 etc) ・データの加工が必要な場合、取得した後に操作が必要になる。 ・「そのまま」データを持つので、サイズが大きくなって しまう事がある。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  43. 43. RDBのレコードを操作/加工してセット 操作/加工 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  44. 44. RDBのレコードを操作/加工してセット 【メリット】 ・データ取得後にそのまま活用できるケースが増える。 ・負荷がかかるデータ操作/加工の回数を減らせる。 ・必要なデータを選択する事で、サイズを減らす事ができる。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  45. 45. RDBのレコードを操作/加工してセット 【注意点】 ・プログラム側でデータ操作/加工の処理が必要になる。 ・RDBのデータが変更されたとき、KVSへのキャッシュが 複雑になる。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  46. 46. レコードの統計情報をセット 統計処理 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  47. 47. レコードの統計情報をセット 【メリット】 ・RDBやプログラムで、統計処理の回数を減らせる。 ・RDBで統計情報を冗長的に持たなくてよくなる。 ・時間のかかる統計処理の結果を活用することができる。 (統計に時間がかかると、リアルタイムでの活用が困難) Copyright © 2013 TriFort, Inc. All Rights Reserved.
  48. 48. レコードの統計情報をセット 【注意点】 ・プログラム側でデータ集計処理の実装が必要になる。 ・データ変更されたとき、再集計の必要がある。 ・実データと集計値に差分が出ない(出ても良い)工夫が必要。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  49. 49. サーバの構成について Copyright © 2013 TriFort, Inc. All Rights Reserved.
  50. 50. サーバ構成パターン ・Redisサーバのみで値を保持する ・RDBのキャッシュサーバとしてRedisを利用する ・WebサーバにRedisを同居させる ・1台のサーバに多数のRedisを立ち上げて、複数のCPUコアを使う ・監視サーバを設置してフェールオーバーできるようにする。 時間の関係で詳しい説明は割愛しますが、 様々な構成が存在します。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  51. 51. 結論 組み合わせのパターンは多いので、 「何を実現したいか」によって構成を 使い分ける事が重要です。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  52. 52. Redisについて詳しく知りたい方 社内勉強会の資料をアップしていますので 「Redis勉強会」で検索してみてください。 Copyright © 2013 TriFort, Inc. All Rights Reserved.
  53. 53. 発表は以上になります。 ご清聴ありがとうございました。 Copyright © 2013 TriFort, Inc. All Rights Reserved.

×