[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto

D33:D33:
そのデータベース
5年後大丈夫ですか
2014年 6月2014年 6月
日本ヒューレット・パッカード株式会社
プリセールス統括本部サーバー技術二部
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
後藤宏

自己紹介 A26: 小幡氏のセッションを思い出してい
ただければ。
Jim Gray を見て、これだ、と感じてはや24年。よもやこんなにデータベースにかか
わるとは思いもせず。以前は皆さんと同じどんな障害にも立ち向かうぞと徹夜もい
ただければ。
とわずでしたが、今やコンピューターシステムを信頼し、「ひと」ではなく「もの」に頑
張ってもらい、もっとクリエイティブな仕事をしようとしつこく「標準化」を唱える。
1986年非常勤講師 (統計学など)1986年非常勤講師 (統計学など)
1990年日本ディジタルイクイップメント入社
DEC Rdb (現Oracle Rdb) 支援
技援1992年 ISV 技術支援 (Oracle, Informix, Sybase)
2005年 IPA OSS実証プロジェクト参加
2010年「国境なき医師団 (Medecins Sans Frontieres=MSF)」へITでボランティア
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
現在もサーバーとデータベースに携わる

半世紀のHP1982
EDS : Electronic Data Systems
Ross Perot
1962
Compaq
Rod Canion
Jim Harris
Bill Murto
1982
1997
Ross Perot
Tandem
Jim Treybig
Bill Murto
1957
1974 1997
1998
DEC : Digital Equipment Corp
Ken Olsen
Harlan Anderson
1939
1989
2002
HP Now !2008
2009
Apollo
Bill Poduska
19891979Hewlett-Packard
Bill Hewlett
Dave Packard
3Com
1979
2009
3Com
Robert M. Metcalfe
1992
Palm
Jeff Hawkins, Donna Dubinsky

目的とゴール
目的ゴール
• ITの進化に合わせたデー
タベスを考えてみよう
• データベースをシンプルに
使うことタベースを考えてみよう
• 5年後の姿を想像してみよ
う
使うこと
• 見直すなら今だ !
• たとえばNonStop SQLうたとえばNonStop SQL

本日の課題
未来永劫(とはいえ、5年後)、特定ベンダーのH/WとRDBMSを使い続けますか
アプリケーションの主流は変えないですかアプリケションの主流は変えないですか
データベースアクセスは残りそうですね
保守費用保守費用
保守性
開発プラットフォーム
開発エンジニア確保

アジェンダ
• 2020年の世界を見てみましょう2020年の世界を見てみましょう
• シンプルに書き換えてみましょう
• こんな「データベース」いかがですか、こんなデタス」いかがですか、
将来よりよいプラットフォームへ移行できます

http //seikats soken jp/
博報堂生活総合研究所
http://seikatsusoken.jp/
2018年
半導体製造が16ナノメートル製造プロセスで技術的な限界に達し、ムーアの法則が
終焉する終焉する
類型：予測
出典： ZDNet USA
資料：「Limits to Binary Logic Switch Scaling--A Gedanken Model」インテル研究者の
論文（2003年11月）
発表： 2003年12月2日
2020年0 0年
電子の代わりにレーザー光で信号を伝えるシリコン大規模集積回路（LSI）が実用化す
る（コンピューターの消費電力を1/100に改善）
類型：政策目標
出典：日本経済新聞
出典：日本経済新聞
資料：東京大学荒川泰彦教授、田辺克明特任助教らの研究
発表： 2010年5月31日

2020年の未来予測データセンタを支える技術
HPの取り組み～ハードウェアの再定義～ “HP Enterprise 20/20 “ www enterprise2020 com
アプリに最適化され
効率を追求したサーバ
チップ統合
光子ネットワーク
ユニバーサル・
メインメモリー
Today By 2020 By 2020
HPの取り組みハドウェアの再定義 HP Enterprise 20/20 www.enterprise2020.com
電子光子から
高速インターコネクト (～20TBytes/秒)
• DRAMのように高速、かつ不揮発性
• メモリとHDDの位置づけが変わる
• ソフトウェアのデザインが変わる
高速インタコネクト ( 20TBytes/秒)
Moonshot Integrated Photonics Memristor

2020年の未来予測データセンタを支える技術
HPの取り組み～ハードウェアの再定義～ “HP Enterprise 20/20 “ www enterprise2020 com
アプリに最適化され
効率を追求したサーバ
チップ統合
光子ネットワーク
ユニバーサル・
メインメモリー
Today By 2020 By 2020
HPの取り組みハドウェアの再定義 HP Enterprise 20/20 www.enterprise2020.com
電子光子から
高速インターコネクト (～20TBytes/秒)
• DRAMのように高速、かつ不揮発性
• メモリとHDDの位置づけが変わる
• ソフトウェアのデザインが変わる
高速インタコネクト ( 20TBytes/秒)
Moonshot Integrated Photonics Memristor
2013～ By 2020By 2020

HP 研究所 (htt // h l h / h/)
次に来る技術
HP 研究所 (http://www.hpl.hp.com/research/)
Silicon photonic (シリコンフォトニクス)
non-volatile memory “Memristor” (不揮発性メモリ)non volatile memory Memristor (不揮発性メモリ)
energy-optimized systems-on-chips (SoCs) (エネルギー最適化システムオンチップ)

HP Memristor
 電源供給がなくてもデータを保持できる受動素子デタタが 電源供給がなくてもデータを保持できる受動素子
 フラッシュメモリよりも高速・低消費電力・高密度
 演算装置としても利用可能
データセンタが
アタッシュケースに？

i t によるユニバサルメモリ
この階層は過去の物へ C21: 石川氏のセッションで
「なくなりますよねと言memristorによるユニバーサルメモリ「なくなりますよね」と言って
いたレイヤの話です。
SRAMOn-chip
cache
M i
ed
rbit
DRAM
Flash
Main
memory
Spee
Costpe
• Flash
• Hard Disk
Mass
storage
Capacity

「コンピュータ」の歴史を変える取り組み
HPは60年間不変の基本構造をイノベションの力で変革HPは60年間不変の基本構造を、イノベーションの力で変革
揮発性
これまでちょっと先
揮発性
メモリ汎用
CPU
汎用
CPU
不揮発性
メモリ
不揮発性
メモリ
磁気
ディスク
アーカイブ

The Machine 詳細は、A34: インメモリーテ
クノロジーでクノジで
Photonics
Special purpose cores
専⽤コア
フォトニクス
Massive memory pool
巨⼤なメモリー群
専⽤コア巨⼤なメモリ群

アジェンダ
• 2020年の世界を見てみましょう2020年の世界を見てみましょう
• シンプルに書き換えてみましょう
• SQL 構文SQL 構文
• PL/SQL (組み込み)
• Pro*COBOLPro COBOL
• こんな「データベース」いかがですか、
将来よりよいプラットフォームへ移行できます

皆さんの求めるものは何ですか
さて現在に戻って、と、ある提案で言われました
皆さんの求めるものは何ですか
機能 Oracle11g NonStop SQL/MX 3.1
インデックス
Ｂ－Ｔｒｅｅインデックス ○ ○ク
ビットマップインデックス ○ ×
クラスタードインデックス ○ ×
圧縮型インデックス ○ ×
ハッシュインデックス ○ ×
逆キーインデックス ○ ×逆キインデックス ○ ×
LookUpインデックス × ×
ビットワイズインデックス × ×
他次元デックス × ×
排他制御
ロックのエスカレーションｴｽｶﾚｰｼｮﾝが発生しない ○ロックのエスカレーションｴｽｶﾚｰｼｮﾝが発生しない ○
リードロックなしの読取一貫性 ○ ×(ANSI準拠のためDirty Read可）
ローカル・デッドロック解消 ○ ×
分散デッドロック解消 ○ ×
独立性レベル 1,3 0,1,2,3
ロック単位行、表、ブロック(RAC) 行、複数行（Generic lock）、表

デタベスをもとシンプルに使いこなそうデータベースをもっとシンプルに使いこなそう
ンピタの性能が上がてきている• コンピュータの性能が上がってきている
→ S/Wの創意工夫の時代は終わった
• 利用用途ありきのインフラを考えよう• 利用用途ありきのインフラを考えよう
• 遅いストレージを克服しよう

なぜ「標準」が存在するのでしょうか
各RDBMS毎のSQL Statements比較まずは
実態把握
200
250
なぜ「標準」が存在するのでしょうか
150
200
50
100ANSI SQL
（標準SQL）
約70構文
データベース A
約200構文
0

ここからの話、実は….
開発者、DBAにとっては
経営者と経営者にとっては
でもね
でもね…..

今一度、アプリケーションの流動性確保
Java Appl.Java Appl. C/C++ Appl.C/C++ Appl.
JVMJVM TUXEDOTUXEDO O l
Java Platform
O l JVMJVM TUXEDOTUXEDO
Oracle EEOracle EE
Oracle
OS
RDBMS
Oracle
Oracle
LinuxLinux
MC/MC/ServiceguardServiceguard HP
Linux
OS
HPHP BladeSystemBladeSystem HP
れまれから
サービスが提供される
これまでこれから

SQL要変換項目
ある例含まれる構文や関数を洗い出しある例: 含まれる構文や関数を洗い出し
1. DECODE関数
2. TRIM関数
/ 関数
16. ADD_MONTHS関数
17. JOIN (+) 外部結合構文
関数3. LTRIM/RTRIM関数
4. LPAD関数
5. RPAD関数
6. REPLACE関数
S G 関数
18. TO_DATE関数
19. NEXT_DAY関数
20. Select for updte nowait
21. ROWNUM関数
文7. SIGN関数
8. TO_CHAR関数
9. SUBSTR 関数
10. NVL関数
11 SYSDATE
22. CALL文
23. /*+FIRST_ROW*/
24. TO_SINGLE_BYTE関数
25. MINUS演算子
S R CO C B 構文11. SYSDATE
12. INSTR関数
13. LEAST/GREATEST関数
14. TRUNC関数
15 TO NUMBER関数
26. START WITH CONNECT BY構文
(階層問い合わせ)
27. DECLARE
28. V$SESSION
15. TO_NUMBER関数

本アセスメントにて洗い出したSQL総数約1 500の内訳
SQLの変更難度による分類結果
本アセスメントにて洗い出したSQL総数約1,500の内訳
レベル0 レベル1 レベル2 レベル3 レベル4
変換不要
キーワードの変換で移行
可能
キーワード変換後に単純
な置換を手動で実施する
必要がある
キーワード変換が不可能
でありアプリケーションの
見直しが必要
アプリケーションロジックの
見直しが必要
DECODE JOIN ( )DECODE
TRIM
LTRIM / RTRIM
LPAD
RPAD
REPLACE
NVL
SYSDATE
INSTR
LEAST / GREATEST
TRUNC
JOIN (+)
TO_DATE
NEXT_DAY
SELECT FOR UPDATE
NOWAIT
ROWNUM
TO_SINGLE_BYTE
MINUS
START WITH CONNECT
BY
DECLAREREPLACE
SIGN
TO_CHAR
SUBSTR
TO_NUMBER
ADD_MONTHS
ROWNUM
CALL文
/*+ FIRST_ROW */
DECLARE
V$SESSION
出現回数 775 202 324 91 0
出現率 55 7% 14 5% 23 3% 6 5% 0%
93 5%
70.2%
55.7%
~手動変換(L2)
~キーワード変換(L1)
変換不要(L0)
6 5%
レベル3は全体の
6.5%
レベル4は
出現率 55.7% 14.5% 23.3% 6.5% 0%
93.5%
0.0% 20.0% 40.0% 60.0% 80.0% 100.0%
~手動変換(L2) 6.5% 未検出

本アセスメントにて洗い出したSQL総数約 300の内訳
SQLの変更難度による分類結果
本アセスメントにて洗い出したSQL総数約 300の内訳
レベル0 レベル1 レベル2 レベル3 レベル4
変換不要
キーワードの変換で
移行可能
キーワード変換後に
単純な置換を手動で
実施する必要がある
キーワード変換が不
可能でありアプリケー
ションの見直しが必要
アプリケーションロ
ジックの見直しが必要
実施する必要があるションの見直しが必要
ヒント文
NVL
LPAD
TRIM
LTRIM
SYSDATE
SUBSTRB
TO_DATE
TO_NUMBER
時間演算
参考)
TO_SINGLE_BYTE
MINUS
START WITH
LTRIM
Select for update
TO_CHAR(,DATE/TIM
E)
TO_CHAR('xxxxxxxx')
時間演算
外部結合
CONNECT BY
DECLARE
V$SESSION
出現回数 173 106 52 0 0
レベル3、4は未+キーワード変換(LV0+1)
変換不要(LV0)
出現回数 173 106 52 0 0
出現率 52.27% 32.02% 15.71% 0% 0%
検出
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
+単純な置き換え(LV0+1+2)
+キワド変換(LV0+1)

SQL構文書き換えの例
外部結合
A.colx = B.colx(+) → A LEFT JOIN B ON A.colx = B.colxA.colx B.colx( ) → A LEFT JOIN B ON A.colx B.colx
A.colx(+) = B.colx → A RIGHT JOIN B ON A.colx = B.colx
文字列検索
INSTR(x,y) → POSITION(y IN x)
INSTR(x,’-’,1,2) →
POSITION('-' IN x) + POSITION('-' IN INSERT(x , 1, POSITION('-' IN x), ''))
字変換文字列変換
TO_CHAR(date1, ‘YYYYMMDD’) →
REPLACE(SUBSTRING(CAST(time1 AS VARCHAR(26), 1, 19), ‘-’, ‘/’))
TO CHAR(time1 ‘YYYY/MM/DD HH24:MI:SS’) →
TO_CHAR(time1, YYYY/MM/DD HH24:MI:SS ) →
REPLACE(CAST(date1 AS VARCHAR(10), ‘-’, ‘’))

PL/SQL要変換項目
1. %TYPE
2. IF then ELSE
/
16. MOD(A,B)
17. LENGTH
3. FOR IN/REVERSE LOOP
4. DUP_VAL_ON_INDEX
5. NO_DATA_FOUND
6. APP_ABORT
APP TIMEUP
18. LENGTHB
19. LPAD
20. TO_CHAR
21. TO_NUMBER
7. APP_TIMEUP
8. RAISE APP_TIMEUP
9. raise_application_error
10. SQLCODE
11 SQLERRM
22. ADD_MONTH
23. REPLACE
24. SYSDATE
25. DBMS_SQL.PERSE
26 DBMS SQL BIND VARIABLE11. SQLERRM
12. 文字結合 ||
13. LTRIM
14. RTRIM
15 SUBSTR(A B)/SUBSTR( b )
26. DBMS_SQL.BIND_VARIABLE
27. DBMS_SQL.EXECUTE
28. DBMS_SQL.VARIABLE_VALUE
29. DBMS_SQL.CLOSE_CURSOR
30 DBMS SQL OPEN CURSOR
15. SUBSTR(A,B)/SUBSTR(a,b,c) 30. DBMS_SQL.OPEN_CURSOR

PL/SQL要変換項目
31. %TYPE
32. DBMS_SQL.define_column
f h33. DBMS_SQL.fetch_rows
34. DBMS_SQL.column_value
35. DBMS_SQL.VARCHAR2S
36. DBMS_SQL.V7
3 DBMS OUTPUTPUTLINE37. DBMS_OUTPUT.PUTLINE
38. DBMS_OUTPUT.enable
39. DBMS_UTILITY.exec_ddl_statement
40. UTIL_FILE.FOPEN
41 UTIL FILE PUT LINE41. UTIL_FILE.PUT_LINE
42. UTIL_FILE.FCLOSE

アセスメントにて洗い出したPL/SQL パッケジ総数80のロジック関数50の内訳
PL/SQLのロジック,関数の出現頻度%TYPE
IFthenEL
FORIN/RE
LOOP
DUP_VAL_
X
NO_DATA_
APP_ABOR
APP_TIME
RAISEAPP
raise_app
rror
SQLCODE
SQLERRM
文字結合
||
LTRIM
RTRIM
SUBSTR
MOD(A,B)
LENGTH
LENGTHB
LPAD
TO_CHAR
TO_NUMB
ADD_MON
アセスメントにて洗い出したPL/SQL パッケージ総数80のロジック,関数50の内訳SE
EVERSE
_ON_INDE
_FOUND
RT
EUP
P_TIMEUP
plication_e
BER
NTH
出現回数 14 65 55 22 16 1 1 1 13 4 4 30 2 4 19 1 1 10 3 3 4 10
出現率(%) 19 4 90 3 76 4 30 6 22 2 1 4 1 4 1 4 18 1 5 6 5 6 41 7 2 8 5 6 26 4 1 4 1 4 13 9 4 2 4 2 5 6 13 9出現率(%) 19.4 90.3 76.4 30.6 22.2 1.4 1.4 1.4 18.1 5.6 5.6 41.7 2.8 5.6 26.4 1.4 1.4 13.9 4.2 4.2 5.6 13.9
DBMS_SQL
DBMS
_OUT
PUT
DBMS
_UTILI
TY
UTIL_FILE
RE
SY
PE
BIN
EX
VA
E
CLO
OP
def
fet
col
DB
en
DB
CH
DB
PU
exe
me
FO
PU
FC
PLACE
SDATE
RSE
ND_VARIABLE
ECUTE
ARIABLE_VALU
OSE_CURSOR
PEN_CURSOR
fine_column
tch_rows
lumn_value
BMS_OUTPUT.
able
BMS_SQL.VAR
AR2S
BMS_SQL.V7
UTLINE
ec_ddl_state
ent
PEN
UT_LINE
LOSE
出現回数 6 1 1 1 1 9 1 2 2 2 4 1 1 1 9 1 2 2 2
出現回数 6 1 1 1 1 9 1 2 2 2 4 1 1 1 9 1 2 2 2
出現率(%) 8.3 1.4 1.4 1.4 1.4 12.5 1.4 2.8 2.8 2.8 5.6 1.4 1.4 1.4 12.5 1.4 2.8 2.8 2.8
※ 各パッケージのロジックはパターン化されている。

次の期待は性能の担保
動作すると、期待する応答時間で動作す
るは異なる
どのフェーズでどの程度の時間がかかる
のか
• Enqueueq
• cpu time
• Db file read
• Db file write

やってみました
CREATE OR REPLACE PROCEDURE SAMPLE_PLSQL(V_LOOPCOUNT IN NUMBER) IS
V_APPNAME VARCHAR2(64) DEFAULT 'PROCEDURE';
V_FUNCNAME VARCHAR2(64) DEFAULT 'SAMPLE_PLSQL';
V_UPDCNT NUMBER;
V_COUNT NUMBER;
V_A_ID VARCHAR2(64);
V_EXT_A_ID VARCHAR2(64);
プロシジャ ADD APPLOG
import java.sql.*;
import java.util.*;
public class SAMPLE_PLSQL
{
public static void spSAMPLE PLSQL(Integer V LOOPCOUNT) throws SQLException Exception-- プロシージャ ADD_APPLOG
CURSOR A_CUR IS
SELECT A_ID FROM SAM;
PROCEDURE ADD_APPLOG(I_APPNAME IN VARCHAR2 DEFAULT NULL,
I_FUNCNAME IN VARCHAR2 DEFAULT NULL,
public static void spSAMPLE_PLSQL(Integer V_LOOPCOUNT) throws SQLException,Exception
{
Connection mConn = DriverManager.getConnection("SQLWAYS_EVAL# onnection");
Integer ErrorCode = -1;
String SqlState = "";
boolean FetchStatus = false;
I_COMMENT IN VARCHAR2 DEFAULT NULL,
I_ERRORMSG IN BOOLEAN DEFAULT FALSE) IS
V_COMMENT RH_APPLOG.COMMENT_TEXT%TYPE;
BEGIN
-- エラーの場合の処理
IF (I ERRORMSG = TRUE) THEN
try
{
/*SQL_EVAL# */
String V_APPNAME = "PROCEDURE";
String V_FUNCNAME = "SAMPLE_PLSQL";
Integer V UPDCNT = null;
IF (I_ERRORMSG = TRUE) THEN
V_COMMENT := I_COMMENT || '(' || SQLERRM || ')';
Integer V_UPDCNT null;
Integer V_COUNT = null;
String V_A_ID = null;
String V_EXT_A_ID = null;

ORACLE LICENSE AND SERVICES AGREEMENT V040309
Oracleのベンチマーク結果の開示禁止
ORACLE LICENSE AND SERVICES AGREEMENT V040309
D.（権利及び制限）
オラクル及びそのライセンサーは、対象プログラムについて一切の所有権及び知的財産権を保有します。本契約に基づく対象サービスに起因して開発さ
れ、納入されたものに関わる全ての所有権及び知的財産権は、オラクルが保有します。お客様は、使用権を許諾された範囲でそれぞれの対象プログラム
プグを必要なだけ複製することができ、また、それぞれの対象プログラムのメディアを1 部複製することができます。
いくつかのオラクルのプログラムと共に使用するのに適している、又は必要となる第三者のテクノロジー製品は、対象ドキュメントに記載されます。当該第
三者のテクノロジー製品は、本契約の条件ではなく、対象ドキュメントで記載される第三者テクノロジー製品のライセンス契約の条件に基づきお客様に使
用権が付与されております。
お客様は以下の行為をしてはならないものとします。
（1）対象プログラムの表示又はオラクル若しくはそのライセンサーの財産権に関する注意事項の表示を削除又は変更すること
（2）対象プログラム、又は対象サービスの提供により生じた成果物を、方法の如何に関わらず第三者の業務処理目的で当該第三者の使用に供すること
（ただし、お客様が購入した特定の対象プログラムの使用権、又は対象サービスの提供により生じた成果物について当該使用を明確に認めている場合を
除
きます）きます）
（3）対象プログラムのリバース・エンジニアリング（ただし、相互運用性検証のため法律で認められている場合を除きます）、逆アセンブル若しくは逆
コンパイルを自ら行ない、又は第三者にそれらの行為を許可すること（前述の禁止事項はデータ構造又は対象プログラムにより作成された同種のものの
検
証を含みますが、この限りではありません）
（4）オラクルの事前の書面による承諾なく、対象プログラムのベンチマークテストの結果を開示すること
[2012/9/1 以降適用]

試験結果
ごめんなさい、公開はできません。
個別にお問い合わせください。個別にお問い合わせください。

もう一度、言います
データベースをもっとシンプルに使いこなそう
• コンピュータの性能が上がってきている• コンピュタの性能が上がってきている
→ 実装 (先ほどはS/W) の創意工夫の時代は終わった !! (と、私は思う)
• 利用用途ありきのインフラを考えよう
• 遅いストレージを克服しよう遅いストレジを克服しよう
標準的に記述しよう標準記う
• 5年後もっといいインフラ (RDBMS、H/W) にいつでも乗り換えられます
→ SQL は担保されます (なんたって標準規格ですから)
• 構文でのチューニングはやめよう

再び、実は….
開発者、DBAにとっては
経営者と経営者にとっては
でもね
でもね…..

データベースに期待すること
「なんか知らんけど動いてくれれば」経営者、営業
「止まってくれるな」サーバー管理者
「バッチが終わらん !!」 DBA, 業務責任者
「メンテ、大変」サーバー管理者、経理
「アプリ追加、めんどう !!」開発者アプリ追加、めんどう」開発者
「導入が大変」サーバー管理者
まだまだありますよね
なぜ、「動き続けて」と願うのでしょうか
なぜ、メンテナンスが大変なのでしょうか
なぜアプリ開発に時間とお金がかかるのでしょうか
なぜ、アプリ開発に時間とお金がかかるのでしょうか

こんな課題からも困た
データベースに期待すること
こんな課題からも困った
• DBサーバ乱立でハードやソフトの保守費、光熱費や場所代が増加
• クラスタのスタンバイ機など遊休リソースが多い
コスト削減
• 災害対策を行う場合DBサーバが乱立したままではお金と手間かかる
• セキュリティレベルやポリシーがバラバラで、可用性が均一では無い
リスク低減
• 台数増加でバックアップやパッチ対応など運用負荷やスタッフが増大
• DBサーバが老朽化して性能や拡張性の限界
サービス品質向上
DBサバ構築時間が長く負荷に応じた迅速なリソス配分も困難• DBサーバ構築時間が長く、負荷に応じた迅速なリソース配分も困難
• データも分断され組織や業務変更などへの迅速な対応が困難
俊敏性の向上
• 合併や事業統合への対応
コンペリングイベント
• 保守切れ、リース切れ
コンペリングイベント

他DBMSとのダウンタイムの比較
データベース可用性に関する実績やはり
止まる !!
＜あるDBMSの User Groupの調査結果＞
他DBMSとのダウンタイムの比較止まる !!
• 1年間のうちに、ユーザーの 90% はシステムダウンを経験
• そのうち、25% は10時間以上復旧せず
部 24時間以上渡ダウた事例もあ
＜N St サバ継続性＞
• 一部では24時間以上に渡りシステムダウンしていた事例もあり
＜NonStop サーバー継続性＞
• NonStop SQL のシステムダウンタイム発生率（実績）は、年間 0.026%
上記DBの約 3500倍の可用性

H/Wへの回帰が始まる
「止めない努力」人手でがんばるか、H/Wに任せるか
H/Wへの回帰が始まる
• サーバーの連続稼働はサービス提供の一部
• サーバーの連続稼働を人手で維持するか、H/Wに頼るか
コスト
H/WH/W
人件費品質を下げて
革新を求めて
品質を下げて
時間

ビジネスリスクを極小化するHP I t it N St S
安心できるミッションクリティカルシステムを
ビジネスリスクを極小化するHP Integrity NonStop Server
■ビジネスチャンスを逃さない！いかなる状況にも NonStop
• 35年以上の実績を誇る「NonStop」なアーキテクチャーで無停止を実現p
• ハードウェアの障害やメンテナンス、ソフトウェア障害などでも止まらない
■将来への備えも万全！必要な時に、ほぼ無限に拡張可能
• 増設が必要な際に、随時オンラインでシステムを拡張可能
• 最大4,080プロセッサ構成まで直線的な性能向上。DB もオンラインで拡張可能
■使って安心！数多くのミッションクリティカルシステム事例
• クレジットカード決済、携帯電話メッセージインフラ、企業間EDIなど数多くの実績
• 国内に20年間一度もシステム停止を経験していない顧客もあり
■誰でも簡単！オープン環境での容易なシステム開発・運用
• 無停止の仕組みは、プラットフォームで吸収（クラスタ等の設計や作り込みが不要）
• POSIX や ANSI 準拠のAPI、 Java の開発フレームワークもサポート
• クラスタとは異なり、１台で無停止を実現するため、運用管理もシンプル
HP Integrity NonStop
NBシリーズ

1) すべてのH/Wパツが標準で2重化以上の構成
NonStop Server 無停止実現のアーキテクチャー
1) すべてのH/Wパーツが標準で2重化以上の構成
HWパーツの冗長構成＋
障害箇所を局所化できる構成
CPU#0
Core
Takwila
CPU#1
Core
Takwila
CPU#2
Core
Takwila
CPU#3
Core
Takwila
POWER
POWER
POWER
POWER
POWER
POWER
CPUの
多重化
電源の
多重化
• 全てのHWは標準構成で2重化もしく
は多重化されている。
• プロセッサ、 I/Oコントローラ、I/Oデ
バイスは互いに電気的に独立してお MEM
Core
Core
Core
MEM
Core
Core
Core
MEM
Core
Core
Core
MEM
Core
Core
Core
POWER
FAN
FAN
FAN
FAN
FAN
FAN
FAN
FAN
FANの
多重化
バイスは互いに電気的に独立してお
り、ServerNetという高速システム内
ネットワークに接続されている。
• I/Oはディスクストレージ、ネットワー
クそれぞれ専用のコントロラを疎
MEM
ServerNetServerNet
SvNet
ServerNet
MEM
SvNet
MEM
SvNet
MEM
SvNet
FAN
FAN
FAN
FAN
システムバス
の2重化
クそれぞれ専用のコントローラを疎
結合で配置。
• NonStop OS はプロセッサごとにコ
ピーが分散稼働。メッセージング連
携によりシングルシステムとして動作
Storage
CLIM
LAN
Storage
CLIM
IP
CLIM
IP
CLIM
ALERM
ALERM
IO装置の
多重化
DISKの
Network
の2重化
自動通報
の2重化
携によりシングルシステムとして動作 DISKの
ミラー化

2) ソフトウアに組み込まれた無停止機能
2) ソフトウェアに組み込まれた無停止機能
プロセスペア技術による
基本ソフトウェアの無停止化
CPU 0 CPU 1 CPU 2 CPU 3
PrimaryBackup PrimaryBackup
• フェイルオーバー（再起動）ではなく、テイク
オーバー（処理継続）がコンセプト
• NonStop OS や、基幹ミドルウェアは、すべ
てプロセスペアにて実装
• 2CPUに 2プロセスがペアとして存在する
Primary Backup
Primary Backup Primary Backup
2CPUに、2プロセスがペアとして存在する
• 実稼動するのは、Primaryプロセスのみ
• Backupプロセスは継続に必要となる情報を
Primaryプロセスから定期的に受信
• 論理的には、1プロセスとして扱える
プセの異常終了やダウ
CPU 0 CPU 1 CPU 2 CPU 3
CPU
障害
• Primaryプロセスの異常終了や、CPUダウン
が起きると、自動的にBackupがPrimaryに
昇格して、ダウン直前の状態から処理を継
続実行する
• データの整合性もトランザクション保護製品
により自動的に一貫性を保持
Primary
Primary
Primary
PrimaryBackup
Primary Backup
により、自動的に貫性を保持 Primary

3) 拡張や交換 DBメンテもすべてオンラインで運用
3) 拡張や交換、DBメンテもすべてオンラインで運用
• オンラインでH/Wの増設が可能
– 最大で4080CPUまで拡張可能
NICやDISKだけでなく CPUまでもがオ
すべてのH/Wが無停止交換
• NICやDISKだけでなく、CPUまでもがオ
ンライン中に増設可能
• 障害発生時は無停止で該当コンポー
ネントを交換
CPUを含む全てのコンポネントが
NIC/FC
カード
– CPUを含む全てのコンポーネントが
サービスを停止することなく交換が
可能
• データベースもオンライ中にメンテ可
能
プロセッサ
ディスク
能
– DBの再編成や再配置など
– バックアップもすべてオンライン中
に
パワーサプライ
ServerNet
ServerNet
（内部バス）
ファンパワーサプライ

