[db tech showcase Tokyo 2015] C17:MySQL Cluster ユーザー事例紹介～ＪＲ東日本情報システム様における導入事例～ by 日本ヒューレット・パッカード株式会社高橋智雄

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
MySQLClusterユーザー事例紹介
〜ＪＲ東⽇本情報システム様
における導⼊事例〜
⽇本ヒューレット・パッカード株式会社
テクノロジーコンサルティング事業統括
⾼橋智雄
2015年6⽉10⽇

© Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
⾃⼰紹介
 ⽒名：⾼橋智雄
 所属：⽇本ヒューレット・パッカード株式会社
 仕事：データベース関連のコンサルタント
Oracle Databaseのトラブル対応やチューニングなど
最近はオープンソースのDBMSも
ここ数年PostgreSQL Enterprise Consortium（PGECons）で活動
 最近：PostgreSQL／Postgres Plus検証
MySQL Cluster検証、技術⽀援
MS SQL Server PDWソリューション開発
Vertica導⼊
Oracle RAC導⼊
Oracle Database性能検証
PostgreSQL コンサルティング
Oracle DatabaseからPostgres Plusへの移⾏PoC
MySQL Cluster Casual Talks#2
でも別の検証結果を発表
http://goo.gl/5qwMzi
で資料公開しています。

はじめに
ＪＲ東⽇本情報システム様が構築・運⽤している「障害情報
システム」には、 MySQL Cluster とHP Moonshot Systemが採⽤
されています。
本セッションではMySQL Cluster とHP Moonshot Systemが採⽤さ
れた背景や、システムの実現性を追求した数多くの検証内容
などをご紹介します。
システム全体像の事例紹介サイト
http://h50146.www5.hp.com/products/servers/proliant/casestudy/jeis/

アジェンダ
1. MySQL Cluster導⼊の背景
2. MySQL Cluster概要
3. MySQL Cluster On HP Moonshot System検証結果
4. まとめ

1.MySQL Cluster導⼊の背景

ＪＲ東⽇本情報システム様ご紹介
 東⽇本旅客鉄道（ＪＲ東⽇本）の情報システム部⾨が独⽴して1989年
に誕⽣
 当時の社名はジェイアール東⽇本情報システム。2015年4⽉にＪＲ東
⽇本情報システムに社名を変更、略称はJEIS
 ＪＲ東⽇本グループ約70社を中⼼に広くシステム提案・開発・運⽤を
⼿がけ、その数は主要なシステムだけで200を超える
 本⽇の事例は、システム障害の発⽣から解決までのプロセスを記録
し、ナレッジとして全社での活⽤や分析を可能にする「障害情報シス
テム」

障害情報システムの概要
ミッションクリティカルなシステムを⾒据えたシステム構築
 システムの⽬的と位置づけ
 あるシステムで発⽣した問題に対して、その原因と解決⽅法を「障害
情報システム」で全社共有し、同種の問題を未然に防ぐ
 ナレッジベースであり社内向けシステムという位置付けではあるが、
業務上重要なシステム
 障害情報システムの構築をとおして、将来的にミッションクリティカ
ルなシステムの構築に役⽴つ新しい技術、ノウハウを習得

障害情報システムの特徴
オープンソースソフトウェアの採⽤
 システム構築における⽅針とチャレンジ
 オープンソースソフトウェア（OSS）を全⾯的に採⽤
 新しい超⾼密度サーバー「HP Moonshot System」の採⽤
1シャーシ／45サーバーノード内に障害情報システムの全機能を集約
し、「1シャーシ＝1システム」を実現

HP Moonshot Systemご紹介
障害情報システムの全機能をHP Moonshot System 1シャーシに集約
 第2世代カートリッジ m300
 CPU：Atom C2750（8コア）
 メモリ：32GB
 ネットワーク：1G bps× 2
 ディスク：1TB HDDもしくは
240GB SSD

