Successfully reported this slideshow.
ミッションクリティカルを実現する国産データベースHiRDBの技術 (ハイアールディービー)2011/09/272011/10/20株式会社 日立製作所 情報・通信システム社ソフトウェア事業部 DB設計部原 憲宏                 ...
1.What is HiRDB2.スケーラビリティを高めるHiRDBの技術と特長3.障害発生時の可用性を高める  HAクラスタの技術と特長4.読み取り一貫性の再考5.おわりに                            © Hitac...
1-1 データベースは社会インフラの要金融                              公共・教育              世の中の重要な社会インフラは               IT基盤なしには支えられない     通信  ...
1-2 信頼性とスケーラビリティを追求してきたHiRDB      「止めない」設計思想を貫く     高信頼スケーラブルデータベース             ハイアールディービー       Highly Scalable Relationa...
1-3 データベースに対する日立の取り組み                                                        オープンシステムで進化  進化   メインフレーム(MF)での発展            ...
1-4 本日のテーマ   ミッションクリティカルを実現する取り組み 1.スケーラビリティを   ビジネス規模が拡大してもサービスレベル   高める         を維持するHiRDBの技術と特長 2.可用性を高める     障害発生時も業務を...
2.スケーラビリティを高めるHiRDBの技術と特長                            © Hitachi, Ltd. 2011. All rights reserved.
2-1 サービスレベルを維持するために               取り扱う業務量やデータ量が増加しても、                サービスレベルを維持し続けたい。                                性    ...
2-2 分割したサーバの独立性を確保するために          DBをアクセスするBES(*1)が、分割されたデータを独立に処理する          FES(*2)がSQLを振り分け、業務APにデータの所在を意識させない          ...
2-3 トランザクションの並列実行度を高められる     分割したデータ単位に、業務を独立して実行させることで、     高トラフィック時にもスループットを確保できる。                 トランA                 ...
2-4 SQLの並列実行度を高められる     複数のサーバを跨ぐSQLは、表の分割単位に処理を分解することで     BESでの並列実行度を高め、レスポンスタイムを向上できる。                                 ...
2-5 日付と支店番号でのDB分割の例                月単位に支店グループを2次元分割                独立したBESで並列に処理                                     関東   ...
2-6 DB格納領域の簡単なローテーション運用    DBの格納領域を、月次で簡単に再利用。                              ■従来の運用                                        ...
2-7 DB格納領域の簡単な容量設計、運用管理        DB格納領域の見積もり、運用がどれだけ必要?大変?■従来の運用                                   ■ストレージ機能と連携した            ...
2-8 マスタ表の効率的なアクセス    マスタ系データの配置は?               関東         関西          その他              集計業務       集計業務        集計業務       ...
2-9 マスタ表の効率的なアクセス(続き)    『共用表』の更新    - 更新要求をFESが受け、全BESに配布。バッファを更新。    - 受け持ちBESだけがストレージ上のデータを更新。                  関東     ...
3.障害発生時の可用性を高める  HAクラスタの技術と特長                  © Hitachi, Ltd. 2011. All rights reserved.
3-1 サービスを提供し続けるために         障害が発生しても、サービスを提供し続けたい    障害発生時、業務を継続するための3つの観点                                             ③障害を...
②素早く切り替える3-2 素早い『検知・引継ぎ・回復』による数秒での切り替え              『検知・引継ぎ・回復』の3つのポイントの高速化で、数秒オーダでの              系切り替えを実現。  実行系 (a)素早く検知 ...
②素早く切り替える3-3 (a)素早く障害を検知する      マシンダウン クラスタウェア間でのAlive監視による検知      OSパニック   HA Booster Packでの通知による瞬時検知      HiRDBダウン HiRDB...
②素早く切り替える3-4 (b)素早くリソースを引き継ぐ    共有ディスクの数に依存しない、短時間でのディスク引継ぎ:    ①HA Booster PackがHiRDBのI/Oに介在し、     実行系からのアクセスのみを許可。    ②障...
②素早く切り替える3-4 (b)素早くリソースを引き継ぐ    共有ディスクの数に依存しない、短時間でのディスク引継ぎ:    ①HA Booster PackがHiRDBのI/Oに介在し、     実行系からのアクセスのみを許可。    ②障...
②素早く切り替える3-5 (c)素早くHiRDBを回復させる       ホットスタンバイㄤ高速DB回復でHiRDBを高速再開始       - ホットスタンバイ ①システムデーモン、DB処理プロセスの開始       - 高速DB回復 ②ディ...
③障害発生を気付かせない3-6 トランザクションキューイング        系切り替え中に受け付けた新規トランザクションを待機させること        により、アプリケーションに障害発生を意識させない        (トランザクションキューイン...
③障害発生を気付かせない3-7 Active-Activeクラスタでのサービスレベル維持         切り替え をBES に複数の稼 中ノードに分 することにより、         障害時における切り替え の性能 化を最 限に え、    ...
③障害発生を気付かせない3-8 Active-Activeクラスタでのサービスレベル維持         複数ノードに障害が発生した場合でも、第2、第3の稼動中の         DBサーバに処理を引き継ぐことで、          重障害でも...
4.読み取り一貫性の再考               © Hitachi, Ltd. 2011. All rights reserved.
4-1 読み取り一貫性とは       他トランザクションで更新中のデータに対する検索を、       待つことなしに実行できてうれしい。       確定 の最新のデータを返す。      更新トランザクションが排他を      取 して更新...
4-2 読み取り一貫性の検証~(1)COMMITの前後~         参照結果はㅀOMMIT とSELEㅀT の開始タイミングに依存。         ㅀOMMIT でも、ㅀOMMIT にSELEㅀTを開始していると、         更新...
4-3 読み取り一貫性の検証~(2)ROLLBACKの前後~              参照結果はROLLBAㅀㅈ とSELEㅀT の開始タイミングに              非依存。                    読み取り一貫性更新...
4-4 読み取り一貫性の検証~(3)順次参照の組み合わせ~          ㅀOMMIT と2つのSELEㅀT それ れの開始タイミングに          よ ては、 ましくない参照結果となる。                      読...
4-5 排他なし検索含めての検証~(1)COMMITの前後~         読み取り一貫性でも、排他なし検索( itho t lock no ait)でも、参照結果は          O IT とSE E T の開始タイミングに依存。   ...
4-6 排他なし検索含めての検証~(2)ROLLBACKの前後~              排他なし検索のケースでは、参照結果はUPDATE とRO BA   の              開始タイミングに依存。              UP...
4-7 排他なし検索含めての検証~(3)順次参照の組み合わせ~          読み取り一貫性でも、排他なし検索でも、2つのデータを順次SELEㅀTする          ケースでは、これら2つのデータの整合性は保 されない。        ...
4-8 読み取り一貫性における考察       読み取り一貫性でも、排他なし検索でも、       参照結果は O IT とSE E T の       開始タイミングに依存。       データの整合性を  に意識する業務では、       ...
4-9 結論         読み取り一貫性では、他のトランザクションの         更新完 を待た にデータを参照でき、 力 。          O IT のデータ整合性を  に意識する         必要のない業務では、排他なし検索...
4-9 結論      HiRDBでは、業務の特性に応 て、      SQL   に  性  を 定可能。    ■HiRDBでの          性       の   定                  性              ...
5.おわりに         © Hitachi, Ltd. 2011. All rights reserved.
5-1 国産データベース技術の発展に貢献しています  日 データベース 会(DBS )から、長年に る継続 な独自データベース管理システムの   究開発と産業 におけるデータベース管理システムの      な 値向上への  を  認められ、20...
5-2    おわりにこれからも国産のHiRDBに   期待ください!  の会社 、製品   は、それ れの会社の商 もしくは 鉇商 です。                                      © Hitachi, Ltd...
[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)
[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)
Upcoming SlideShare
Loading in …5
×

[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)

1,265 views

Published on

Published in: Technology
  • Be the first to comment

[INSIGHT OUT 2011] C26 ミッションクリティカルを実現する国産データベースHiRDBの技術(hara)

  1. 1. ミッションクリティカルを実現する国産データベースHiRDBの技術 (ハイアールディービー)2011/09/272011/10/20株式会社 日立製作所 情報・通信システム社ソフトウェア事業部 DB設計部原 憲宏 © Hitachi, Ltd. 2011. All rights reserved.
  2. 2. 1.What is HiRDB2.スケーラビリティを高めるHiRDBの技術と特長3.障害発生時の可用性を高める HAクラスタの技術と特長4.読み取り一貫性の再考5.おわりに © Hitachi, Ltd. 2011. All rights reserved.
  3. 3. 1-1 データベースは社会インフラの要金融 公共・教育 世の中の重要な社会インフラは IT基盤なしには支えられない 通信 流通・製造 データベース IT基盤の要はデータベース マスコミ 交通・運輸 データベースの信頼性が IT基盤の信頼性につながる © Hitachi, Ltd. 2011. All rights reserved. 2
  4. 4. 1-2 信頼性とスケーラビリティを追求してきたHiRDB 「止めない」設計思想を貫く 高信頼スケーラブルデータベース ハイアールディービー Highly Scalable Relational DataBase Hi 社会基盤を支えるために 日立が自社開発にこだわり続ける 純国産RDBMS © Hitachi, Ltd. 2011. All rights reserved. 3
  5. 5. 1-3 データベースに対する日立の取り組み オープンシステムで進化 進化 メインフレーム(MF)での発展 累計出荷76,000サーバ ’10/1 ’10/4 ※11年3月(10年度末)時点の累計出荷台数 XDM/RD V12 ■クラウド時代を支える 高性能・高信頼データベースへ ’05/1 ’06/6銀行や交通、公共分野の XDM/RD V11 HiRDB V8 ■ ビジネスの急速な変化に対応する 柔軟性を兼ね備えた、情報統合基盤とオンラインを止めない基盤 ’03/8 ’03 高信頼ノンストップデータベースへが欲い! XDM/RD V10 HiRDB V7 ■ ノンストップビジネスに応える 耐障害性と可用性を追及 ’02/9 ’01 HiRDB V6 ■ネットビジネス(24×7運用)社会インフラを支える XDM/RD V9 に応える長時間連続運転の更なる強化究極の信頼性の追求 ~’99 ~’ ’95~’ XDM/RD ■ミッションクリティカル向け機能・性能強化 ~ HiRDB V2~5 ■デジタルコンテンツの拡張 MF技術の継承 ・Universal Server リリース ’94 RDB1 HiRDB V1 ■オープンシステム向けミッションクリティカル向けデータベース XDM/SD ・Shared Nothingでのパラレルサーバ リリース メインフレームの ADM オープンでの 安心感をそのままに、 PDM オープンプラットフォーム 高信頼性の追求 に対応したい! 時代 1970 1990 2000 2010 © Hitachi, Ltd. 2011. All rights reserved. 4
  6. 6. 1-4 本日のテーマ ミッションクリティカルを実現する取り組み 1.スケーラビリティを ビジネス規模が拡大してもサービスレベル 高める を維持するHiRDBの技術と特長 2.可用性を高める 障害発生時も業務を継続する HAクラスタの技術と特長 3.データの整合性を 確保する 読み取り一貫性の再考 © Hitachi, Ltd. 2011. All rights reserved. 5
  7. 7. 2.スケーラビリティを高めるHiRDBの技術と特長 © Hitachi, Ltd. 2011. All rights reserved.
  8. 8. 2-1 サービスレベルを維持するために 取り扱う業務量やデータ量が増加しても、 サービスレベルを維持し続けたい。 性 性能向上 能■Shared Nothingアーキテクチャ 並列処理で性能向上 並列数 ・ハードウェアの能力を最大限に引き出せる。 ・並列処理で処理時間を短縮できる。 APサーバ データベースを ・・・ 分割する ・完全独立で、サーバ間の共有リソースなし。 ・データ量の増大に対応して拡張しやすい。 DBサーバ ・・・ ストレージ パーティション(分割)表 100台規模構成 での実績あり © Hitachi, Ltd. 2011. All rights reserved. 7
  9. 9. 2-2 分割したサーバの独立性を確保するために DBをアクセスするBES(*1)が、分割されたデータを独立に処理する FES(*2)がSQLを振り分け、業務APにデータの所在を意識させない 完全独立 業務APは、 業務AP データの所在を意識しない APサーバ FES 1 FES 2 FES n ・データの所在位置はFESで自動認識。 ・BESが受け持つデータを並列に処理。 ・BESの処理結果をFESが纏めて返却。 DBサーバ BES 1 BES 2 BES m 排他プール DBバッファ DBアクセスに必要なリソー ストレージ スが独立し、競合が無い パーティション *1 : SQL受付サーバFES (分割)表 (Front End Server) 更新ログ *2 : DBアクセスサーバBES (Back End Server) © Hitachi, Ltd. 2011. All rights reserved. 8
  10. 10. 2-3 トランザクションの並列実行度を高められる 分割したデータ単位に、業務を独立して実行させることで、 高トラフィック時にもスループットを確保できる。 トランA トランB 表の分割単位に独立 関東 関西 その他 してDBをアクセス 集計業務 集計業務 集計業務 APサーバ FES 1 ・・・ FES 3 ・・・ FES 8 高トラフィック時も DBサーバ BES 1 BES 3 BES 8 ・・・ ・・・ スループットを確保 ストレージ パーティショニング(分割表) 表の分割キーの例 関東 関西 その他 DB格納領域1 DB格納領域3 DB格納領域8 © Hitachi, Ltd. 2011. All rights reserved. 9
  11. 11. 2-4 SQLの並列実行度を高められる 複数のサーバを跨ぐSQLは、表の分割単位に処理を分解することで BESでの並列実行度を高め、レスポンスタイムを向上できる。 SQLをBES単位の処理 に分解し並列実行 SQL 検索、更新、ジョイン、ソート、 グループ化、集合演算処理 全店舗 パイプライン並列 集計業務 APサーバ ジョイン、ソートなどの負荷の高い FES 1 ・・・ ・・・ 処理をFESが更に分解して順次 処理。 I/O並列、サーバ間並列 DBサーバ BES 1 BES 3 BES 8 ・・・ ・・・ 分割した表を並列に検索・更新。 ストレージ パーティショニング(分割表) 表の分割キーの例 関東 関西 その他 レスポンスタイムを向上 DB格納領域1 DB格納領域3 DB格納領域8 © Hitachi, Ltd. 2011. All rights reserved. 10
  12. 12. 2-5 日付と支店番号でのDB分割の例 月単位に支店グループを2次元分割 独立したBESで並列に処理 関東 関西 その他 集計業務 集計業務 集計業務 空間軸での BES 1 BES 2 BES 3 分割 支店売上管理表 第1次元 第2次元 <関東地区> <関西地区><その他地区> 分割列 分割列 支店番号 支店番号 支店番号 時間軸での ~1999 2000~2999 3000~ 日付 地区 支店 支店番号 売上 ・・・ 分割2011-07-30 関東 東京 1001 DBAREA1 DBAREA2 DBAREA32011-07-30 関西 大阪 2001 関東07 関西07 他07 <7月>2011-07-30 九州 福岡 3010 ・・ DBAREA4 DBAREA5 DBAREA62011-08-30 関東 1010 <8月>2011-08-30 東 4001 関東08 関西08 他082011-08-30 関西 京 2008 ・・ 一定期間保管 DBAREA7 DBAREA8 DBAREA92011-09-30 関東 東京 1001 関東09 関西09 他09 <9月>2011-09-30 関西 2015 ・・ © Hitachi, Ltd. 2011. All rights reserved. 11
  13. 13. 2-6 DB格納領域の簡単なローテーション運用 DBの格納領域を、月次で簡単に再利用。 ■従来の運用 DB格納領域の 削除・追加が大変 <7月> 関東10 <10月>ローテーション運用を容易にする『月別ハッシュ分割』の利用 DBAREA1 DBAREA2 DBAREA3 <7月> <7月>⇒<10月> 関東07 関西07 他07 <8月> 月別 DBAREA4 DBAREA5 DBAREA6 ハッシュ 関東08 関西08 他08 <8月> 分割 <9月> DBAREA7 DBAREA8 DBAREA9 関東09 関西09 他09 <9月> <10月> <関東地区> <関西地区><その他地区> 支店番号 支店番号 支店番号 ~1999 2000~2999 3000~ © Hitachi, Ltd. 2011. All rights reserved. 12
  14. 14. 2-7 DB格納領域の簡単な容量設計、運用管理 DB格納領域の見積もり、運用がどれだけ必要?大変?■従来の運用 ■ストレージ機能と連携した シン・プロビジョニングでの運用 <関東地区> <関西地区><その他地区> DBAREA1 DBAREA2 DBAREA3 支店番号 支店番号 支店番号 最大 ~1999 2000~2999 3000~ DBAREA1 DBAREA2 DBAREA3 予備 予備 オンデマンド 仮想Vol(ディスク) ・仮想ディスクに最大サイズでDB ディスク追加 エリアを確保でき、DB容量設計 が容易。 見積もり、設計が大変 ・DBエリアの自動拡張に伴い、 ストレージ オンデマンドでストレージを割り プール ・データ増加を予測した見積もり設計。 当てられる。 ・それに伴う拡張・運用設計の立案。 ・ストレージプール全体で枯渇 ・DBエリアのパンク回避のための余裕値設計。 HDD 監視でき、監視、拡張運用が容易。 監視、運用が大変 ストレージプールを活用した ・個々のDBエリアの監視。 資源共有により負担を軽減 ・ディスク追加によるDBエリア拡張。 © Hitachi, Ltd. 2011. All rights reserved. 13
  15. 15. 2-8 マスタ表の効率的なアクセス マスタ系データの配置は? 関東 関西 その他 集計業務 集計業務 集計業務 全BESから参照できる FES 1 FES 2 FES 3 APサーバ 『共用表』を利用 ・全BESから参照できる表属性。 ・各BESのバッファで独立して参照できる。 ・複数のBESから参照する場合でも、 DBサーバ BES 1 BES 2 BES 3 BES間での通信はおこなわない。 DBバッファ DBバッファ DBバッファ マスタ マスタ マスタ 関東 関西 その他 DBAREA10 特定BESへのアクセス ストレージ 集中を回避できる 商品マスタ 共用表属性 DBAREA1 DBAREA2 DBAREA3 関東 関西 他 © Hitachi, Ltd. 2011. All rights reserved. 14
  16. 16. 2-9 マスタ表の効率的なアクセス(続き) 『共用表』の更新 - 更新要求をFESが受け、全BESに配布。バッファを更新。 - 受け持ちBESだけがストレージ上のデータを更新。 関東 関西 その他 更新 集計業務 集計業務 集計業務 FES 1 FES 2 FES 3 APサーバ 受け持ちBES BES 1 BES 2 BES 3 DBサーバ DBバッファ マスタ DBバッファ マスタ DBバッファ マスタ DBサーバの独立性を 関東 関西 その他 確保する ・共用表の更新要求を全BESに配布。 ストレージ DBAREA10 ・バッファヒットしない場合はストレージから 商品マスタ 読み込んでバッファを更新。 共用表属性 ・受け持ちBESだけがストレージ上の データを更新。 DBAREA1 DBAREA2 DBAREA3 ・更新ログは全BESで出力。 関東 関西 他 © Hitachi, Ltd. 2011. All rights reserved. 15
  17. 17. 3.障害発生時の可用性を高める HAクラスタの技術と特長 © Hitachi, Ltd. 2011. All rights reserved.
  18. 18. 3-1 サービスを提供し続けるために 障害が発生しても、サービスを提供し続けたい 障害発生時、業務を継続するための3つの観点 ③障害を気付かせない ②素早く切り替える 待機系 ①障害箇所の局所化・障害の発生サーバのみに影響を 実行系 局所化でき、他の稼動中サーバへ の影響なし。・全面ダウンに繋がらない。 DB DB DB ログ ログ ログ © Hitachi, Ltd. 2011. All rights reserved. 17
  19. 19. ②素早く切り替える3-2 素早い『検知・引継ぎ・回復』による数秒での切り替え 『検知・引継ぎ・回復』の3つのポイントの高速化で、数秒オーダでの 系切り替えを実現。 実行系 (a)素早く検知 待機系 (b)素早く引継ぎ 障害 HiRDB HA HA HiRDB (c)素早く回復 モニタ モニタ Alive監視 フェイルオーバ時間 ※1 HA Booster Pack HA Booster Pack 数秒オーダ 高速系切り替え 時間 ▼トランザクション決着 ※2 ▼障害検知 DB ▼メモリ状態の復元(DB回復) ▼リソース切り替え ▼システムプロセスの初期化 ログ ※1:障害発生~新規トランザクション受付開始までの時間。 ※2:トランザクション決着時間はシステムログ量に依存。※ HAモニタ、HA Booster Pack : クラスタウェア © Hitachi, Ltd. 2011. All rights reserved. 18
  20. 20. ②素早く切り替える3-3 (a)素早く障害を検知する マシンダウン クラスタウェア間でのAlive監視による検知 OSパニック HA Booster Packでの通知による瞬時検知 HiRDBダウン HiRDB自らの申告によるゼロ秒検知 マシンダウン 実行系 待機系 監視 HiRDB HA HA HiRDB モニタ モニタ HiRDB障害 申告 Alive監視 監視HiRDBスローダウン Time Stamp HA Booster Pack HA Booster Pack OSパニック 通知・実行系のマシンダウンを、 HiRDBのスローダウンを、生存監視 待機系からのハートビートで検知。 DB 機能(Time Stampの定期更新/定期参照)に・待機系から実行系マシンをリセット。 ログ より、HAモニタが検知。 © Hitachi, Ltd. 2011. All rights reserved. 19
  21. 21. ②素早く切り替える3-4 (b)素早くリソースを引き継ぐ 共有ディスクの数に依存しない、短時間でのディスク引継ぎ: ①HA Booster PackがHiRDBのI/Oに介在し、 実行系からのアクセスのみを許可。 ②障害発生時、アクセス制御の変更のみで引継ぎを実現。 実行系 待機系 HA HA モニタ モニタ HiRDB HiRDB HA Booster Pack HA Booster Pack ・・・ ・・・①I/O介在での アクセス制御 常時オンライン (活性)状態 DB DB ログ DB ログ DB ログ ログ © Hitachi, Ltd. 2011. All rights reserved. 20
  22. 22. ②素早く切り替える3-4 (b)素早くリソースを引き継ぐ 共有ディスクの数に依存しない、短時間でのディスク引継ぎ: ①HA Booster PackがHiRDBのI/Oに介在し、 実行系からのアクセスのみを許可。 ②障害発生時、アクセス制御の変更のみで引継ぎを実現。 実行系 待機系 HA HA モニタ モニタ HA Booster Packなし HA Booster Packあり HiRDB HiRDB シ 非活性化 ー アクセス 実行系 拒否 ケ HA Booster Pack HA Booster Pack ン ディスク 一 活性化 括 シ 処 ャ ・・・ ・・・ ル 理 処 アクセス ②アクセス制御 活性化 許可 理 待機系 ディスク の変更(引継ぎ) 切 切 替 替 時 時 間 間 共有ディスク数 共有ディスク数 DB DB ログ DB ログ DB ログ ログ © Hitachi, Ltd. 2011. All rights reserved. 21
  23. 23. ②素早く切り替える3-5 (c)素早くHiRDBを回復させる ホットスタンバイㄤ高速DB回復でHiRDBを高速再開始 - ホットスタンバイ ①システムデーモン、DB処理プロセスの開始 - 高速DB回復 ②ディスク の並列DB回復 ③新規トランザクションの早期受付開始 ③新規トランザクションの待機系⇒実行系 早期受付開始 ①ホットスタンバイ ・システムデーモン ・DB処理プロセス HA HiRDB モニタ DB回復 ホットスタンバイ (ディスク1) 再開始 DB回復 (ディスク2) HiRDB再開始 (DB回復) : : DB回復 (ディスクn) HA Booster Pack 時間 ②ディスク の 回復トランザクション メモリ状態の復元 トランザクションの 並列DB回復 (DB回復処理) 決着 新規トランザクションDB ログ © Hitachi, Ltd. 2011. All rights reserved. 22
  24. 24. ③障害発生を気付かせない3-6 トランザクションキューイング 系切り替え中に受け付けた新規トランザクションを待機させること により、アプリケーションに障害発生を意識させない (トランザクションキューイング)。 トランザクションキューイング 障害発生を トランザクション 系切替え期間 気付かせない 受付 キュー 業務AP FES サービス再開 まで待機 実行 待機系 BES BES BES BES 受付 非 用実行系 エラー DB DB DB マシンダウン ログ ログ ログ © Hitachi, Ltd. 2011. All rights reserved. 23
  25. 25. ③障害発生を気付かせない3-7 Active-Activeクラスタでのサービスレベル維持 切り替え をBES に複数の稼 中ノードに分 することにより、 障害時における切り替え の性能 化を最 限に え、 安定性能を維持できる。 待機 用サーバマシンが 要なため、 資対 果の高いシステム を実現できる。■通常時 ■1台障害発生時 業務AP 業務AP DBサーバ 1 DBサーバ 2 DBサーバ 3 DBサーバ 1 DBサーバ 2 DBサーバ 3 BES1 BES3 BES5 BES1 BES3 BES5 BES2 BES4 BES6 BES2 BES4 BES6 BES1 BES2 障害 DB及 システムログ 引継ぎㄤ継続 用 BES単位で DBサーバ2、DBサーバ3で 系切り替え( 動) 処理を分 して引き継ぐ。 ⇒分 引継ぎ サーバ間の負荷は 化。 © Hitachi, Ltd. 2011. All rights reserved. 24
  26. 26. ③障害発生を気付かせない3-8 Active-Activeクラスタでのサービスレベル維持 複数ノードに障害が発生した場合でも、第2、第3の稼動中の DBサーバに処理を引き継ぐことで、 重障害でも、HiRDBは まること無くサービスを提供し続ける。■1台障害発生時 ■さらに障害発生時 業務AP 業務AP DBサーバ 1 DBサーバ 2 DBサーバ 3 DBサーバ 1 DBサーバ 2 DBサーバ 3 BES1 BES3 BES5 BES3 BES5 BES2 BES4 BES6 BES4 BES6 BES1 BES2 BES1 BES2障害 障害 BES3 BES4 BES1 DBサーバ2の障害発生時は、 HAモニタ(マルチスタ DBサーバ3で処理を引き継ぐ。 ンバイ機能)との連携 重障害でもノンストップ © Hitachi, Ltd. 2011. All rights reserved. 25
  27. 27. 4.読み取り一貫性の再考 © Hitachi, Ltd. 2011. All rights reserved.
  28. 28. 4-1 読み取り一貫性とは 他トランザクションで更新中のデータに対する検索を、 待つことなしに実行できてうれしい。 確定 の最新のデータを返す。 更新トランザクションが排他を 取 して更新中のデータ。 待た に検索できる。更新トランザクション 更新 データ 1 2 ㅒPDATE 1 A⇒ㅕ A⇒ 2 参照トランザクション 2 B A 3 ㅀ SELEㅀT A SELEㅀT開始時点で確定 のデータ ㅀOMMIT を参照する。 © Hitachi, Ltd. 2011. All rights reserved. 27
  29. 29. 4-2 読み取り一貫性の検証~(1)COMMITの前後~ 参照結果はㅀOMMIT とSELEㅀT の開始タイミングに依存。 ㅀOMMIT でも、ㅀOMMIT にSELEㅀTを開始していると、 更新 データを返す。 読み取り一貫性更新トランザクション 参照トラン1 参照トラン2 SE E T SE E T A ㅒPDATE SE E T A A⇒ SE E T 開始が A O ITの か かで時 SE E T 結果が なる。間 ㅀOMMIT SE E T A O IT でもその に SE E T を開始していると 更新 データを返す。 © Hitachi, Ltd. 2011. All rights reserved. 28
  30. 30. 4-3 読み取り一貫性の検証~(2)ROLLBACKの前後~ 参照結果はROLLBAㅀㅈ とSELEㅀT の開始タイミングに 非依存。 読み取り一貫性更新トランザクション 参照トラン1 参照トラン2 SE E T SE E T A ㅒPDATE SE E T A A⇒ A時 SE E T SE E T 開始が間 RO BA RO BA の か かで SE E T A 結果は変わらない。 A © Hitachi, Ltd. 2011. All rights reserved. 29
  31. 31. 4-4 読み取り一貫性の検証~(3)順次参照の組み合わせ~ ㅀOMMIT と2つのSELEㅀT それ れの開始タイミングに よ ては、 ましくない参照結果となる。 読み取り一貫性更新トランザクション 参照トラン1 SE E T A 更新 データの値 データの値 ㅒPDATE (データ1、データ2) データ1 データ2 データ1 SE E T トランザクション A⇒ B 参照トラン2 2 更新 A、B SE E T A 更新 ㅕ、ㅖ SE E T時 B ㅒPDATE間 データ2 B⇒ 参照トラン3 3 ㅀOMMIT SE E T 参照トランザクション3 A では、 ましくない結果 SE E T (A、ㅖ)となる。 © Hitachi, Ltd. 2011. All rights reserved. 30
  32. 32. 4-5 排他なし検索含めての検証~(1)COMMITの前後~ 読み取り一貫性でも、排他なし検索( itho t lock no ait)でも、参照結果は O IT とSE E T の開始タイミングに依存。 O IT を に意識する業務でなけれ 、 を意識する必要はない。 読み取り一貫性 排他なし検索更新トランザクション 参照トラン1 参照トラン2 参照トラン1 参照トラン2 SE E T SE E T SE E T SE E T A A ㅒPDATE SE E T A SE E T A A⇒ A A UPDATEの かで時 SE E T SE E T 結果が なる間 ㅀOMMIT SE E T SE E T A O ITの かで 結果が なる © Hitachi, Ltd. 2011. All rights reserved. 31
  33. 33. 4-6 排他なし検索含めての検証~(2)ROLLBACKの前後~ 排他なし検索のケースでは、参照結果はUPDATE とRO BA の 開始タイミングに依存。 UPDATE とRO BA の開始タイミングを に意識する業務 でなけれ 、 を意識する必要はない。 読み取り一貫性 排他なし検索更新トランザクション 参照トラン1 参照トラン2 参照トラン1 参照トラン2 SE E T SE E T SE E T SE E T A A ㅒPDATE SE E T A SE E T A A⇒ A時 SE E T SE E T間 RO BA SE E T SE E T A A A UPDATEとRO BA の UPDATEとRO BA の で結果は変わらない で結果が なる © Hitachi, Ltd. 2011. All rights reserved. 32
  34. 34. 4-7 排他なし検索含めての検証~(3)順次参照の組み合わせ~ 読み取り一貫性でも、排他なし検索でも、2つのデータを順次SELEㅀTする ケースでは、これら2つのデータの整合性は保 されない。 読み取り一貫性 排他なし検索更新トランザクション 参照トラン1 参照トラン1 SE E T SE E T A A ㅒPDATE データ1 SE E T SE E T A⇒ B 参照トラン2 2 B 参照トラン2 2 SE E T SE E T A SE E T SE E T時 B B ㅒPDATE間 データ2 B⇒ 参照トラン3 3 参照トラン3 3 SE E T SE E T ㅀOMMIT A SE E T SE E T © Hitachi, Ltd. 2011. All rights reserved. 33
  35. 35. 4-8 読み取り一貫性における考察 読み取り一貫性でも、排他なし検索でも、 参照結果は O IT とSE E T の 開始タイミングに依存。 データの整合性を に意識する業務では、 排他を取 してから参照する必要がある。 © Hitachi, Ltd. 2011. All rights reserved. 34
  36. 36. 4-9 結論 読み取り一貫性では、他のトランザクションの 更新完 を待た にデータを参照でき、 力 。 O IT のデータ整合性を に意識する 必要のない業務では、排他なし検索との を 意識する必要はない。 データ整合性の 性が求められる業務では、 排他を取 してから参照する必要がある。 © Hitachi, Ltd. 2011. All rights reserved. 35
  37. 37. 4-9 結論 HiRDBでは、業務の特性に応 て、 SQL に 性 を 定可能。 ■HiRDBでの 性 の 定 性 HiRDBにおける実現 (Isolation level) READ UNCOMMITTED 検索時の排他オプションに ( コミットデータの読込み) 「WITHOUT LOCK NOWAIT」を 定 READ COMMITTED 検索時の排他オプションに (コミット みデータの読込み) 「WITHOUT LOCK WAIT」を 定 REPEATABLE READ 検索時の排他オプションに ( り返し可能の読込み) 「WITH SHARE LOCK」を 定 SERIALIZABLE LOCK TABLE を用いて、 ( 列化可能) 表に対して排他をかける © Hitachi, Ltd. 2011. All rights reserved. 36
  38. 38. 5.おわりに © Hitachi, Ltd. 2011. All rights reserved.
  39. 39. 5-1 国産データベース技術の発展に貢献しています 日 データベース 会(DBS )から、長年に る継続 な独自データベース管理システムの 究開発と産業 におけるデータベース管理システムの な 値向上への を 認められ、2010年度に新設された業績 の第一号を受 しました。 日 データベース 会(DBS ) 業績 とは 業績 は、 が国のデータベースに関する ・技術の産業化をはかり、も て 術、 化、産業の発 に大いに した 体の業績を するためのものです。 業績 は各年 体を 定して表 するものではなく、 な 績があ た 体が あれ 表 する制度です。 © Hitachi, Ltd. 2011. All rights reserved. 38
  40. 40. 5-2 おわりにこれからも国産のHiRDBに 期待ください! の会社 、製品 は、それ れの会社の商 もしくは 鉇商 です。 © Hitachi, Ltd. 2011. All rights reserved. 39

×