Your SlideShare is downloading. ×
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)

1,369
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,369
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 近年、大量データにおける分析需要の高まりから様々な製品およびプロジェクトが誕生 また、商用大手ベンダーも列指向と行指向のハイブリッド化を進めているCommercialSybase IQAster DataVerticaGreenplumVectorWiseBigTableFree or OpenInfiniDB CEMonetDB x100LucidDB 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 Date1ブロックには様々な 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 submitted100GB DELL Dell PowerEdge R610 303,289 VectorWise 1.6 05/23/11300GB DELL Dell PowerEdge R910 400,931 VectorWise 1.6 05/03/111,000GB DELL Dell PowerEdge R910 436,788 VectorWise 1.6 05/03/113,000GB ORACLE Sun SPARC Enterprise 386,478 Oracle 11g EE with 03/22/11 M9000 Server Partitioning10,000GB HP HP Integrity 208,457 Oracle 11G EE 03/10/08 Superdome/Dual-Core Itanium2/1.6Ghz30,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 latencyMonetDB: A high performance database kernel for query-intensive applications 9http://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-2MB150-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) × 1Mem: 8GB VS. Mem: 8GB 1TB × 1 1TB × 1 13
  • 14. 処理 10000 サイズ 35000時間 (MB) 32768(秒) 9000 約 8590 30000 1 / 8000 2 に 7000 25000 圧 縮 6000 約 20000 1 17899 5000 6 倍 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) × 1Mem: 8GB VS. Mem: 8GB プット 1TB × 1 64GB × 2(RAID0) 15
  • 16. 1009080 案の定、Disk I/O waitにより70 CPUリソースが使用されない60 状況になっている(idle) idle50 io/wait system40 user302010 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. 10090807060 idle50 io/wait Disk I/O waitの改善により system40 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 約 と 1 更 5000 6 300 に 倍 約 4000 の 6 性 倍 200 3000 能 向 2000 上 100 91 1000 533 0 0 RDBMS X Vectorwise Vectorwise VectorWise(SSD) 18
  • 19. 処理 10000 処理 10000時間 時間(秒) (秒) 9000 9000 8590 8590 8000 9 RDBMS X 8000 6 7000 7000 倍 の 6000 約 6000 性 1 能 と 5000 6 向 比 上 較 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