データベースに対する課題
データ保持⽅式と可⽤性の実現⽅式が課題
 データ保持⽅式
想定データ量が1台のサーバーカートリッジが搭載できるディスク（最
⼤1TB）を超える可能性があったため、外部の共有ストレージを使わず
Moonshot Systemのシャーシ内にデータを保持する⽅式の検討が課題
 可⽤性
サーバー障害によるサービス停⽌時間を最⼩限にする冗⻑化⽅式の検
討が課題
⾼可⽤性を備えた分散DBMS MySQL Clusterを採⽤

導⼊までの体制と流れ
 体制
 JEIS様：障害情報システムの開発主幹
 エスケイケイ様：JEIS様の開発⼦会社で、実際の開発を担当
 ⽇本HP：MySQL Clusterの検証と開発時の技術⽀援を担当
 導⼊までの流れ
 2014年1⽉〜3⽉：第1回⽬検証
第⼀世代のMoonshotを使⽤して、性能検証や耐障害性を検証
 2014年4⽉〜5⽉：第2回⽬検証
実システムで使⽤する第ニ世代Moonshotでの性能検証
 2014年6⽉〜2015年1⽉：システム開発
本日の後半でご紹介
大きな問題なし

MySQL Clusterとは
シェアードナッシングアーキテクチャのインメモリ分散データベースシステム
 リアルタイム・パフォーマンス
 インメモリで動作するため⾮常に⾼速
 ⾼可⽤性
 SPOFのないシェアードナッシング・アーキテクチャ
 各データ・ノードのデータは、同期的に他のデータ・ノードにレプリケート
 障害時は通常1秒以内にクラスタ内の他のノードに⾃動フェイルオーバー
 スケーラビリティ
 データをノード間で⾃動的にシャーディングするためスケーラブル
 オンラインでのノード追加が可能
 Active／Activeアーキテクチャにより、どのノードでも更新処理が可能

MySQL Cluster略歴
 もともとはNetwork DataBase（NDB）と呼ばれていた携帯通信網⽤
データベースで、以下のような特徴があった
 インメモリで⾼速
 ⽐較的シンプルな処理向き（SQLは使⽤できなかった）
 加⼊者増加にあわせた拡張性
 ⾼可⽤性
 MySQLと統合されSQLによるアクセスも可能となった
 バージョンが進むにつれ、複雑なSQLの⾼速化や、⼀般的なRDBMSが備
えている機能を実装（現在の最新版は7.4）
 v7.0でデータノードのマルチスレッド化
 v7.2、7.3でjoinの性能が⼤幅に改善
 v7.3で外部キーをサポート

MySQL Clusterの構成
3種類のノードにより構成
SQLノード・・・
アプリケーション
データノード
管理ノード
MySQL
Cluster
・・・
SQLノード
データノードデータノードデータノード
レプリケーションレプリケーション

各ノードの役割
 管理ノード
 MySQL Cluster内のノードを管理
 複数台により冗⻑化も可能
 データノード
 実データを保持するノード
 複数台で同期データ・レプリケーション
 複数台により冗⻑性を⾼め、かつスケールアウトにより性能向上
 SQLノード
 通常のMySQL Server（mysqld）に相当
 アプリからのSQL⽂を解析し、データノードにアクセスしてデータを返す
 複数台によりスケールアウト可能（冗⻑性はロードバランサやアプリで実装）

障害情報システムで採⽤したデータベース構成
サーバーの2重障害に備えた冗⻑構成を採⽤
管理ノード×3 データノードSQLノード ×6
MySQL
Cluster
×2
 3台でレプリケーションを⾏うグループ
（ノードグループ）を2グループ構成
 同⼀ノードグループの2台のデータノード
がダウンしてもサービス継続が可能
管理ノードがダウンしても
サービス継続可能なため、
2台構成とした
 CentOS 6.5
 MySQL Cluster
7.3.5

