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

RDBとKVSとの上手な付き合い方

株式会社トライフォート

大谷祐司

Copyright © 2013 TriFort, Inc. All Rights Reserved.

自己紹介
・山口県出身の33歳
・2013年4月にトライフォート入社。

・サーバーサイド開発チームの責任者。
・車とプログラミングを愛しています。


自己紹介
ソーシャル業界に飛び込んで約8ヶ月。
それまでは、ネット広告関連の比較的固い開
発を行っていました。

今ではすっかりソーシャルに染まっています。


今日のテーマ

RDBとKVSとの上手な付き合い方


ところで、
皆さんKVS使ってますか？


KVSについてのおさらい

データに対応する一意のキーを設定し、
ペアで保存するDB。


KVSについてのおさらい

KVS
Keyを指定して
Valueを取得する

Value

key

Value

key


key

Value

今日お話すること
KVSとRDBをどうやって使うと、
どんな問題解決ができるのか。
AWSの採用で注目されているRedisを例
にお話します。


KVSは主に、データアクセスにおける
パフォーマンスの問題を解決できます。


KVSが速い3つのポイント
・インメモリー
・シンプルな処理
・イベント駆動アーキテクチャ


問題：メモリとHDDはどれくらいの速
度差があるでしょうか？


答え：10万〜100万倍


高いパフォーマンス
全てのデータセットをメモリ内に読み込む

高速なデータアクセスを実現


一般的なRDBのSELECTクエリ実行
① プロセスを作成する
② SQLを解析する
③ 該当の行をロックする
④ HDDから値を取得する

⑤ ロックを解除する
⑥ 値を返す
※分かりやすいように単純化しています。

KVSから値を取得する処理
① コマンドを解読
② メモリから値を取得する
③ 値を返す
→シンプルに素早く動作します。
※分かりやすいように単純化しています。

イベント駆動アーキテクチャ
命令をトリガにプロセスを立ち上げるのではなく、
予め待機しているプロセスが命令を処理します。
プロセス生成は時間がかかるのです。
※スレッドを立ち上げるRDBも存在します。

プロセス
プログラムコード

プロセスの情報

データ


イベント駆動アーキテクチャ
ボクシングに例えるなら、
RDB : パンチが来たらそれからグローブを付けて殴り返す。

KVS : ファイティングポーズをとっておき、いつでも
殴り返せるようにしておく

というイメージです。


シングルスレッド
Redisはシングルスレッドで動作します。
一般的なRDBのように複数の処理を並列で行う事は不可能です。
必然的に、全てのデータ操作は排他的になります。

コマンド
コマンド
コマンド
コマンド


1スレッドで
順番に処理

Redis

これらのポイントから、
KVSは高速なデータアクセス
を実現します。


KVSの良い点を上げましたが、

もちろん弱点もあります。


KVSの弱点
・ディスク容量
・クラッシュセーフでない
・取得時の集計/ソートに弱い


メモリにデータを保存するので、大容量を
保存する事が難しくなってきます。
①ハードウェア的なメモリの上限
②コスト的なデメリット
という要因があります。


一般的な16スロットサーバの場合、
16G × 16 = 256G
程度が、メモリの上限になります。
※実際はOSがメモリを使うので、もっと少なくなります。


データのバックアップを行う場合には、
使用できる量がその半分程度になります。
バックアップ実行時に、保存データと同
じサイズのメモリを使用します。


②コスト的なデメリット
16G × 16 = 256Gのメモリは、
約43万円にもなります。
安価になったとはいえ、まだまだ

値が張ります。


メモリにデータを保存しているので、
マシンを再起動すると全て消失してし
まいます。
バックアップ/リカバリ方法が用意され
ていますが、まだRDBの方が信頼性が
高いと言われています。


データ永続化(バックアップ)
①SAVE/BGSAVE
⇒DBのフルダンプ（RDB = Redis DataBase）を作成。

SAVE/BGSAVE

全データ

Redis


RDB

データ永続化(バックアップ)
②AOF(Append Only File)
⇒コマンド実行ログ。ここからデータ復元可能。

コマンド

コマンド

Redis


AOF

値の集計/ソート/計算などの柔軟な操作が
できない。

アプリケーション側で実装する必要があ
ります。


SQLなら簡単な操作も、アプリケーション
側で実装する必要があります。
ソート

order by

集計

group by

件数

count()

合計

sum()

フィルタ

where YY = ZZ

結合

join


結論
異なる特徴を持っているRDBとKVS。
補完し合う事で多くの問題解決ができます。


RDBとKVSをどのように共存させる？


RDBの値をKVSに保持する方法
・RDBのレコードをそのままセット
・RDBのレコードを結合/加工してセット

・レコードの統計情報をセット
等があります。


RDBのレコードをそのままセット


【メリット】
・RDB→KVSのキャッシュ処理をシンプルに実装できる。
・値をKVSから取得してもRDBから取得しても、
同じように扱う事ができる。
・データ更新時のRDB→KVSのキャッシュを簡単に行える。


【注意点】
・データの持ち方によっては、KVSへのアクセス回数が増える。
(レコードを補完するデータを取得 etc)
・データの加工が必要な場合、取得した後に操作が必要になる。
・「そのまま」データを持つので、サイズが大きくなって
しまう事がある。


RDBのレコードを操作/加工してセット

操作/加工


【メリット】
・データ取得後にそのまま活用できるケースが増える。
・負荷がかかるデータ操作/加工の回数を減らせる。

・必要なデータを選択する事で、サイズを減らす事ができる。


【注意点】
・プログラム側でデータ操作/加工の処理が必要になる。
・RDBのデータが変更されたとき、KVSへのキャッシュが

複雑になる。


レコードの統計情報をセット

統計処理


【メリット】
・RDBやプログラムで、統計処理の回数を減らせる。
・RDBで統計情報を冗長的に持たなくてよくなる。

・時間のかかる統計処理の結果を活用することができる。
(統計に時間がかかると、リアルタイムでの活用が困難)


【注意点】
・プログラム側でデータ集計処理の実装が必要になる。
・データ変更されたとき、再集計の必要がある。
・実データと集計値に差分が出ない(出ても良い)工夫が必要。


サーバの構成について


サーバ構成パターン
・Redisサーバのみで値を保持する
・RDBのキャッシュサーバとしてRedisを利用する

・WebサーバにRedisを同居させる
・1台のサーバに多数のRedisを立ち上げて、複数のCPUコアを使う
・監視サーバを設置してフェールオーバーできるようにする。

時間の関係で詳しい説明は割愛しますが、
様々な構成が存在します。

結論
組み合わせのパターンは多いので、
「何を実現したいか」によって構成を
使い分ける事が重要です。


Redisについて詳しく知りたい方
社内勉強会の資料をアップしていますので
「Redis勉強会」で検索してみてください。


発表は以上になります。
ご清聴ありがとうございました。


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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

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

Mehr von Yuji Otani

Mehr von Yuji Otani (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

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