データウェアハウスとは何なのか?

データウェアハウス導入の手引き

ビジネスを運営すれば、日々データが増え続けます。業種や事業規模によっては、天文学的に増える可能性だってあります。昨今では、データをきちんと整理し、しっかり管理して、その状況を十分に把握しておくことが、健全なビジネス運営に欠かせない条件となっています。そして、その実現に必要となるのが、データウェアハウスです。

本稿では、そもそもデータウェアハウスとは何なのか、どのように機能するのか、を説明し、それをサポートするアーキテクチャモデルについて、さらに実用上の利点と課題についても紹介していきます。

データウェアハウスとは何なのか?

データウェアハウス(Data Warehouse)とは、さまざまな媒体から集められる多種多様なデータを単一の組織化されたデータベースにまとめ、ビジネス上の意思決定をデータ主導で行えるように整理するためのシステムです。これは、特にビジネスインテリジェンス(BI)において威力を発揮します。BIは、履歴データと現行データの両方への迅速かつ構造化されたアクセスを必要とするので、データウェアハウスの質がBIの意思決定効果を大きく左右します。

データウェアハウスを構築するには、通常、以下の2つのアプローチがとられます。

トップダウン ― データウェアハウスの全体的な設計から始めて、部門ごとのニーズに合わせたデータマートの構築へと細分化していくアプローチです。

ボトムアップ ― まず部門に特化したデータマートを作成し、それらを統合して、より大規模なデータウェアハウスを構成していくアプローチです。

企業がデータウェアハウス構築時にどちらのアプローチを取るかは、ビジネスのニーズ、利用可能なリソース、プロジェクトのスコープなど、さまざまな要因によって決まります。

データウェアハウスを構成する要素

データウェアハウスは、主に4つのレイヤーから成り、それぞれのレイヤーがデータ処理パイプラインを構成するうえで重要な独自の役割を担っています。

データソースレイヤー

データソースレイヤーは、とれたての生の情報が集められた、データウェアハウスの基盤となるレイヤーです。これは、ビジネスの目的に応じ、従来型のシステム向けにはリレーショナル データベースのような構造化されたデータ群であったり、より最新型のシステム向けには、JSONファイルのような半構造化データや、画像、音声、センサーデータなどの非構造化データであったりします。

データステージングレイヤー

データステージングレイヤーは、ソースシステムから収集された生データの一時的な格納庫の役割を果たします。この段階では、データはまだ検証も標準化もされてなく、クリーンな状態ではありません。ステージングレイヤーが、生データをより精製されたデータレイヤーに移行する前のバッファーとなり、重複排除、フォーマット化、エラーの修正などを行える場を提供します。

データストレージ(ウェアハウス)レイヤー

データウェアハウスの中核となるレイヤーで、構造化され、統合されたフォーマットのデータが永続的に保存されます。前段階のステージングレイヤーで処理されたデータがここで整理整頓され、長期的な使用目的で格納されます。時系列に則ったデータの一貫性がここで確立され、いつでも分析可能な状態となります。

データアナリティクス(プレゼンテーション)レイヤー

構造化されたデータをユーザーが分析やレポートに利用できるようにする最終段階のレイヤーです。ダッシュボードやレポーティングツール、その他のユーザーインターフェースとここで統合され、ビジネスユーザーがストレージシステムを直接処理しなくてもデータを可視化して理解できる場を提供します。

データウェアハウス アーキテクチャの種類

データウェアハウスのアーキテクチャには単純なものから複雑なものまでいろいろあり、組織の規模、ビジネス目標、技術的ニーズなどに応じて、多種多様なアプローチでアーキテクチャが実装されます。ここでは、もっとも一般的なアーキテクチャ モデルを紹介します。

単一ティア アーキテクチャ

複数のレイヤーが論理的に(多くのケースでは物理的にも)単一のティアに統合され、実装されます。データの冗長性を排除できる利点がある反面、さほど高度な拡張性と柔軟性は期待できず、パフォーマンスのボトルネックを生じさせるリスクがあります。

2ティア アーキテクチャ

データソース/データステージング レイヤーとデータウェアハウス/プレゼンテーション レイヤーを論理的にも物理的にも切り離して実装するアーキテクチャです。中小規模のビジネスに広く採用されており、データとストレージの管理力により優れています。スケーラビリティと大規模データの処理面では多少の制約がともないます。

3ティア アーキテクチャ

データソース、ステージング、ストレージ、プレゼンテーションのすべての主要レイヤーを物理的、論理的に区別して実装する、もっとも一般的で安定したアプローチです。レイヤーを切り離すことで、拡張性、柔軟性、パフォーマンスのすべてを高次元で実現することができます。

最新のデータウェアハウス アーキテクチャ事情

最新のデータウェアハウスは、近年のITトレンドを敏感に取り入れたものが主流で、一般的に以下の特長を備えています。

クラウドネイティブ アーキテクチャ ― オンプレミスの制約を取り払い、簡易スケーリング、あるいはスケーリング オンデマンドを可能にします。料金は使用分だけを払うことができるので、初期投資を大幅削減できる「サーバレス」アーキテクチャとしての利点があります。また、すべてのデータをAWS S3やAzure Blobなどのストレージを使用する「データレイク」に保管できる点でも、コスト効率に長けています。

リアルタイム プロセシング ― 最新のデータウェアハウス アーキテクチャはContinuous Data Ingestion(継続的なデータ取り込み)を可能にすることで、オンデマンドの即時分析を実現しています。

AIとMLの統合 ― 大規模言語(LLM)モデルとの統合が進み、アナリティクスが機能的にも速度的にも強化され、より的確なビジネスの意思決定が可能になっています。

典型的なアーキテクチャには、データソース、ステージング、ストレージ、プレゼンテーションのレイヤーが含まれますが、設定方法によっては、レイヤーを部分的に組み合わせたり、逆に複数システムに分散させたりするバリエーションがあります。

的確なデータウェアハウス アーキテクチャ設計がもたらす効果

データウェアハウスを正しく設計、構造化することで、企業は確かなデータにもとづく迅速かつ的確な意思決定が可能になり、そのビジネス効果は計り知れません。データウェアハウスは、企業にとって、ビジネス戦略上の重要な資産となるものです。適正に設計されたデータウェアハウスには、以下の効果が期待できます。

パフォーマンスの改善 ― 必要なデータを必要な形で迅速に引き出せるので、レポーティングとアナリティクスの即応性と正確性が向上します。

データ品質の向上 ― データの質が上がれば、それにもとづいて動くビジネスの質も上がります。

スケーラビリティ ― データウェアハウスが正しく設計されていれば、将来のスケーリングが保証され、ビジネスの成長をサポートできます。

最新アナリティクスの統合 ― LLMモデルを活用した最新のデータアナリティクスで、ビジネスの意思決定がいっそう研ぎ澄まされます。

課題および検討事項

データウェアハウスの導入は、企業にとって非常に大きな一歩となります。そこから得られる効果も絶大であると同時に、思わぬ壁に直面する可能性もあり、入念な計画が求められます。実装方法によって直面しうる課題は異なりますが、すべての実装方法に共通した典型的な課題もあり、あらかじめ検証しておく必要があります。たとえば、以下の課題が挙げられます。

データ統合の複雑化 ― システムが拡大していくにつれ、新しいデータタイプやデータソースが追加されることは珍しくなく、データウェアハウスには継続的な調整が必要になります。明確な統合戦略をあらかじめ策定しておかないと、データのサイロ化やミスマッチが生じ、問題が複雑化は避けられません。

データ品質 ― データは人的な入力ミスであったり、部門ごとの定義の不統一であったり、旧式システムの併用などによって、簡単に品質が損なわれてしまいます。データの品質を保つには、データがシステムに入る段階でクリーニングや整合性の検証などを確実に実施する強力なガバナンスが求められます。

スケーラビリティとパフォーマンス ― データウェアハウスの設計に不備があると、パフォーマンスのボトルネックとなり、スケーラビリティを阻害して将来の成長の足かせになりかねません。適切な最適化が行われないと、データクエリの速度が低下し、ストレージ費用が増し、システムの反応も劣化します。データウェアハウスの導入時には、準備段階から将来を見据えた戦略的な設計が必要になります。

ビジネスの変化への適応 ― ビジネスが進化するとデータ要件も変わってきます。事業の合併や新製品の導入、レポーティング ニーズや顧客動向の変化など、データ要件に影響しうる要因は多く、すべての企業にとって、将来的にデータウェアハウスの調整が必要になるリスクは低くありません。

適正なアーキテクチャ設計とは

では、データウェアハウスのアーキテクチャを的確に設計するにはどうすればよいでしょうか。ここでは、設計段階で検討しておくべき重要事項を5つ紹介します。

