[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社並木悠太

db tech showcase Tokyo 2015 - Session D35
高トランザクションを実現する
スケーラブルRDBMS技術
NEC
並木悠太
2015年6月12日

© NEC Corporation 2015
自己紹介
並木悠太
NECクラウドプラットフォーム事業部
▌NEC入社以来、データベース製品の設計開発を担当
InfoFrame DataBooster
• 高速データ処理向けインメモリ列指向DB
InfoFrame Relational Store
• スケーラブルなトランザクショナルDB
• SQL処理部分を担当

発表の流れ
▌トランザクション性能とスケーラビリティを必要とするRDBMS登場の背景
▌InfoFrame Relational Storeの技術
アーキテクチャ
マイクロシャーディング
▌ユースケース
▌性能
▌まとめ

データベース = トランザクション処理向けRDB?
▌データベースと言えば?
Oracle Database
Microsoft SQL Server
IBM DB2
MySQL
PostgreSQL
...?
▌長い歴史を持つ著名なデータベースには以下の特性がある
データモデル：リレーショナルデータモデル
目的：トランザクション処理

近年の新しい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
（柔軟なモデル）

One Size Fits All?
▌DBMSは適材適所で使い分けなければならない
KVS
ドキュメント
指向DB
RDB
トランザクションの
必要性
データモデル
スケーラビリティの
要求ワークロード
要件を踏まえて最適なものを選択
問合せの複雑さ

今日のテーマはRDB

RDBに対するニーズ
▌RDBが廃れたわけではない
▌従来のRDBだけでは新たな要求に対応しきれない
データソースの多様化
スケーラビリティの要求
高度な分析の要求
伝統的なRDB
分析処理量増加
データ量増加
さまざまな「もの」が
インターネットにつながる
あらゆる場所から
データが発生
蓄積したデータを
活かせないか
要求に対応できない
今日のテーマ

RDBMSにおけるスケーラビリティへの対応
▌RDBMSの機能を保ちつつデータ量、処理量の増加にどう対処するか?
第1段階：スケールアップ
• サーバのスペックを上げる
• 向上の度合いは限られる、ソフトのライセンス費もあがる
第2段階(1)：レプリケーション
• 参照を分散させる
• 更新は分散しない
第2段階(2)：処理を分割する（シャーディング）
• アプリケーションで意識してデータ・処理を分割
• 構築・保守コストの増加
第3段階：RDBMSをあきらめてKVSやドキュメント指向DBを使う
• データベース側の機能をスリムで軽いものにしてRDBMSでは実現不可能だった性能やス
ケーラビリティを得る
• 必要な機能は自前でアプリに実装

シャーディングでスケーラビリティを確保する際の問題
▌構築
アプリケーションの処理が複雑になる
• アプリがどのデータをどこで管理するか意識しなければならない
• 複数DBにまたがる結果のマージ、トランザクションの制御をアプリで行わなければなら
ない
▌運用・保守
バックアップなどの運用の手間が増加
アプリの保守にも手間がかかる
• 負荷の偏り調整などのためにデータ分割の方法を変えるとなるとアプリの改修が必要
db1 db2 db3
アプリ
負荷の偏りに
対する対処
運用に手間
アプリが複雑化
負荷
大
0~9 10-19 20-29

KVSでRDBを代用する際の問題点
▌構築
データ構造をアプリで管理しなければならない
• バリュー部にはどんな構造でデータが格納されているのかKVSは管理してくれない
ジョイン、ソートといった基本的なDBの処理もアプリで実装する必要がある
• KVSのインタフェースはput/get/delete
• アトミックな操作は基本的に単一のKVペアに閉じた範囲
{
“name”: “suzuki”,
“zip”: “100-0000”,
...
}
name,zip,...
suzuki,100-0000,...
名前郵便番号
suzuki 100-0000
?キーバリュー
データ構造は
アプリで管理
ジョイン、ソートな
ど基本的な処理も
アプリに実装

ドキュメント指向データベースでRDBを代用する際の問題点
▌キーバリュー構造よりもリッチなデータモデル（JSON形式）を持つドキュメン
ト指向データベースもあり
▌事前のスキーマ定義がないことはKVSと同じ
格納するデータの構造の管理（スキーマ）はアプリが行う
• やりようによってはどんなデータでも入れられるということになる
ただし、いざ取り出そうと思ったときに構造が分からず探し出せないことも
また時系列データを適当に入れていったらデータが膨らんでしまったり
{
“zip”: “100-0000”
} {
“zipcode”: “100-0000”
}{
“名前”: “suzuki”,
“郵便番号”: “100-0000”
}
zip/zipcode/郵便番号
どれだっけ?
{
“名前”: “suzuki”,
“郵便番号”: “100-0000”,
“購入履歴”: [
{ “日付”: “2015-06-10”,
“商品”: “p123”, “数量”: 1 },
{ “日付”: “2015-06-11”,
“商品”: “p42”, “数量”: 2 },
]
} データが肥大化し、
性能が悪化
JSON形式のドキュメント

NECの高トランザクションを実現する
スケーラブルRDBMS技術

NECが提案するDBMS
リレーショナルデータモデル
トランザクション処理
（OLTP）
スケーラビリティ
SQL
InfoFrame Relational Store
RDBの機能をスケーラブルに
従来RDBの特性

Partiqleサーバ
InfoFrame Relational Storeのアーキテクチャ
「小さいサイズのデータに対する更新・参照リクエスト」
が大量同時発生する環境で真価を発揮するデータベース
表形式データに対する処理
リクエスト（SQL）を解析
トランザクションサーバ
更新・参照トランザクション
をインメモリ処理
ストレージサーバ
データをキーバリュー形式で
内蔵ディスクに永続化
NEC特許技術
マイクロシャーディング

参照・更新の混在する
環境において、
100万TPSを超える
データ処理数が可能
ペタバイト（PB）クラスの
データ量の蓄積も可能
スモールスタートからペタバイトクラスまでのスケールに対応

CAP定理
▌CAP定理
分散システムは以下の3つを同時に保証することはできない
• 一貫性（Consistency）
• 可用性（Availability）
• 分断耐性（Partition-tolerance）
▌IRSでは特性の異なる2つの
システムを融合し全体の
バランスをとる
Partition-toleranceAvailability
Consistency
ストレージサーバ：AP
トランザクションサーバ：CP

どのようにKVSでRDBのトランザクション処理を実現するか?

▌RDBはスケーラブルではない
なぜか? 処理をうまく分割・分散できない
▌IRSではトランザクション処理の範囲を事前に定義する
関係性のない処理を分割することで複数のサーバに分散できる
高いスケーラビリティを実現できる
▌マイクロシャーディング：データをトランザクションの範囲で分割すること
マイクロシャード：個々のトランザクション処理の範囲
商品i1の商品情報商品i2の商品情報
商品i1の入札履歴1 商品i2の入札履歴1
商品i2の入札履歴2
マイクロシャード：商品i1 マイクロシャード：商品i2
トランザクション
は必要ない
が必要
この例ではすべてのトランザクションは商品ごとに閉じているので
商品ごとにマイクロシャードを構成

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

トランザクションクラスの定義
▌トランザクションクラス = 「マイクロシャードをどう構成するかの定義」
▌例：
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
トランザクションキートランザクションキー

マイクロシャーディングの実現
▌ここまでは論理層の話
マイクロシャーディングによりデータをトランザクション処理の範囲で分割する
▌ここからは物理層の話
マイクロシャーディングをどのようにKVSの上で実現するか

KVSの特性
・単一KVペア内でのみ
アトミックな操作が可能
・キーを特定しないと
データにアクセスできない
・スケーラビリティに優れる
・高いスループット
RDBとして考えると制約：
IRSに組み込むためには
工夫が必要
IRSに無条件にマッチ

KVSでのトランザクショナルな操作の実現
▌KVSでは基本的に1つのKVペアに閉じたアトミックな操作しかできない
異なる表や行にまたがるトランザクション処理をどう実現するか?
トランザクションログを1つのKVペアで管理し、
複数のKVペアに対する間接的なアトミックな操作を実現する
KV1 KV2
直接複数をアトミックに操作することはできない
KV1に対する操作
KV2に対する操作
操作（トランザクションログ）をまとめたKVペア

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

トランザクションの処理
▌トランザクションをコミットする際はトランザクションサーバにトランザクション
ログのKVペアをコミットして、排他制御する
▌コミット後にストレージサーバの実データをログに基づき非同期で更新する
ｱﾌﾟﾘｹｰｼｮﾝ
Partiqleサーバ
トランザクションサーバ
ストレージサー
バ
ログデータ
• マイクロシャードキーでルーティング（配置場所を決定）、ひとつの物理トランザクションは、
ひとつのマイクロシャードキーに対応する。
• マイクロシャードキーに割り当てる実データは、データ構造などに応じた設定が可能。割り
当て幅が小さいと、共有・排他制御が高速になる。
マイクロシャード2 更新履歴
マイクロシャード1 更新履歴
Key1 Value1 Key2 Value2 Key3 Value3
実データ
• トランザクションとは独立にデータ配置場所を選択できる。
• KVSではデータのキーでルーティング
Key1 Value1 Key2 Value2 Key3 Value3

トランザクション開始
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) 操作で原子性
を確保