「直線的な拡張性」リソスを足せば足しただけ線形にスケルアウト
NonStop Serverの特徴
「直線的な拡張性」～リソースを足せば足しただけ線形にスケールアウト
シェアード・ナッシング構造のためCPUと
DISKのセットを追加するだけで比例的
に性能がスケル
CPU#0
Takwila
CPU#1
Takwila
CPU#2
Takwila
CPU#3
Takwila
Add-on
CPU#4
Takwila
CPU#5
Takwila
Add-on
に性能がスケール
• シェアしているH/W要素やS/Wモジュールが、一般
的なサーバーと比較して極端に少ないため、増設
によるオバヘド増が無視できる
MEM
Core
Takwila
MEM
Core
Takwila
Core CoreCore Core
Core Core
SvNet SvNet
MEM
Core
Takwila
MEM
Core
Takwila
Core CoreCore Core
Core Core
SvNet SvNet
MEM
Core
Takwila
MEM
Core
Takwila
Core CoreCore Core
Core Core
SvNet SvNet
によるオーバーヘッド増が無視できる
• CPU同士のメッセージ通信は、ServerNetの専用
ASICチップが制御するため、メインのCPUやメモリ
への負荷を軽減
• 将来のトランザクション量の伸びに対するキャパ
SvNet SvNet SvNet SvNet SvNet SvNet
• 将来のトランザクション量の伸びに対するキャパ
シティープランが容易
• CPUの数が増えても、ユーザーからは1つのサー
バーとして見えるので、運用負荷も変わらない
• 増設時の既存業務への影響は僅少
処理
性能
(TPS)
2CPU 4CPU 6CPU
増設時の既存業務の影響は僅少
リソース (CPU)

他DBでは実現できないことがN St SQLでは実現可能です
HP NonStop SQLの4大特徴
他DBでは実現できないことがNonStop SQLでは実現可能です
24h×365日絶対的な高可用スケールアウトが容易なDB
• NonStop ServerとNonStop OSが実現する高い
可用性をそのまま受け継いだNonStop SQL
•1台のサーバのみで、他では実現できない可用性
を提供
• NonStop Serverの特徴であるシェアード・ナッシ
ング・コンセプトを活かした超並列データベース
• HWリソースを足せば足しただけ直線的に性能の
増加が期待できる
運用負荷が軽減→TCO削減
立すバを台が能
安心のサポート体制
ま• 乱立するDB/周辺サーバを1台にコンソリが可能
• バージョンUP時は上位コンパチをhpが保証
• HW増設・交換、DBバックアップや再編成など
ほぼすべての作業がオンライン中に可能
• HWからOS、DBMS、JVMやFrameworkまで、
すべてhpによる1社サポートを実現
• 問題発生時の切り分けや原因追求がスムースに

日本ヒレットパッカドがインメモリを語るセッション
未来に出会える次のセッションご紹介
三宅祐典
日本ヒューレット・パッカードがインメモリーを語るセッション
[CORE TECH] Hardware
HDDからインメモリーテクノジーへ
6⽉20⽇ A34
15:00 15:50
インメモリーデータベースの時代は確実にやってきています。HPは現在の業界の動きと2020年までに実現を
⽬指す技術をご紹介。また、今導⼊できるS/W技術を最適に実装できるコンピューター、サーバーをご紹介し
ます。インメモリーテクノロジーはS/W技術と、H/W技術の双⽅が⾼度に融合して実現します。あなたも近未
来を体感してみませんか。
Software (Database System) Perspective
15:00-15:50
⼩森博之
Software (Database System) Perspective
Hardware Perspective
Future Technology
[CORE TECH] Hardware
インメモリーデータベース徹底⽐較
6⽉20⽇ D35
⼩森博之
すべてのデータをメモリー上で処理するアーキテクチャーを備えたデータベースシステムが今脚光を浴びてい
ます。独SAPの「Hana」を始め、⽶マイクロソフトが「SQL Server 2014」で実装し、⽶Oracleが次期バージョ
ンで追随します。それぞれ実装技術は異なり、何を選択したらいいのか、またその⾼速性ゆえ、「リアルタイ
ム処理」も期待され、ますます悩み多きとなりました。そんな皆様のご要望にそれぞれの製品を徹底的に⽐較
インメモリーデータベース徹底⽐較
16:00-16:50
ム処理」も期待され、ますます悩み多きとなりました。そんな皆様要望にそれぞれ製品を徹底的に⽐較
し、得意、不得意を明らかにします。またコンピュータシステムとの親和性も忘れてはいけません。コン
ピューターメーカーの視線も交え、事例を織り交ぜつつご紹介します。

後藤宏
プリセールス統括本部
サーバー技術本部
サーバー技術二部部長
hiromu.goto@hp.com
直通 050 3138 0848 携帯 090 8770 0963直通 050 3138 0848 携帯 090 8770 0963
FAX 03 5628 2698
日本ヒューレット・パッカード株式会社
本社
〒136‐8711〒136‐8711
東京都江東区大島2‐2‐1
Thank you!
T n y !

[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto

[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Destaque

Destaque(12)

Similar a [D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto

Similar a [D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto(20)

Mais de Insight Technology, Inc.

Mais de Insight Technology, Inc.(20)

Último

Último(8)

[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto