製品・サービス発表レター検索

1-1-1] 製品の概要

本日付けで IBM は、IBM solidDB V6.1 を発表いたします。

IBM solidDB V6.1 は、リレーショナル・インメモリー・データベースであり、従来型のディスク・ベースのデータベースに比べて 10 倍の速度で動作することで、優れた高速性を提供します。 よく知られている SQL 言語を使用し、アプリケーションはマイクロ秒単位で応答するため、潜在的に毎秒数万件のトランザクション処理を実現します。 IBM DB2 または IDS 用のキャッシュとしてデプロイされても、あるいは通常のデータベースとしてスタンドアロンでデプロイされても、solidDB は、パフォーマンスが重要なデータに対して、非常に高速なアクセス性能を提供いたします。 solidDB を既存のIBM データ・サーバーに統合することで、データへのアクセスを非常に高速化することが可能となります。この高速化は、多くの同時ユーザーによって頻繁にアクセスされるパフォーマンスが重要なデータに特に有益です。 典型的な例としては、チケット発行および予約システム、オンライン・ゲーム、イベント処理および警報などのアプリケーション、e-コマース・アプリケーション、および SaaS (Software as a Service) アプリケーション・プラットフォームとしてのソフトウェアなどのデータがあります。 さらに、DB2 または IDS からのデータを solidDB にキャッシュできるため、カスタマー・サービスや株取引のようなアプリケーションで発生するピーク負荷の支援にも役立ちます。

IBM solidDB は、システム障害が発生しても 1 秒以内に回復できる、高度な可用性を実現します。 solidDB は、2 ノード、ホット・スタンバイ構成の使用により、2 つの solidDB ノード間で同期されたデータのコピーを維持します。 この構成は、DB2 または IDS 用の solidDB Cache によりデプロイすることも可能で、これらのデータ・サーバーの高可用性および災害時回復機能 (HADR: High Availability and Disaster Recovery) を補完することもできますので、より総合的なソリューションが提供できます。

IBM solidDB は、従来型のディスク・ベースのデータベースに比べて、速度と可用性が非常に優れており、ビジネスにおけるデータの可用性とアクセスの容易性を実現するように設計されています。 高度な可用性は、想定される、あるいは想定外のシステム停止や遅延に関連するコストの低減に役立ちます。 solidDB は、アプリケーションによって制御され、ほぼ自動で実行可能なため、さらなるコストの削減を実現します。 自動的なデータベースの実行はデプロイを高速化し、管理コストを削減するのにも貢献します。 さらに、solidDB はクラス最高のハードウェア・システムだけでなく、一般的なハードウェア・システムでも動作するため、企業はニーズに合った最適なソリューションを選択することができます。



製品資料は英語版でのご提供ですが、Unicode に基づく日本語の入出力もサポート対象となります。(2008-06-27 補足)

■　発表製品出荷予定時期

• solidDB
• solidDB Cache for DB2
• solidDB Cache for IDS

• 高速性の提供: solidDB は、データをディスクではなく常時メイン・メモリーに保持するように設計されています。 アプリケーションでは、標準の ODBC、JDBC、SQL インターフェースを介してその機能を活用できます。
• 高可用性の提供: solidDB は、ほぼ常時、同期されたデータのコピーを 2 つ保持するように構成できます。 システム障害が発生した場合、solidDB はアプリケーションが 1 秒以内に solidDB へのアクセスを回復できるように設計されています。
• コスト削減に有効: solidDB は、アプリケーションに直接埋め込み可能で、ほぼ自動で実行させることができるよう設計されており、デプロイおよび管理が容易です。 また、アプリケーションによるプログラム制御が可能なので、総所有コストを低減できます。 専任のデータベース管理者も必要ありません。

［1-2-1］製品の機能詳細

■　卓越した高速性

インメモリー・データベース・テクノロジーによる卓越した高速性を実現しています。

インメモリー・データベースは、高速性と予測可能な応答時間を要求するリアルタイム・アプリケーションのパフォーマンス要件に対応した技術です。 名前が示すとおり、インメモリー・データベースは、ディスク上ではなくすべてメイン・メモリー内に存在するため、高速データ・アクセスを実現します。

図1: 条件付き最大スループット (MQTH: Maximum Qualified Throughput) で計測した
solidDB と従来型のディスク・ベースのデータベースとの高速性比較