トランザクション１開始
Partiqleサーバトランザクションサーバ
100
更新ログkey value
AAA{record1-1}, {record2-1}
トランザクション１更新バージョン番号
100
更新ログkey value
UPDATE
トランザクション2開始
100
更新ログ
key value
100
key value
トランザクション１領域
トランザクション2領域
トランザクション１コミット
101
更新ログ
key value
100
key value
トランザクション１領域
トランザクション2領域
CASをして格納
更新ログ
100
key value
トランザクション2領域トランザクション2参照
SELECT
独立性確保の仕組み
▌トランザクションごとに処理領域をもち、独立性を確保

ストレージサーバ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重化

楽観的排他制御
▌データ処理の競合・衝突がほとんど起こらないことを前提とする同時実行
制御方式
▌データの読み込み時にロックを行わず、更新時に競合・衝突を確認してト
ランザクションの成功・失敗を判断する
▌重いロック管理処理を省き、性能を向上
口座番号=1を読み込むTx1
口座番号=1を読み込む Tx2
口座番号=1を変更 Tx2
コミット Tx2
口座番号=1を変更Tx1
← ここで待ち合わせない
エラー
後行トランザクションのコミット時に衝突を検知してコミットを失敗させる

リレーショナルからKVへのマッピング
▌KVSでデータをアクセスするためにはキーが特定できている必要がある
ワークロードに応じて、アクセスに使う列がKVのキーにあるようにリレーショナル
からKVへのマッピングをする必要がある
また、トランザクション処理の仕組み上、トランザクションキーでアクセスできなけ
ればならない
▌リレーショナルモデルをKV形式にマッピングするいくつかの方法を提供
以下からワークロードに応じて適切に選択
• フラット
• インデックス
• クラスタ
• レンジクラスタ