MySQL Clusterのパラメータ（1/4）
 MaxNoOfExecutionThreadsパラメータでデータノードで動作するプロセス
（ ndbmtd）のスレッド数を指定することが可能
例
 さらにThreadConfigパラメータを使⽤すると、役割の異なるスレッドに
割り当てるCPUを細かく設定できる
例
CPU関連パラメータ
MaxNoOfExecutionThreads = 8
ThreadConfig=main={cpubind=0},ldm={count=4,cpubind=1,2,5,6},io={cpub
ind=3}

 レプリカ数
 NoOfReplicas：デフォルト2（1 〜 4）
 チェックポイント関連
 DiskCheckpointSpeed
 TimeBetweenLocalCheckpoints
 TimeBetweenGlobalCheckpoints
 TimeBetweenEpochsTimeout
レプリカ数、チェックポイント関連パラメータ
後述

 MaxNoOfTables：デフォルト128（8 〜 20320）
 MaxNoOfOrderedIndexes：デフォルト128（0 〜 4294967039 ）
 MaxNoOfUniqueHashIndexes：デフォルト64（0 〜 4294967039 ）
オブジェクト数関連パラメータ

 MaxNoOfConcurrentScansパラメータの最⼤値が500に注意
 MaxNoOfConcurrentScansパラメータはデータノード毎の同時実⾏可能
なテーブルスキャンまたはインデックススキャンの数
 この値を超える「ALERT: MySQL error: Got temporary error 488 'Too many
active scans' from NDBCLUSTER」というエラーが発⽣。
 最⼤の500に設定してもエラーが出る場合は、データノードの増設が必
要
 その他に、MaxNoOfConcurrentTransactions、
MaxNoOfConcurrentOperationsなど。
同時実⾏数関連パラメータ

ディスクテーブル
ディスクにデータを格納する機能とその注意点
 ディスクにデータを格納する機能
 注意点
 メモリテーブルと⽐較すると遅い
 メモリ上にメモリテーブルとは別のバッファ領域が必要である。その
ためディスクテーブルの性能を向上させるために、バッファ領域を⼤
きくすると、メモリテーブル⽤の領域が少なくなってしまう。
 BLOB型、TEXT型のようなサイズの⼤きなデータを格納するために使⽤す
るケースが多い

MySQL Clusterの主なメモリ領域
No メモリ領域主な⽤途
1 DataMemory メモリテーブルのデータを格納。Ordered （B-Tree ）
インデックスのデータもこの領域に格納される。
ディスクテーブルのインデックスとインデックスを作
成した列も格納される
2 IndexMemory ハッシュインデックスのデータを格納
3 RedoBuffer Redoログに出⼒するデータのバッファ領域。COMMITさ
れるまでの変更は全てこの領域に保持する必要がある
4 SharedGlobalMemory 外部キーのチェックなどの各種操作で使⽤するメモリ
領域。ディスクテーブルを使⽤する場合、この領域に
UNDOバッファが作成される
5 DiskPageBufferMemory ディスクテーブルデータ⽤のキャッシュ領域

データの永続化（1/2）
LCPとGCPによるデータ永続化
 LCP（Local Check Point）
 LCPはある時点における全データをディスクに書き出す処理
 TimeBetweenLocalCheckpointsパラメータで指定した間隔ごとに⾏われ
る（デフォルトは20（4MB））
 DiskCheckpointSpeedパラメータでディスクへの書き込み速度を制御
（デフォルトは10MB/s）
 ディスクテーブルのデータは更新されたデータが全てディスクに
フラッシュされる（いわゆるチェックポイント）

データの永続化（2/2）
LCPとGCPによるデータ永続化
 GCP（Global Check Point）
 更新された内容をRedoログへ出⼒する処理
 TimeBetweenGlobalCheckpointsパラメータで指定した間隔ごとに⾏われ