インメモリー・データベース solidDB は、すべてのデータをメイン・メモリーにキャッシュするディスク・ベースのデータベースと比較すると、応答時間がより短く、一貫性に優れているだけでなく、より高度なトランザクション・スループットで高速性を実現するように設計されています。

図1 は、インメモリー・データベース solidDB のパフォーマンスと、従来型のディスク・ベースのデータベースのパフォーマンスを比較した Telecom One ベンチマーク・テストの結果を示しています。 solidDB のスループットが約 10 倍優れていることが分かります。 Telecom One は、IBM 傘下の Solid 社によって開発されたデータベース用ベンチマーク・テストのプログラムです。 2003 年にヘルシンキ大学の修士論文集の一部として発表されたもので、通信アプリケーション向けに設計されたベンチマーク・テスト手法に基づいています。 Telecom One ベンチマーク・テストの詳細については、下記の Web サイトを参照してください。
http://www.solidtech.com/en/developers/CarrierGrade/tm1.asp

上記のベンチマーク・テストは、 CPU、・コアの Intel Xeon 2.66GHzプロセッサー (合計 8 コア)、4GB RAM、および Windows Server 2003SP2 を使用したシステムで実行されました。 また、このテストでは Telecom One Benchmark v.4.1 を使用し、10 分間のランプアップと 20 分間のサンプリングが行われました。 テストは、10 万人の携帯電話加入者を想定し、非同期ロギング、リンクされたライブラリ・デプロイメント、および 5 分間隔のチェックポイントで構成された solidDB 上で、128 人の同時クライアントを使って実施されました。

solidDB のようなインメモリー・データベースは、高速アクセスを必要とするすべてのデータがメイン・メモリー内に存在するという前提の元で機能します。 このため、solidDB のデータ構造およびアクセス方式は、効率的な並列制御メカニズムによりメイン・メモリー内でデータを保存、検索、処理することに特化して設計されています。 従来型のディスク・ベースのデータベースに対し、solidDB にはパフォーマンスの面で 2 つの優れた特徴があります。 1 つ目は、データ・ブロックをディスクからメイン・メモリーに移動する必要がないという点です。 これは、アプリケーションが必要とするすべてのデータが、メイン・メモリー内にすでに存在しているためです。 2 つ目は、たとえディスク・ベースのデータベースがすべてのデータをメイン・メモリー内にキャッシュしたとしても、solidDB はメイン・メモリーへのアクセスのために最適化されたデータ構造とアクセス方式を採用しているため、ディスク・ベースのデータベースよりも本質的に高速であるという点です。

さらに、solidDB はマルチコア、マルチプロセッサーのアーキテクチャーによって処理の拡張性が提供されているだけでなく、64 ビット・コンピュータによる大容量メモリー・サイズを活用するように設計されています。 solidDB のアクセス方式には、効率的な同時制御メカニズムも実装しているため、マイクロ秒で計測される応答時間を提供しながらも、大量の同時トランザクションにおける一貫性を保持します。 IBM DB2 または IDS 用のキャッシュとしてデプロイされても、あるいはレコードのデータベースとしてスタンドアロンでデプロイされても、solidDB はパフォーマンスが重要なデータに優れた高速性を提供します。

■　データの永続性と回復能力

solidDB のインメモリー・データベースは、すべてのデータがメイン・メモリー内でアクセス可能であるという前提の元で機能しますが、solidDB は、データの回復能力を確保するために、更新されたデータを常時ディスクに書き込んでいます。 この書き込みは、solidDB のチェックポイント機能とトランザクション・ロギング・メカニズムによって実行されます。 チェックポイント機能を使用する場合、solidDB はメイン・メモリーからコミットされたトランザクションを、ディスク上のデータベース・ファイルにコピーします。 チェックポイント間でサーバー障害が発生した場合、solidDB は一貫性のあるデータのスナップショットがディスクに確実に保持されるようにします。 チェックポイント間で、solidDB はコミットされたトランザクションをトランザクション・ログに書き込みます。 システムがクラッシュした後、solidDB はこのトランザクション・ログとロールフォワード・リカバリーを使用して、最後のチェックポイントでコミットされたトランザクションを最新のコミットされた状態へ自動的に回復させるように試行します。 パフォーマンスと持続性をバランスよく活用するため、solidDB のトランザクション・ロギングにはさまざまな構成オプションが用意されています。 厳密なロギングの場合、トランザクションはコミットされると同時に同期され、ログに記録されます。 緩やかなロギングの場合、solidDB はトランザクション・ログへの書き込みを非同期的に遅らせます。 さらに、solidDB スナップショットの一貫性を維持するチェックポイント機能により、トランザクション・ロギングが停止されます。 これは、最後のチェックポイントでのみ回復機能を提供すれば十分な状況において、アプリケーションのパフォーマンスの速度を上げることに役立ちます。

