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

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

2. © 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 で資料公開しています。

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

4. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.4 アジェンダ 1. MySQL Cluster導⼊の背景 2. MySQL Cluster概要 3. MySQL Cluster On HP Moonshot System検証結果 4. まとめ

5. 1.MySQL Cluster導⼊の背景

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

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

8. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.8 障害情報システムの特徴オープンソースソフトウェアの採⽤  システム構築における⽅針とチャレンジ  オープンソースソフトウェア（OSS）を全⾯的に採⽤  新しい超⾼密度サーバー「HP Moonshot System」の採⽤ 1シャーシ／45サーバーノード内に障害情報システムの全機能を集約し、「1シャーシ＝1システム」を実現

9. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.9 HP Moonshot Systemご紹介障害情報システムの全機能をHP Moonshot System 1シャーシに集約  第2世代カートリッジ m300  CPU：Atom C2750（8コア）  メモリ：32GB  ネットワーク：1G bps× 2  ディスク：1TB HDDもしくは 240GB SSD

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

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

12. 2.MySQL Cluster概要

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

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

15. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.15 MySQL Clusterの構成 3種類のノードにより構成 SQLノード・・・アプリケーションデータノード管理ノード MySQL Cluster ・・・ SQLノードデータノードデータノードデータノードレプリケーションレプリケーション

16. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.16 各ノードの役割  管理ノード  MySQL Cluster内のノードを管理  複数台により冗⻑化も可能  データノード  実データを保持するノード  複数台で同期データ・レプリケーション  複数台により冗⻑性を⾼め、かつスケールアウトにより性能向上  SQLノード  通常のMySQL Server（mysqld）に相当  アプリからのSQL⽂を解析し、データノードにアクセスしてデータを返す  複数台によりスケールアウト可能（冗⻑性はロードバランサやアプリで実装）

17. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.17 障害情報システムで採⽤したデータベース構成サーバーの2重障害に備えた冗⻑構成を採⽤管理ノード×3 データノードSQLノード ×6 MySQL Cluster ×2  3台でレプリケーションを⾏うグループ（ノードグループ）を2グループ構成  同⼀ノードグループの2台のデータノードがダウンしてもサービス継続が可能管理ノードがダウンしてもサービス継続可能なため、 2台構成とした  CentOS 6.5  MySQL Cluster 7.3.5

18. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.18 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}

19. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.19 MySQL Clusterのパラメータ（2/4）  レプリカ数  NoOfReplicas：デフォルト2（1 〜 4）  チェックポイント関連  DiskCheckpointSpeed  TimeBetweenLocalCheckpoints  TimeBetweenGlobalCheckpoints  TimeBetweenEpochsTimeout レプリカ数、チェックポイント関連パラメータ後述

20. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.20 MySQL Clusterのパラメータ（3/4）  MaxNoOfTables：デフォルト128（8 〜 20320）  MaxNoOfOrderedIndexes：デフォルト128（0 〜 4294967039 ）  MaxNoOfUniqueHashIndexes：デフォルト64（0 〜 4294967039 ）オブジェクト数関連パラメータ

21. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.21 MySQL Clusterのパラメータ（4/4）  MaxNoOfConcurrentScansパラメータの最⼤値が500に注意  MaxNoOfConcurrentScansパラメータはデータノード毎の同時実⾏可能なテーブルスキャンまたはインデックススキャンの数  この値を超える「ALERT: MySQL error: Got temporary error 488 'Too many active scans' from NDBCLUSTER」というエラーが発⽣。  最⼤の500に設定してもエラーが出る場合は、データノードの増設が必要  その他に、MaxNoOfConcurrentTransactions、 MaxNoOfConcurrentOperationsなど。同時実⾏数関連パラメータ

22. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.22 ディスクテーブルディスクにデータを格納する機能とその注意点  ディスクにデータを格納する機能  注意点  メモリテーブルと⽐較すると遅い  メモリ上にメモリテーブルとは別のバッファ領域が必要である。そのためディスクテーブルの性能を向上させるために、バッファ領域を⼤きくすると、メモリテーブル⽤の領域が少なくなってしまう。  BLOB型、TEXT型のようなサイズの⼤きなデータを格納するために使⽤するケースが多い

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

24. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.24 データの永続化（1/2） LCPとGCPによるデータ永続化  LCP（Local Check Point）  LCPはある時点における全データをディスクに書き出す処理  TimeBetweenLocalCheckpointsパラメータで指定した間隔ごとに⾏われる（デフォルトは20（4MB））  DiskCheckpointSpeedパラメータでディスクへの書き込み速度を制御（デフォルトは10MB/s）  ディスクテーブルのデータは更新されたデータが全てディスクにフラッシュされる（いわゆるチェックポイント）

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

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