る（デフォルトは2秒）
 GCPよりも⾼い頻度で、データノード間の同期処理を⾏うmicro-GCPが
実⾏される。
 micro-GCPがTimeBetweenEpochsTimeoutパラメータで設定された時間以
内に完了しないとデータノードがクラスタから切り離される。v7.1ま
でのデフォルト値は4秒。7.2以降は0（タイムアウトを検知しない）
となっている。

商⽤版とコミュニティ版の差異
サポート構成の制限と商⽤ツール
 商⽤版でサポートされるレプリカ数は1または2のみ
 商⽤版のみに付属するツール
 MySQL Enterprise Monitor
• SQL ノード、データノードの状態、システムリソースなどを監視
• 問題のあるクエリの特定に役⽴つQuery Analyzer機能
 MySQL Cluster Manager
• MySQL Cluster の管理を⼀元化するCLIの商⽤ツール
• インストール、設定変更、ノード追加、ローリングリスタートの⾃動
化

3.MySQL Cluster On HP MoonshotSystem
検証結果

検証概要
1. MySQL Cluster構成による性能⽐較
2. メモリテーブル、ディスクテーブル（SSD）、ディスクテーブル
（HDD）の性能⽐較
3. 単⼀SQLの処理時間性能測定
① プライマリーキーによる1レコード取得
② インデックスによる複数レコード取得
③ インデックスによる複数レコード取得 + ソート
④ ⾮インデックス列への中間⼀致
4. ノード追加によるスケーラビリティ確認
第2世代Moonshot、m300カートリッジを使⽤して性能検証を実施

検証環境構成イメージ
L3 Switch A L3 Switch B
Moonshot Cartridge m300× 19
Management LANL2 Switch
1Gbps
10Gbps
Moonshot
シャーシ
管理データ
Cluster1
3レプリカ
（HDD）
Cluster2
2レプリカ（HDD）
Cluster3
2レプリカ（SSD）
m300 カートリッジ
管理
管理管理
管理管理
SQL SQL SQL データデータデータデータデータ
SQL SQL SQL データデータデータデータ
SQL SQL SQL データデータデータデータ
クライアント

検証環境MySQL Cluster主要パラメータ設定
パラメータ設定値備考
DataMemory 20G
IndexMemory 4G
DiskPageBufferMemory 64M デフォルト
RedoBuffer 64M
MaxNoOfExecutionThreads 8
 データノード⽤パラメータ（config.ini）
 SQLノード⽤パラメータ
（my.cnf）パラメータ設定値備考
ndb-cluster-connection-pool 8
max_connections 1000

検証1 MySQL Cluster構成による性能⽐較
 下記パターンの性能測定を実施し、レプリカ数の差が性能に与える影響
と、メモリテーブルのみの環境で、ストレージ種別が性能に与える影響
を確認
 sysbench OLTP complexモードを使⽤してスループット（TPS）を測定
 レコード数は100万
 それぞれの構成についてRead OnlyとRead Writeの2ケースを測定
構成No SQLノード数データノード数レプリカ数ストレージ
P1 3 6 3 HDD
P2 3 4 2 HDD
P3 3 4 2 SSD

（補⾜） sysbenchで実⾏されるトランザクション
SELECT c FROM sbtest WHERE id = :1; × 10回
SELECT c FROM sbtest WHERE id BETWEEN :1 AND :2;
SELECT SUM(k) FROM sbtest WHERE id BETWEEN :1 AND :2;
SELECT c FROM sbtest WHERE id BETWEEN :1 AND :2 ORDER BY c;
SELECT DISTINCT c FROM sbtest WHERE id BETWEEN :1 AND :2
ORDER BY c;
UPDATE sbtest SET k = k + 1 WHERE id = :1;
UPDATE sbtest SET c = :1 WHERE id = :2;
DELETE FROM sbtest WHERE id = :1;
INSERT INTO sbtest (id, k, c, pad) VALUES (:1, :2, :3, :4);
COMMIT;
更新SQL
Read Onlyでは実行されない
 テーブル構造