■　DB2 または IDS におけるデータ・アクセスの高速化

従来型のディスク・ベースのデータベースが、大規模なデータベースを保管する能力と、広範囲で多様な作業負荷をサポートする汎用性を提供するのに対し、インメモリー・データベース solidDB は、メイン・メモリーに収まるデータに対して高速性を実現するように設計されています。 したがって、DB2 または IDS データの中で、パフォーマンスが重要な部分を solidDB Cache 内に保持することにより、 2 つのデータベースから最高の結果を得ることができます。 DB2 または IDS のデータの中で、パフォーマンスが重要な部分が solidDB Cache にロードされると、アプリケーションは、マイクロ秒単位で測定される、短時間で一貫性のある応答時間と、毎秒数万ものトランザクションのスループットで、これらの部分にアクセスし、更新できるようになります。 すべての変更は自動的に DB2 または IDS にも同期されます。 その一方で、DB2 または IDS はデータベース全体で、広範囲の多様な作業負荷に対し、より幅広いアプリケーションへのアクセスを提供します。

IBM DB2 または IDS 用のキャッシュとしてデプロイされても、あるいはレコードのデータベースとしてスタンドアロンでデプロイされても、solidDB はホット・ スタンバイ構成によりパフォーマンスをさらに向上させることができます。 ホット・スタンドバイ構成では、プライマリーおよびホット・スタンバイ solidDB のインスタンス全体で、読み取り操作をアプリケーションに対してトランスペアレントにロード・バランシングさせることができます。 ロード・バランシングを活用するには、アプリケーションから solidDB の ODBC または JDBC ドライバーを使用し、プライマリーおよびホット・スタンバイの solidDB インスタンスの両方に対し 1 つの論理的接続だけを維持するようにします。 この構成では、書き込みトランザクションは自動的にプライマリー solidDB ノードに送信されます。 また、読み取りトランザクションはホット・スタンバイ solidDB ノードのみに送信されるか、あるいはプライマリー solidDB インスタンスおよびホット・スタンバイ solidDB インスタンスにまたがってロード・バランシングされます。 このため、アプリケーション開発者がコードを記述する必要はありません。
ロード・バランシングの使用により、プライマリーおよびスタンバイの両方のデータベース・インスタンスの計算能力を活用し、パフォーマンスを最大 100% 向上させることができます。 ホット・スタンバイ構成は、solidDB のノードの可用性を高め、障害発生時でも通常 1 秒以内のフェイルオーバーを可能にします。

ホット・スタンバイ構成は、トランザクション・ロギングの最適化によってもパフォーマンスを向上させることができます。 適用力のある耐久性を備えたプライマリー solidDB インスタンスは、緩やかなロギングのパフォーマンスの向上からメリットが得られます。 ネットワーク上でホット・スタンバイ・インスタンスと同期することで耐久性が維持されるため、耐久性が損なわれることはありません。 障害が発生した場合、残っているインタンスが同期ロギングに自動的に移行する設計であるため、より高度なデータの耐久性が提供されます。

さらに、単一サーバーのメイン・メモリーに収まりきれない大規模なテーブルの場合、DB2 または IDS 用の solidDB Cache は、複数のサーバーに対してテーブルをスケールアウトするため、管理者が複数の solidDB Cache インスタンスに対してテーブルを分割できるようになります。 例えば、DB2 または IDS 上の大きな顧客テーブルに 100 万人の顧客が含まれていれば、100 万人の顧客データ全体を単一の solidDB Cache インスタンスにキャッシュするのではなく、solidDB Cache インスタンスを 4 つに分割し、各インスタンスに 25 万人の顧客データを保存することができます。 キャッシュする必要のある、パフォーマンスが重要なデータのサイズが数十ギガバイトある場合、テーブルの分割は大変便利です。 このような場合に、solidDB Cache の保存には、80 ギガバイトのメイン・メモリーを備えた単一の 64 ビット・プロセッサー・サーバーの代わりに、複数の商用サーバーを使用することができます。 パフォーマンスをさらに向上させ、同時にパフォーマンスが重要なデータの可用性を高めるために、複数の solidDB Cache インスタンスにまたがるデータの分割を solidDB のホット・スタンバイ構成と組み合わせることで、読み取り操作と 1 秒以内の障害回復の自動的なロード・バランシングを実現します。