物理デザイン (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が単一のドキュメントの中に
スキーマとデータを格納するのとは異なる）

物理デザイン (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]のインデックス

物理デザイン (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
別途主キーに対する
インデックスも作られる

物理デザイン (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テーブル
レンジクラスタ生成

高信頼インメモリ処理技術
▌同期レプリケーションによりインメモリ処理でも信頼性を確保
▌トランザクションサーバにおける高信頼な高速処理を実現
トランザクションサーバ群
サーバ②
サーバ③
マスター
バックアップバックアップ
書き込み
複製複製
サーバ①
サーバ②
サーバ③
マスターサーバで
障害発生
サーバ①
サーバ②
サーバ③
① 通常運転時 ② 障害発生時 ③ 障害復旧後
サーバ①
バックアップバックアップバックアップ
マスター
マスター
技術2
ノードにはそれぞれ2台のスレーブがあり
同期レプリケーション
ハッシュにより複数のノードにデータと処理を分散

画像管理サービス
▌インターネットサービスのバックエンドの画像管理
画僧
ファイル
InfoFrame
Relational Store
画像
ファイル
ウェブアプリケーション
画像ファイル
のメタデータ
処理はユーザごとに閉じているため
ユーザごとにマイクロシャードを構成
ユーザが写真をアッ
プロード（投稿）、公開
従来のRDBと同じ使い心地で
時に爆発的なアクセス増加に対応できるスケーラビリティを実現

輸送機の稼働履歴分析ソリューション
お客さまの目標
輸送機の稼働状況を分析・予測し、輸送機
の運用・管理コストを最適化して収益改善
データ蓄積量
InfoFrame Relational Storeの創出価値
 データ蓄積量にジャストフィットした
データベースを提供し過剰投資を抑制
 輸送機毎の稼働履歴（時系列データ）
をいつでも安定的に高速検索
 お客さま分析基盤に大量データを一括
アップロード（Hadoop連携）でき、分析・予測
の実行サイクルを短縮
位置データセンサデータ環境データ
既存データベース
スモールスタート
業務無停止
スケールアウト
SLA保証
業務アプリ分析基盤
SQL
履歴
Hadoop Map/Reduce
生データ
データマート
最終 100 TB以上
現在 10 TB

大規模センサデータ（IoT／M2M）の集計ソリューション
▌スマートメーターなどデバイスデータをInfoFrame Relational Storeに収集
データストアを適材適所で使い分け
Webアプリ
InfoFrame
Relational
Store
Hadoop
過去蓄積
データ
デバイスマスター情報
リアルタイム
センサーデータ
RDB
顧客マスター情報
センサーデータ
顧客情報など
マスターデータ
分析基盤
データ量小
データ量大
高速書き込み
データ量大
広範囲の読み込み

性能
▌TPC-Bを簡略化した軽いトランザクションを発行
7台構成から始めてボトルネックになったところをスケールアウト
0
5,000
10,000
15,000
20,000
構成１構成２構成３
トランザク
ションサーバ
をスケール
アウト
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

まとめ
▌NECはInfoFrame Relational Storeで高いトランザクション処理性
能を持つ、スケーラブルなRDBMSを実現しています
すぐに試せるAMI（Amazon Machine Image）をご用意しています
• 下記窓口よりお問い合わせください
http://jpn.nec.com/infoframe/relationalstore/license_agreement.html
スケーラビリティ
SQL
ACID
SQLと
トランザクション処理
リレーショナルモデル
× ×
アンケートにご協力をお願いします

[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社並木悠太

[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太

More Related Content

What's hot

Viewers also liked

Similar to [db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太

More from Insight Technology, Inc.