No 列名データ型備考
1 id integer PK
2 k integer
3 c char(120)
4 pad char(60)
 トランザクション
PKによる単純な検索
範囲検索およびソート
sysbenchは検証1,2,4で使⽤

TPS
メモリテーブル-ReadOnly
3レプリカ(HDD) 2レプリカ(HDD)
2レプリカ(SSD)
検証1 結果〜Read Only〜
MySQL Clusterの構成による性能⽐較
 レプリカ数を3にすると約10%
の性能ダウン
 Read Onlyではストレージ種別
は性能にほぼ影響しない
P1 P2 P3

TPS
メモリテーブル-Read Write
3レプリカ(HDD) 2レプリカ(HDD)
2レプリカ(SSD)
検証1 結果〜Read Write〜
 レプリカ数を3にすると約10%
の性能ダウン
 Read Writeではストレージを
SSDにした場合メモリテーブ
ルでも5%程度性能向上
P1 P2 P3

検証1 CPU使⽤状況〜3レプリカ-HDD構成〜
0.0
20.0
40.0
60.0
80.0
100.0
1-0 1-1 1-2 1-3 1-4 1-5 1-6 1-7 2-0 2-1 2-2 2-3 2-4 2-5 2-6 2-7 3-0 3-1 3-2 3-3 3-4 3-5 3-6 3-7
CPU使用率
CPU 番号
SQLノード（3レプリカ-HDD）
%iowait
%soft
%sys
%user
0.0
20.0
40.0
60.0
80.0
100.0
1-0
1-1
1-2
1-3
1-4
1-5
1-6
1-7
2-0
2-1
2-2
2-3
2-4
2-5
2-6
2-7
3-0
3-1
3-2
3-3
3-4
3-5
3-6
3-7
4-0
4-1
4-2
4-3
4-4
4-5
4-6
4-7
5-0
5-1
5-2
5-3
5-4
5-5
5-6
5-7
6-0
6-1
6-2
6-3
6-4
6-5
6-6
6-7
CPU使用率
CPU 番号
データノード（3レプリカ-HDD）
%iowait
%soft
%sys
%user
SQLノードの全CPUで、使⽤率が90%以上の⾼負荷状態

検証1 ネットワーク使⽤状況〜3レプリカ-HDD構成〜
SQLノードのネットワークは⾼負荷ではあるが、
iperfによる測定結果の約117MB/secと⽐較すると若⼲の余裕
0
20
40
60
80
100
120
SQL01
SQL02
SQL03
DATA01
DATA02
DATA03
DATA04
DATA05
DATA06
ネットワーク帯域（MB／Sec）
3レプリカ-HDD
tx
rx

検証1 CPU使⽤状況〜2レプリカ-HDD構成〜
SQLノードの全CPUで、使⽤率が90%以上の⾼負荷状態SQLノードのCPU使⽤率は⾼いが、3レプリカ構成と⽐較すると下がっている
0.0
20.0
40.0
60.0
80.0
100.0
1-0 1-1 1-2 1-3 1-4 1-5 1-6 1-7 2-0 2-1 2-2 2-3 2-4 2-5 2-6 2-7 3-0 3-1 3-2 3-3 3-4 3-5 3-6 3-7
CPU使用率
CPU 番号
SQLノード（2レプリカ-HDD）
%iowait
%soft
%sys
%user
0.0
20.0
40.0
60.0
80.0
100.0
1-0
1-1
1-2
1-3
1-4
1-5
1-6
1-7
2-0
2-1
2-2
2-3
2-4
2-5
2-6
2-7
3-0
3-1
3-2
3-3
3-4
3-5
3-6
3-7
4-0
4-1
4-2
4-3
4-4
4-5
4-6
4-7
CPU使用率
CPU 番号
データノード（2レプリカ-HDD）
%iowait
%soft
%sys
%user