図2: solidDB Cache の複数のインスタンスにより、複数のサーバーにまたがる
DB2 および IDS のパフォーマンスが高速化されます




■　卓越した可用性

通常、solid DB サーバーは、システム障害からの 1 秒以内の回復が可能であり、パフォーマンスが重要なアプリケーションに要求されるデータの可用性を提供するのに役立ちます。 solidDB は、2 ノードのホット・スタンバイ構成によって、 solidDB のノード間で同期されたデータのコピーを 2 つ保持します。 システム障害が発生した場合、solidDB ノード間のフェイルオーバーは 1 秒以内で行われます。 この機能により、想定外のシステムの停止からユーザーが保護されます。 さらに、このアーキテクチャーでは、プライマリー solidDB ノードをオフラインにする必要がなく、保守作業（アップグレード、レポート作成、バックアップ等）に solidDB ホット・スタンバイ・ノードを使用する機能など、潜在的に副次的なメリットがあります。 システム障害が起きた場合、あるいは solidDB ノードのペアを計画的に切り替える場合でも、セカンダリー solidDB サーバーが処理中のロードを迅速に引き継ぐように設計されており、データ損失の機会が最小化されます。 フェイルオーバーはアプリケーションに対してトランスペアレントであるように設計されており、solidDB ODBC および JDBC ドライバーはデータベース接続とセッション属性を維持します。

さらに、solidDB には、プライマリーおよびセカンダリーの solidDB サーバーの同期方法を指定するために、複数の高可用性構成オプションが用意されています。 システム、セッション、およびトランザクションの各レベルで、これらのオプションを選択できます。 これにより、ユーザーはスループット、耐久性、および回復時間をより柔軟にバランスよく設定することができます。

solidDB のホット・スタンバイ構成は、DB2 または IDS 用の solidDB Cache によってデプロイすることもできます。 この場合 solidDB Cache は、高可用性および災害時回復 (HADR) のために構成されます。

図3: 高可用性および災害時回復 (HADR) 用に構成された DB2 および IDS



ホット・スタンバイ構成:

• パフォーマンス、平均修復時間 (MTTR: Mean Time To Recovery)、および耐久性間の適切なトレードオフを実現するために構成可能なレプリケーションとロギング設定
• キャッシュ・インスタンスの 1 つが使用できなくなった場合の 1 秒以内のフェイルオーバー
• トランスペアレントな接続性:
• アプリケーションがプライマリーおよびセカンダリーの両方の solidDB Cache インスタンスに 1 つの論理的接続だけを維持する場合
• フェイルオーバーおよび切り替え時に、アプリケーションが接続ハンドルとセッション属性を維持するようにする
• 読み取り操作のトランスペアレントなロード・バランシング

• セカンダリー・データベースは、プライマリー・データベースからの要求を受信すると、すぐにコミット・レコードを確認します。
• セカンダリー・データベースは、プライマリー・データベースから受信したトランザクション・リクエストを処理した後、ログに書き込まれる前に、コミット・レコードを確認します。
• セカンダリー・データベースは、トランザクション・ログがセカンダリー・データベースで完全にコミットされた後、コミット・レコードを確認します。 これらの設定は全体のリカバリー時間とアプリケーションのパフォーマンスに影響を与えます。 プライマリー・データベースでコミットされたすべてのトランザクションが、セカンダリー・データベースでもコミットされる場合、リカバリー時間は非常に短くなります。 プライマリー・データベースでシステム障害が発生した場合、セカンダリー・データベースはリカバリー作業を実行する必要がないため、プライマリー・データベースの役割を迅速に引き継ぐことができます。

• アプリケーションでは solidDB Cache をクライアント/サーバー構成で使用したり、solidDB にリンクしたライブラリーと連携させることができます。
• solidDB Cache のホット・スタンバイのペアを、高可用性および読み取りのロード・バランシングといった目的で使用することができます。
• solidDB は複数のサーバーにまたがって調整できます。