27. 3.MySQL Cluster On HP MoonshotSystem 検証結果

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

29. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.29 検証環境構成イメージ 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 データデータデータデータクライアント

30. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.30 検証環境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

31. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.31 検証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

32. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.32 （補⾜） 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で使⽤

33. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.33 TPS メモリテーブル-ReadOnly 3レプリカ(HDD) 2レプリカ(HDD) 2レプリカ(SSD) 検証1 結果〜Read Only〜 MySQL Clusterの構成による性能⽐較  レプリカ数を3にすると約10% の性能ダウン  Read Onlyではストレージ種別は性能にほぼ影響しない P1 P2 P3

34. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.34 TPS メモリテーブル-Read Write 3レプリカ(HDD) 2レプリカ(HDD) 2レプリカ(SSD) 検証1 結果〜Read Write〜 MySQL Clusterの構成による性能⽐較  レプリカ数を3にすると約10% の性能ダウン  Read Writeではストレージを SSDにした場合メモリテーブルでも5%程度性能向上 P1 P2 P3

35. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.35 検証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 MySQL Clusterの構成による性能⽐較 SQLノードの全CPUで、使⽤率が90%以上の⾼負荷状態

36. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.36 検証1 ネットワーク使⽤状況〜3レプリカ-HDD構成〜 MySQL Clusterの構成による性能⽐較 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

37. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.37 検証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 MySQL Clusterの構成による性能⽐較

38. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.38 0 20 40 60 80 100 120 SQL01 SQL02 SQL03 DATA01 DATA02 DATA03 DATA04 ネットワーク帯域（MB／Sec） 2レプリカ-HDD tx rx 検証1 ネットワーク使⽤状況〜2レプリカ-HDD構成〜 MySQL Clusterの構成による性能⽐較 SQLノードではiperfによる測定結果の約117MB/secとほぼ等しい帯域を使⽤

39. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.39 検証1 考察 MySQL Clusterの構成による性能⽐較  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)  レプリカ数を多くするのは慎重に検討

40. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.40 検証2 テーブル配置種別による性能⽐較  下記パターンの性能測定を実施し、メモリテーブル、ディスクテーブル（SSD）、ディスクテーブル（HDD）の性能を⽐較  sysbench OLTP complexモードを使⽤してスループット（TPS）を測定  レコード数は1000万  それぞれの構成について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

41. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.41 検証2 結果〜Read Only〜テーブル配置種別による性能⽐較  Read OnlyではSSDを使⽤したディスクテーブルはメモリテーブルとほぼ同等の性能（環境によって異なるので注意）  HDDのディスクテーブルの性能は極端に低い TPS Read Only 3レプリカ-メモリ 2レプリカ-メモリ 2レプリカ-ディスク(SSD) 2レプリカ-ディスク(HDD) P4 P1 P2 P3

42. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.42 検証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

43. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.43 検証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)

44. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.44 検証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

45. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.45 検証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

46. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.46 検証4 ノード追加によるスケーラビリティ確認  データノードやSQLノードを追加してスループットが向上するかどうかを確認  レプリカ数は2に固定し、データノード数を2台〜10台、SQLノード数を2 台〜14台に変化させて性能測定  sysbench OLTP complexモードを使⽤してスループット（TPS）を測定  レコード数は100万  それぞれの構成についてRead Onlyの性能を測定

47. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.47 検証4 結果ノード追加によるスケーラビリティ確認  ノードを追加することにより、スループットは向上  データノードとSQL ノードを適切な割合で増加させることが重要  データノード数が多い場合、MySQL Clusterが苦⼿とする範囲検索の影響のためスループットがのびない（？） 0 2 4 6 8 10 12 14 TPS SQLノード数 2データノード 4データノード 6データノード 8データノード 10データノード

48. 4. まとめ

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

50. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. 日本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を構築できるのか、データの整合性を保てるのか」

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

53. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. Thank you! ⾼橋智雄テクノロジーコンサルティング事業統括サービス統括本部オープンソース部シニアスペシャリスト Tomoo.Takahashi@hp.com ⽇本ヒューレット・パッカード株式会社本社〒136-8711 東京都江東区⼤島2-2-1

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

Insight Technology, Inc.

Transcript

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

Insight Technology, Inc.

Transcript

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