1. ビジネス目標を明確に定義する ― データウェアハウスに何を求めているのか、データウェアハウスでどのような問題を解決したいのかを、あらかじめ明確にする必要があります。まず、自社のデータを十分に理解し、それがビジネスインテリジェンスにどのように活用できるのかを整理することが先決です。

2. データを監査する ― データソース、フォーマット、ボリュームについて詳細を記録し、データをいつでも監査できるように目録を準備しておく必要があります。データは企業にとって重要な資産であり、財産目録が必要になるのは当然と言えます。

3. デプロイメント モデルを選択する ― 利用可能なツールやプラットフォームを調べ、オンプレミス環境に実装するのか、完全にクラウド化するのか、両方にまたがるハイブリッド アプローチを採用すのかを決定します。

4. スケーラビリティを考慮する ― 潜在的なボトルネックを特定し、克服方法を事前に確認しておく必要があります。

5. 安定した自動プロセスを設計する ― 自動化された信頼できるExtract(抽出)、Transform(変換)、Load(ロード)またはExtract、Load、Transform(つまりETLまたはELT)パイプラインを設計することが、データを常に利用可能な状態に保つためには不可欠です。

代表的なデータウェアハウス ソリューション

Amazon Redshift ― すでにAWSを活用している企業にとっては有効な選択肢となります。

Google BigQuery ― 大規模なアナリティクス ワークロードに適しています。

Snowflake ― パフォーマンスとマルチクラウド サポートで高い評価を得ています。

Databricks  ― ML/AIワークロードと非構造化データの処理に強いという評価が定着しています。

Azure Synapse Analytics ― すでにSQLとSparkを活用しているユーザーに適しています。

まとめ

最新のデータウェアハウスは、単なる情報リポジトリにとどまらず、データドリブンが求められる現代のビジネス環境で企業戦略を支える重要なアセットとなるものです。正しく準備され、考え抜かれたアーキテクチャ設計が、適切なテクノロジーとプラクティスでサポートされれば、データウェアハウスは組織全体に価値をもたらすビジネスの強力な武器になります。逆に言えば、準備が不十分だと、効果を発揮できないリスクがあります。データウェアハウスを導入するからには、ビジネス目標に合致した的確なアーキテクチャを設計し、データ品質を維持し、スケーラブルなソリューションを確立してビジネスへの効果を最大限に高めましょう。

データウェアハウスのためのコスト効率とパフォーマンスに優れたストレージ ソリューションをお探しの場合は、お気軽にクライムにご相談ください。たとえば、StarWind Virtual SAN(VSAN)は、Hyper-V、vSphere、KVMクラスタ向けに高可用性(HA)に優れた共有ストレージを実現します。StarWind VSANでは、ハイパーバイザーホストのローカルストレージを利用して、仮想マシン(VM)向けに共有HAストレージを確保できるので、抜群の費用対効果が期待できます。詳しくは、クライムサポートまで。

 

 

コメントする -->

[Gluesync 2.1.1] Allowed Operation機能によるTruncate操作のサポート対応追加について

先日リリースされたGluesync 2.1.1にて、「Allowed Operation」と呼ばれる機能が追加されました。

この新機能は、ソースおよびターゲット間でレプリケーション対象とするデータベース操作を制御することができ、ユーザのニーズに応じたレプリケーションが実現できます。

スナップショット(全件レプリケーション)処理、CDC(差分レプリケーション)処理それぞれ設定箇所や対応が異なるため、それぞれ紹介します。

スナップショットの場合

従来のGluesyncでは、スナップショットモードとしてUpsertモードおよびInsertモードが提供されており、高速に処理できるInsertモードはターゲット側にレコードが存在しないケースで利用する機能となっていました。


このため、予めターゲット側でTruncateを実行するなどしてレコードがクリアされている状態でない場合、重複レコードエラーとなっていましたが、Gluesync 2.1.1では仕様変更があり、Insertモード利用実行時には自動的にターゲット側でTruncateクエリによってレコードをクリアされるようになりました。
これに伴い、Insertモード選択時の文言もアップデートされ、Truncateが実行される記載が追加されています。


ただ複数テーブルを1つのテーブルへ集約する(N対1構成)など、ターゲット側でのTruncateが運用上許可されない特定のケースでは、このTruncateによって必要なレコードが全消去されてしまいます。
この場合は、パイプライン(DB接続設定)の編集画面を開き、ターゲットセットアップ詳細設定 > カスタムプロパティ項目にて、”Disable truncate on target before snapshot inserts“というパラメータをドロップダウンリストから選択し有効化することで、スナップショット実行時にもターゲット側へのTruncateを実行しないように制御可能です。

CDCの場合

Gluesyncでは、ソーステーブルに対して実行された下記操作がターゲットテーブルへCDC(差分レプリケーション)されます。
・Insert
・Update
・Delete
・Truncate

GluesyncのCDCでは、エンティティ(レプリケーションジョブ)単位で許可する操作を制御可能です。
エンティティの編集画面を開き、設定 > オプション設定と調整 > 許可された操作をクリックすることで、CDCでレプリケーションする操作を指定します。

このように、Gluesyncの「Allowed Operation」機能を利用することで、ニーズに応じたレプリケーションを簡単に構成可能です。

タグ: , ,

Gluesyncのバージョンアップ方法

Gluesyncのバージョンアップ方法を紹介します。
現在利用中のGluesyncバージョンは、Webコンソール左上より確認可能です。
以下の例では、2.1.0 – build 9が利用されています。

バージョンアップは、Gluesync構成時に実行したdocker composeコマンドより実行します。
まず、現在動作しているGluesyncコンテナをdocker compose downコマンドにて停止します。

[root@asahi-gluesync gluesync-docker]# docker compose down
[+] Running 13/13
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-1       Removed                                                                                                                                     2.2s 
 ✔ Container gluesync-docker-reverse-proxy-1                  Removed                                                                                                                                     8.5s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-3-1     Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-3-1  Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-2-1  Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-gluesync-chronos-1               Removed                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-1    Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-grafana-1                        Removed                                                                                                                                     0.3s 
 ✔ Container gluesync-docker-portainer-1                      Removed                                                                                                                                     0.2s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-2-1     Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-prometheus-1                     Removed                                                                                                                                     0.2s 
 ✔ Container gluesync-docker-gluesync-core-hub-1              Removed                                                                                                                                     2.1s 
 ✔ Network gluesync-docker_default                            Removed