• IBM solidDB Getting Started Guide
• IBM solidDB Administrator Guide
• IBM solidDB Programmer Guide
• IBM solidDB SQL Guide
• IBM solidDB High Availability User Guide
• IBM solidDB In-Memory Database User Guide
• IBM solidDB Linked Library Access User Guide
• IBM solidDB Advanced Replication Guide
• IBM solidDB Connector Guide

• ライセンス情報 (文書)
• solidDB V6.1.0 マルチプラットフォーム・メディア・パック (DVD)

• ライセンス情報 (文書)
• solidDB Cache V6.1.0 for DB2 マルチメディア・プラットフォーム・パック (DVD)

• ライセンス情報 (文書)
• solidDB Cache V6.1.0 for IDS マルチプラットフォーム・メディア・パック (DVD)
  

最小限のハードウェア要件:

• 32 ビットおよび 64 ビット (x64) Windows および Linux: サポートされる Windows または Linux オペレーティング・システムを実行することができる、Intel または AMD プロセッサーをベースにした全システム (x86 および x64 システム)。
• AIX for IBM System p システム: POWER5 またはそれ以降のプロセッサーが搭載された 64 ビットのシステムが必要。
• Solaris: UltraSPRC プロセッサーが搭載された 32 ビットおよび 64 ビットのシステム、AMD 32 ビットおよび 64 ビットのプロセッサー、または Intel x86 プロセッサーが必要。
• HP-UX: Itanium ベースの HP Integrity Series システムが必要。

このセクションでは、この発表の時点で solidDB、solidDB Cache for DB2、および solidDB Cache for IDS によってサポートされるオペレーティング・システムおよびデータ・サーバーを示します。

Linux

• Red Hat Enterprise Linux (RHEL) 4 および 5
• SUSE Linux Enterprise Server (SLES) 9 および 10

• 32 ビットおよび 64 ビット (x64) Windows Server 2003、Standard Server、Enterprise Server、および Datacenter 版
• 32 ビットおよび 64 ビット (x64) Windows XP Professional版
• 32 ビットおよび 64 ビット (x64) Windows Vista Business、Enterprise、および Ultimate 版

• AIX 5L V5.3 for POWER5 および POWER6 64 ビットのシステム

• HP-UX 11i for HP 64-bit Integrity サーバー (Itanium ベースのシステム)

• Solaris 10 for Sun UltraSPARC、AMD 32 ビットおよび 64 ビット、および Intel x86 サーバー

• DB2 for Linux、Unix、および Windows Enterprise Server Edition V9.5
• DB2 for Linux、Unix、および Windows Enterprise Server Edition V9.1
• DB2 9 for z/OS
• DB2 for z/OS V8

• IDS V11.5 Enterprise Edition
• IDS V11.1 Enterprise Edition

［1-5-1］ライセンス、制限事項、考慮点その他

ライセンス上の制限事項につきましてはライセンス情報をご参照ください。

［1-5-2］セキュリティ、監査および管理

発表された製品は、ホスト・ハードウェアおよびホスト・ソフトウェアのセキュリティーおよび監査機能を使用します。

アプリケーション・システムや通信機能でのセキュリティー機構、管理手順、および適切な制御を、評価、選択、実装することは、お客様の責任で行っていただきます。

［1-6-1］パッケージング

1) IBM solidDB V6.1.0 Multiplatform English

• License Information (paper)
• solidDB V6.1.0 Multiplatform Media Pack (DVD)

• License Information (paper)
• solidDB Cache V6.1.0 for DB2 Multiplatform Media Pack (DVD)

• License Information (paper)
• solidDB Cache V6.1.0 for IDS Multiplatform Media Pack (DVD)

• IBM、WebSphere、MQSeries、AIX、Everyplace、AS/400、DB2、QMF、zSeries、xSeries、iSeries、pSeries、RS/6000、z/OS、および OS/390 は、International Business Machines Corporationの米国およびその他の国における商標です。
• Microsoft、Windows、Windows NT、および Windows のロゴは、Microsoft Corporation の商標です。
• Solaris, Java およびすべての Java ベースの商標およびロゴは Sun Microsystems, Inc の商標または登録商標です。
• UNIX は The Open Group の商標です。
• Intel は Intel Corporation の登録商標です。
• 他の会社名、製品名およびサービス名などはそれぞれ各社の商標または登録商標です。