Enviar búsqueda
Cargar
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
•
3 recomendaciones
•
2,863 vistas
Insight Technology, Inc.
Seguir
Denunciar
Compartir
Denunciar
Compartir
1 de 55
Descargar ahora
Descargar para leer sin conexión
Recomendados
ヤフー発のメッセージキュー「Pulsar」のご紹介
ヤフー発のメッセージキュー「Pulsar」のご紹介
Yahoo!デベロッパーネットワーク
Ethernetの受信処理
Ethernetの受信処理
Takuya ASADA
Apache Hadoop & Hive 入門 (マーケティングデータ分析基盤技術勉強会)
Apache Hadoop & Hive 入門 (マーケティングデータ分析基盤技術勉強会)
Takeshi Mikami
その ionice、ほんとに効いてますか?
その ionice、ほんとに効いてますか?
Narimichi Takamura
Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状
NTT DATA OSS Professional Services
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
Yahoo!デベロッパーネットワーク
Oracle GoldenGate アーキテクチャと基本機能
Oracle GoldenGate アーキテクチャと基本機能
オラクルエンジニア通信
試して覚えるPacemaker入門 『リソース設定編』
試して覚えるPacemaker入門 『リソース設定編』
健太 松浦
Recomendados
ヤフー発のメッセージキュー「Pulsar」のご紹介
ヤフー発のメッセージキュー「Pulsar」のご紹介
Yahoo!デベロッパーネットワーク
Ethernetの受信処理
Ethernetの受信処理
Takuya ASADA
Apache Hadoop & Hive 入門 (マーケティングデータ分析基盤技術勉強会)
Apache Hadoop & Hive 入門 (マーケティングデータ分析基盤技術勉強会)
Takeshi Mikami
その ionice、ほんとに効いてますか?
その ionice、ほんとに効いてますか?
Narimichi Takamura
Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状
NTT DATA OSS Professional Services
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
Yahoo!デベロッパーネットワーク
Oracle GoldenGate アーキテクチャと基本機能
Oracle GoldenGate アーキテクチャと基本機能
オラクルエンジニア通信
試して覚えるPacemaker入門 『リソース設定編』
試して覚えるPacemaker入門 『リソース設定編』
健太 松浦
Oracle Cloud Infrastructure:2023年2月度サービス・アップデート
Oracle Cloud Infrastructure:2023年2月度サービス・アップデート
オラクルエンジニア通信
Oracle GoldenGate Veridata概要
Oracle GoldenGate Veridata概要
オラクルエンジニア通信
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
OpenStackをコマンドで攻める! 構築・運用とトラブル解決 - OpenStack最新情報セミナー 2014年6月
OpenStackをコマンドで攻める! 構築・運用とトラブル解決 - OpenStack最新情報セミナー 2014年6月
VirtualTech Japan Inc.
DataGuard体験記
DataGuard体験記
Shinnosuke Akita
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
ksk_ha
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
NTT DATA Technology & Innovation
Linux-HA Japanプロジェクトのこれまでとこれから
Linux-HA Japanプロジェクトのこれまでとこれから
ksk_ha
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
Satoshi Shimazaki
Kafka vs Pulsar @KafkaMeetup_20180316
Kafka vs Pulsar @KafkaMeetup_20180316
Nozomi Kurihara
Oracle GoldenGateでの資料採取(トラブル時に採取すべき資料)
Oracle GoldenGateでの資料採取(トラブル時に採取すべき資料)
オラクルエンジニア通信
ロードバランスへの長い道
ロードバランスへの長い道
Jun Kato
Ws2012フェールオーバークラスタリングdeep dive 130802
Ws2012フェールオーバークラスタリングdeep dive 130802
wintechq
PostreSQL監査
PostreSQL監査
NTT DATA OSS Professional Services
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
Takashi Takizawa
新機能によるデータベースシステムの改善ポイント
新機能によるデータベースシステムの改善ポイント
オラクルエンジニア通信
オラクルのHPC/GPUソリューションご紹介(2021/08版)
オラクルのHPC/GPUソリューションご紹介(2021/08版)
オラクルエンジニア通信
Pacemakerを使いこなそう
Pacemakerを使いこなそう
Takatoshi Matsuo
Azure ADと外部アプリのID連携/SSO - Deep Dive
Azure ADと外部アプリのID連携/SSO - Deep Dive
Naohiro Fujie
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
情報技術の基本と仮想化について
情報技術の基本と仮想化について
rookwin
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
Sunao Tomita
Más contenido relacionado
La actualidad más candente
Oracle Cloud Infrastructure:2023年2月度サービス・アップデート
Oracle Cloud Infrastructure:2023年2月度サービス・アップデート
オラクルエンジニア通信
Oracle GoldenGate Veridata概要
Oracle GoldenGate Veridata概要
オラクルエンジニア通信
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
OpenStackをコマンドで攻める! 構築・運用とトラブル解決 - OpenStack最新情報セミナー 2014年6月
OpenStackをコマンドで攻める! 構築・運用とトラブル解決 - OpenStack最新情報セミナー 2014年6月
VirtualTech Japan Inc.
DataGuard体験記
DataGuard体験記
Shinnosuke Akita
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
ksk_ha
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
NTT DATA Technology & Innovation
Linux-HA Japanプロジェクトのこれまでとこれから
Linux-HA Japanプロジェクトのこれまでとこれから
ksk_ha
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
Satoshi Shimazaki
Kafka vs Pulsar @KafkaMeetup_20180316
Kafka vs Pulsar @KafkaMeetup_20180316
Nozomi Kurihara
Oracle GoldenGateでの資料採取(トラブル時に採取すべき資料)
Oracle GoldenGateでの資料採取(トラブル時に採取すべき資料)
オラクルエンジニア通信
ロードバランスへの長い道
ロードバランスへの長い道
Jun Kato
Ws2012フェールオーバークラスタリングdeep dive 130802
Ws2012フェールオーバークラスタリングdeep dive 130802
wintechq
PostreSQL監査
PostreSQL監査
NTT DATA OSS Professional Services
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
Takashi Takizawa
新機能によるデータベースシステムの改善ポイント
新機能によるデータベースシステムの改善ポイント
オラクルエンジニア通信
オラクルのHPC/GPUソリューションご紹介(2021/08版)
オラクルのHPC/GPUソリューションご紹介(2021/08版)
オラクルエンジニア通信
Pacemakerを使いこなそう
Pacemakerを使いこなそう
Takatoshi Matsuo
Azure ADと外部アプリのID連携/SSO - Deep Dive
Azure ADと外部アプリのID連携/SSO - Deep Dive
Naohiro Fujie
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
La actualidad más candente
(20)
Oracle Cloud Infrastructure:2023年2月度サービス・アップデート
Oracle Cloud Infrastructure:2023年2月度サービス・アップデート
Oracle GoldenGate Veridata概要
Oracle GoldenGate Veridata概要
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
OpenStackをコマンドで攻める! 構築・運用とトラブル解決 - OpenStack最新情報セミナー 2014年6月
OpenStackをコマンドで攻める! 構築・運用とトラブル解決 - OpenStack最新情報セミナー 2014年6月
DataGuard体験記
DataGuard体験記
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
Linux-HA Japanプロジェクトのこれまでとこれから
Linux-HA Japanプロジェクトのこれまでとこれから
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
Kafka vs Pulsar @KafkaMeetup_20180316
Kafka vs Pulsar @KafkaMeetup_20180316
Oracle GoldenGateでの資料採取(トラブル時に採取すべき資料)
Oracle GoldenGateでの資料採取(トラブル時に採取すべき資料)
ロードバランスへの長い道
ロードバランスへの長い道
Ws2012フェールオーバークラスタリングdeep dive 130802
Ws2012フェールオーバークラスタリングdeep dive 130802
PostreSQL監査
PostreSQL監査
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
新機能によるデータベースシステムの改善ポイント
新機能によるデータベースシステムの改善ポイント
オラクルのHPC/GPUソリューションご紹介(2021/08版)
オラクルのHPC/GPUソリューションご紹介(2021/08版)
Pacemakerを使いこなそう
Pacemakerを使いこなそう
Azure ADと外部アプリのID連携/SSO - Deep Dive
Azure ADと外部アプリのID連携/SSO - Deep Dive
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
Destacado
情報技術の基本と仮想化について
情報技術の基本と仮想化について
rookwin
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
Sunao Tomita
Multiple Sites and Disaster Recovery with Ceph: Andrew Hatfield, Red Hat
Multiple Sites and Disaster Recovery with Ceph: Andrew Hatfield, Red Hat
OpenStack
[中1英語] 01_英語の勉強の仕方
[中1英語] 01_英語の勉強の仕方
curio-e
オペレーティングシステム 第2回-公開用
オペレーティングシステム 第2回-公開用
Ruo Ando
第三回ネットワークチーム講座資料
第三回ネットワークチーム講座資料
densan_teacher
情報システム系
情報システム系
Hagihara Ryosuke
Scis2017 2007-01-27-02
Scis2017 2007-01-27-02
Ruo Ando
情報セキュリティと標準化I 第1回-公開用
情報セキュリティと標準化I 第1回-公開用
Ruo Ando
基本情報技術者試験 勉強会
基本情報技術者試験 勉強会
Yusuke Furuta
4_C言語入門 - n進数と基数変換について
4_C言語入門 - n進数と基数変換について
bc_rikko
講演資料 201606 web公開版
講演資料 201606 web公開版
Ruo Ando
オペレーティングシステム 第1回-公開用
オペレーティングシステム 第1回-公開用
Ruo Ando
How to use continuous improvement kungfu to pay down technical debt - Kevin B...
How to use continuous improvement kungfu to pay down technical debt - Kevin B...
Devopsdays
kagami_comput2015_1
kagami_comput2015_1
swkagami
Web 2.0
Web 2.0
Oliver Centeno
12_C言語入門 - 読みやすいソースコードを書く
12_C言語入門 - 読みやすいソースコードを書く
bc_rikko
kagami_comput2016_12
kagami_comput2016_12
swkagami
10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage
10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage
Etsuji Nakai
kagami_comput2016_13
kagami_comput2016_13
swkagami
Destacado
(20)
情報技術の基本と仮想化について
情報技術の基本と仮想化について
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
Multiple Sites and Disaster Recovery with Ceph: Andrew Hatfield, Red Hat
Multiple Sites and Disaster Recovery with Ceph: Andrew Hatfield, Red Hat
[中1英語] 01_英語の勉強の仕方
[中1英語] 01_英語の勉強の仕方
オペレーティングシステム 第2回-公開用
オペレーティングシステム 第2回-公開用
第三回ネットワークチーム講座資料
第三回ネットワークチーム講座資料
情報システム系
情報システム系
Scis2017 2007-01-27-02
Scis2017 2007-01-27-02
情報セキュリティと標準化I 第1回-公開用
情報セキュリティと標準化I 第1回-公開用
基本情報技術者試験 勉強会
基本情報技術者試験 勉強会
4_C言語入門 - n進数と基数変換について
4_C言語入門 - n進数と基数変換について
講演資料 201606 web公開版
講演資料 201606 web公開版
オペレーティングシステム 第1回-公開用
オペレーティングシステム 第1回-公開用
How to use continuous improvement kungfu to pay down technical debt - Kevin B...
How to use continuous improvement kungfu to pay down technical debt - Kevin B...
kagami_comput2015_1
kagami_comput2015_1
Web 2.0
Web 2.0
12_C言語入門 - 読みやすいソースコードを書く
12_C言語入門 - 読みやすいソースコードを書く
kagami_comput2016_12
kagami_comput2016_12
10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage
10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage
kagami_comput2016_13
kagami_comput2016_13
Similar a [C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
Insight Technology, Inc.
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
Insight Technology, Inc.
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
Insight Technology, Inc.
[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作...
[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作...
Insight Technology, Inc.
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
Yahoo!デベロッパーネットワーク
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
日本ヒューレット・パッカード株式会社
[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~デ...
[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~デ...
Insight Technology, Inc.
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
Kazunori Sato
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
Insight Technology, Inc.
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクルエンジニア通信
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
ShuheiUda
Performance and Scalability of Web Service
Performance and Scalability of Web Service
Shinji Tanaka
[Modern Cloud Day Tokyo 2019] Oracle Cloud Infrastructure 基本サービス入門(1) - Netwo...
[Modern Cloud Day Tokyo 2019] Oracle Cloud Infrastructure 基本サービス入門(1) - Netwo...
オラクルエンジニア通信
20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10
Kohei KaiGai
Oracle Exadata MAA - Platinum層特化版プレゼンテーション
Oracle Exadata MAA - Platinum層特化版プレゼンテーション
オラクルエンジニア通信
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#3
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#3
オラクルエンジニア通信
ヤフーを支えるフラッシュストレージ
ヤフーを支えるフラッシュストレージ
Yahoo!デベロッパーネットワーク
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
オラクルエンジニア通信
RDMA for Windows Server 2012
RDMA for Windows Server 2012
Naoto MATSUMOTO
Oracle Database Appliance X5-2 アップデート内容のご紹介
Oracle Database Appliance X5-2 アップデート内容のご紹介
オラクルエンジニア通信
Similar a [C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
(20)
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作...
[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作...
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~デ...
[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~デ...
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
Performance and Scalability of Web Service
Performance and Scalability of Web Service
[Modern Cloud Day Tokyo 2019] Oracle Cloud Infrastructure 基本サービス入門(1) - Netwo...
[Modern Cloud Day Tokyo 2019] Oracle Cloud Infrastructure 基本サービス入門(1) - Netwo...
20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10
Oracle Exadata MAA - Platinum層特化版プレゼンテーション
Oracle Exadata MAA - Platinum層特化版プレゼンテーション
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#3
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#3
ヤフーを支えるフラッシュストレージ
ヤフーを支えるフラッシュストレージ
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
RDMA for Windows Server 2012
RDMA for Windows Server 2012
Oracle Database Appliance X5-2 アップデート内容のご紹介
Oracle Database Appliance X5-2 アップデート内容のご紹介
Más de Insight Technology, Inc.
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
Insight Technology, Inc.
Docker and the Oracle Database
Docker and the Oracle Database
Insight Technology, Inc.
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Insight Technology, Inc.
事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する
Insight Technology, Inc.
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
Insight Technology, Inc.
MBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごと
Insight Technology, Inc.
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
Insight Technology, Inc.
DBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォーム
Insight Technology, Inc.
SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門
Insight Technology, Inc.
Lunch & Learn, AWS NoSQL Services
Lunch & Learn, AWS NoSQL Services
Insight Technology, Inc.
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉
Insight Technology, Inc.
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也
Insight Technology, Inc.
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
Insight Technology, Inc.
難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?
Insight Technology, Inc.
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Insight Technology, Inc.
そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?
Insight Technology, Inc.
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
Insight Technology, Inc.
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
Insight Technology, Inc.
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Insight Technology, Inc.
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
Insight Technology, Inc.
Más de Insight Technology, Inc.
(20)
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
Docker and the Oracle Database
Docker and the Oracle Database
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
MBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごと
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
DBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォーム
SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門
Lunch & Learn, AWS NoSQL Services
Lunch & Learn, AWS NoSQL Services
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
1.
db tech showcase
東京 2013 フラッシュドライブで挑む Oracle超高速化と信頼性の両立 2013/11/13 株式会社 日立製作所 ITプラットフォーム事業本部 © Hitachi, Ltd. 2013. All rights reserved.
2.
Contents 1. 従来のシステムの問題点 2. フラッシュを使った高速化 3.
フラッシュのシステムの信頼性 4. フラッシュドライブの活用 5. SSDとOracleの相性 6. RAC on SSD分析系SQLでの検証 7. 信頼性に関する検証 © Hitachi, Ltd. 2013. All rights reserved.
3.
0-1. DB高速化需要の高まり データの増加に伴い、処理時間が増加。これに伴い、 処理時間の短縮=DB高速化 が重要になりつつある。 DWHで抽出してる データが少な過ぎると 言われているが、 増やせば時間がかかる 朝までかかる夜間 バッチは、ハードを リプレースするだけで、 速くなるだろうか。 DB担当者 既存アプリは、今更 手を入れるなんて できないから DB自体を速くしないと 担当者のDB高速化の悩みは尽きない ©
Hitachi, Ltd. 2013. All rights reserved.
4.
1.従来のシステムの問題点 © Hitachi, Ltd.
2013. All rights reserved.
5.
1-1. H/Wの性能進化の不均衡 2005年を1とした時の性能推移 相対性能 25 24倍 8core 20 15 6core 10 10倍 5 2core 1 2005 2006 4倍 4core HDD回転数 2007 2008 2009 2010 2011 2012 1倍 ※CPU性能はSAP SDベンチ マークをベースにした値
CPU性能はコア数の増加と共に劇的に向上している。 CPU性能の伸びに比べ、HDD回転数やFC帯域は伸びていない システム構成は今でも2005年と同じ作りだが、それで良いのか © Hitachi, Ltd. 2013. All rights reserved. 5
6.
1-2. 2005年と同じ構成のシステムでは CPU,FC帯域,HDDの使用率の状況は (%) HDDの使用率は OSの性能モニタでは 直接表示されない 100 90 80 70 60 HDDの使用率が ボトルネックなのが 実は分かりにくい! 50 40 30 20 10 0 パーツ使用率のイメージ HDDは常に稼働し続けており、ほぼ100%張りつきの状態。
CPUはあまり稼働率が上がらず、底辺を這っている様な状態。 FCの帯域はまだまだ余裕があるが、CPUよりは使われている状態。 HDDの高速化を行えば、CPUをもっと有効に使えるようになる © Hitachi, Ltd. 2013. All rights reserved.
7.
1-3. HDDのデータリード処理の問題点 円盤に書かれたデータが来るまで待つ 要求 データ 要求 データ ャ ト シ ー 要求 データ ッ レ ュ ジ 要求 東京 12:00 28° 大阪 14:00 32° 名古屋 14:00 35° 7/9 甲府 13:00 37° 7/9 ス 気温 7/8 キ 時間 7/8 データベース サーバ 都市 7/8 アプリケーション サーバ 日付 京都 14:00 36° データ HDDは円盤にデータが記録されている。
円盤は1分間に15,000回転している。 目的のデータがヘッドまで来ると読み出せる。 例えば、 7/9の京都の最高気温が知りたい ヘッドの移動(データのあるトラックまで移動) 回転待ち(最大1回転:1/15,000分=1/250秒) つまりHDDは1秒間に最悪250件しか読めないから遅い。 © Hitachi, Ltd. 2013. All rights reserved.
8.
1-4. HDD I/O性能基本データ HDDはランダムアクセスが苦手 SAS
15,000回転/s, RAID5:4D+1P ブロックサイズ:512KB, 多重度:8 リード帯域性能 シーケンシャル ランダム 1 7.8 ライト帯域性能 シーケンシャル ランダム 1 19 © Hitachi, Ltd. 2013. All rights reserved.
9.
1-5. ストレージのアクセス種別について 業務処理の1日のアクセス状況 IOPS必要 夜(バッチ処理) 昼(オンライン) 夜 業務処理では、昼間はIOPSが必要で夜間は帯域が必要となる。 IOPSはまさにHDDの回転数に依存するので、HDDの本数が少ないと厳しい。 HDDはランダムアクセスの帯域が出ない為、バッチがランダムなら性能が出ない。 HDDで構成している限り、目に見える性能改善は難しい! ※グラフはストレージアクセスイメージです。 © Hitachi,
Ltd. 2013. All rights reserved.
10.
2.フラッシュを使った高速化 © Hitachi, Ltd.
2013. All rights reserved.
11.
2-1. ストレージI/Oの高速化には これからはFlashメモリー USBメモリー コンパクトフラッシュ SDカード ① 半導体なのでリード/ライトが速い CompactFlash
磁気記憶では無く、メモリーチップを使用して いる為、HDDより桁違いにリード/ライトが速い。 書 Flashの特徴として、ライトは上書きでは無く、 別の場所に書き、元の場所を無効化する。 ブロック内に無効領域が増えたらガーベッジ コレクションしてから消去する。 ② 容量がHDD並みとなってきた HDD互換のSSDでは数100GB~1TB超の デバイスが製品化されてきており、価格はHDD より割高だが性能が必要な状況で採用される 様になってきた。 込 み 済 空 き 1ブロック 領 域 (消去単位) 容量 年代 © Hitachi, Ltd. 2013. All rights reserved.
12.
2-2. SSDの特性 SSDとは HDD互換インターフェース(SATA/SAS)を装備 したFlashメモリー。パソコン用から始まり、今で は信頼性の高いエンタープライズ用もある。 SLCとMLC FlashにはSLCとMLCがあり、MLCの方がビッ ト単価が安く大容量化に向いているが、短寿命等 の弱点もある。しかし技術進歩でMLCでも信頼 性が上がってきている。 データ保持時間 Flashは不揮発性ではあるが、電源が無い状態 で長期放置を行うと、微量ながらも電荷が減って いく為、データが失われることがある。MLCの場 合は、3ヵ月以内には通電することを推奨。 SLC 0 1 荷 電 MLC 00 01 10 (2) 11 (3) © Hitachi,
Ltd. 2013. All rights reserved.
13.
2-3. SSDのパフォーマンス HDDよりもかなり高速 ランダムWRITE (7D+1P,
8KB)のIOPS相対比較 SAS HDD 1 15 SSD ランダムREAD (7D+1P, 8KB)のIOPS相対比較 SAS HDD SSD 1 61 ※性能・時間は構成/使用条件により異なる場合があります。 © Hitachi, Ltd. 2013. All rights reserved.
14.
2-4. SSDに変えるとどうなるか 今までのシステム構成は サーバからFCケーブルが2本ストレージ に接続されている。
HDDはRAID構成で組まれている。 サーバ1台(またはActive-Standby)の構成 ★単純にHDDをSSDに 置き換えただけだと... ストレージの内部バス帯域限界を超える。 コントローラーの処理性能が不足する FCポートの帯域限界を超える I/O待ちが無くなりCPUが忙しくなる サーバ P P P P P P コントローラ P P P P コントローラ RAID構成 ストレージ せっかくのSSDの高速性が、今までの構成では引き出せない! © Hitachi, Ltd. 2013. All rights reserved.
15.
2-5. 高速化を実現するハードウェア構成 ボトルネックを極力排除する Public LAN サーバは2台以上で Oracle
RAC構成に 可用性と性能を両立 処理能力が上がるため、 RACインターコネクトは、 10Gの冗長構成が必要 RAC Interconnect 10G LANSW 1G NIC 1G NIC 10G NIC Bonding 10G NIC Bonding 10G NIC F C F C F C F C 1G NIC Bonding 1G NIC Bonding サーバ F C F C 処理性能ネックを回避 する為にSSD数に 応じたコントローラ数を F C F C F C F C F C F C F C F C F C 8Gbps x 16 P 内部バスがボトルネック にならない様なSSDの スロット配置を行う 10G NIC サーバ F C FCはSSDの数に応じ 帯域を確保できる本数 並列性と可用性に効果 10G LANSW P P Ctrl0 P P P P P P Ctrl1 P P Ctrl2 P P P P P Ctrl3 ストレージ これが理想のSSDシステム © Hitachi, Ltd. 2013. All rights reserved.
16.
2-6. 複数LUへのDB配置 高速化構成の副作用 各LUにアクセスするFCポートを 固定化しOSとFCのキューを一 致させオーバーヘッドを削減。 しかしLUが複数になると、どの データをどのLUに割り当てるか 検討が必要になる。 検討不十分だとLUのデータ占 有量が不揃いになったり、アクセ ス頻度が偏る。 最悪本番稼働後に配置の見直し や、テーブル分割などを実施し なければならなくなる。 サーバ TableC TableA TableD TableB HBA (FCカード) FC 利用率 100% 0% LU 使い 過ぎ ストレージ 少な 過ぎ © Hitachi,
Ltd. 2013. All rights reserved.
17.
2-7. サイズやアクセス頻度の偏りの無いASM 複数LUをまとめて管理 TableA 複数LUをうまく使うには、 Oracle ASMを使用すること で対応が可能。 複数LUがストライピングされ、 全てのLUを均等に利用可能。 理想構成では全てSSDで統一 しており、最高のパフォーマン スを発揮可能。 TableC TableD HBA (FCカード) FC帯域も均等に利用でき、パ フォーマンスも向上。 遅いLUが混在していると性能 が引きずられ、DB全体が遅く なることがある。 TableB FC 利用率 100% 0% LU Oracle
ASM 最高のパフォーマンス © Hitachi, Ltd. 2013. All rights reserved.
18.
2-8. そのシステムを実現したのがこの構成! BladeSymphony BS2000 高信頼の日立ハイエンドブレードサーバ 10Gイーサネットファブリックスイッチ搭載可能 APサーバ、バックアップサーバ等も混載可能 I/Oスロット拡張装置(IOドロワ) サーバ当たり8本のPCI-Eスロットを追加 独立した管理プロセッサが状態を監視 I/Oケーブル断でもサーバが落ちない可用性 8Gb/s×16 Hitachi
Unified Storage 100 ・・・ 200/400/800GB SSD SSD搭載前提の高性能コントローラ搭載 帯域ネックになりにくい高速バックエンドパス ShadowImageやTrueCopyバックアップ機能 (筺体内ボリュームコピー) (筺体間コピー) データリードで 11GB/sの I/O処理を確認。 © Hitachi, Ltd. 2013. All rights reserved.
19.
3.フラッシュのシステムの信頼性 © Hitachi, Ltd.
2013. All rights reserved.
20.
3-1. SSDの寿命について SSDの寿命とは SSDはデータ書き込み時に電子が移動することで半導体が劣化し、書き込み回数上 限を決めている。200GBのSSDの場合3.6PBの書き込みが上限である。 ※3.6PBは日立採用のSSDの場合 SSDの書き込み限界 SSDではRAIDの場合、構成本数と書込み量で寿命が決まる SSD 1本の書き込み上限 (2D+1P)*4組での合計書込み上限 1日で書き込める容量 1秒で書き込める容量 値 3,600TB/5年 28,800TB/5年 備考 5年でこの値に達すると仮定 200GB×8本分=1.6TB 15,781GB/日 182MB/s 約16TB/日 ※寿命まで絶対故障しないということではありません 全容量1.6TBを1日10回全て書き替えても、5年間使えます。 上限値通知や対応も SSDの書き込み容量が寿命の90%(&95,96,97,98%)に達すると通知を出します。 更に99%になるとスペアへデータをコピーし、書き込みを継続するように備えます。 保守契約されていれば、万一期間内に寿命となったSSDは、無償交換します。 ©
Hitachi, Ltd. 2013. All rights reserved.
21.
3-2. ネットワークの可用性 忘れがちなネットワークも重要 SSDのシステムでは1Gbpsでは不足。10Gが必要 RACのインターコネクトは1Gでは不足。 1:1通信の場合Bondingでは帯域を増やせない。 直結は禁止なので2台のスイッチ(冗長)で接続 10G
LAN Port数は最低4port。もっと欲しい RACのインターコネクトとPublicで4port。 Active DataGuard専用Portも性能に有効 管理ネットワークも別セグメントで欲しい Public LANの可用性は いくつ? 仮想LA スパニングツリーで構成するのが良いのか。 リンクアグリゲーション(LA)なら相性問題はまずない。 複数スイッチでのLA機能(vPC, vLAG, MLAG)が旬。 グループ LA(bond) © Hitachi, Ltd. 2013. All rights reserved.
22.
3-3. サーバの信頼性 メーカーはどこでも一緒。では無い 障害発生頻度を減らすには 壊れやすい部品を使わない ⇒
壊れ易いかどうか判別するプロセスが必要。 部品の個体差による不具合品を排除する ⇒ 部品受け入れ時と完成後にも検査する。 万一の障害時の対応は 故障に対しては自動通報で迅速に対応。サービス拠点も日立なら全国至る所にある。 難しい問題切り分けや解析は、国内に技術者がいれば短期間で判明するもの。 © Hitachi, Ltd. 2013. All rights reserved.
23.
3-4. 障害発生頻度を極力減らすには 元々メインフレームでやっていた処理なんだけど... 開発検査 量産検査 ■外観検査 通電検査だけでは判ら ない異常を検出。 半田飛散 ■複合マージン試験 温度・電圧の組合せによる 過酷な環境による試験。 X線透視 観察装置 © Hitachi,
Ltd. 2013. All rights reserved.
24.
3-5. 万一の障害発生時に迅速な対応をするには 遠隔保守支援システムが自動通報を ~ユーザーエリア~ IP-VPN フ ァ イ ア VPN ルータ ウ ォ 監視通報装置 ー ル サポート センタ ユーザの負担作業 遠隔保守無 障害発生 遠隔保守有 障害切分 電話受付&問診 駆けつけ
ログ採取/解析 部品手配 保守作業 復旧 障害連絡 ログ解析 自動通報 駆けつけ 部品手配 保守作業 復旧 業務のダウン時間を短縮 © Hitachi, Ltd. 2013. All rights reserved.
25.
4.フラッシュドライブの活用 © Hitachi, Ltd.
2013. All rights reserved.
26.
4-1. エンタープライズ向けフラッシュストレージ DBにはどのフラッシュが向いているのか PCIフラッシュ フラッシュアレイ装置 少~中容量の シングルDBに 最適 中容量の DWHに 最適 フラッシュストレージの中では最も高速。 RAID構成はソフトウェアで実施。 共有ディスクとして使用できない。 稼働中のドライブ交換ができない。 PCIフラッシュの次に高速。 従来型ストレージと使い勝手同じ。 フラッシュデバイスのみで構成。 FCやInfiniBandインターフェース 共有ディスクとしても使用可能 従来型SANストレージ装置 中~大容量の OLTP/DWH に最適 SSDを搭載することで高速化。 DRAMキャッシュによるリード/ライトの高速化。 ストレージ内の各種オプション機能が豊富。 HDDとのハイブリッド構成による大容量化が可能。 © Hitachi,
Ltd. 2013. All rights reserved.
27.
4-2. SANストレージの利点 バックアップ/DRとコストパフォーマンス SSDでもボリュームコピーは必要 ストレージ間でのDR機能 フルバックアップならボリュームコピーは必須。
回復時間を重要視するならこれが最適。 ストレージ機能による遠隔データ コピーによりDRサイト構築が容易。 DBサーバ 正VOL バックアップ サーバ 副VOL ハイブリッド・ドライブ対応 大容量かつコストパフォーマンスを追求するには、 HDD混載が解決策。 ボリュームコピーの副ボリュームにはHDDが最適。 ニアラインドライブを使用すれば、二次バックアップ やアーカイブ用途も。 © Hitachi, Ltd. 2013. All rights reserved.
28.
4-3. フラッシュの価格は今後どうなるのか ビットコストの動向 デバイス技術動向調査結果(日立調べ) 各デバイスのビットコスト推移予想 ビットコスト($/GB) MLC SSDと SAS
HDDが 逆転する 数年後のリプレースにはSAS HDDは時代遅れとなる。 いつSSDを導入するか? 今でしょ! © Hitachi, Ltd. 2013. All rights reserved.
29.
4-4 日立ストレージのボリューム自動階層制御 HDDとのハイブリッドでも高速アクセス 仮想ボリューム サーバから見せるLU。 容量は将来を見据えた大き さに設定可能。 実データはプールの領域が 割り当てられる。 Tier1 Hitachi Dynamic Tiering Tier2 プール HDDやSSDからなる 物理ボリューム。 優先順位設定可能。 この例ではSSDを高い 優先順位に設定。 © Hitachi,
Ltd. 2013. All rights reserved.
30.
4-5. 日立自製フラッシュドライブ 大容量・超高速アクセス HAF(Hitachi Accelerated
Flash) SANストレージに最適なフラッシュ 1.6TBの大容量、高信頼、高性能フラッシュメモリドライブ レスポンス性能重視 適用拡大 キャッシュメモリ フラッシュドライブ SAS HDD SATA/ NL-SAS HDD ビットコスト重視 SSD(Solid State Drive)<他社OEM品> 高性能 HAF(Hitachi Accelerated Flash)<日立製> 高性能 高信頼 高機能 コストパフォーマンス 大容量/スケーラビリティ 日立はストレージシステムとフラッシュドライブの両方を自製 © Hitachi, Ltd. 2013. All rights reserved.
31.
4-6. HAFのパフォーマンス SSDよりもかなり高速 Hitachi Virtual
Storage Platform(VSP) ランダムWRITE (7D+1P, 8KB)のIOPS相対比較 SAS HDD 1 SSD HAF ランダムREAD (7D+1P, 8KB)のIOPS相対比較 SAS HDD 1 SSD HAF ※性能・時間は構成/使用条件により異なる場合があります。 HAFはVSPでFlash accelerationを適用した場合の値です。 © Hitachi, Ltd. 2013. All rights reserved.
32.
4-7. HAFのしくみ フラッシュメモリの性能を最大限に引き出す構造 高速なランダム性能 • 高性能マルチコアプロセッサと多重アクセス制 御により高いスループット性能を実現 •
小さいデータは大容量DRAMに書き込むこと で超高速なライト性能を実現 インターフェース 専用フラッシュ コントローラ 大容量 DRAM フラッシュメモリの長寿命化 • 高性能プロセッサによる書き込み回数平準化 などによりフラッシュメモリの耐久性向上 M M M M M M M M スケーラビリティ/コストパフォーマンス C C C C C C C C • 多数のフラッシュメモリの制御を効率化すること で、大容量/スケーラビリティを実現し、コストパ フォーマンスを向上 リ モ メ ュ シ ッ ラ フ L MLC フラッシュメモリ リ モ メ ュ シ ッ ラ フ L MLC フラッシュメモリ リ モ メ ュ シ ッ ラ フ L MLC フラッシュメモリ リ モ メ ュ シ ッ ラ フ MLC フラッシュメモリ リ モ メ ュ シ ッ ラ フ MLC フラッシュメモリ リ モ メ ュ シ ッ ラ フ L リ モ メ ュ シ ッ ラ フ MLC フラッシュメモリ L L MLC フラッシュメモリ リ モ メ ュ シ ッ ラ MLC フラッシュメモリ L フ L 高信頼/高機能 • ストレージコントローラと連携した高信頼/高機 能(定期データチェック/回復機能、高速LDEV フォーマット機能、ゼロデータ圧縮機能など) © Hitachi, Ltd. 2013. All rights reserved.
33.
4-8. HAFとSSD及びHDTとの棲み分け DB容量とコストパフォーマンスで選択 コ HDT パ HDDとのハイブリッド により性能と容量の 最適なバランスを ー ォ フ ト ス マ HAF ン ス SSD 200GB/枚~ 数TBまでのDBに最適 1.6TB/枚 数TB以上のDBおよび 超高速性を求める場合 に最適 DB容量 © Hitachi,
Ltd. 2013. All rights reserved.
34.
5.SSDとOracleの相性 © Hitachi, Ltd.
2013. All rights reserved.
35.
5-1. SSD対HDDのI/O性能基本データ シーケンシャルI/O (RAID5:4D+1P,
ブロックサイズ:512KB, 多重度:1) 【READ】 SSD 【WRITE】 SSD 性能差はあまり大きくない HDD HDD ランダムI/O(RAID5:4D+1P, ブロックサイズ:4KB, 多重度:32) 【READ】 【WRITE】 SSD SSD HDD HDD ※性能値は構成/使用条件により異なります。 ※HDDは10000rpm, SASディスク。 SSDはランダムI/Oで抜群の効果。 一方でシーケンシャルI/Oでは投資効果が薄い © Hitachi, Ltd. 2013. All rights reserved. 34
36.
5-2. 高速化したい業務は何? Oracle DBで高速化したい業務は何か? Oracleから見た I/Oパターン オンライン バッチ処理 分析系業務 ランダムI/O 多い 普通 少ない シーケンシャルI/O あまりない 普通 多い より高速化の要望が強い シーケンシャルリードのSQLを多く擁するバッチ処理や 分析系業務ではSSDの効果をどう考えればよいか? ©
Hitachi, Ltd. 2013. All rights reserved. 35
37.
5-3. 分析系SQLのI/Oパターンは? ◆シーケンシャルリードの SQL発行でストレージ側 (SSD)が受け取るI/Oパター ンを調べてみた。 ◆ストレージ側が受け取るI/Oパターン(分析系のSQL22個) 約6~7割がランダムI/O シーケンシャルI/O ランダムI/O [分] その理由は Oracle Parallel
Query © Hitachi, Ltd. 2013. All rights reserved. 36
38.
5-4. パラレルクエリとは シリアル実行では、1つのSQLに1つのコアが割り当てられる。 ◆オンライン処理の場合 ※多くのSQLが複数端末から発行される SQL SQL
SQL SQL SQL SQL ◆分析系処理の場合 ※1本の重いSQLが流れる PX:Parallel Execution Process SQL SQL PX PX PX PX PX Parallel Query PX SQL SQL SQL SQL SQL SQL マルチコアが活用できない。 CPUネック。 PX PX PX PX PX マルチコアを有効活用。 CPUネックが解消され ディスク速度に依存。 マルチコアサーバでバッチ処理や分析系処理を行う場合、 Parallel Queryはレスポンス向上に有効。 さて、ランダムvsシーケンシャルの話は・・・ Parallel Queryでは、I/Oも多重化されて発行される。 © Hitachi, Ltd. 2013. All rights reserved. 37
39.
5-5. パラレルクエリ+ASMでI/Oはどうなる? SQL発行 Parallel Query 多重 DBサーバ パラレル化 SQL発行 FC 分割 ASM FC DBサーバ FC パラレル化 FC FC P P FC P FC P P Ctrl0 分割 RAID P P P P P P P P P LU LU LU LU LU LU LU LU Oracle
ASM RAID5 LU LU LU Oracle ASM LU LU RAID5 LU P Ctrl1 LU 分割 P Ctrl1 Ctrl0 LU Drive(HDD/SSD) FC RAID5 RAID5 1ドライブに対する I/O要求が多重 /並列化し、 ランダムI/Oとなる。 HUS130 #0 #0 HUS130 © Hitachi, Ltd. 2013. All rights reserved. 38
40.
5-6. SSDとOracleの相性はとてもいい。 ランダムI/OではSSDは抜群の効果 だから Oracle DBが発行するI/Oパターンと SSDは、業務の性質によらず相性が良い。 (もちろん、I/O負荷が高いもの) ©
Hitachi, Ltd. 2013. All rights reserved. 39
41.
6.RAC on SSD分析系SQLでの検証 ©
Hitachi, Ltd. 2013. All rights reserved.
42.
6-1. 検証構成 Oracle RAC
on SSDの構成 ハードウェア 【サーバ】 Blade数: BS2000 × 2Blade CPU: Xeon X5690 3.46GHz 6core×2 Memory: 96GB 【ストレージI/O】 インターフェース: FC FCケーブル: 16本 (8本/Blade × 2) FC通信速度: 8Gbps/port 【ストレージ】 台数: HUS130(基本筺体+拡張筺体) × 2台 SSD: 200GB × 28 (6D+1P × 4組) 8Gb/s×16 データベース情報 OS:Redhat Enterprise Linux 6.2 DB:Oracle Database 11g Release2 (11.2.0.3) ・・・ 200GB SSD DB構成:2ノード RAC構成 DBサイズ:150GB, 及び350GB DBブロックサイズ:32K DBキャッシュサイズ:48GB © Hitachi, Ltd. 2013. All rights reserved.
43.
6-2. HDDとSSDでの比較 帯域とSQL処理時間を測定 I/Oが多く出る分析系DB処理を模擬した SQLを使用 I/Oスループット及びSQLのレスポンスタイム の合計を測定 PCサーバ+HDD搭載ストレージと比較。 比較機器 【サーバ】 機種:HA8000/RS210-hHM CPU:E5-2690×2 メモリー:96GB I/O: 6Gbps/port
4本(2本/台 × 2) 【ストレージ】 機種:BR1200×2台 HDD: 146GB (15,000rpm) × 16 (7D+1P × 2) ■ I/O帯域 (GB/s) ■ SQL処理時間 11.00 12 09:00 8.44 10 (mm:ss) 07:53 07:30 8 06:00 6 04:30 4 03:00 2 0.75 01:30 0 HDD(SQL性能) 01:19 SSD(SQL性能) SSD(dd性能) HDD 00:41 SSD(1ノード) SSD(2ノード) ※dd性能とは、OSのddコマンドにてI/O性能を測定した結果 I/O帯域、レスポンスとも、10倍以上は想定通り。 © Hitachi, Ltd. 2013. All rights reserved.
44.
read 1000 900 800 700 600 500 400 300 200 100 0 50 45 40 35 30 25 20 15 10 5 0 write性能(MB/sec) I/O性能(iostat) HDD 0:17:15 I/O性能が頭打ち © Hitachi,
Ltd. 2013. All rights reserved. 0:17:15 0:16:30 0:15:45 0:15:00 0:14:15 0:13:30 0:12:45 0:12:00 0:11:15 0:10:30 0:09:45 0:09:00 0:08:15 0:07:30 0:06:45 0:06:00 0:05:15 0:04:30 0:03:45 0:03:00 0:02:15 0:01:30 0:00:45 0:00:00 実行時のI/OとCPUの状況 0:16:30 使用率(%) ・800MB弱でI/Oネックとなる。 ・CPUは余裕がある 0:15:45 0:15:00 0:14:15 0:13:30 0:12:45 0:12:00 0:11:15 0:10:30 0:09:45 0:09:00 0:08:15 0:07:30 0:06:45 0:06:00 0:05:15 0:04:30 0:03:45 0:03:00 0:02:15 0:01:30 0:00:45 0:00:00 read性能(MB/sec) 6-3. OS統計情報(HDD構成) CPU利用状況 Parallel 20 CPU利用状況 HDD 100 90 80 70 60 50 40 30 20 10 0 時間(hh:mi:ss) cpu ※1ノードでSQL実施 ※DBサイズは150GB 時間(hh:mi:ss) write 43
45.
6-4. OS統計情報(RAC on
SSD) 実行時のI/OとCPUの状況 CPU利用状況 「RAC on SSD」 0:12:40 0:12:00 0:11:20 0:10:40 0:10:00 0:09:20 0:08:40 0:08:00 0:07:20 0:06:40 0:06:00 0:05:20 0:04:40 0:04:00 0:03:20 0:02:40 0:02:00 0:01:20 0:00:40 100 90 80 70 60 50 40 30 20 10 0 0:00:00 使用率(%) ・約 MB/sのI/O性能 ・ I/Oにはまだ余裕がある状況 ・ CPUはほとんど使えている。 時間(hh:mi:ss) 時間(h:mm:ss) CPU I/O性能(iostat) 「RAC on SSD」 700 9000 最大I/O性能 8000 ※2ノードでSQL実施 ※DBサイズを350Gに拡張。 600 6000 5000 400 4000 300 3000 200 write性能(MB/sec) 500 (150GのままではI/O負荷が少な かったため) 2000 100 時間(hh:mi:ss) sum(read) 0:12:40 0:12:00 0:11:20 0:10:40 0:10:00 0:09:20 0:08:40 0:08:00 0:07:20 0:06:40 0:06:00 0:05:20 0:04:40 0:04:00 0:03:20 0:02:40 0:02:00 0:01:20 0 0:00:40 1000 0:00:00 read性能(MB/sec) 7000 0 sum(write) © Hitachi, Ltd. 2013. All rights reserved. 44
46.
6-5. リプレースが必要な古いUNIX環境との比較 2005年頃のシステムと比較してみた 比較機器 2005年当時のUnixサーバと比較 【サーバ】 機種:HA8500/310 CPU:Itanium 2
1.30GHz 1core×2 メモリー:2GB I/O: FC-2Gbps/port 2本 【ストレージ】 機種:SANRISE9570 HDD: 146GB (15,000rpm) × 12 測定ケース 旧UNIX環境 「RAC on SSD」 1ノード 「RAC on SSD」 2ノード パラレル度 2 24 24 Partition数 16 24 24 圧縮 無効 有効 有効 物理メモリ(搭載) 2GB 96GB 96GB メモリ(Oracle割当) 1GB 45GB 45GB SQL実行時間合計 約165倍高速 約318倍高速 CPU性能の差(24倍)以上の改善があることが分かった。 © Hitachi, Ltd. 2013. All rights reserved.
47.
7.信頼性に関する検証 © Hitachi, Ltd.
2013. All rights reserved. 46
48.
7-1. RAC on
SSDの可用性 「RAC on SSD」は、I/Oパスの冗長化により、パス障害やI/O機器障 害が発生した場合にも業務を継続できるよう可用性を高めている。 BS2000 サーバシャーシ Blade #0 (P0)I/Oスロット拡張装置接続ボード サーバシャーシ 接続ポート#0 Blade #1 (P1)I/Oスロット拡張装置接続ボード サーバシャーシ 接続ポート#1 I/Oモジュール#0 (P2)I/Oスロット拡張装置接続ボード サーバシャーシ 接続ポート#0 I/Oスロット 拡張装置 Expander(1:4モード) (P3)I/Oスロット拡張装置接続ボード サーバシャーシ 接続ポート#1 I/Oモジュール#1 Expander(1:4モード) #0(Blade#0) #1(Blade#0) #2(Blade#1) #3(Blade#1) #8(Blade#0) #9(Blade#0) #10(Blade#1) #11(Blade#1) 日立8GFC 日立8GFC 日立8GFC 日立8GFC 日立8GFC 日立8GFC 日立8GFC 日立8GFC P0 P1 0A 0B P0 0C P1 0D P0 P1 1A Ctrl #0 LU1 LU2 1B P1 10 1C P0 0A 1D LU3 LU4 … LU5 LU6 LU7 P1 0B P0 0C P1 0D LU8 LU11 LU12 LU13 LU14 … … SSD(RAID5) SSD(RAID5) HUS130 P0 P1 1A P0 1B 1C P1 1D Ctrl #1 Ctrl #0 Ctrl #1 SSD(RAID5) HUS130 P0 LU15 LU16 LU17 LU18 … SSD(RAID5) © Hitachi, Ltd. 2013. All rights reserved. 47
49.
7-2. FCケーブル抜線テスト FCケーブル抜線テスト Blade数: BS2000
× 2Blade CPU: Xeon X5690(6core)×2/Blade Memory: 96GB/Blade P P P テストツール、およびテスト内容 R3ブレード #1 R3ブレード #0 P F C F C IOドロワ P F C F C F C F C F C BS2000 I/Oケーブルの本数が増えることで 障害発生確率は多少なりとも増加。 ケーブル障害でも耐えうる構成である が、性能に与える影響を調査する。 F C P P F C F C P F C F C F C F C F C F C 分析系DB処理の一般的なベンチマーク からI/O不可の高いSQLを実行。 OS稼働時にケーブルを抜いてから測 定を実施。 SQLのレスポンスタイムの合計、及び I/Oスループットを測定。 ① FCケーブルを1本抜いた状態 ② IOドロワ片系障害としてドロワケー ブルを抜いてFC8本分繋がらない 状態の確認 FCケーブル 8Gbps×16本 A B C D A B C D A B C D A B C D Ctrl0 Ctrl1 Ctrl0 Ctrl1 HUS基本筺体 HUS基本筺体 HUS拡張筺体 HUS拡張筺体 HUS130(基本筺体+拡張筺体) × 2台 SSD: 200GB × 28本 (6D+1P) ×4組) © Hitachi, Ltd. 2013. All rights reserved.
50.
7-3. 稼動確認と性能比較 ケーブル抜いても停止すること無く連続稼働 それぞれの場合のSQLレスポンスとI/Oスループットの推移 正常時 FCケーブル16本 最大Read帯域: MB/sec SQL
実行時間 : 13分59秒 ①FCパス1本抜線 FCケーブル15本 最大Read帯域: MB/sec SQL 実行時間: 14分14秒 ②I/Oドロワ片系障害 FCケーブル8本相当 最大Read帯域: MB/sec SQL 実行時間: 14分31秒 SQL実行時間に殆ど影響無し!帯域確保されているからこそ。 © Hitachi, Ltd. 2013. All rights reserved.
51.
まとめ © Hitachi, Ltd.
2013. All rights reserved.
52.
まとめ 高速化と信頼性を両立するDB高速化ソリューション その鍵はSSD HDD⇒SSDだけでは効果薄、通り道のネックを全部排除してSSDを生かす。 OracleDBのI/Oパターンは、SSDと相性がよい。 オンラインのみならず、バッチ、分析処理の大幅な高速化を実現できる オープンで信頼性の高いプラットフォーム オープンIAサーバを利用した通常のRAC構成。AP移行も安心。 通常のLinux/Windowsサーバ。バックアップ、監視ソフトも問題なし。 高信頼サーバ/ストレージと、あらゆる箇所の冗長構成でサービスを止めない。
実証された構成、でも柔軟な選択 構成選定やH/Wチューニングの手間をかけずに性能と信頼性を両立できる。 サーバCPU、メモリ量、SSD容量を処理内容に応じて調整できる。 Oracleライセンス/サポートを抑えられる様に少ないコア数でも構成できる。 © Hitachi, Ltd. 2013. All rights reserved. 51
53.
他社商品名、商標等の引用に関する表示 • OracleとJavaは,Oracle Corporation
及びその子会社,関連会社の米国及びその他の国における登録商標で す。 • Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。 • Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。 • その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。 • 製品の改良により予告なく記載されている仕様が変更になることがあります。 © Hitachi, Ltd. 2013. All rights reserved. 52
Descargar ahora