docker compose pullコマンドを実行し、DockerリポジトリよりGluesyncの最新イメージをPull(ダウンロードします。

[root@asahi-gluesync gluesync-docker]# docker compose pull
[+] Pulling 31/58
 ✔ gluesync-mssql-ct-target-2 Skipped - Image is already being pulled by gluesync-mssql-ct-target                                                                                                         0.0s 
 ✔ gluesync-mssql-ct-target-3 Skipped - Image is already being pulled by gluesync-mssql-ct-target                                                                                                         0.0s 
 ✔ gluesync-ibm-iseries-source-3 Skipped - Image is already being pulled by gluesync-ibm-iseries-source                                                                                                   0.0s 
 ✔ gluesync-ibm-iseries-source-2 Skipped - Image is already being pulled by gluesync-ibm-iseries-source                                                                                                   0.0s 
 ⠋ gluesync-mssql-ct-target [⣤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling                                                                                                                                                        12.1s 
 ✔ reverse-proxy Pulled                                                                                                                                                                                   1.7s 
 ✔ prometheus Pulled                                                                                                                                                                                      1.8s 
 ⠋ grafana [⣿⣿⣿⣿⣿⣿⣤⡀⣿⣿] 91.26MB / 197.6MB Pulling                                                                                                                                                        12.1s 
 ✔ portainer Pulled                                                                                                                                                                                       1.7s 
 ⠋ gluesync-ibm-iseries-source [⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling                                                                                                                                                     12.1s 
 ✔ gluesync-chronos Pulled                                                                                                                                                                                1.8s 
 ✔ gluesync-core-hub Pulled                                               

docker compose up -dコマンドを実行し、Gluesyncコンテナを起動します。

[root@asahi-gluesync gluesync-docker]# docker compose up -d
[+] Running 13/13
 ✔ Network gluesync-docker_default                            Created                                                                                                                                     0.1s 
 ✔ Container gluesync-docker-portainer-1                      Started                                                                                                                                     0.9s 
 ✔ Container gluesync-docker-gluesync-core-hub-1              Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-reverse-proxy-1                  Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-2-1     Started                                                                                                                                     0.6s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-1       Started                                                                                                                                     0.9s 
 ✔ Container gluesync-docker-prometheus-1                     Started                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-chronos-1               Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-3-1     Started                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-2-1  Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-3-1  Started                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-1    Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-grafana-1                        Started                                                                                                                                     1.1s 
[root@asahi-gluesync gluesync-docker]# 

Gluesync Webコンソールへログインし、画面左上を確認しバージョンアップされていることを確認します。

タグ: , ,

オフライン環境のDockerでGluesyncを実行

Gluesyncは評価用に事前構成されたdocker-compose.ymlを提供しています。

そのため、これをDocker composeが使用できる環境に配置してdocker compose up -dを実行すれば下記のように自動的にインターネット上のリポジトリからイメージをpull(ダウンロード)してきます。

しかし、当然ことながらこれはオフライン環境では下記のようにエラーで失敗します。

climb@offlinetest:~/gluesync-docker$ docker compose up -d
[+] Running 7/7
 ! grafana                         Interrupted      0.0s 
 ✘ prometheus Error                Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:40746->[::1]:53: read: connection refused  0.0s 
 ! gluesync-chronos                Interrupted      0.0s 
 ! gluesync-core-hub               Interrupted      0.0s 
 ! reverse-proxy                   Interrupted      0.0s 
 ! gluesync-postgresql-cdc-target  Interrupted      0.0s 
 ! gluesync-ibm-iseries-source     Interrupted      0.0s 
Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:40746->[::1]:53: read: connection refused

このため、オフライン環境で使用する場合、事前にコンテナのイメージを配置しておく必要があります。今回はdocker savedocker loadコマンドを使用してこれを実施する方法を紹介します。

オンライン環境でのイメージ取得

オンライン環境のDockerにて評価キットから展開したgluesync-dockerディレクトリへ移動し、docker compose pullを実行し、イメージを取得します。

climb@step:~$ cd gluesync-docker/
climb@step:~/gluesync-docker$ docker compose pull
[+] Pulling 57/57
 ✔ gluesync-ibm-iseries-source Pulled         28.4s 
 ✔ gluesync-chronos Pulled                    31.4s 
 ✔ gluesync-postgresql-cdc-target Pulled      37.1s 
 ✔ prometheus Pulled                           1.9s 
 ✔ grafana Pulled                              1.9s 
 ✔ reverse-proxy Pulled                       22.3s 
 ✔ gluesync-core-hub Pulled                    1.9s 

問題なく取得できていればdocker image lsでイメージを確認できます。

climb@step:~/gluesync-docker$ docker image ls
REPOSITORY                       TAG       IMAGE ID       CREATED        SIZE
molo17/gluesync-core-hub         latest    d75160f6137f   31 hours ago   499MB
molo17/gluesync-ibm-iseries      latest    a683d17a7de0   31 hours ago   488MB
molo17/gluesync-postgresql-cdc   latest    60addcb8cba6   31 hours ago   483MB
molo17/gluesync-chronos          latest    cf964252e130   38 hours ago   633MB
grafana/grafana                  latest    75006c93b887   5 days ago     722MB
prom/prometheus                  latest    a3bc50fcb50f   9 days ago     313MB
traefik                          v3.3      ff8877338069   2 months ago   224MB

イメージはdocker saveコマンドで保存できますが、複数あるため、今回は下記のbulksave.shスクリプトでsavesフォルダにまとめて保存するようにします。

#!/bin/sh
set -e
mkdir -p saves
docker images --format "{{.Repository}}:{{.Tag}} {{.Repository}}_{{.Tag}}" | while read image
do
  image_id=`echo $image | cut -d ' ' -f1`
  image_name=`echo $image | cut -d ' ' -f2 | tr -d "/"`

  docker save $image_id > ./saves/${image_name}.tar
done

スクリプトを実行するとsavesフォルダにまとめて保存されています。このスクリプトでは存在しているすべてのイメージを保存しますので、必要に応じてdocker imagesコマンドに–filterオプションを追加し、不要なイメージは除外するように変更してください。

climb@step:~/gluesync-docker$ chmod 755 bulksave.sh 
climb@step:~/gluesync-docker$ ./bulksave.sh
climb@step:~/gluesync-docker$ ls saves
grafanagrafana_latest.tar  molo17gluesync-chronos_latest.tar  molo17gluesync-core-hub_latest.tar  molo17gluesync-ibm-iseries_latest.tar  molo17gluesync-postgresql-cdc_latest.tar  promprometheus_latest.tar  traefik_v3.3.tar

この保存したイメージも含めてオフライン環境にgluesync-dockerディレクトリごとコピーします。

climb@step:~/gluesync-docker$ scp -r ../gluesync-docker climb@192.168.77.77:/home/climb/
climb@192.168.77.77's password: 
core-hub-metrics.json                      100%   38KB  13.2MB/s   00:00
dashboard.yml                              100%  291   383.3KB/s   00:00
datasource.yml                             100%  180   321.3KB/s   00:00
gluesync.com.jks                           100% 3068     3.5MB/s   00:00
gs-license.dat                             100%  868   953.1KB/s   00:00
bootstrap-core-hub.json                    100%   76   111.3KB/s   00:00
prometheus.yml                             100%  401   646.5KB/s   00:00
molo17gluesync-core-hub_latest.tar         100%  481MB 186.1MB/s   00:02
molo17gluesync-postgresql-cdc_latest.tar   100%  466MB 186.4MB/s   00:02
traefik_v3.3.tar                           100%  214MB 149.5MB/s   00:01
promprometheus_latest.tar                  100%  300MB 225.8MB/s   00:01
grafanagrafana_latest.tar                  100%  698MB 176.2MB/s   00:03
molo17gluesync-chronos_latest.tar          100%  617MB 229.2MB/s   00:02
molo17gluesync-ibm-iseries_latest.tar      100%  471MB 155.6MB/s   00:03
certs.yml                                  100%  151    96.1KB/s   00:00
traefik.yml                                100%  342   177.1KB/s   00:00
logback.xml                                100% 1267   757.4KB/s   00:00
gluesync-cert.pem                          100% 1974     1.5MB/s   00:00
grafanagrafana_latest.tar                  100%  698MB 166.9MB/s   00:04
security-config.json                       100%  293   244.0KB/s   00:00
docker-compose.yml                         100% 8878     6.7MB/s   00:00
gluesync-key.pem                           100% 1849     1.2MB/s   00:00
bulksave.sh                                100%  284   483.6KB/s   00:00

オフライン環境でのイメージのロード

コピーしたgluesync-dockerディレクトリに移動します。

climb@step:~/gluesync-docker$ ssh 192.168.77.77
climb@192.168.77.77's password: 
Linux offlinetest 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jul 24 10:50:55 2025 from 192.168.77.79
climb@offlinetest:~$ cd gluesync-docker/

一つずつ保存したイメージのtarをdocker loadコマンドで読み込むこともできますがここでは下記のスクリプトでまとめて読み込んでします。

climb@offlinetest:~/gluesync-docker$ cat bulkload.sh 
#!/bin/sh
for file in saves/*.tar; do
  docker load -i "$file"
done
climb@offlinetest:~/gluesync-docker$ chmod 755 bulkload.sh 
climb@offlinetest:~/gluesync-docker$ ./bulkload.sh 
08000c18d16d: Loading layer [==================================================>]  8.121MB/8.121MB
a79fd921bc73: Loading layer [==================================================>]   2.56kB/2.56kB
9cc7b6091a3e: Loading layer [==================================================>]   8.67MB/8.67MB
97b6092cb34c: Loading layer [==================================================>]  26.55MB/26.55MB
47ef72cb0b55: Loading layer [==================================================>]  223.2kB/223.2kB
41cfb2f3b7e1: Loading layer [==================================================>]  111.1kB/111.1kB
e1b6356de126: Loading layer [==================================================>]  394.2MB/394.2MB
0e16bb8c20c8: Loading layer [==================================================>]  294.1MB/294.1MB
4d1cec8ac292: Loading layer [==================================================>]  37.89kB/37.89kB
c27dd65cf52a: Loading layer [==================================================>]   5.12kB/5.12kB
Loaded image: grafana/grafana:latest
7cc7fe68eff6: Loading layer [==================================================>]  77.88MB/77.88MB
0a00f6ce5fb7: Loading layer [==================================================>]  9.561MB/9.561MB
943faa7467a0: Loading layer [==================================================>]  47.51MB/47.51MB
d22cc68b10d7: Loading layer [==================================================>]   5.12kB/5.12kB
5a0f38a32659: Loading layer [==================================================>]  1.536kB/1.536kB
07ba18ad0976: Loading layer [==================================================>]  13.83MB/13.83MB
124b774a0b12: Loading layer [==================================================>]  4.096kB/4.096kB
15583e9073b8: Loading layer [==================================================>]  9.728kB/9.728kB
1b460b1eb790: Loading layer [==================================================>]  39.42kB/39.42kB
25873ba4bfe3: Loading layer [==================================================>]  175.6kB/175.6kB
21f0912ce811: Loading layer [==================================================>]   2.56kB/2.56kB
2ffe43ddab52: Loading layer [==================================================>]  4.608kB/4.608kB
18a78bb070bd: Loading layer [==================================================>]  4.096kB/4.096kB
7dba9bb060c8: Loading layer [==================================================>]  19.97kB/19.97kB
a91e752ef628: Loading layer [==================================================>]    255kB/255kB
6b46174d5e90: Loading layer [==================================================>]  9.216kB/9.216kB
f43d597bacf0: Loading layer [==================================================>]  25.09kB/25.09kB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
74877e0efd6a: Loading layer [==================================================>]  57.21MB/57.21MB
189e5c7c2d81: Loading layer [==================================================>]  384.1MB/384.1MB
0e358b9565d7: Loading layer [==================================================>]  69.63kB/69.63kB
46c609cd3326: Loading layer [==================================================>]   56.7MB/56.7MB
Loaded image: molo17/gluesync-chronos:latest
8d853c8add5d: Loading layer [==================================================>]  77.83MB/77.83MB
bec6e6f75d3a: Loading layer [==================================================>]  350.6MB/350.6MB
64833d7e8df2: Loading layer [==================================================>]   20.9MB/20.9MB
6fa85aa38ed6: Loading layer [==================================================>]  489.5kB/489.5kB
5721c53402cb: Loading layer [==================================================>]  6.774MB/6.774MB
14e212539af1: Loading layer [==================================================>]  24.06kB/24.06kB
d71eb2cc9fff: Loading layer [==================================================>]  2.048kB/2.048kB
805690ba64f0: Loading layer [==================================================>]  3.072kB/3.072kB
91fe7aa6c83a: Loading layer [==================================================>]  3.072kB/3.072kB
21556ecc8350: Loading layer [==================================================>]  3.584kB/3.584kB
db18493ecfca: Loading layer [==================================================>]  3.584kB/3.584kB
b0dd230dcb86: Loading layer [==================================================>]  47.64MB/47.64MB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
c82aaef265b1: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: molo17/gluesync-core-hub:latest
fb4a92957d0c: Loading layer [==================================================>]   20.9MB/20.9MB
41f27d21f926: Loading layer [==================================================>]  489.5kB/489.5kB
eb69e4939385: Loading layer [==================================================>]  6.774MB/6.774MB
3162aeb41db4: Loading layer [==================================================>]  24.06kB/24.06kB
8bc5a96ce609: Loading layer [==================================================>]  2.048kB/2.048kB
c534fb8b0541: Loading layer [==================================================>]  3.072kB/3.072kB
8d45e791d0a1: Loading layer [==================================================>]  3.072kB/3.072kB
367c68a25e66: Loading layer [==================================================>]  3.584kB/3.584kB
3fcc70161be9: Loading layer [==================================================>]  3.584kB/3.584kB
76a88d2ac879: Loading layer [==================================================>]  36.75MB/36.75MB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
dc765fd0e258: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: molo17/gluesync-ibm-iseries:latest
8c10cec765ff: Loading layer [==================================================>]   20.9MB/20.9MB
27e5aab6aead: Loading layer [==================================================>]  489.5kB/489.5kB
8f647a62c02e: Loading layer [==================================================>]  6.774MB/6.774MB
7cb9b54cf4e6: Loading layer [==================================================>]  24.06kB/24.06kB
e1c67e777fed: Loading layer [==================================================>]  2.048kB/2.048kB
6746c71279b3: Loading layer [==================================================>]  3.072kB/3.072kB
835b1bee674f: Loading layer [==================================================>]  3.072kB/3.072kB
76ba3ab2a760: Loading layer [==================================================>]  3.584kB/3.584kB
8b5bb6db1f76: Loading layer [==================================================>]  3.584kB/3.584kB
0addd6c13f8f: Loading layer [==================================================>]   31.8MB/31.8MB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
49ad86643221: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: molo17/gluesync-postgresql-cdc:latest
1e604deea57d: Loading layer [==================================================>]  1.458MB/1.458MB
6b83872188a9: Loading layer [==================================================>]  2.455MB/2.455MB
51058541ddde: Loading layer [==================================================>]  159.4MB/159.4MB
aced3db9898b: Loading layer [==================================================>]  150.7MB/150.7MB
735c0da4fd32: Loading layer [==================================================>]  4.096kB/4.096kB
349de0ee3a82: Loading layer [==================================================>]  13.31kB/13.31kB
f19ace59c2b4: Loading layer [==================================================>]  5.632kB/5.632kB
5797eee2097b: Loading layer [==================================================>]  62.46kB/62.46kB
bd712c1df0b0: Loading layer [==================================================>]  1.536kB/1.536kB
83608e9fa217: Loading layer [==================================================>]  5.632kB/5.632kB
Loaded image: prom/prometheus:latest
31b41022049d: Loading layer [==================================================>]  1.688MB/1.688MB
3eae8a7fbd15: Loading layer [==================================================>]  215.1MB/215.1MB
3fc935bcee95: Loading layer [==================================================>]  2.048kB/2.048kB                                                                                                                
climb@offlinetest:~/gluesync-docker$ 

loadが完了すると下記のようにイメージが読み込まれていることがわかります。

climb@offlinetest:~/gluesync-docker$ docker image ls
REPOSITORY                       TAG       IMAGE ID       CREATED        SIZE
molo17/gluesync-core-hub         latest    d75160f6137f   32 hours ago   499MB
molo17/gluesync-ibm-iseries      latest    a683d17a7de0   32 hours ago   488MB
molo17/gluesync-postgresql-cdc   latest    60addcb8cba6   32 hours ago   483MB
molo17/gluesync-chronos          latest    cf964252e130   39 hours ago   633MB
grafana/grafana                  latest    75006c93b887   5 days ago     722MB
prom/prometheus                  latest    a3bc50fcb50f   9 days ago     313MB
traefik                          v3.3      ff8877338069   2 months ago   224MB

この状態であれば、インターネットから取得しなくとも、これらのイメージがすでに利用できますのでdocker compose up -dでコンテナを起動できます。

climb@offlinetest:~/gluesync-docker$ docker compose up -d
[+] Running 8/8
 ✔ Network gluesync-docker_default                             Created   0.1s 
 ✔ Container gluesync-docker-gluesync-core-hub-1               Started   0.4s 
 ✔ Container gluesync-docker-reverse-proxy-1                   Started   0.5s 
 ✔ Container gluesync-docker-prometheus-1                      Started   0.8s 
 ✔ Container gluesync-docker-gluesync-postgresql-cdc-target-1  Started   0.8s 
 ✔ Container gluesync-docker-gluesync-chronos-1                Started   1.0s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-1     Started   0.9s 
 ✔ Container gluesync-docker-grafana-1                         Started   1.2s 
コメントする -->

Gluesyncの技術お問い合わせに必要な情報

評価版・製品版のGluesyncをご使用時に技術的なお問合せをしていただく際は、下記の情報のご提供をお願いいたします。

Gluesyncバージョン

Gluesync Webコンソールへログインし、左上メニューから確認可能です。

Gluesync通知ハブのスクリーンショット

Gluesync Webコンソール右上の鐘アイコン > 通知ハブの詳細を表示をクリックすることで、

エラー全文か確認できるため、スクリーンショットを取得します。

エンティティ(レプリケーションジョブ)のスクリーンショット

パフォーマンスに関して調査したい場合、対象エンティティをクリックすることでパフォーマンスに関するダッシュボードが表示されます。
この画面をスクリーンショットします。

Gluesyncログファイル

以下コマンドを実行し、Gluesyncのログをzip形式で出力します。
docker compose logs > gluesync-logs.txt && zip gluesync-logs.zip gluesync-logs.txt && rm gluesync-logs.txt

[オプション] 追加のGluesyncログファイル

※本手順は、クライムサポートより要求された場合に出力します。
Gluesyncの追加ログファイルは、デフォルト設定ではdocker-compose.ymlで定義されたDB接続エージェントおよびCore Hubごとに、logback.xmlの保持ルールに従って「gluesync-xxx-logs」フォルダへ保存されます。
例えば、以下の例ではdocker-compose.yml内で6つのDB接続エージェントと1つのCore Hubが定義されており、それぞれログが出力されています。

下記コマンドを実行して、logsと名のついたログフォルダが選択されていることを確認し、

ls -d *logs*/

以下のコマンドより、各logsフォルダを圧縮しlog.zipとしてエクスポートし、ご提供お願いします。

zip -r log.zip *logs*/

 

タグ: , , , ,

[Gluesyncブログ] タイムゾーン変更方法

Gluesyncは、Gluesyncコンテナが動作するコンテナランタイム(dockerなど)やOSのタイムゾーン設定に関わらず、デフォルト設定でUTCタイムゾーンで動作します。

ただこのタイムゾーンは変更可能であり、本ブログでは対応方法を紹介します。
まず、Gluesyncのツールキットが構成されたディレクトリへ移動し、docker-compose.ymlファイルを見つけます。
念のため、編集前のdocker-compose.ymlファイルはコピーし別名保存(cpコマンドなど)しておくことを推奨します。

cp docker-compose.yml old_docker-compose.yml

次に、vimやnanoなどのエディタを利用してdocker-compose.ymlを開きます。

vim docker-compose.yml

このファイル内では、Gluesyncの各種DB接続エージェントやCore HubといったGluesyncサービスが定義されており、それぞれenvironment:内でタイムゾーンを指定します。
例えば、以下の例ではgluesync-oracle-triggers-sourceというサービス内にて、environment:のパラメータとしてタイムゾーン(TZ)はコメントアウトされており、デフォルト値のUTCで動作していることがわかります。

gluesync-oracle-triggers-source:
image: molo17/gluesync-oracle-triggers:latest
# deploy:
# resources:
# limits:
# cpus: "2.0"
# memory: 2.0G
environment:
- type=source
- ssl_enabled=true # set to true if you want to activate TLS encryption
- LOG_CONFIG_FILE=/opt/gluesync/data/logback.xml
# Time zone: defaults to UTC, you can change it to match yours (https://docs.diladele.com/docker/timezones.html)
# - TZ: "Etc/UTC"

日本のタイムゾーンへ変更する場合は、コメントアウトを解除し以下のように更新します。

gluesync-oracle-triggers-source:
image: molo17/gluesync-oracle-triggers:latest
# deploy:
# resources:
# limits:
# cpus: "2.0"
# memory: 2.0G
environment:
- type=source
- ssl_enabled=true # set to true if you want to activate TLS encryption
- LOG_CONFIG_FILE=/opt/gluesync/data/logback.xml
- TZ=Asia/Tokyo

変更後は、docker-compose up -dコマンドを実行することで、タイムゾーンが更新された状態でGluesyncコンテナが起動し、指定したタイムゾーンとしてログ上でも表記されます。

2025-07-17T09:34:05.659 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:10.659 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:15.660 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:20.660 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:23.793 c.m.g.i INFO Stats: {"os":{"family":"Debian GNU/Linux","manufacturer":"GNU/Linux","version":"12","codeName":"bookworm","buildNumber":"5.14.0-570.23.1.el9_6.x86_64","systemUptime":75883,"systemBootTime":1752636578},"cpu":{"cpuVendor":"GenuineIntel","cpuName":"Intel(R) Xeon(R) D-2146NT CPU @ 2.30GHz","cpuFamily":"6","cpuModel":"85","physicalProcessorCount":6,"logicalProcessorCount":6,"processorCpuLoad":[0.02,0.010101010101010102,0.020202020202020204,0.0297029702970297,0.0297029702970297,0.01],"systemCpuLoad":0.018333333333333333,"interrupts":167592579,"systemCpuTicks":[5696850,18140,2315770,445202690,7300,671240,715640,0]},"ram":{"total":11700,"available":7506},"jvmRam":{"total":2926,"totalFree":2887,"allocated":64,"allocatedFree":25,"used":38},"networkIfs":[{"name":"eth0","iPv4address":["172.18.0.3"],"speedInMegabits":9536,"megabytesReceived":234,"megabytesSent":682}]}
[root@asahi-minikube gluesync-core-hub-logs]#

タグ: , , , , , , ,

【2025/6/25オンライン開催セミナー録画】Gluesyncで実現するAerospike・RDB連携〜ミリ秒レスポンスを支える仕組みと導入事例〜

【主な内容】

・NoSQL市場が伸びている背景
・NoSQLとRDBの比較 – ユースケース
・Gluesyncによるノンコーディングでのデータ連携


【このような方におすすめ】

RDBで限界を感じており、NoSQLを一部導入したい
RDBとNoSQLのデータ連携を自前でやっていて辛い
データ転送や変換処理に時間がかかりすぎている


▼ご登録はこちら

タグ: ,

Gluesync 2: Oracle 19cとPostgreSQL 16.4間でのリアルタイムデータ統合

レガシーのOracle 19cからPostgreSQL 16.4へ数分で移行可能ですか?はい。

🔥🔥このデモでは、GluesyncがOracleマルチテナントDB(Xstream経由)とPostgreSQLの間でリアルタイムデータレプリケーションを迅速に設定する方法を示します。カスタムコードは不要です。手順解説動画をご覧ください 👇

タグ: , ,

YugabyteDB agent for Gluesync: 分散型SQLによるリアルタイムデータ統合を実現

yugabytedb agent for gluesyncYugabyteDB agent for Gluesync が利用可能になりました。これにより、YugabyteDB 分散型 SQL データベースとのシームレスな統合が実現します。この新しいエージェントは、双方向統合と完全な変更データキャプチャ(CDC)機能をサポートし、企業はリアルタイムでデータの同期とレプリケーションを行うことができます。オンプレミス環境またはクラウド環境で YugabyteDB を使用する場合でも、YugabyteDB Agent for Gluesync は安全かつ効率的なデータ統合を保証します。

YugabyteDB:現代的な分散型SQLデータベース

YugabyteDBは、ミッションクリティカルなアプリケーション向けに設計された高性能なクラウドネイティブ分散型SQLデータベースです。PostgreSQL互換性、高可用性、水平スケーラビリティを組み合わせた独自のアーキテクチャにより、データインフラストラクチャの現代化を目指す組織から採用が進んでいます。新しいYugabyteDB agent for Gluesyncは、この強力なデータベースに高度なデータ統合機能を追加し、エンタープライズデータエコシステムへの組み込みを容易にします。

Gluesyncとの統合:スマートな接続性と信頼性

YugabyteDBエージェントを活用することで、Gluesync 2.0はYugabyteDBと他のシステム間のリアルタイムデータパイプラインを構築可能です。エージェントはソースとターゲットの両方の構成をサポート、データ移行、ハイブリッドクラウドアーキテクチャ、リアルタイム同期など、多様なユースケースに対応する柔軟性を提供します。

エージェントは、YugabyteDBの組み込みJDBCスマートドライバー経由でYugabyteDBに接続し、クラスター認識やロードバランシングなどの機能を活用します。これにより、複雑な分散環境でも最適な接続性を確保します。

YugabyteDBエージェントの主要な機能

YugabyteDB Agent for Gluesyncには、データ統合を簡素化・強化するための複数の機能が搭載されています:

  • 変更データキャプチャ (CDC): エージェントはYugabyteDBのレプリケーションスロット技術を活用し、変更をリアルタイムでキャプチャしてレプリケートします。これにより、データベースのパフォーマンスに影響を与えることなく、システム間でのデータ一貫性が確保されます。
  • 広範な互換性: YugabyteDBバージョン2.0以降に対応しています。
  • スマートドライバー統合: クラスター認識機能を備えた組み込みのJDBCスマートドライバーを使用して、YugabyteDBとのシームレスな接続を確立します。
  • 自動ロードバランシング: クラスターノード間で接続負荷を分散し、最適なパフォーマンスを実現します。
  • ソースとターゲットのサポート: エージェントはYugabyteDBをデータソースとターゲットの両方として機能させ、双方向の統合機能を提供します。

YugabyteDBコネクタの構成

YugabyteDBエージェントの設定は簡単で、Gluesyncの直感的なウェブインターフェースまたはAPIを通じて完了できます。主要な設定項目は以下の通りです:

  • JDBC接続:エージェントはネイティブJDBCスマートドライバー経由でYugabyteDBに接続します。
  • CDC設定:ソース設定の場合、エージェントはレプリケーションスロットを自動的に設定し管理します。

YugabyteDBをGluesyncと組み合わせて使用するメリット

YugabyteDBエージェントは、データ運用を最適化する企業に数多くのメリットを提供します。CDC機能により、組織は変更をリアルタイムで捕捉し、システム間でのデータ一貫性を保証します。エージェントはYugabyteDBの分散アーキテクチャに特化して設計されており、YugabyteDBインスタンスが水平スケールする際にクラスター構成をスムーズに処理します。

シームレスなハイブリッドクラウド統合を実現し、オンプレミスのYugabyteDBインスタンスとクラウドサービスをつなげたり、マルチクラウド展開のYugabyteDBを連携させることができます。複雑なデータ統合シナリオを簡素化することで、企業はインフラ管理ではなくインサイト抽出に集中できます。

一般的な利用ケース

YugabyteDBエージェントは多様な利用ケースに対応します。組織は、データベースのモダン化イニシアチブの一環としてYugabyteDBへのデータ移行をシームレスに実行したり、分析プラットフォームへの変更をリアルタイムで反映させながらACID準拠を維持できます。

YugabyteDBを複数のクラウドやオンプレミス環境の他のデータベースと同期し、災害復旧のためのレプリケーション機能を提供し、YugabyteDBをバックエンドとするマイクロサービスとアプリケーションエコシステムの他のコンポーネントを接続します。

なぜGluesyncを選ぶべきか?

Gluesync は、複雑なデータ同期タスクを簡素化するリアルタイムデータ統合プラットフォームです。将来対応型のアーキテクチャと、YugabyteDBを含む幅広いデータベースのサポートにより、Gluesyncは企業がデータワークフローを最適化するための信頼性が高くスケーラブルなソリューションを提供します。リレーショナルデータベース、NoSQLシステム、分散型SQL、クラウドネイティブプラットフォームのいずれを使用する場合でも、Gluesyncはすべての統合ニーズに対応するソリューションを提供します。

YugabyteDB Agent for Gluesyncが利用可能に:(Gluesync 2.0.10と互換性あり)これにより、企業はYugabyteDBデータベースの真のポテンシャルを解放できます。データ移行、ハイブリッドシステムの同期、リアルタイムパイプラインの構築など、あらゆるシナリオで成功するためのツールが揃っています。

タグ: , ,

Gluesync for Google BigQuery: Google BigQueryとのシームレスなデータ同期を実現する最速のソリューション

Gluesync for Google BigQuery

Gluesync for Google BigQuery

Google BigQueryへのデータ統合は、高速で効率的かつコスト効果が高いべきです。しかし、多くの伝統的なデータ同期ツールはサードパーティのJDBCドライバーに依存しており、不要な複雑さを導入し、パフォーマンスを低下させ、回避可能なライセンスコストを追加します。Gluesyncは、ネイティブのGoogle BigQuery SDKを活用する異なるアプローチを採用し、高速なデータ移動、コスト削減、リアルタイム効率を実現します。

JDBC不要のGoogle BigQueryデータ同期のスマートなアプローチ

Google BigQueryは、大規模な高速分析向けに設計された強力なサーバーレスデータウェアハウスです。しかし、ボトルネックなしでデータを効率的にBigQueryに投入するには、堅牢で最適化された同期ソリューションが必要です。

Gluesyncは、JDBCベースのソリューションのオーバーヘッドなしに、高速なデータ転送を処理するように設計されたシームレスでリアルタイムなデータ同期ソリューションです。多くの伝統的なETLツールは、BigQueryとの接続にサードパーティのJDBCドライバーに依存していますが、このアプローチは本質的に非効率的です。JDBCドライバーは追加の翻訳レイヤーを導入し、データ取り込みを遅らせ、処理遅延を増大させます。さらに、これらのドライバーの多くは高額なライセンス料金を必要とし、組織が回避できるコストを追加します。

Gluesyncはこの問題を完全に解消します。Google BigQuery SDKを使用することで、BigQueryのAPIとの直接通信を可能にし、データ取り込みの高速化、遅延の低減、サードパーティドライバーへの依存ゼロを実現します。これにより、大規模なデータオペレーションを管理する企業にとって、より信頼性が高くコスト効果の高いソリューションが提供されます。

JDBCを超えて:SDKベースの統合が重要な理由

多くのデータ統合ソリューションは、データベース接続の標準化された方法としてJDBCドライバーに依存しています。しかし、BigQueryのような現代のクラウドベースアーキテクチャでは、この方法は最適化されていません。JDBCベースの統合の制限には以下の点が挙げられます:

  • パフォーマンスのボトルネック:JDBCは追加の処理ステップを必要とし、データ転送を遅延させます。
  • コストの増加:多くのJDBCドライバーは商用ライセンスを必要とし、不要な費用が発生します。
  • 最適化の制限:JDBCは汎用の接続レイヤーであり、BigQueryの強力なネイティブ機能を十分に活用できません。

一方、Gluesyncの直接SDK統合は、データがより高速かつ効率的に移動することを保証します。JDBCの制限がないため、GluesyncはBigQueryのネイティブ機能を完全に活用し、リアルタイムストリーミングとバッチインジェストを容易に処理できます。Oracle、MySQL、PostgreSQL、MongoDB、Couchbase、DynamoDB、またはその他の対応ソースから同期する場合でも、GluesyncはデータをBigQueryに迅速かつ信頼性高く送信します。

追加コストなしで、比類ないパフォーマンス

組織がBigQueryとの統合時に直面する最大の課題の一つは、過剰なコストをかけずに高速なデータ取り込みを実現することです。多くの企業は、基本的な接続を可能にするため、第三者のJDBCライセンス料金に数千ドルを費やしています。

Gluesyncはこれらの追加コストを排除しつつ、優れたパフォーマンスを提供します。BigQueryのAPIと直接通信するため、遅延を削減しスループットを最大化し、データが可能な限り迅速にクエリ可能になるようにします。リアルタイムストリーミングやバッチインジェストのいずれを必要とするビジネスでも、Gluesyncは両方のシナリオを比類ない効率で処理するように設計されています。

JDBCが導入するミドルウェアのオーバーヘッドを排除することで、Gluesyncは組織がBigQueryのネイティブ機能を完全に活用できるようにします。これにより、秒単位の速度が求められる高速データ環境で事業を展開する企業にとって、理想的なソリューションとなります。

Google BigQueryの真のポテンシャルを解き放つGluesync

Google BigQuery用のGluesyncを使用すれば、サードパーティのJDBCドライバーの制限なしに、より高速で効率的なデータ同期を実現できます。パフォーマンスのボトルネックや不要なライセンス料金から解放され、ビジネスの速度に合わせてデータを移動させましょう。JDBCなしでGoogle BigQueryのデータ同期を体験しましょう!

タグ: , , , , ,

NoSQL/RDBMからApache KafkaへGluesync経由でCDC(Change Data Capture:変更データキャプチャ)

Apache Kafkaがクラウドネイティブデータレプリケーター「GlueSync」のターゲットとして利用可能

クラウドネイティブデータレプリケーター「GlueSync」の新たなターゲットとしてApache Kafkaが追加に。この新たな互換性により、KafkaのユーザーはGlueSyncの低遅延と高帯域幅の機能を、トランザクションのデータを一切失うことなく利用できるようになります!

これにより、企業はGlueSyncを使用して、主要なRDBMSとAEROSPIKE, MongoDB, Couchbaseなどの NoSQLデータベースからApache Kafkaへのリアルタイムデータレプリケーションが可能になり、異種システム間のデータストリーミングやイベント駆動型アーキテクチャなどのユースケースを実現できます。また、Kafkaトランザクションサポートも含まれます。

GlueSyncは、オンプレミスまたはクラウドインフラストラクチャ向けのプラグアンドプレイソリューションで、高速なデータオフロード、キャッシュ、分析、モバイルユースケースを提供します。オンザフライのデータモデリング機能、超低遅延(最近のベンチマークでは1000トランザクションあたり平均15msに対し、Debziumの2秒)、そして数分で設定可能なセットアップにより、GlueSyncはデータモダナイゼーションの旅の理想的なパートナーです。

 

2025年6月25日 14:00 PM開催:オンラインセミナー「Gluesyncで実現するAerospike・RDB連携〜ミリ秒レスポンスを支える仕組みと導入事例〜」

タグ: , , , , , , , ,

Database Performance Analyzer (DPA) 2025.2 リリース

Database Performance Analyzer (DPA) 2025.2の一般提供開始(GAリリース)がスタートしました。今回のリリースでは、DPAにAIの力を活用した新機能「AI Query Assist」が追加されました。この機能はSQLを再最適化してパフォーマンスを向上させ、問題のあるクエリの平均解決時間を短縮します。詳細な機能や今回のDPAリリースに含まれるその他の新機能については、以下をご覧ください。

AI Query Assist

 AI Query Assist Demo

最適なパフォーマンスを発揮しながら希望の結果を生成するクエリを書くことは、特に複雑なSQLやスキーマが十分に理解されていない場合、困難な作業です。さらに、パフォーマンスの悪いクエリをDB管理者や開発者が書き直すには、試行錯誤を繰り返すため、多大な時間がかかることがあります。

AI Query Assistは、SQLパフォーマンス向けにトレーニングされた AIを活用し、機能的な等価性を維持しつつ、より高いパフォーマンスを実現するクエリを専門的に再作成します。このAI機能は制御された環境内で動作し、機密性の高い個人識別情報(PII)が完全にマスクされ、安全に保護されます。AI Query Assistは現在SQL Serverのクエリ最適化をサポートしていますが、今後のリリースでより広範なDBMSサポートが予定されています。

このAI機能は、SQLテキストと実行計画をインプットとして受け取り、DBMSがクエリを実行する方法に関する洞察を基にクエリを再作成(最適化)します。DDLには実行計画がないため、DDL文は最適化できません。最適化結果は次の通りです:

  • Summary: クエリが最適化された方法の概略説明
  • Thinking: AIが最適化時に考慮したポイントの説明
  • 説明: クエリが最適化された詳細な説明
  • 最適化されたSQL: DPAは、元のSQLテキストと最適化されたSQLテキストを並べて表示します

AIは新興技術であり、継続的に改善されています。したがって、最適化結果は採用前に分析およびテストする必要があります。

AI Quest Assistの使用

この機能を使用するための前提条件は次のとおりです:

  • Platform Connect: AI Query Assistを有効にする最初のステップは、DPAのオプションページにあるPlatform Connectリンクに従って、DPAのPlatform Connectコンポーネントを設定することです。AI Query Assist機能がオンになっていることを確認してください。
  • Licensing: この機能を使用するには、監視対象のSQL ServerインスタンスにDBSHまたはDBSHDSライセンスが割り当てられている必要があります。
  • User Permissions: DPA管理者または監視対象インスタンスの「監視管理」権限を持つユーザーは、最適化リクエストを送信できます。読み取り専用ユーザーまたは監視対象インスタンスの「表示」権限を持つユーザーは、最適化結果を確認できますが、新しい最適化リクエストを送信できません。

最適化の取得:

  1. 問題のあるクエリのクエリ詳細ページに移動します。このページへのアクセス方法は複数ありますが、最も一般的な方法は、トレンドページチャートからSQLハッシュをクリックすることです。
  2. AI クエリアシスト タブをクリックします
  3. ドロップダウンからプランを選択します
  4. 「SQL をプラン用に最適化」ボタンをクリックします。これにより、最適化リクエストが SolarWinds AI に送信され、完了まで数秒から数分かかる場合があります。これは主にクエリの複雑さに依存します。
  5. 「最適化を表示」をクリックして最適化結果を確認します。

新しい最適化のリクエスト

 

PostgreSQL の実行計画とチューニングのアドバイス

PostgreSQL のパラメーター化クエリ(バインド変数を使用するクエリ)では、PostgreSQL は自動的に実行計画を生成しません。これにより、DPA がクエリのパフォーマンスに関する詳細な洞察を提供することが困難になります。

このリリースでは、DPAがPostgreSQLに対してパラメーター化されたクエリのプランを生成するように明示的に要求します。実行プランの詳細を確認できるメリットに加え、プランを活用する機能(例:テーブルチューニングやインデックスアドバイス)の利便性が向上します。

IPv6

DPAは現在、IPv6を完全にサポートしており、IPv6またはハイブリッドネットワークでDPAを使用可能です。IPv6アドレスを指定する際は、次のように角括弧で囲むことが推奨されます:

  • ポート番号を指定するURLでは角括弧を使用してください:
    • https://[::1]:8080
    • https://[fd42:8204:8306:c108:250:56ef:fe98:9466]:3000
  • ネットワーク設定、ping コマンドなどでは角括弧を使用しないでください:
    • ping6 fd42:8204:8306:c108:250:56ef:fe98:9466

 

 

タグ: , , , , ,

DBA:データベース管理の働きに付いて

最近議論になるの一つが「DBAチームの有効性を管理するために、どのような指標や測定基準が有用か?」というものです。

この質問に答えるのは簡単ではありません。なぜなら、優れたDBAは「多才な専門家」でなければならないからです。つまり、DBAは多くの異なるタスク(または専門分野)に精通している必要があります。そして、これらの各「専門分野」には、成功を測定するための複数の指標が存在します。例えば、ある指標では「成功的に処理されたSQL文の件数」です。しかし「成功」とは何を意味するかも疑問です!単に正しい結果が返されたことを指すのか、それとも合理的な時間内に正しい結果が返されたことを指すのでしょうか?

「合理的な時間」とは何でしょうか?2秒?1分?30分のどこになるでしょうか!サービスレベル契約(SLA)が確立されていない場合、DBAの応答時間を測定することは不公平で、不可能です。DBAは、コストと応答時間の両面から合理的なSLAの確立と管理に参加する必要があります。そうでないと、達成不可能なタスクを任されることになるでしょう。

インシデント報告の件数を測定する指標も提案されました。ただし、これはDBAに影響を与える可能性のある真の問題に限定される場合に限って問題ありません。DBAは、DBMSベンダによるDBMSのバグや、管理部門の無理なスケジュールや開発チームの過剰な要求により強制された設計要素については責任を負うべきものではありません。

可用性指標を使用するアイデアは良いかもしれませんが、環境と組織の可用性要件を考慮する必要があります。つまり、必要な可用性は何かということです。再びサービスレベル契約に戻ります。DBMSが望ましい可用性レベルを達成するための技術的インフラを提供しない場合、または組織が第三者のベンダーからデータベース可用性ソリューションを購入しない場合、DBAが可用性を達成できなかったとしても厳しく評価すべきではありません。もちろん、使用中のDBMSの購入を決定した場合はDBAが責任を負うべきですが、これは通常の場合にあてはまりません。多くのDBAは、DBMSが選択された後で採用されるからです。

問題への対応に基づくメトリクス(尺度)はどうでしょうか?このメトリクスは、問題が解決されたことを意味するわけではありませんが、DBAが「クレームを申し立てた」エンティティに対応し、解決に向けて取り組んでいることを示します。このようなメトリクスは、データベース管理をサービスやヘルプデスクのような機能として扱う傾向があります。しかし、これはDBAを評価するメトリクスとしてはあまりにも狭すぎるでしょう。DBAは問題への対応だけでなく、はるかに多くの業務を行っています。

DBAの評価メトリクスは、DBAが働く環境を理解した上で開発する必要があります。これには、以下の事項に関する詳細な分析が求められます:

  • サポートが必要なアプリケーションの数;
  • データベースの数とそれらのサイズ;
  • オンプレミスとクラウドデータベースのサポート;
  • データベースの使用用途(OLTP、OLAP、ウェブ対応、分析、AI、アドホックなど);
  • 異なるDBMSとベンダーの数(例:Oracle、Db2、SQL Serverなど);
  • サポートが必要なOSプラットフォームの数(Windows、UNIX、Linux、z/OSなど);
  • ERPアプリケーションにおける非標準DBMS使用に関する特別な考慮事項;
  • ユーザ数と同時接続ユーザ数;
  • 適用中または計画中のサービスレベル契約(SLA)の種類;
  • DevOpsやアジャイル開発環境への参加要件;
  • 可用性要件(24/7またはそれ以下);
  • データベースダウンタイムがビジネスに与える影響💰️;
  • パフォーマンス要件(サブセカンドまたはそれ以上);
  • アプリケーションの種類(ミッションクリティカル vs. ミッションクリティカルでないもの)
  • 変更リクエストの頻度。

これはおそらく完全なリストではないでしょうが、DBAが日常的に直面する複雑さと課題を示しています。

もちろん、DBAの有効性を測定する最良の方法は、DBAが実行するすべてのタスクの品質を評価することです。しかし、そのような測定の多くの側面は主観的になります。DBAは、組織のデータとデータベースが有用で、利用可能で、可用性があり、正確であることを確保するために、多くのタスクを実行します。これらのタスクには、データモデリング、論理的および物理的なデータベース設計、パフォーマンス監視とチューニング、可用性の確保、セキュリティの承認、バックアップと復旧、データ整合性の確保、そして、会社のデータベースとインターフェースするあらゆるものが含まれます。これらのタスクを主観的でない方法で測定するための一貫したメトリクスを開発することは困難です。

おそらく、上記のすべてを包含する複雑な式を考案する必要があるでしょう。これが、私たちがDBA向けの公平で主観的でない指標に基づく測定プログラムを見たことがない理由でしょう。

タグ: , ,

データベースのトラブルシューティングを迅速化する方法

データはレポートと分析の基盤を成す不可欠な要素であり、データを格納するデータベースは現在、ほとんどのカスタムアプリケーションや業務システムを駆動し、その意思決定を支援しています。したがって、組織がデータベースの問題のトラブルシューティングを迅速化するためのあらゆる取り組みは、まさに宝物です。実際、トラブルシューティングに費やす時間を短縮することは、組織がより生産的で利益を生み出す活動に投資できる時間へと変換されます。継続的なデータベースパフォーマンス監視は、組織がトラブルシューティングの障害を迅速に克服し、本来の業務に戻れるよう支援します。

データベースパフォーマンス監視の真の価値

データベースパフォーマンス監視は、組織がデータベース管理システムを最大限に活用するのを支援します。これは、MySQL、PostgreSQL、MongoDB、Amazon Aurora、Redisなど、広く使用されているオープンソースデータベースにおいて特に重要です。これらのデータベースは、組み込みツールやコンソールにおいて、パワー、使いやすさ、自動化において優れているとは知られていません。これらのプラットフォームのパフォーマンスを継続的に監視するために、強力なソフトウェアとしてサービス(SaaS)でホストされたツールを導入する方がはるかに優れています。これにより、重要なデータへのアクセスを確保できます。よく設計された汎用的なデータベースパフォーマンス監視ツールを継続的に実行することで、組織はサービスの可用性と応答性を常に可視化できます。データベース・パフォーマンス監視ツールは、分析機能を備え、過去のメトリクスと現在の値を比較し、これらの値に意味を付与して傾向を明らかにします。これにより、管理者は現在の読み取り値が過去の平均値や典型的な基準値とどのように比較されるかを評価できます。よく構築されたデータベースパフォーマンス監視ツールは、組織のデータベースをあらゆる場所で監視します:オンプレミス、クラウド、または複数のクラウドとオンプレミス要素を跨ぐハイブリッド実装。データベースの問題の根本原因を特定し対処するには時間が重要です。幸いなことに、適切に構築されたデータベースパフォーマンス監視ツールは、生産環境での問題解決を迅速化します。さらに、このようなツールはデータベースクエリやアプリケーションの開発をガイドします。DBAと開発者は、変更前後の特定のクエリやデータベースアプリケーションを比較するためにデータベースパフォーマンス監視ツールを使用できます。これにより、パフォーマンスとリソース消費の影響を詳細に測定できます。これは、より最適化された効率的なデータベース設計、重要なデータへのアクセスが容易で高速化、およびより安定したアプリケーションの実現を支援します。

データベース中心の監視

より深いレベルでは、包括的なデータベースパフォーマンス監視ツールは、詳細なデータベース監視を活用してデータベースの問題をトラブルシューティングし診断できます。このようなツールは、データベースエンジンとOSのメトリクスを自動的に生成するため、既存のデータベース活動にほとんどまたは全くオーバーヘッドを追加しません。さらに、クラウドネイティブのデータベースパフォーマンス監視ツールは、データ収集と分析に独自のリソースとストレージを使用するため、監視対象の資産に追加のパフォーマンスオーバーヘッドを課すことなく、広範に分散した生産環境とテストデータベースを大規模に監視できます。データベースパフォーマンス監視ツールの出力は、データベース、ユーザー体験、ホストOSの観点から、データベースの健康状態とパフォーマンスを即時可視化します。データベースパフォーマンス監視ツールが幅広いオープンソースデータベースに対応する場合、データベースインスタンスがオンプレミスかクラウドかにかかわらず、この可視化を提供できます。履歴データと現在のメトリクスにアクセスできるため、データベースパフォーマンス監視ツールはデータベースの異常を迅速に検出できます。これは、継続的に収集されるメトリクスデータの流れにおいて、平均値や傾向を示すシステム動作と、パフォーマンスやリソース消費の異常値を比較することで実現されます。同じ歴史的なデータベースメトリクスのビューは、成長と容量計画の堅固な基盤を提供します。したがって、組み込みの分析機能を備えたデータベースパフォーマンス監視ツールは、計算、ストレージ、ネットワークリソースのパフォーマンスと将来の要件を分析できます。また、組織がデータベース(およびアプリケーション)の移行を計画し監視し、最適な結果を発見するのを支援します。これは、コード変更に有効な「前後比較」手法が、ロケーションやホスティングの変更にも適用可能だからです。組織は強力なデータベースパフォーマンスモニターを使用して、多様な状況や環境下でのコードデプロイメントを追跡できます。個々のクエリレベルでのコード変更がパフォーマンスに与える影響を把握し、特定のクエリ変更がデータベース環境の全体的なパフォーマンス、応答性、リソース消費にどう影響するかを分析できます。これらのツールは、商用SaaSや類似のアプリケーションにおける潜在的なボトルネックやクエリの問題に関する情報も提供できます。これにより、SaaSクライアントはサービスプロバイダーに提出できる具体的な改善策を特定し、問題解決に活用できます。一般的に、データベースパフォーマンス監視ツールは、遅いデータベースクエリを迅速に特定するため、DBAや開発者は調査と最適化に集中できます。実際、優れたデータベースパフォーマンスモニターは、チューニングのアドバイスや最適化・改善のベストプラクティスリストを提供し、DBAが効率性とリソース消費の改善に役立つ具体的な指針を得られます。時間、遅延、リソース消費量などの基準に基づくトップ10リストも、リソース不足により想定より遅く実行されているクエリを特定し、管理者に対し適切なリソース配分の方法を示します。DBAと開発者は、個々のデータベースクエリを全体的なデータベース活動の文脈に置き、特定の変更が全体的なデータベースパフォーマンスと機能に与える影響を観察できます。したがって、優れたデータベースパフォーマンス監視ツールは、データベースアプリケーションのランタイムスタック全体にわたるトランザクションのグローバルビューとも連携します。これは、特に複雑な状況において、データベース、ネットワーク、データセンター、またはサービスプロバイダーのスタッフ間の責任のなすり合いを回避し、すべてのチームが同じ方向に向かって協力する際に問題をより容易に解決できる優れた方法です。

知識を深めるには

データベースパフォーマンス監視ツールを検討する際は、Database Performance Analyser(DPA)が、上述のすべての機能を提供していることを覚えておいてください。

タグ: , , , , ,

データベース・パフォーマンス管理の5つの必須事項

データベースは複雑で多面的な存在であり、あらゆる組織の健全性に不可欠です。データベースはデータセンターの核心であり、オンプレミス、クラウド、またはハイブリッドIT環境のいずれにおいても、組織のテクノロジーインフラストラクチャの最も重要なコンポーネントの一つであると言えます。このため、データベースのパフォーマンスを最適化することは、最適化されたデータセンターを実現するために不可欠です。IT管理者がこの目標を達成するためにできる5つのことがあります:

  1. データベースの健全性を確保する
  2. データとメトリクスの可視化を確保する
  3. データとメトリクスを文脈に置く
  4. 最適化計画を追跡する
  5. パフォーマンスの基準値を作成し維持する

これらのステップを個別に確認し、全体像を考えてみます:

データベースの健全性を確保する

データベースにおいて、健全性とパフォーマンスは異なる概念です。データベースは最適化される前に健全でなければなりません。データベースの健全性を示す指標には、CPU使用率、I/O統計、メモリ圧力などが含まれます。これらのメトリクスを総合的に分析することで、データベースが適切に機能するかどうかを判断できます。

可視化を確保する

次に、クエリを迅速に実行し、スループットを最大化するためのパフォーマンス最適化プロセスを開始します。これには、データベースパフォーマンスを評価するために必要なデータとメトリクスに完全な可視性を確保することが不可欠です。例えば、リソース競合やデータベースのワークロードなどの詳細なメトリクスにドリルダウンする能力は、パフォーマンス問題の根本原因を特定し、緩和するのに役立ちます。

データをコンテキストに置く

組織は、監視ツールから提供されるデータが、問題の解決とパフォーマンスの最適化に必要な真の洞察を提供するように構造化され、提示されていることを確認する必要があります。具体的には、データはパフォーマンス問題の根本原因を迅速に特定し解決するのに役立ち、不要な二次的な調査や分析の「迷路」に迷い込まないようする必要があります。

最適化計画を追跡する

ITチームはパフォーマンスをテストし最適化するための措置を講じます。例えば最適化クエリの実行などです。すべてのクエリとテストが追跡され、結果が実施されたテストと慎重に相関付けられていることを確認してください。

パフォーマンスの基準値を作成し維持する

データベースがパフォーマンス低下しているかどうかを判断するには、日次基準の「正常値」を測定する基準がありません。最適なアプローチは、包括的な管理および監視ツールのシリーズを実装することです。データベース内、データベース技術間、展開方法(クラウドを含む)を横断して分析できる機能も必須です。さらに、選択したツールがパフォーマンスメトリクスの履歴記録を確立できることを確認してください。これらの情報と基準値の設定能力を組み合わせることで、ITチームがデータベースの健康状態とパフォーマンスを最適化するためのツールを確実に提供できます。

タグ: