More Related Content
Similar to [db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太 (20)
More from Insight Technology, Inc. (20)
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太
- 1. db tech showcase Tokyo 2015 - Session D35
高トランザクションを実現する
スケーラブルRDBMS技術
NEC
並木 悠太
2015年6月12日
- 2. Page 2 © NEC Corporation 2015
自己紹介
並木悠太
NECクラウドプラットフォーム事業部
▌NEC入社以来、データベース製品の設計開発を担当
InfoFrame DataBooster
• 高速データ処理向けインメモリ列指向DB
InfoFrame Relational Store
• スケーラブルなトランザクショナルDB
• SQL処理部分を担当
- 3. Page 3 © NEC Corporation 2015
発表の流れ
▌トランザクション性能とスケーラビリティを必要とするRDBMS登場の背景
▌InfoFrame Relational Storeの技術
アーキテクチャ
マイクロシャーディング
▌ユースケース
▌性能
▌まとめ
- 4. Page 4 © NEC Corporation 2015
データベース = トランザクション処理向けRDB?
▌データベースと言えば?
Oracle Database
Microsoft SQL Server
IBM DB2
MySQL
PostgreSQL
...?
▌長い歴史を持つ著名なデータベースには以下の特性がある
データモデル:リレーショナルデータモデル
目的:トランザクション処理
- 5. Page 5 © NEC Corporation 2015
近年の新しいDB関連製品
▌2008年
HBase:Bigtableをモデルにしたデータベース
Hive:Hadoop上のデータウェアハウス
Pig:Hadoop上のデータウェアハウス
Cassandra:Bigtableをモデルにしたデータベース
▌2009年
MongoDB:ドキュメント指向データベース
▌2010年
Spark:高速なデータ処理基盤
▌2012年
Cloudera Impala:リアルタイム分析のためのクエリエンジン
Amazon Redshit:クラウド上のデータウェアハウス
▌2013年
Presto:リアルタイム分析のためのクエリエンジン
▌2015年
Azure Data Lake Service:HDFS互換のクラウド上のスケーラブルなリポジトリ
2000年ごろ
データウェアハウス
(分析に特化)
2005年ごろから
Hadoop関連
KVS
(大量データ処理)
2010年ごろから
ドキュメント指向DB
(柔軟なモデル)
- 6. Page 6 © NEC Corporation 2015
One Size Fits All?
▌DBMSは適材適所で使い分けなければならない
KVS
ドキュメント
指向DB
RDB
トランザクションの
必要性
データモデル
スケーラビリティの
要求ワークロード
要件を踏まえて最適なものを選択
問合せの複雑さ
- 7. Page 7 © NEC Corporation 2015
今日のテーマはRDB
- 8. Page 8 © NEC Corporation 2015
RDBに対するニーズ
▌RDBが廃れたわけではない
▌従来のRDBだけでは新たな要求に対応しきれない
データソースの多様化
スケーラビリティの要求
高度な分析の要求
伝統的なRDB
分析 処理量増加
データ量増加
さまざまな「もの」が
インターネットにつながる
あらゆる場所から
データが発生
蓄積したデータを
活かせないか
要求に対応できない
今日のテーマ
- 9. Page 9 © NEC Corporation 2015
RDBMSにおけるスケーラビリティへの対応
▌RDBMSの機能を保ちつつデータ量、処理量の増加にどう対処するか?
第1段階:スケールアップ
• サーバのスペックを上げる
• 向上の度合いは限られる、ソフトのライセンス費もあがる
第2段階(1):レプリケーション
• 参照を分散させる
• 更新は分散しない
第2段階(2):処理を分割する(シャーディング)
• アプリケーションで意識してデータ・処理を分割
• 構築・保守コストの増加
第3段階:RDBMSをあきらめてKVSやドキュメント指向DBを使う
• データベース側の機能をスリムで軽いものにしてRDBMSでは実現不可能だった性能やス
ケーラビリティを得る
• 必要な機能は自前でアプリに実装
- 10. Page 10 © NEC Corporation 2015
シャーディングでスケーラビリティを確保する際の問題
▌構築
アプリケーションの処理が複雑になる
• アプリがどのデータをどこで管理するか意識しなければならない
• 複数DBにまたがる結果のマージ、トランザクションの制御をアプリで行わなければなら
ない
▌運用・保守
バックアップなどの運用の手間が増加
アプリの保守にも手間がかかる
• 負荷の偏り調整などのためにデータ分割の方法を変えるとなるとアプリの改修が必要
db1 db2 db3
アプリ
負荷の偏りに
対する対処
運用に手間
アプリが複雑化
負荷
大
0~9 10-19 20-29
- 11. Page 11 © NEC Corporation 2015
KVSでRDBを代用する際の問題点
▌構築
データ構造をアプリで管理しなければならない
• バリュー部にはどんな構造でデータが格納されているのかKVSは管理してくれない
ジョイン、ソートといった基本的なDBの処理もアプリで実装する必要がある
• KVSのインタフェースはput/get/delete
• アトミックな操作は基本的に単一のKVペアに閉じた範囲
{
“name”: “suzuki”,
“zip”: “100-0000”,
...
}
name,zip,...
suzuki,100-0000,...
名前 郵便番号
suzuki 100-0000
?キー バリュー
データ構造は
アプリで管理
ジョイン、ソートな
ど基本的な処理も
アプリに実装
- 12. Page 12 © NEC Corporation 2015
ドキュメント指向データベースでRDBを代用する際の問題点
▌キーバリュー構造よりもリッチなデータモデル(JSON形式)を持つドキュメン
ト指向データベースもあり
▌事前のスキーマ定義がないことはKVSと同じ
格納するデータの構造の管理(スキーマ)はアプリが行う
• やりようによってはどんなデータでも入れられるということになる
ただし、いざ取り出そうと思ったときに構造が分からず探し出せないことも
また時系列データを適当に入れていったらデータが膨らんでしまったり
{
“name”: “suzuki”,
“zip”: “100-0000”
} {
“name”: “suzuki”,
“zipcode”: “100-0000”
}{
“名前”: “suzuki”,
“郵便番号”: “100-0000”
}
zip/zipcode/郵便番号
どれだっけ?
{
“名前”: “suzuki”,
“郵便番号”: “100-0000”,
“購入履歴”: [
{ “日付”: “2015-06-10”,
“商品”: “p123”, “数量”: 1 },
{ “日付”: “2015-06-11”,
“商品”: “p42”, “数量”: 2 },
]
} データが肥大化し、
性能が悪化
JSON形式のドキュメント
- 14. Page 14 © NEC Corporation 2015
NECが提案するDBMS
リレーショナルデータモデル
トランザクション処理
(OLTP)
スケーラビリティ
SQL
InfoFrame Relational Store
RDBの機能をスケーラブルに
従来RDBの特性
- 15. Page 15 © NEC Corporation 2015
Partiqleサーバ
InfoFrame Relational Store
InfoFrame Relational Storeのアーキテクチャ
「小さいサイズのデータに対する更新・参照リクエスト」
が大量同時発生する環境で真価を発揮するデータベース
表形式データに対する処理
リクエスト(SQL)を解析
トランザクションサーバ
更新・参照トランザクション
をインメモリ処理
ストレージサーバ
データをキーバリュー形式で
内蔵ディスクに永続化
NEC特許技術
マイクロシャーディング
- 16. Page 16 © NEC Corporation 2015
InfoFrame Relational Store
参照・更新の混在する
環境において、
100万TPSを超える
データ処理数が可能
ペタバイト(PB)クラスの
データ量の蓄積も可能
スモールスタートからペタバイトクラスまでのスケールに対応
- 17. Page 17 © NEC Corporation 2015
CAP定理
▌CAP定理
分散システムは以下の3つを同時に保証することはできない
• 一貫性(Consistency)
• 可用性(Availability)
• 分断耐性(Partition-tolerance)
▌IRSでは特性の異なる2つの
システムを融合し全体の
バランスをとる
Partition-toleranceAvailability
Consistency
ストレージサーバ:AP
トランザクションサーバ:CP
- 19. Page 19 © NEC Corporation 2015
マイクロシャーディング
▌RDBはスケーラブルではない
なぜか? 処理をうまく分割・分散できない
▌IRSではトランザクション処理の範囲を事前に定義する
関係性のない処理を分割することで複数のサーバに分散できる
高いスケーラビリティを実現できる
▌マイクロシャーディング:データをトランザクションの範囲で分割すること
マイクロシャード:個々のトランザクション処理の範囲
商品i1の商品情報 商品i2の商品情報
商品i1の入札履歴1 商品i2の入札履歴1
商品i2の入札履歴2
マイクロシャード:商品i1 マイクロシャード:商品i2
トランザクション
は必要ない
トランザクション
が必要
この例ではすべてのトランザクションは商品ごとに閉じているので
商品ごとにマイクロシャードを構成
- 20. Page 20 © NEC Corporation 2015
SQLからのマイクロシャードの定義
▌どのようにマイクロシャードを構成するかはスキーマ定義時に行う
▌定義はSQLらしく宣言的
TDL: Transaction Definition Languageを導入
データの独立性
物理設計:indexing,パーティション,…
DDL
Schema
TDL
Transaction classes
DML
queries
SELECT・UPDATE・
DELETE etc
CREATE
TRANSACTION
CLASSES etc
ALTER,DROP,
GRANT,
CREATE USER
etc
- 21. Page 21 © NEC Corporation 2015
トランザクションクラスの定義
▌トランザクションクラス = 「マイクロシャードをどう構成するかの定義」
▌例:
items表のidの値、bids表のitem_idの値が同じ行でマイクロシャードを構成
(ある商品について関係するデータをまとめる)
値の具体値については知らなくてよい
items bids
id name nb_of_bids max_bids id user_id item_id bid
i1 LifeTouch 2 20 b1 u3 i1 10
b2 u1 i1 20
i2 MEDIAS 1 10 b4 u1 i2 10
i3 VersaPro 2 30 b5 u3 i3 30
b3 u2 i3 20
item i1
microshard
item i2
microshard
CREATE TRANSACTION CLASS items_trx_cls AS
items BY id, bids BY item_id;
item i3
microshard
トランザクションキートランザクションキー
- 22. Page 22 © NEC Corporation 2015
マイクロシャーディングの実現
▌ここまでは論理層の話
マイクロシャーディングによりデータをトランザクション処理の範囲で分割する
▌ここからは物理層の話
マイクロシャーディングをどのようにKVSの上で実現するか
- 23. Page 23 © NEC Corporation 2015
KVSの特性
・単一KVペア内でのみ
アトミックな操作が可能
・キーを特定しないと
データにアクセスできない
・スケーラビリティに優れる
・高いスループット
RDBとして考えると制約:
IRSに組み込むためには
工夫が必要
IRSに無条件にマッチ
- 24. Page 24 © NEC Corporation 2015
KVSの特性
・単一KVペア内でのみ
アトミックな操作が可能
・キーを特定しないと
データにアクセスできない
・スケーラビリティに優れる
・高いスループット
RDBとして考えると制約:
IRSに組み込むためには
工夫が必要
IRSに無条件にマッチ
- 25. Page 25 © NEC Corporation 2015
KVSでのトランザクショナルな操作の実現
▌KVSでは基本的に1つのKVペアに閉じたアトミックな操作しかできない
異なる表や行にまたがるトランザクション処理をどう実現するか?
トランザクションログを1つのKVペアで管理し、
複数のKVペアに対する間接的なアトミックな操作を実現する
KV1 KV2
直接複数をアトミックに操作することはできない
KV1に対する操作
KV2に対する操作
操作(トランザクションログ)をまとめたKVペア
- 26. Page 26 © NEC Corporation 2015
items bids
id name nb_of_bids max_bids id user_id item_id bid
i1 LifeTouch 2 20 b1 u3 i1 10
b2 u1 i1 20
i2 MEDIAS 1 10 b4 u1 i2 10
i3 VersaPro 2 30 b5 u3 i3 30
b3 u2 i3 20
item i1
microshard
item i2
microshard
CREATE TABLE items (
id TEXT PRIMARY KEY,
name TEXT,
nb_of_bids INT,
max_bid INT,
seller TEXT
);
テーブル定義
データ
INSERT INTO bids VALUES ('b4', 'u1', 'i2', 10);
UPDATE items SET
nb_of_bids = nb_of_bids + 1,
max_bid = CASE WHEN max_bid < 10
THEN 10 ELSE max_bid END
WHERE id = 'i2';
COMMIT;
処理
トランザクションの処理内容をWALとして
一つのキーのKVペアに記録
key value
i2
INSERT bids: (b4, u1, i2, 10)
UPDATE items: (i2, MEDIAS, 1, 10)
内部でのデータの持ち方とトランザクションログの作成
CREATE TABLE bids (
id TEXT PRIMARY KEY,
user_id TEXT,
item_id TEXT,
bid INT
);
item i3
microshard
- 27. Page 27 © NEC Corporation 2015
トランザクションの処理
▌トランザクションをコミットする際はトランザクションサーバにトランザクション
ログのKVペアをコミットして、排他制御する
▌コミット後にストレージサーバの実データをログに基づき非同期で更新する
アプリケーション
Partiqleサーバ
トランザクションサーバ
ストレージサー
バ
ログデータ
• マイクロシャードキーでルーティング(配置場所を決定)、ひとつの物理トランザクションは、
ひとつのマイクロシャードキーに対応する。
• マイクロシャードキーに割り当てる実データは、データ構造などに応じた設定が可能。割り
当て幅が小さいと、共有・排他制御が高速になる。
マイクロシャード2 更新履歴
マイクロシャード1 更新履歴
Key1 Value1 Key2 Value2 Key3 Value3
実データ
• トランザクションとは独立にデータ配置場所を選択できる。
• KVSではデータのキーでルーティング
Key1 Value1 Key2 Value2 Key3 Value3
- 28. Page 28 © NEC Corporation 2015
トランザクション開始
key value
order1
{order1, userA, 2012/6/6}
{order1, MEDIAS, 1}
{order1, LAVIE, 1}
Partiqleサーバ トランザクションサーバ
バージョン番号
100
更新ログ
更新実行 更新ログ
INSERT
COMMIT実行
key value
更新ログ
COMMIT
バージョン番号
101
CASをして格納
key value
原子性確保の仕組み
▌トランザクションログに対するCAS (Compare-And-Swap) 操作で原子性
を確保
- 29. Page 29 © NEC Corporation 2015
トランザクション1開始
Partiqleサーバ トランザクションサーバ
バージョン番号
100
更新ログkey value
AAA{record1-1}, {record2-1}
トランザクション1更新 バージョン番号
100
更新ログkey value
AAA{record1-2}, {record2-1}
UPDATE
トランザクション2開始
バージョン番号
100
更新ログ
key value
AAA{record1-2}, {record2-1}
バージョン番号
100
key value
AAA{record1-1}, {record2-1}
トランザクション1領域
トランザクション2領域
トランザクション1コミット
バージョン番号
101
更新ログ
key value
AAA{record1-2}, {record2-1}
バージョン番号
100
key value
AAA{record1-1}, {record2-1}
トランザクション1領域
トランザクション2領域
CASをして格納
更新ログ
バージョン番号
100
key value
AAA{record1-1}, {record2-1}
トランザクション2領域トランザクション2参照
SELECT
独立性確保の仕組み
▌トランザクションごとに処理領域をもち、独立性を確保
- 30. Page 30 © NEC Corporation 2015
ストレージサーバCOMMIT トランザクションサーバ
マスタスレーブセットA マスタスレーブセットB
A record1
B record2
C record3
A record1
B record2
C record3
A record1
B record2
C record3
D record4
E record5
D record4
E record5
D record4
E record5
G record7
H record8
F record6
H record8
F record6
G record7
H record8 F record6
G record7
耐久性確保の仕組み
▌トランザクションログはトランザクションサーバで3重化
▌実データ(レコード)はストレージサーバで3重化
- 31. Page 31 © NEC Corporation 2015
楽観的排他制御
▌データ処理の競合・衝突がほとんど起こらないことを前提とする同時実行
制御方式
▌データの読み込み時にロックを行わず、更新時に競合・衝突を確認してト
ランザクションの成功・失敗を判断する
▌重いロック管理処理を省き、性能を向上
口座番号=1を読み込むTx1
口座番号=1を読み込む Tx2
口座番号=1を変更 Tx2
コミット Tx2
口座番号=1を変更Tx1
← ここで待ち合わせない
エラー
後行トランザクションのコミット時に衝突を検知してコミットを失敗させる
- 32. Page 32 © NEC Corporation 2015
KVSの特性
・単一KVペア内でのみ
アトミックな操作が可能
・キーを特定しないと
データにアクセスできない
・スケーラビリティに優れる
・高いスループット
RDBとして考えると制約:
IRSに組み込むためには
工夫が必要
IRSに無条件にマッチ
- 33. Page 33 © NEC Corporation 2015
リレーショナルからKVへのマッピング
▌KVSでデータをアクセスするためにはキーが特定できている必要がある
ワークロードに応じて、アクセスに使う列がKVのキーにあるようにリレーショナル
からKVへのマッピングをする必要がある
また、トランザクション処理の仕組み上、トランザクションキーでアクセスできなけ
ればならない
▌リレーショナルモデルをKV形式にマッピングするいくつかの方法を提供
以下からワークロードに応じて適切に選択
• フラット
• インデックス
• クラスタ
• レンジクラスタ
- 34. Page 34 © NEC Corporation 2015
物理デザイン (1) フラット
▌各表の1行を主キーをキーとするキーバリューペアとする
id name nb_of_bids max_bid
レコード i3 VersaPro 2 30
主キー
KVペア { Key: value } = { i3: (i3, VersaPro, 2, 30) }
リレーショナルの世界
内部
メタ情報
{ db1.table1: { id: text, name: text, nb_of_bids: int, max_bid: int}}
表定義情報は別のKVペアで管理
(ドキュメントDBが単一のドキュメントの中に
スキーマとデータを格納するのとは異なる)
- 35. Page 35 © NEC Corporation 2015
物理デザイン (1) インデックス
▌インデックスを定義し、主キー以外の属性によるアクセスパスを確保するこ
ともできる
id Item_id User_id bid
1 1 3 10
2 1 1 20
3 3 2 20
4 2 1 10
5 3 3 30
Item_id id
1 [1,2]
2 [4]
3 [3,5]
凡例: Key value
bidテーブル
[item_id]のインデックス
- 36. Page 36 © NEC Corporation 2015
物理デザイン (2) クラスタの例
▌特定列に同じ値を持つ行をひとつのKVペアにまとめる
メリット:同時にアクセスされやすいレコードが1回のgetで取得できる
デメリット:KVペアのサイズが大きくなりがち、性能問題となる可能性
id Item_id User_id bid
1 1 3 10
2 1 1 20
3 3 2 20
4 2 1 10
5 3 3 30
キー
(Item_id)
バリュー (bidレコードの集合)
1 [(1,1,3,10),(2,1,1,20)]
2 [(4,2,1,10)]
3 [(3,3,2,20),(5,3,3,30)]
bidテーブル
作成されるKVペア
暗黙PK Item_id
1 1
2 1
3 3
4 2
5 3
別途主キーに対する
インデックスも作られる
- 37. Page 37 © NEC Corporation 2015
物理デザイン (3) レンジクラスタの例
▌クラスタの各要素をB-treeにする
クラスタ内の行が増加してもKVペアの肥大化を防ぐことができる
machine_id log_sequence_no log_info log_time
1 1 st1 xxx
1 2 st2 xxx
1
1 2000 st100 xxx
2 1 war5 xxx
2 2 st3 xxx
2 3 war1 xxx
~ ~ ~
クラスタキー 主キー
テーブル定義
CREATE TABLE mlog(
machine_id int,
log_sequence_no int,
log_info int,
log_time time_stamp,
primary key (machine_id, log_sequence_no)
);
レンジクラスタ定義
CREATE RANGE CLUSTER mlog_table
BY machine_id;
mlogテーブル
レンジクラスタ生成
- 38. Page 38 © NEC Corporation 2015
高信頼インメモリ処理技術
▌同期レプリケーションによりインメモリ処理でも信頼性を確保
▌トランザクションサーバにおける高信頼な高速処理を実現
トランザクションサーバ群
トランザクション
サーバ②
トランザクション
サーバ③
マスター
バックアップ バックアップ
書き込み
複製複製
トランザクション
サーバ①
トランザクション
サーバ②
トランザクション
サーバ③
マスターサーバで
障害発生
トランザクション
サーバ①
トランザクション
サーバ②
トランザクション
サーバ③
① 通常運転時 ② 障害発生時 ③ 障害復旧後
トランザクション
サーバ①
バックアップ バックアップ バックアップ
マスター
マスター
技術2
ノードにはそれぞれ2台のスレーブがあり
同期レプリケーション
ハッシュにより複数のノードにデータと処理を分散
- 40. Page 40 © NEC Corporation 2015
画像管理サービス
▌インターネットサービスのバックエンドの画像管理
画僧
ファイル
InfoFrame
Relational Store
画像
ファイル
ウェブアプリケーション
画像ファイル
のメタデータ
処理はユーザごとに閉じているため
ユーザごとにマイクロシャードを構成
ユーザが写真をアッ
プロード(投稿)、公開
従来のRDBと同じ使い心地で
時に爆発的なアクセス増加に対応できるスケーラビリティを実現
- 41. Page 41 © NEC Corporation 2015
輸送機の稼働履歴分析ソリューション
お客さまの目標
輸送機の稼働状況を分析・予測し、輸送機
の運用・管理コストを最適化して収益改善
データ蓄積量
InfoFrame Relational Storeの創出価値
データ蓄積量にジャストフィットした
データベースを提供し過剰投資を抑制
輸送機毎の稼働履歴(時系列データ)
をいつでも安定的に高速検索
お客さま分析基盤に大量データを一括
アップロード(Hadoop連携)でき、分析・予測
の実行サイクルを短縮
InfoFrame Relational Store
位置データ センサデータ 環境データ
既存データベース
スモールスタート
業務無停止
スケールアウト
SLA保証
業務アプリ 分析基盤
SQL
履歴
Hadoop Map/Reduce
生データ
データマート
最終 100 TB以上
現在 10 TB
- 42. Page 42 © NEC Corporation 2015
大規模センサデータ(IoT/M2M)の集計ソリューション
▌スマートメーターなどデバイスデータをInfoFrame Relational Storeに収集
データストアを適材適所で使い分け
Webアプリ
InfoFrame
Relational
Store
Hadoop
過去蓄積
データ
デバイスマスター情報
リアルタイム
センサーデータ
RDB
顧客マスター情報
センサーデータ
顧客情報など
マスターデータ
分析基盤
データ量小
データ量大
高速書き込み
データ量大
広範囲の読み込み
- 43. Page 43 © NEC Corporation 2015
性能
▌TPC-Bを簡略化した軽いトランザクションを発行
7台構成から始めてボトルネックになったところをスケールアウト
0
5,000
10,000
15,000
20,000
構成1 構成2 構成3
トランザク
ションサーバ
をスケール
アウト
Partiqleサー
バをスケール
アウト
スループット(tps)
OS Red Hat Enterprise Linux 6 (x64)
AWS
インスタンス
r3.2xlarge:26ECU8コア 61GiB
EBS:汎用(SSD)
仮想化タイプ:HVM(拡張NW有効)
クライアント数 900
構成 1 2 3
Partiqleサーバ 1 1 2
トランザクションサーバ 3 6 6
ストレージサーバ 3 3 3
合計 7 10 11
- 44. Page 44 © NEC Corporation 2015
まとめ
▌NECはInfoFrame Relational Storeで高いトランザクション処理性
能を持つ、スケーラブルなRDBMSを実現しています
すぐに試せるAMI(Amazon Machine Image)をご用意しています
• 下記窓口よりお問い合わせください
http://jpn.nec.com/infoframe/relationalstore/license_agreement.html
スケーラビリティ
SQL
ACID
SQLと
トランザクション処理
リレーショナルモデル
× ×
InfoFrame Relational Store
アンケートにご協力をお願いします