1. ひとつのデータベース技術だけでは生き残れない
- カラムナー・データベース 編 -
Insight Technology, Inc.
新久保 浩二
1

2. 1. Insight Qubeなる新プロダクト開発中
2. おら オラ Oracle どっぷり検証生活
2. Oracle ACE
3. @kouji_s_0808
4. JPOUG(Japan Oracle User Group)
本日はOracle以外の話です。
本資料に使用されている社名、ロゴ、製品、サービス名およびブランドは、該当する各社の登
録商標または商標です。本資料の一部あるいは全体について、許可なく複製および転載するこ
とを禁じます。
2

3. History
‘70s RDBMS黎明期から開発は行われている
’76 カナダ統計局の RAPID (カナダの国勢調査および統計的処理システム)
* 80年代には世界中でRAPIDが共有され、90年代まで使用された(wikipedia)
’00 長年、Sybase IQが商用のColumnar Databaseとして存在
NOW 近年、大量データにおける分析需要の高まりから様々な製品およびプロジェクトが誕生
また、商用大手ベンダーも列指向と行指向のハイブリッド化を進めている
Commercial
Sybase IQ
Aster Data
Vertica
Greenplum
VectorWise
BigTable
Free or Open
InfiniDB CE
MonetDB
x100
LucidDB
3

4. • 列指向とは?
• メリットは?
(シーケンシャルな)アクセス効率 + データ圧縮 = 分析基盤に向いている
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
1ブロックには様々な 1ブロックには同様の
タイプのデータが格納 タイプのデータが格納
されているので圧縮効 されているので圧縮効
率を上げにくい 率を上げやすい
4

5. • デメリットは?
一般的に
(ランダムな)アクセスが非効率 + データ圧縮 = OLTP基盤に向いていない
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
Prod ID Prod Name Date Prod ID Prod Name Date
更新時に圧縮・展開
のオーバーヘッドが
大きい(*1)
(*1) 圧縮のデメリットはカラムナーデータベースに限った話ではありません 5

6. Ingres (現 ACTIAN)が自社のIngresをベースに開発
列指向データベースのアイデア自体は、Open SourceのMonetDBのx100
プロジェクトがベースになっていると思われる。
MonetDBはオランダのCWI(Centrum Wiskunde & Infomatica)にてオー
プンソースで開発されている。なかでもI/Oディペンドな処理をCPUディ
ペンドに追い込み、またCPU処理の中でもメモリ処理を極限まで効率化さ
せるx100(Times Hundred)という意欲的なプロジェクトが誕生している。
MonetDB(およびx100)とVectorWiseは、そのアーキテクチャに多くの類
似点が見られる。
6

7. TPC-H Non-Clustered Results(2011/10/13)
(http://www.tpc.org/tpch/results/tpch_perf_results.asp?resulttype=noncluster&version=2%&currencyID=0)
Size Company System QphH Database Data submitted
100GB DELL Dell PowerEdge R610 303,289 VectorWise 1.6 05/23/11
300GB DELL Dell PowerEdge R910 400,931 VectorWise 1.6 05/03/11
1,000GB DELL Dell PowerEdge R910 436,788 VectorWise 1.6 05/03/11
3,000GB ORACLE Sun SPARC Enterprise 386,478 Oracle 11g EE with 03/22/11
M9000 Server Partitioning
10,000GB HP HP Integrity 208,457 Oracle 11G EE 03/10/08
Superdome/Dual-Core
Itanium2/1.6Ghz
30,000GB HP HP Integrity 150,960 Oracle 10gR2 EE 06/18/07
Superdome/Dual-Core
Itanium2/1.6Ghz
7

8. VectorWiseはDWHへ最適化が図られている。
- CPUベクトル演算
- パラレル処理
- 列指向
- ストレージインデックス
- データ圧縮
- CPUキャッシュ最適化
8

9. 50% up/year:
- cpu speed
- mem size
- mem bandwidth
- disk bandwidth
1% up/year:
- mem latency
10% up/year:
- disk latency
MonetDB: A high performance database kernel for query-intensive applications
9
http://monetdb-xquery.org/Assets/monetdb_lecture.pdf

10. CPU Speed(Cores)
- パラレル処理によるCPU(Core)の有効活用
- CPUのベクトル処理の活用
- SSE(Streaming SIMD拡張命令)
- 複数レジスタのパラレル処理による単一命令での一括処理
(演算幅は128bit、Sandy Bridgeからは256bit)
- 文字列処理での効果が大きい(characterだと16～32個の同時処理)
1×1=1 1×1 1
2×2=4 2×2 4
3×3=9 3×3 = 9
… … …
n × n = n^2 n×n n^2
10

11. Disk Latency
- 列指向ストレージアーキテクチャーによるシーケンシャルI/Oの最適化
- 圧縮によるディスクI/Oの低減(圧縮/展開はベクター処理)
- (列指向)格納ブロック単位で動的なインデクシング
- データブロック毎に最大値、最小値を自動メンテナンス
- スキャン候補となるデータブロックを効率よく抽出
- “パーティショニングに似ている”
11

12. Memory Latency
- L1/L2キャッシュアクセスの最適化によるメインメモリーへのアクセスを
低減(および最適化)
- 全てのベクトルがCPUキャッシュに収まるよう実行計画を最適化
Latency
Latency Throughput
10-15
million DISK 10-15ms 40-100MB/s
RAM 150-200ns 2-3GB/s
Cache 2-20ns 10GB/s
CPU Cache size
Xeon 512KB/1-2MB
150-250 Xeon 50X0 4MB
Xeon 33X0 8 – 12MB
2-20 Xeon 75XX 12 – 24MB
40-100MB 2-3GB 10GB Throughput
12

13. TPC-H Power Test (www.tpc.org) @SF=32
主にDWH処理をモデル化したベンチマーク。集計関数によるI/O
ディペンドな処理になっているのが特徴。
今回は、TPC-HのPower Test(1セッションで22種類のSQLを実
行し速度を測る)を実施。
VectorWise 1.6 (列指向) RDBMS X (行指向)
3.3Ghz(6core) × 1 3.3Ghz(6core) × 1
Mem: 8GB VS. Mem: 8GB
1TB × 1 1TB × 1
13

14. 処理 10000 サイズ 35000
時間 (MB) 32768
(秒)
9000
約
8590
30000 １
/
8000 ２
に
7000
25000 圧
縮
6000
約 20000
１ 17899
5000 ６
倍 15000
4000 の
性
3000 能 10000
向
2000
上
5000
1000
533
0 0
RDBMS X Vectorwise Original(MB) Compress(MB)
14

15. Columnar DatabaseがディスクI/OボトルネックをCPUボトル
ネックへなるように最適化しても、最終的にはディスクI/Oは必
須。最高の処理速度を得るには高速なディスクI/Oの設計が大切
VectorWise 1.6 (列指向) VectorWise 1.6 (列指向)
1TBのHDDに比べ
3.3Ghz(6core) × 1 8倍程度のスルー
3.3Ghz(6core) × 1
Mem: 8GB VS. Mem: 8GB プット
1TB × 1 64GB × 2(RAID0)
15

16. 100
90
80
案の定、Disk I/O waitにより
70 CPUリソースが使用されない
60
状況になっている(idle)
idle
50 io/wait
system
40
user
30
20
10
0
Q01 Q02 Q03 Q04 Q05 Q06 Q07 Q08 Q09 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22
16

17. 100
90
80
70
60
idle
50 io/wait
Disk I/O waitの改善により system
40
user
CPUリソースが使用され
30
VectorWise本来の力が発揮
20 されるようになった
10
0
Q01 Q02 Q03 Q04 Q05 Q06 Q07 Q08 Q09 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22
17

18. 処理 10000 処理 600
時間 時間
の
SSD
(秒) (秒)
533
9000
8590
性
500 能 に
8000
向 変
上 更
7000
400
。 す
る
6000
約 と
１ 更
5000 ６ 300 に
倍 約
4000 の ６
性 倍
200
3000 能
向
2000
上
100 91
1000
533
0 0
RDBMS X Vectorwise Vectorwise VectorWise(SSD)
18

19. 処理 10000 処理 10000
時間 時間
(秒) (秒)
9000 9000
8590 8590
8000
９
RDBMS X
8000
６
7000 7000 倍
の
6000
約 6000 性
１ 能 と
5000 ６ 向 比
上 較
5000
倍 し
4000 の 4000 て
性
3000 能 3000
向
2000
上 2000
1000 1000
533 533
91
0 0
RDBMS X Vectorwise RDBMS X Vectorwise VectorWise(SSD)
19

20. • データベースが多機能化する中、特徴を絞りエッジの効いた製品
も多く見られる
• 特に大量データに対する取り組みは現時点の課題であり、様々な
アプローチ(データベース)が存在する
• データベースは用途により、正しく選択する必要性が、再び重要
になった
• 正しい選択には、ソフトウェアだけでなく、ハードウェアの進化
も考慮する必要がある
• 今後の動向もさることながら、この古くて新しい分野に挑戦しな
いという選択肢はない
20

21. 21