0
20
40
60
80
100
120
SQL01
SQL02
SQL03
DATA01
DATA02
DATA03
DATA04
ネットワーク帯域（MB／Sec）
2レプリカ-HDD
tx
rx
検証1 ネットワーク使⽤状況〜2レプリカ-HDD構成〜
SQLノードではiperfによる測定結果の約117MB/secとほぼ等しい帯域を使⽤

検証1 考察
 SQLノードもCPUリソースが重要
 パフォーマンスを求めるのであれば、ネットワーク帯域は10Gbps
最新のMoonshotでは10Gbps対応のスイッチとサーバーカートリッジも
 m400（AppliedMicro X-Gene / ARM 64bit v8 8 cores 2.4GHz / 64GB)
 m710（Xeon E3 1284Lv3 4 cores 1.8-3.2GHz/ 32GB)
 レプリカ数を多くするのは慎重に検討

検証2 テーブル配置種別による性能⽐較
 下記パターンの性能測定を実施し、メモリテーブル、ディスクテーブル
（SSD）、ディスクテーブル（HDD）の性能を⽐較
 それぞれの構成についてRead OnlyとRead Writeの2ケースを測定
構成No SQLノード数データノード数レプリカ数テーブルストレージ
P1 3 6 3 メモリ HDD
P2 3 4 2 メモリ HDD
P3 3 4 2 ディスク SSD
P4 3 4 2 ディスク HDD

検証2 結果〜Read Only〜
テーブル配置種別による性能⽐較
 Read OnlyではSSDを使⽤し
たディスクテーブルはメモ
リテーブルとほぼ同等の性
能（環境によって異なるの
で注意）
 HDDのディスクテーブルの
性能は極端に低い
TPS
Read Only
3レプリカ-メモリ 2レプリカ-メモリ
2レプリカ-ディスク(SSD) 2レプリカ-ディスク(HDD)
P4
P1 P2 P3

検証2 結果〜Read Write〜
テーブル配置種別による性能⽐較
 Read WriteではSSDを使⽤した
ディスクテーブルの性能も劣
化
 SSDの性能特性にも影響され
ると考えられる。（使⽤した
SSDのWrite性能はそれほど⾼
性能ではなかった）
 ランダムRead：64k IOPS
 ランダムWrite：8k IOPS
TPS
Read Write
3レプリカ-メモリ 2レプリカ-メモリ
2レプリカ-ディスク(SSD) 2レプリカ-ディスク(HDD)
P1 P2
P3
P4

検証3 単⼀SQL処理時間性能⽐較
 以下の条件のクエリの実⾏時間をMySQL ClusterとMySQL（InnoDB）で⽐較
① プライマリーキーによる1レコード取得
② インデックスによる複数レコード取得
③ インデックスによる複数レコード取得 + ソート
④ ⾮インデックス列への中間⼀致
 クエリ⽤テーブルは以下のような単純なテーブル
 レコード数は100万⾏と1億⾏の2パターンで測定（MySQLのInnoDBバッファプー
ルに全データがのるケースとのらないケースを想定）
列名列定義備考
1 col1 char(8) primary key
2 col2 char(8) index
3 col3 char(200)
4 col4 char(200)

検証3 結果〜100万⾏テーブル検索〜
単⼀SQL処理時間性能⽐較
No クエリタイプ
取得
⾏数
処理時間（ミリ秒）
性能⽐MySQL
Cluster
MySQL
1 プライマリーキーによる1レコード取得 1 0.65 0.25 0.39
2
プライマリキー以外のインデックス
による複数レコード取得
10,000 149.76 71.30 0.48
3
による複数レコード取得＋ソート
10,000 3,369.47 75.61 0.02
4 ⾮キー項⽬の中間⼀致検索 15,741 396.36 3,087.59 7.79

検証3 結果〜1億⾏テーブル検索〜
単⼀SQL処理時間性能⽐較
No クエリタイプ
取得
⾏数
処理時間（ミリ秒）
性能⽐MySQL
Cluster
MySQL
1
プライマリーキーによる1レコード
取得
1 0.67 21.04 31.45
2
による複数レコード取得
1,000,000 14,764.93 467,372.91 31.65
3
による複数レコード取得＋ソート
1,000,000 279,945.79 467,381.68 1.67
4 ⾮キー項⽬の中間⼀致検索 1,574,101 27,955.42 480,301.26 17.18

検証4 ノード追加によるスケーラビリティ確認
 データノードやSQLノードを追加してスループットが向上するかどうか
を確認
 レプリカ数は2に固定し、データノード数を2台〜10台、SQLノード数を2
台〜14台に変化させて性能測定
 それぞれの構成についてRead Onlyの性能を測定

検証4 結果
ノード追加によるスケーラビリティ確認  ノードを追加すること
により、スループット
は向上
 データノードとSQL
ノードを適切な割合で
増加させることが重要
 データノード数が多い
場合、MySQL Clusterが
苦⼿とする範囲検索の
影響のためスループッ
トがのびない（？）
0 2 4 6 8 10 12 14
TPS
SQLノード数
2データノード 4データノード 6データノード
8データノード 10データノード

まとめ
 ＪＲ東⽇本情報システム様がMySQL Clusterを導⼊した背景
 新しい技術へのチャレンジ：OSSの採⽤
 データの分散配置、⾼可⽤性を備えたDBMS：MySQL Cluster
 MySQL Clusterの特徴
 インメモリ、⾼速、⾼可⽤性、スケーラビリティ
 管理ノード、SQLノード、データノードから構成
 さまざまなパラメータ
 MySQL Cluster 検証結果
 CPU性能、ネットワーク帯域、その後にディスク性能
 SQLノードとデータノードを適切に配置することでスケール

日本HP:次のセッションは、
10日15:30- B15:PostgreSQL
「最新PostgreSQLはCPUパフォーマンスが飛躍的に向上する！？
～PostgreSQLのCPUスケーラビリティについて～」
10日16:30- D16:Vertica
「マイケルストーンブレーカー発の超高速データベースで実現する分析基盤の
簡単構築・運用ステップ」
10日17:30- C17:MySQLCluster事例
「MySQLClusterユーザー事例紹介
～ＪＲ東日本情報システム様における導入事例～」
11日14:30- B24:NonStopSQL
「最高峰の可用性～NonStopSQLが止まらない理由～」
11日15:30- c25:NonStopSQL
「HPNonStopSQLはなぜグローバルに分散DBを構築できるのか、データの
整合性を保てるのか」

日本HP:ベンダーディセッションでは、
12日12:30- D32:In-Memory/SAPHANA
「HPPresents:インメモリDBを見据えた、スケールアップへの回帰その1:
HPの全方位インメモリDB化に向けた取り組みとSAPHANAインメモリDBの効果
を、SAP
社とともに読み解く」
12日13:30- D33:SQLServer
SuperdomeX上のSQLServer2014OLTP検証結果とSQLServervNext最新情報」
12日14:30- D34:In-Memory
In-DatabaseAnalyticsが実現する圧倒的なデータ分析パフォーマンス」

アンケートにご協力ください

Thank you!
⾼橋智雄
テクノロジーコンサルティング事業統括
サービス統括本部オープンソース部
シニアスペシャリスト
Tomoo.Takahashi@hp.com
⽇本ヒューレット・パッカード株式会社
本社
〒136-8711
東京都江東区⼤島2-2-1

[db tech showcase Tokyo 2015] C17:MySQL Cluster ユーザー事例紹介～ＪＲ東日本情報システム様における導入事例～ by 日本ヒューレット・パッカード株式会社高橋智雄

More Related Content