[db tech showcase tokyo 2015]...

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の技術

アーキテクチャ

マイクロシャーディング

▌ユースケース

▌性能

▌まとめ

15分

25分

5分

5分


データベース = トランザクション処理向け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


RDBの機能をスケーラブルに

従来RDBの特性


Partiqleサーバ


InfoFrame Relational Storeのアーキテクチャ

「小さいサイズのデータに対する更新・参照リクエスト」が大量同時発生する環境で真価を発揮するデータベース

表形式データに対する処理リクエスト（SQL）を解析

トランザクションサーバ

更新・参照トランザクションをインメモリ処理

ストレージサーバ

データをキーバリュー形式で内蔵ディスクに永続化

NEC特許技術マイクロシャーディング



参照・更新の混在する環境において、 100万TPSを超えるデータ処理数が可能

ペタバイト（PB）クラスのデータ量の蓄積も可能

スモールスタートからペタバイトクラスまでのスケールに対応


CAP定理

▌CAP定理

分散システムは以下の3つを同時に保証することはできない

• 一貫性（Consistency）

• 可用性（Availability）

• 分断耐性（Partition-tolerance）

▌IRSでは特性の異なる2つの

システムを融合し全体の

バランスをとる

Partition-tolerance Availability

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 bidsid name nb_of_bids max_bids id user_ id item_id bidi1 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 30b3 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 bidsid name nb_of_bids max_bids id user_ id item_id bidi1 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 30b3 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

← ここで待ち合わせない

エラー

後行トランザクションのコミット時に衝突を検知してコミットを失敗させる


KVSの特性

・単一KVペア内でのみ

アトミックな操作が可能

・キーを特定しないと

データにアクセスできない

・スケーラビリティに優れる

・高いスループット

RDBとして考えると制約： IRSに組み込むためには

工夫が必要

IRSに無条件にマッチ


リレーショナルから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アプリ


Hadoop

過去蓄積データ

デバイスマスター情報

リアルタイムセンサーデータ

RDB

顧客マスター情報センサーデータ

顧客情報など

マスターデータ分析基盤

データ量小

データ量大

高速書き込み

データ量大

広範囲の読み込み


性能

▌TPC-Bを簡略化した軽いトランザクションを発行

7台構成から始めてボトルネックになったところをスケールアウト

0

5,000

10,000

15,000

20,000

構成１構成２構成３

トランザクションサーバをスケールアウト

Partiqleサーバをスケールアウト

スループット（tp

s）

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]...

Technology