GlueSyncがAWS S3(互換も含む)に対応:分析、データレイク、コールドストレージ向けに、AWS S3 へのリアルタイムデータレプリケーションがシンプルに

Amazon S3 データを AI、ML、データレイクなどで活用可能

Gluesync は、リアルタイム RDBMS および NoSQL データを AWS S3 バケットに直接複製するための堅牢なクラウドネイティブ ソリューションを提供します。この統合により、データ レイクやコールド オブジェクト ストレージなどのさまざまなユース ケースが容易になり、最新のストレージ ソリューションへの移行が効率的かつ安全になります。

可能性の追求

大規模なオブジェクト ストア内でデータを複製することで何を達成できますか?

RDBMS または超高速 NoSQL を介してビジネス システムから AWS S3 バケットにリアルタイム データ パイプラインを実装することで、データ コストに関する考え方を一新できます。AWS S3 などの大規模オブジェクト ストレージは、簡単に定義できるストレージ ポリシーを使用してギガバイトあたりのコストを削減する、コールド データ ストレージに効果的なソリューションを提供します。さらに、単一の真実のソースを制御できるようになるため、すぐに大規模なクエリや分析のユース ケースに適したデータ レイクになります。

リアルタイムデータをバケットに入力する

今日の企業は、今すぐ経済に参入する権利をすべて持っています。では、なぜ企業は待たなければならないのでしょうか?

GluesyncのリアルタイムCDC(変更データキャプチャ)エンジンを使用すると、AWS S3バケットを任意の主要なデータソースにリンクし、受信した増分変更のみをフィードできるため、意思決定とAIツールをすぐに実行できるようになります。

カスタマイズ可能なデータモデルまたは削除をスキップする

データモデリング

データレイク、ビッグデータ、またはデータウェアハウスでは、カスタマイズされたアプローチが必要になる場合があります。コードが不要な場合は、それがより望ましいです。

Gluesync は、高度なデータ モデリング エンジンや、簡単なフラグでレコードの削除をスキップする機能などの強力なツールを提供することで、新しいデータ レイクの設計に役立ちます。モデル化および変換されたデータを保存前にクエリすることは、大規模なデータセットを扱う際に重要な要件であり、貴重な洞察を得るまでの時間を節約し、コストを削減するのに役立ちます。

主要なRDBMSからAWS S3へ

主要なリレーショナルデータベースから Amazon S3 にデータを簡単に複製できます。GlueSync は、Microsoft SQL Server、Oracle、IBM Db2、MySQL など、幅広い RDBMS をサポートし、スナップショットと CDC レプリケーションを提供します。データは JSON 形式で保存され、AWS S3 と完全に互換性があり、分析やその他のアプリケーションで簡単にアクセスできます。

NoSQL からAWS S3 へ

GlueSync を使用すると、NoSQL データを AWS S3 に簡単に移動できます。現在のソリューションをコーディングしたり再構築したりする必要はありません。Gluesync はオブジェクト ストレージをサポートし、データを柔軟な JSON 形式に変換し、AWS S3 の SDK を活用してシームレスなストレージ操作とセキュリティを実現します。データ モデリングをカスタマイズし、S3 バケット内で最適なデータ構成を確保して、将来にわたって効率的なデータ取得を実現します。

タグ: , , , , , ,

Azure Cosmos DB CDC & Target Connector:Gluesyncで双方向データ統合を可能に

Gluesync用のAzure Cosmos DB コネクタがリリースされ、(CDC)変更データキャプチャとターゲット機能の両方が提供されています。 この多機能なアップデートにより、企業はAzure Cosmos DBとデータを同期し、そこからの変更をキャプチャできるようになり、データ統合とリアルタイム分析のための包括的なソリューションが提供されます。

Azure Cosmos DB:クラウドネイティブアプリケーション用のマルチモデルデータベース

Azure Cosmos DB は、Microsoft Azure が提供する完全マネージド型の NoSQL データベースサービスです。 ドキュメント、キーバリュー、ワイドカラム、グラフデータベースをサポートするマルチモデルデータベース機能を提供します。 Azure Cosmos DB コネクタを使用すると、Azure Cosmos DB へのデータの送信と Azure Cosmos DB からのデータの受信の両方が可能になり、情報を一元化して詳細な分析に利用できるようになります。

Gluesync との統合:双方向の柔軟性と制御

Gluesync 2.0将来を見据えたアーキテクチャにより、SQLとNoSQLの両モデルで効率的かつ柔軟なデータ同期が可能になります。Azure Cosmos DBコネクタは双方向のデータフローをサポートしています。

  1. ターゲットとして:さまざまなソースから直接、データをAzure Cosmos DBインスタンスに複製できます。
  2. ソース(CDC)として:Azure Cosmos DBの変更をキャプチャし、他のサポート対象のターゲットに複製できます。

Azure Cosmos DBコネクタの主な機能

GluesyncのAzure Cosmos DBコネクタには、以下の主要な機能が含まれています。

  • 双方向データフロー(CDCおよびターゲット機能)
  • 挿入、更新、削除操作のサポート
  • Azure Key認証を使用したセキュアな通信
  • コンテナターゲットの構成

前提条件と構成

Azure Cosmos DBコネクタを使用するには、以下のものが必要です。

  • 有効なAzure Cosmos DBサービスキー
  • Azure Cosmos DBのインスタンス

構成の詳細

Azure Cosmos DB コネクタの設定は簡単で、ウェブインターフェースまたは REST API を使用して行うことができます。主な設定項目は以下の通りです。

  • ホスト名/IP アドレス:Azure DB サービスのホスト名。
  • ポート:オプション、デフォルトは 443。
  • データベース名:ソースのネームスペース名。
  • Azure キー:Azure Cosmos DB サービスのキー。
  • コンテナ:ターゲットのコンテナ名。
  • リース(CDC用):変更フィードプロセッサのリースコンテナ名。

変更データキャプチャ(CDC)の仕様

GluesyncのAzure Cosmos DB CDCコネクタは、Cosmos DBインスタンスからのデルタ変更をキャプチャするために変更フィードプロセッサを利用します。変更フィードプロセッサの詳細と動作については、Microsoftのドキュメントページ(このリンク)を参照してください。

CDC機能については、

  • Change Feedプロセッサにはリースコンテナが必要であり、これは手動または動的に作成できます。
  • リースコンテナは複数のワーカーにわたる処理を調整し、同じアカウントまたは別のアカウントに保存できます。
  • 現時点では、「ソフト」 (論理) 削除操作のみがサポートされています。

Azure Cosmos DBコネクタを使用するメリット

GluesyncのAzure Cosmos DBコネクタは、データ管理と分析の世界で際立つユニークな機能の組み合わせを提供します。その中核となるのは双方向データフロー機能であり、データの取り込みと変更データのキャプチャの両方を可能にします。これは、コネクタでは珍しい汎用性です。この適応性は、Azure Cosmos DBのグローバル分散機能によって補完され、世界中で低レイテンシのデータアクセスを保証します。

コネクタのマルチモデルサポートも際立った機能であり、幅広いアプリケーションに適応する多様なデータタイプと構造に対応しています。この柔軟性は、Azure Cosmos DBのアーキテクチャにより、パフォーマンスを損なうことなくストレージとスループットの両方をシームレスに拡張できる優れたスケーラビリティによって実現されています。

その機能を完璧なものにするために、コネクタは複数の一貫性レベルを提供しており、企業は高い一貫性と高い可用性のバランスを微調整することができます。これらの機能の組み合わせにより、Azure Cosmos DBコネクタは、ニーズに合わせて進化できる堅牢でグローバルに分散されたデータアーキテクチャを構築したい企業にとって強力なツールとなります。

結論として、GluesyncのAzure Cosmos DBコネクタは、強力な双方向データ統合ソリューションを提供します。これにより、企業はデータ管理の一元化、リアルタイムでの変更の取得、Azure Cosmos DBのグローバル分散およびマルチモデル機能の活用が可能になります。この汎用性により、堅牢でスケーラブルなグローバル分散データアーキテクチャの構築を目指す組織にとって、優れた選択肢となります。

タグ: , ,

現代のデータベース環境におけるマルチタスク

すべてのデータベース マネージャーは、複数のエンタープライズ データベースの維持と最適化に伴う複雑さを知っています。しかし、データベース管理の複雑さを理解し、その作業を完了するために必要な知識とスキル (適切なツールは言うまでもありません) を持つことは別の問題です。今日の企業は、さまざまなアプリケーションとデータ タイプをサポートするために、幅広いデータベース システムを使用しています。このアプローチは、特定のデータ ニーズに対応する (テクノロジをその場その場で要件に合わせる) のに最適ですが、データベース管理の観点からは、複数の多様なシステムを同時に監視することを意味します。

最近見られる最も明確なパターンの 1 つは、クラウドベースのソリューションへの大規模な移行です。クラウド ソリューションは、拡張性、柔軟性、コスト効率を提供します。クラウドで運用するメリットは明らかですが、データベース プロフェッショナルが新しいツールやテクノロジに迅速に適応する必要があることも意味します。これは、従来のデータベース設定での作業に慣れている人の役割に大きく影響する要因です。最近のもう 1 つの傾向は、オープン ソース データベース ソリューションの採用または共同採用への移行です。今日の市場では、大量の貴重なデータを従来のエンタープライズ データベースから PostgreSQL などのソリューションに移行する方法を知っていることは、非常に役立つスキルです。

複数のデータベースの管理

弊社の最新のホワイトペーパー「複数データベースの管理」では、マルチデータベース環境の複雑化について取り上げています。業界の洞察とケーススタディを参考にして、複数のデータベースとデータベース タイプの戦略的な実装と管理を検討します。主なポイントは次のとおりです。

  • 複数の多様なデータベース:組織は、さまざまなアプリケーションやデータ タイプをサポートするために、さまざまなデータベース システム (データ ウェアハウスや NoSQL データベースなど) を使用しています。このアプローチは特定のニーズやユース ケースに対応していますが、データベース マネージャーは、運用可能で最適化された効率的なシステムを確保しながら、複数のシステムを同時に監視する必要があることも意味します。
  • クラウドへの移行:クラウドベースのデータベースは、拡張性、柔軟性、コスト効率に優れていますが、データベース管理者はハイブリッド環境やクラウド環境を管理するための新しいツールや手法に適応する必要があります。クラウド データベースでは、物理管理から仮想管理への移行を反映して、パフォーマンスとセキュリティの監視が必要です。
  • マルチデータベース戦略:冗長性とトランザクション容量が主な利点です。分散デッドロック検出により、トランザクション処理が向上します。その他の利点としては、冗長性、高可用性、柔軟なスケジュール設定、ダウンタイムの短縮などがあります。マルチデータベース戦略を採用することで、企業は十分な容量、簡素化されたコンプライアンス対策、手間のかからないスケーラビリティを確保することを目指します。

大規模なマルチタスク

現代のマルチデータベース環境では、データベース プロフェッショナルは大規模なマルチタスクを実行することが求められます。しかし、多種多様なデータ レイヤーを最適に稼働させるために必要な専門知識や経験を備えたデータベース マネージャーはほとんどいません。これはデータベース マネージャーの失敗ではなく、データ管理に万能なアプローチがない現在の IT 環境の複雑さの表れです。

むしろ、複雑で分散化されたデータベース環境への移行により、包括的なデータベース監視および管理ツールの必要性がさらに高まっています。データベース最適化の鍵は、適切なデータベース担当者を採用することだけではありません。適切な人材を採用したら、適切なツールを使用できることを確認することです。マルチデータベース環境の詳細については、こちらの「時代はマルチ・データベース管理」へ

タグ: , ,

データベース・パフォーマンス・アナライザ (DPA) 2024.4 : MySQL および Percona MySQL 用チューニング・アドバイザをサポート

MySQL/Percona MySQL用テーブルチューニングアドバイザー

すべてのデータベースには非効率的なクエリが存在します。つまり、少ないリターンに対して多大な労力を費やしているます。この非効率性は、高い入出力、長い待ち時間、より多くのブロック、リソースの競合の増加につながる可能性があります。

非効率的なクエリのチューニングは困難であり、そのプロセスにおいて多くの疑問が生じがちです。例えば、

    • クエリをチューニングすべきか? 新しいインデックスを追加すべきか? あるいは、既存のインデックスに列を追加すべきか?
    • プランは複雑で分析が困難です。どのステップを考慮すべきでしょうか?
    • プラン内のどの条件が非効率なデータアクセスや大量の読み取りを引き起こしているのでしょうか?
    • 出発点として使用できる推奨事項はあるでしょうか?
    • 同じテーブルにアクセスする他の非効率なクエリがあり、インデックス作成の決定に影響される可能性があるでしょうか?
    • 現在、テーブルにいくつインデックスが存在し、それらはどのように構成されていますか?
    • テーブル内のデータは、データの更新(挿入、削除、および場合によっては更新)の頻度から見て、どの程度トランザクション性が高いですか?

Table Tuning Advisorは、これらの疑問の解決に役立ちます。

Table Tuning Advisorは、高価なクエリを分析し、その理由に関わらず、非効率的なワークロードが実行されているテーブルを特定するのに役立ちます。各テーブルについて、アドバイザーページには、テーブルと非効率的なクエリに関する集約された情報が表示されます。この情報を利用して、データベースのパフォーマンス最適化の機会について、より適切な判断を下すことができます。また、インデックスを追加した場合の潜在的なコストとメリットを比較検討することもできます。

ナビゲーション

アドバイザーページにアクセスするには、2つの方法があります。

    • インスタンスをクリックした後、ページの上部に「チューニング」というスーパー・タブが表示されます。これをクリックすると、クエリ、インデックス、およびテーブル・チューニング・アドバイザーを組み合わせたページに移動します。

・特定のクエリパフォーマンス分析(QPA)ページにドリルダウンしたら、テーブルチューニングアドバイザセクションまでスクロールダウンします。このセクションでは、テーブルレベルに集約されたアドバイスが要約され、アドバイザ詳細ページへのリンクが含まれています。

アドバイザーのページレイアウト

テーブル調整アドバイザーのページには、選択したオブジェクトに関連する重要な情報がぎっしりと詰まっています。 主な領域は次の3つです。

  • 非効率なSQL:テーブルにアクセスするクエリのリストを、相対的な作業負荷でランク付けしたもの
  • SQLおよびプランの詳細:選択したクエリのSQLおよびプランの詳細
  • テーブルおよびインデックス情報:現在のテーブル情報、テーブル上の既存のインデックス、テーブルの列

テーブルチューニングアドバイザーの例

先を見越して、何かをチューニングして大きな影響を与えたいと仮定してみましょう。 概要レベルでは、チューニングタブに非効率なクエリを持つテーブルが表示され、非効率なワークロードに基づいてそれらのテーブルがランク付けされます。 このリストには、各テーブルの待機時間の集約ビューと、テーブル上の非効率なプランステップを持つクエリの数が含まれています。 これらはチューニングの絶好の機会です。

出発点として使用する推奨事項はあるか?

「orders」テーブルをクリックすると、テーブルにアクセスする非効率的なクエリの詳細が記載されたテーブルチューニングアドバイザのページに移動します。このページには、非効率的な使用パターン、統計情報、現在のインデックスの設計など、テーブルについて知っておくべきことがまとめられています。

プランのどのステップが非効率ですか?

DPAは独自のアルゴリズムを使用して、非効率なプランステップと問題の原因を特定します。非効率な「プロデューサー」ステップ(例:フルテーブルスキャン/インデックススキャン)は、後続のコンシューマー・プラン・ステップで後から処理されるデータを読み取ります。コンシューマー・ステップ(例:ソート)は高いコストを伴うことがありますが、通常は、過剰なデータを読み取る先行のプロデューサー・ステップの影響を受けます。DPAは、チューニングの対象として、非効率なプロデューサー・プラン・ステップを指摘することができます。

上の図では、DPAは使用されている2つのプランと、それぞれのプランにおける非効率なステップを特定しています。

  1. SEQ SCAN—ステップ7: 「customer」テーブルのシーケンシャル・スキャン。 述語値が同様の比較を示していることに注目してください。 シーケンシャル・スキャンにより、一致する電話番号の150,000行が検査されました。

この情報を手動プラン分析で取得するには、おそらく何時間もかかるでしょう。プラン分析は困難な作業です。そこで、Table Tuning Advisor を使用して、最適な出発点を見つけましょう。

このテーブルへのアクセスで、他に非効率的なクエリはありますか?

Table Tuning Advisor ページの左側のペインには、「customer」テーブルへのアクセスで、相対的な作業負荷でランク付けされた、他の非効率的なクエリが表示されます。このリストの上位にあるクエリは、テーブルに対する負荷が大きいので注意してください。逆に、相対的な負荷が小さいリストの下位にあるクエリには、それほど時間を費やす必要はありません。インデックスの追加や変更などのわずかな調整が、多くの非効率的なクエリに大きな違いをもたらすこともあります。

テーブルにはいくつインデックスが存在し、どのように設計されているでしょうか?

テーブル・チューニング・アドバイザのページの下部には、現在のインデックスとカラム、統計および使用状況に関する情報が表示されます。その他のテーブルおよびインデックスのメタデータは、リアルタイムのクエリの後、最新の情報として表示されます。これは、いくつかの理由で重要です。

  • テーブルのデータ更新頻度は高いですか?もしそうであれば、挿入/更新/削除の頻度が高く、新しいインデックスは有益よりも有害となる可能性があります。
  • 述語で呼び出された列を含む既存のインデックスが役立つ可能性はありますか?新しいインデックスを作成するよりも、このクエリに役立つようにインデックスを修正することは可能ですか?
  • オプティマイザ統計は最近生成されましたか?生成されていない場合、かつ更新頻度が高い場合は、テーブルの統計を更新することが優れた第一歩となる可能性があります。
  • インデックスが肥大化していますか?肥大化している場合、かつスキャンがインデックスに対して実行されている場合は、バキューム処理プロセスの健全性を確認してください。

新たな発見は? あるDPAユーザ開発チームは、DPAを使用してコードのパフォーマンス向上に役立てています。テーブルチューニングアドバイザーを使用したところ、問題のあるテーブルのセットを指摘されました。数時間以内に簡単な書き換えでクエリをチューニングし、毎晩のクリーンアッププロセスでデータベース時間を数時間節約することができました。

タグ: , ,

Snowflake Target Connectorのサポートで:Gluesyncとのシームレスなデータ統合へ

Gluesync Snowflake's integration

Gluesync用のSnowflakeターゲットコネクタが、リリースされました。この重要なアップデートにより、企業は市場で最も先進的で強力なクラウドデータウェアハウスの1つであるSnowflakeと多種のデータを同期できるようになり、データ統合が簡素化され、分析機能が強化されます。

Snowflake:データ管理のためのクラウドソリューション

Snowflakeは、大量のデータを管理・分析するために企業で広く利用されているクラウドネイティブのデータウェアハウスプラットフォームです。Snowflakeターゲットコネクターを使用すると、さまざまなソースから直接Snowflakeにデータを送信し、情報を一元化して詳細な分析に利用することができます。

Gluesyncとの統合:より柔軟性と制御性を向上

Gluesync 2.0は、将来にわたって有効なアーキテクチャを導入し、SQLとNoSQLの両モデルに対応した、より効率的で柔軟なデータ同期を実現します。Snowflakeがターゲットコネクタとしてサポートされたことで、Gluesyncは他のソースから直接Snowflakeデータベースへのデータ複製を可能にし、お客様のデータが常に最新の状態に保たれ、使用可能な状態であることを確実にします。

Snowflakeコネクタの主な機能

GluesyncのSnowflakeターゲットコネクタには、データ同期化のための強力なツールとなるさまざまな主要機能が含まれています。さらに、コネクタには、お客様のニーズに合わせて統合をカスタマイズできる設定可能なオプションが用意されています。

  • 挿入、更新、削除操作のサポート:Snowflakeコネクタは、挿入、更新、削除操作をサポートしており、ソースシステムからのデータがSnowflakeデータベースと常に整合性を保つようにします。
  • Apache Arrowデータベース接続(ADBC): SnowflakeとGluesyncアプリケーション間のデータ転送を最適化するために、カラム型メモリ形式を活用します。このドライバは、シリアライズ/デシリアライズのオーバヘッドを削減し、より効率的なメモリ使用を可能にすることで、特に大規模な結果セットの場合にパフォーマンスを大幅に向上させます。
  • Warehouse name: デフォルトはCOMPUTE_WHですが、Snowflakeインスタンスに合わせて調整できます。
  • 設定可能なタイムアウト:このパラメータを使用すると、GluesyncとSnowflake間の通信にカスタムタイムアウト(デフォルトは60秒)を設定でき、高負荷時でもスムーズな動作を確保できます
  • オブジェクト削除をスキップするオプション:この機能により、レプリケーション中の削除操作を除外し、データ挿入または更新に関連する変更のみを伝搬することができます。これは、新規挿入や更新を同期しながら、履歴データを保持する必要があるビジネスにとって特に有益です。

これらのカスタマイズ可能な設定により、Snowflake コネクタをさまざまな企業環境に適応させることができ、データ同期プロセスの柔軟性と制御性を向上させることができます。

Snowflake コネクタの設定

Snowflake ターゲット コネクタの設定は簡単で、ウェブインターフェイスから行うことができます。主な設定内容は以下の通りです。

  • ホスト名/IP アドレス:Snowflake テナントの DNS または IP アドレス
  • データベース名:ターゲット Snowflake データベースの名前
  • ユーザー名とパスワード:読み取りおよび書き込みアクセス権を持つユーザーの認証情報
  • データウェアハウス名:Snowflakeコンソールから取得したデータウェアハウス名

Snowflakeをターゲットコネクタとして使用するメリット

Snowflakeをターゲットコネクタとして使用することで、データ管理と分析にいくつかのメリットがもたらされます。

まず、データの集中化が可能になり、複数のソースからデータを単一の統合プラットフォームに集約できるようになります。この集中化により、データ分析が簡素化され、すべての重要な情報が容易にアクセス可能になります。

さらに、Snowflakeの堅牢なアーキテクチャは高度な分析をサポートしており、ユーザーは複雑なクエリを実行したりリアルタイム分析を行ったりすることができ、より迅速で情報に基づいた意思決定が可能になります。

最後に、Snowflakeのクラウドスケーラビリティにより、大量のデータを管理する理想的なソリューションとなります。クラウドネイティブな設計により、データが増大しても複雑なインフラストラクチャのアップグレードを必要とせずに高いパフォーマンスを維持できます。一元化、分析能力、スケーラビリティのこの組み合わせにより、Snowflakeはあらゆる組織のデータ主導型戦略にとって強力なターゲットとなります。

まとめると、Gluesync用のSnowflakeターゲットコネクタが現在一般公開されています。これにより、Snowflakeとのシームレスなデータ同期が可能になり、企業は複数のソースからデータを一元化し、分析データ管理を改善することができます。拡張性リアルタイム分析により、企業は大量のデータを効率的に管理し、より迅速にデータ主導の意思決定を行うことができます。

タグ: ,

時代はマルチ・データベース管理へ

複数のデータベースを効率的かつ効果的に運用することは、ビジネスの継続性とデータベースのパフォーマンスにとって非常に重要です。データが現代ビジネスの通貨であるならば、データベースは現代企業のバックボーンです。組織は、ビジネスを円滑に運営するために、一貫性のある最適なデータベース・パフォーマンスを確保する必要があります。データベースのパフォーマンスが低下したり、最適でなくなったりすると、顧客からの問い合わせや販売プロセス、トランザクション処理への応答が遅れるなど、重大な影響が生じる可能性があります、
販売プロセス、およびトランザクション処理への対応の遅れなど、重大な結果を招きかねません。

適切なトランザクション処理能力を確保するために、ほとんどの企業はマルチデータベース戦略を採用しています。つまり、異なるクラスまたはカテゴリのデータを格納するために、複数の異なるデータベース・プラットフォームを使用しています。データベースの数が急増しているということは、データベース・マネジャーが多様なデータベース・インスタンスやタイプを担当する機会が増えていることを意味します。

最近の報告書では、以下のような主要な発見が概説されています:

– 複数かつ多様なデータベース: 企業は現在、さまざまなアプリケーションやデータタイプをサポートするために、複数のデータベースシステム(データウェアハウスやNoSQLデータベースを含む)を使用しています。このアプローチは、組織が適切なデータベース・テクノロジーを使用して特定のニーズに対応するのに役立つ一方で、データベース管理者が複数のシステムを同時に監督しなければならないことを意味します。この傾向は、多用途なデータベース管理の必要性が最優先される、複雑で分散したデータベース環境への幅広い動きを反映しています。

– パフォーマンスが重要: データベース・マネージャーにとって、パフォーマンス管理は依然として極めて重要です。人工知能(AI)と機械学習のデータベースシステムへの急速な統合は、データベース管理者がシステムの運用、最適化、効率化を確実に行う必要性を強調しています。AIと機械学習の統合は、システムのパフォーマンスと信頼性を維持するために重要な、日常的なセキュリティとバックアップのタスクを自動化するのに役立ちます。

– クラウド: クラウドデータベースへの移行は、データベース管理者の役割に大きく影響します。従来のソリューションに比べ、クラウドは拡張性、柔軟性、コスト効率の高いソリューションを提供します。この移行に伴い、データベース管理者は新しいツールや管理手法、特に高可用性の維持やハイブリッド環境またはクラウド環境の管理に適応する必要です。クラウド・ソリューションは物理的なインフラストラクチャの負担を軽減できる一方で、管理者はクラウドデータベースが物理的な管理から仮想的な管理への移行を反映し、パフォーマンスとセキュリティの大幅な監視を必要とすることに気がつきます。

マルチデータベース戦略のビジネス・メリット

冗長性とトランザクション容量は、マルチデータベース戦略の2つの利点であり、技術的な利点がそのままビジネス上の利点となります。多くの企業は、異なるアプリケーションとデータを分離するバックエンドとして複数のデータベースを使用しています。このアプローチは、トランザクションが様々なデータベースからデータにアクセスできることを意味するため、分散デッドロック検出に役立ちます。トランザクション要求が1つのインスタンスでブロックされた場合、ロックの検出と緩和が容易になり、トランザクション処理のスピードアップにつながる。その他、複数のデータベースを使用することによる業務への直接的なメリットには、以下のようなものがあります:

● 冗長 性とバックアップ          ●ダウンタイムによる影響の軽減
●高可用性と フォールトトレランス   ●十分な容量の確保
● 柔軟な スケジューリング(クエリーとバックアップルーチンのため) ●コンプライアンスの簡素化
● スケーラビリティ (最適なパフォーマンスのため)

マルチデータベース戦略の課題

企業内で稼働するデータベースの数や種類が増えたとしても、データベース管理者は、最高のパフォーマンスと安定した稼働時間を確保する必要があります。一貫したアップタイムを確保する必要があります。

複数のデータベースを管理する上での課題には、次のようなものがあります:
● 複数のデータベースプラットフォームでの作業
●  企業データベース間の移行
● データのフォーマットと 整合性
●  一貫した最適パフォーマンスの確保

データベース・マネジャーは、複数の種類のデータベースを扱う際、しばしば異なるアプローチを用います。つまり、パフォーマンス・チューニングを実施し、高可用性を維持し、さまざまなテクノロジーでデータ・セキュリティを確保するために、関連する専門知識を身につける必要があるのです。これは、知識とスキルの大幅な拡大を必要とするだけでなく、各データベースに割く時間を減らすことにもなります。プラットフォームが物理的に異なる場所にある場合や、クラウドベースの場合は特にそうです。エキスパートであるデータベース管理者にとっても、複数のデータベースを幅広くサポートするモニタリング・ソリューションは強力な味方となります。

オープンソースの立ち上がり

データベースの種類の増加とともに、使用されるデータベースの量も増加している。OracleやMicrosoft SQLServer のような業界の雄が依然として目立つ一方で、一握りのオープンソースの選択肢がエンタープライズ環境で大きな支持を得ています。それはMySQLやPostgreSQLを含むオープンソース・ソリューションの継続的な採用です。
オープンソースのデータベースは、既存のデータベースの容量や機能を補強するために導入されることが多くあります。

オープンソースデータベースは、従来のトップクラスのデータベースと遜色なく競合しています。2024年5月現在、DB-Enginesランキングによると、最も人気のあるリレーショナル・データベース管理システム(RDBMS)は以下の通りです:

1. Oracle は 、大規模運用や複雑な処理をサポートする包括的な機能で注目され、トップ RDBMS として引き続きリードしています。
2. MySQLは 、使いやすさ、柔軟性、ウェブホスティング業界での人気により、上位にランクされています。
3. Microsoft SQL Serverは 、Microsoftの他のサービスと深く統合されており、エンタープライズ環境で幅広く使用されていることで知られています。
4.PostgreSQLは 、標準準拠と拡張性で高く評価されています。PostgreSQLは、大量のデータを効率的に管理することができます。
5. IBM Db2は、 高いパフォーマンスと堅牢なデータ処理を必要とするエンタープライズ環境でよく使用されています。

プレイヤーを詳しく検証

OracleとMicrosoft SQLサーバーは、伝統的なデータベース・プラットフォームの代表的存在であり、両者とも極めて高いパフォーマンスを発揮しています:

●Oracle:
オラクルは、安定性、パフォーマンス、セキュリティの面で高い評価を得ています。オンプレミスでもクラウドベースのインスタンスでもよく機能し、非常に大きなデータセットも扱えます。オラクルは競合するデータベース・プラットフォームよりも高価ですが、その性能はMicrosoft SQL Serverをはじめとする競合他社を圧倒しています。またオラクルのスペシャリストやコンサルタントは、高額な費用がかかります。

● Microsoft SQL Server:
Microsoft SQL Serverの大きな利点は、複数のエディションが用意されていることです。これは、組織がデータベース戦略を慎重に調整するのに役立ちます。Oracle同様、Microsoft SQL Serverもまた、エンタープライズ・アプリケーションに十分な機能とパフォーマンス、オンプレミスおよびクラウドベースのインスタンスのサポート、包括的なセキュリティ、Linuxのサポートを提供しています。多くの場合、オラクルと価格競争力がある(エディションによるが)一方で、マイクロソフトのライセンス慣行は複雑な場合があります。そのため、最近のデータでは、MySQLとPostgreSQLが主流を占めるオープンソースデータベースへのトレンドが確認されています:

●MySQL:
MySQL:その効率性と、特にWeb開発などさまざまなアプリケーションでの幅広い採用により、依然として有力な選択肢となっている。堅牢性で知られ、そのパフォーマンスと複数のアプリケーションとの互換性で広く利用されています。

●PostgreSQL:
高度な機能とSQL標準への準拠が評価され、複雑なデータ管理タスクに非常に適しています。また、幅広いデータ型とインデックス機能を提供し、人気の要因となっています。


●MongoDB :
柔軟なスキーマ設計と大規模データセットの効果的な処理により、特に高可用性と水平スケーリングを必要とする用途において、強力な地位を維持しています。

これらのデータベースは、オープンソースデータベースの使用量のかなりの部分を占めており、多様な業界にわたる現代のデータ管理において重要な役割を担っていることを証明しています。

PostgreSQL

MySQLは純粋なリレーショナルデータベースですが、PostgreSQLはオブジェクトリレーショナルデータベースです。その結果、データベーススキーマと問い合わせ言語において、PostgreSQLはオブジェクト、クラス、継承、その他のオブジェクト指向モデルの側面をサポートしています。PostgreSQLは包括的な機能セットを持ち、完全に拡張可能です。PostgreSQLは大量のデータを効率的に管理することができ、SQL標準に極めて忠実に従っています。データベースの専門家の多くは、PostgreSQLの方がより重要な利点を備えていると感じています。多くのデータベース専門家は、PostgreSQLが非常に幅広いSQL機能を含む、より重要な利点を提供すると感じています。しかし、組織のニーズがより複雑になってくると、よりシンプルな設計、より複雑でないソースコード、より高いパフォーマンスにより、MySQLがより強力な候補となる可能性があります。いずれにせよ、どちらの製品にも活躍の場があり、オープンソースのエンタープライズデータベースの世界では、MySQLとPostgreSQLが近い将来も最強の候補であり続けるでしょう。

データレイヤーの最適化

データベースのパフォーマンスを決定づける要素として、最適化はモニタリングと分析から始まります。マルチデータベース環境では、個々のデータベースが最適に動作するようにすることが重要です。データベースのパフォーマンスには、ワークロードのサイズや量、スループット容量(およびその他のリソース)、データベース構成の最適化など、いくつかの要因が影響します。多くのエンタープライズ・アプリケーションは複数のデータベースでサポートされているため、パフォーマンスの問題の原因を迅速に突き止めることは、ビジネスの継続性を確保する上で非常に重要です。

そこで、Database Performance Analyzer(DPA)が役立ちます。DPAは、SQLクエリパフォーマンスの監視、分析、チューニングに特化して構築されています。MySQLやPostgreSQLなどの主要なオープンソースデータベースをサポートしています。またOracle、AzureRSQL Database、Microsoft SQL Serverもサポートしています。DPAは、多くの企業で採用されているマルチデータベース戦略に非常に適しています。


Database Performance Analyzerは以下を提供します:

● クロスプラットフォームデータベースの サポート、●拡張性のある エージェントレスアーキテクチャー(クラウドおよびオンプレミス)、● 秒単位の データ収集
●リアルタイム および履歴データフィード、●機械学習による異常 検知
●パフォーマンスチューニングアドバイザー プラットフォーム
●直感的な Webベースのインターフェース

DPA とデータベースネイティブな分析ツールを併用することで、データベース管理者は、データベー ス性能を最適化し、セキュリティリスクを軽減するためのベストプラクティスを得ることができます。このレベルの多次元データベース性能分析により、組織は複数のデータベースを管理し、最適なパフォーマンスを実現するためのチューニングを行い、データベース管理者に正確で実用的な情報を提供することができます。

データ駆動型ビジネス
データは現代の企業運営の原動力となり続けており、複数のデータベースはどのような組織戦略においてもますます重要になっています。データベースが最高の効率で稼動していることを確認することは不可欠です。最適なパフォーマンス分析には、応答時間を監視し、データベースのアクティビティを相関させて、パフォーマンス問題の原因を特定し、理解することが必要です。DPAのようなパフォーマンス監視ソリューションの監視下にある組織は、最も効率的で効果的なデータベース戦略に従っていることを確信できます。

 

タグ: ,

コレクショングループタイプで管理を簡単に[Syniti Replciate]

Syniti Replicate 10.3からグループを作成する際にコレクショングループを作成できるようになりました。これは従来のグループタイプ(シングルリーダーグループタイプ)とは異なり、単純に管理を簡単に行うために利用できます。

コレクショングループタイプはレプリケーションの動作自体には影響なく、複数の独立したレプリケーションジョブをグループにまとめることができます。つまり、いままグループ化(シングルリーダーグループタイプ)すると、1セッションで処理されていたものが、あくまでも独立してそれぞれのセッションで実施されることになります。

これだけですと、特に意味が無いように思われますが、元々十分なパフォーマンスがソース/ターゲットデータベースにあり、シングルリーダーグループタイプでグループ化する必要がないようなケースや複数のソース/ターゲットデータベースがあるようなケースでは、レプリケーション数が多くなり、特定のレプリケーションを探すことが困難になることがあります。

コレクショングループタイプはレプリケーションの動作に影響しないため、他のグループに追加済みでなければ、そのレプリケーションのモード(リフレッシュ/ミラーリング/シンクロナイゼーション)やソース、ターゲットDBに関係なく一つのグループへ追加できます。

これにより、そのレプリケーションの目的別に、異なるモード、異なるソースDBを持つレプリケーションをグループへまとめて管理を簡単にできます。

例えば、下記のようなレプリケーションを構成している場合、シングルリーダーグループタイプでは➁と➂を1つのグループに➄と➅を1つのグループにできますが、他はまとめることができません。数が少なければこれでも管理できますが、多くなるとどれがどれだか判別が難しくなってきます。

コレクショングループタイプを使用すると➀から➅まで一つのグループにまとめることができ、例えば、以下のようなテーブルの用途別にグループ化するといったことも可能です。

グループ化してもそれぞれ独立したレプリケーションとして動作しますが、レプリケーションの有効化、無効化、設定変更などはグループ単位でまとめて実施できます。

管理用の環境だけメンテナンスするために停止したいなどのケースではグループ単位でレプリケーションをまとめて無効化しておくといった対応が可能です。

タグ:

保護中: Syniti Replicate 10.7リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

コメントを読むにはパスワードを入力してください。 -->

Syniti ReplicateによるRFCを使用したSAPシステムからのデータレプリケーション

 

SAP 4/HANA、ECCユーザの80%はSnowflake, AWS RedShift, Google BigQueryなどのクラウド・データウェアハウスを所有しています。これらのデータウェアハウスの用途は分析にあり、タイムリーに必要に応じたフレッシュなデータを提供する必要があります。

多くのSAP S4/HANA、ECCユーザはランタイム・ライセンスを使用しているのでサードパーティ・ツールは基本層にあるデータベースと相互に作用することはできません。

Syniti Replicateはそれらを解決する新機能を提供します!

Syniti Replicate(SDR) は、SAP RFC(Remoto Functional Call)プロトコルに基づくSAPシステムからのデータ抽出をサポートします。この機能を使用すると、SAPトランスペアレントテーブル、クラスタテーブル(SAP ECCのみ)、プールテーブル(SAP ECCのみ)、ビュー(SAP S/4HANAのみ)からデータを抽出できます。さらに、ユーザーはSAPシステムで複雑なクエリ(グローバルおよびローカル)を作成し、これらのクエリから標準テーブルのようにデータを抽出することができます。

このSyniti Replicate(SDR) の新機能はデータウェアハウスへ最新でタイムリーなデータ移動をデータ分析者に提供します。Synitiは、リアルタイムの変更データキャプチャを使用して、SAPから任意のデータウェアハウスプラットフォームに最新の重要なビジネスデータをレプリケーション、アップデート、統合します。それはSAPのアプリケーション層と直接の相互作用を可能とします。これによりCDC(Change Data Capture)ベースのレプリケーションが可能とし、SAPのランタイム・ライセンス違反も回避できます。

Syniti 新機能のデモ

SAP S/4HANAのデータをSnowflakeにリアルタイムにレプリケーション

(注)Remote Function Call (RFC) は、SAP システム間の通信のための SAP 標準インタフェースです。RFC は、リモートシステムで実行される関数を呼び出します。

タグ: , , , , , , , , ,

NoSQLクラウドデータベース: メリットと特徴

 

NoSQLクラウドデータベースは、クラウド上でサービスとして提供される非リレーショナルデータベースです。従来のリレーショナル・データベースのようなサイズの制限無く、データを保存、処理、検索するプラットフォームを提供します。このカテゴリーのデータベースは、SQLのような一連の同じフォーマットのレコードではなく、様々なデータモデルを扱うことができ、その柔軟性と拡張性で知られています。

NoSQLクラウドデータベースは、Database-as-a-Service(DBaaS)モデルの一部として利用されることが多く、開発者はインストール、プロビジョニング、チューニング、パッチ適用、更新、メンテナンスなどの運用作業から解放されます。これらのデータベースはパブリック・クラウド・プロバイダーで利用可能で、アプリケーション開発者に俊敏性と効率性の向上をもたらします。

具体的にどのようなメリットがあるのかをNoSQLとクラウドの側面を別々に考えてみます。

一般的なNoSQLデータベースの特徴

  • 非常に大きなデータセットを扱う
  • 柔軟な非リレーショナル・データベース構造を提供
  • ドキュメント、キーバリュー、グラフ、空間、時系列、ベクトルなど、さまざまなデータモデルの保存と管理が可能
  • 水平方向にスケーラブル、つまりリソースを追加可能。垂直方向にしかスケーラブルでないデータベースとは対照的。

NoSQLデータベースのメリット

  • 費用対効果
  • 非常に大規模なデータセットからのデータ検索の高速化
  • 変化するストレージ要件や処理要件に対応し、状況の変化への対応と運用コストの削減を実現

一般的なクラウドデータベースの機能

  • NoSQLデータベースはビッグデータ時代の直接的な成果であり、その多くは最新のクラウド・コンピューティング機能を実現するために特別に開発
  • Database-as-a-Service(DBaaS)のようなサービス・オプションを提供し、インストール、プロビジョニング、メンテナンスなどの運用タスクを削除することで、資本費用と専門従業員の必要性を削減
  • パブリック・クラウド・プラットフォーム上でホスティング可能
  • 通常、定期的に更新されるストレージ・テクノロジーが含まれ、より高いパフォーマンス、効率性、信頼性を提供

NoSQLクラウドデータベースのメリット

NoSQLデータベースがクラウドと組み合わされることで、その真価が発揮される。軽快で、適応性が高く、信頼性が高い。その利点を整理。

  • 機動性: ユーザはいつでもどこからでもクラウドデータベースにアクセスできます。
  • 柔軟な拡張性: 必要なときにクラウドリソースを追加し、不要なときにクラウドリソースとその費用を削除することが容易です。レガシーなリレーショナル・データベース(1台のサーバーで動作するよう制約されることが多い)とは異なり、NoSQLデータベースは水平方向に拡張できるため、コードを追加することなくクラウドの追加リソースを活用できます。
  • 管理が容易: NoSQLクラウドデータベースは、多くの場合、導入と管理が容易で、エンドユーザからはその複雑さの多くから解放されます。
  • セキュリティ: NoSQLクラウドデータベースは通常、バックアップ、複製、侵入に対するセキュリティが確保されています。

結局のところ、NoSQLクラウドデータベースは、企業がハードウェアの購入と保守に資本と人的資源を投下する必要がなく、その代わりに他の運用経費を予算化できることを意味します。同時に、必要なメンテナンスと運用タスクはすべてベンダが行うのが一般的で、フォークリフトによるアップグレードを必要とせずに、企業が必要とする分だけリソースが増加します。

楽天は、キャッシュバックやショッピングの特典を通じて、個人、地域社会、企業にインターネット・サービスを提供するの世界的リーダーである。同社のディスプレイ広告プラットフォームをサポートするために、楽天は、大容量データストア、低レイテンシ、無制限のスケーラビリティ、高可用性といういくつかの基準を満たすNoSQLデータベースを必要としていました。

適切なNoSQLクラウドデータベースの選択

ニーズを評価する 柔軟性、拡張性、パフォーマンス

クラウドを決定する前に、組織のニーズを検討しよう。柔軟性、スケーラビリティ、パフォーマンスであれば、NoSQLが答えとなる可能性が高くなります。

ここでは、何が重要かを評価する方法を説明します:

柔軟性:

  • 進化するニーズにデータベースがどれだけ適応できるか?
  • 自社のレガシー・テクノロジーとうまく連携できるか?

スケーラビリティ:

  • 企業やデータの成長に合わせてデータベースを拡張できるか。
  • 拡張の容易さと運用コストへの影響を考慮する。

パフォーマンス:

  • 待ち時間を最小限に抑えたリアルタイムの応答が求められるようになっているため、スピードを優先しましょう。
  • どのような負荷がかかっても安定したレスポンスを約束するデータベースを探しましょう。

要件を評価することで、アプリケーションのニーズに適したデータベースを選択することができます。これらの核となる属性をビジネス目標に合わせることで、アプリケーションに適したテクノロジーを選択できる可能性が高まります。

NoSQLがサポートするデータモデルの種類を理解する

NoSQLデータベースはすべて同じではありません。NoSQLデータベースにはさまざまな種類があり、それぞれが得意とするデータモデルを使用しています。

以下にいくつか例を挙げる:

  • ドキュメント・データベース: ドキュメント・データベース:データがJSON、XML、またはBSONアイテムで構成されている場合、これらを検討してください。ドキュメントデータストアをサポートするデータベースには、Aerospike、MongoDB、Couchbaseなど
  • キーバリューストア: Aerospike、DynamoDB、Redisなど
  • グラフ・データベース: Aerospike、Neo4j、Amazon Neptuneなど
  • ベクターデータベース: 大量の非構造化データを検索して類似点を探していますか?ベクターデータベースは、比較できないものを比較するのに役立ちます。Aerospike、Pinecone、Milvusがベクトルデータベースの例です。
  • カラム・ファミリー・ストア あなたのデータは、分析や時系列データなどのコンポーネントを含むスプレッドシートに似ていますか?Apache Druid、Snowflake、Cassandraなどがその例です。

この知識があれば、意思決定プロセスを暗中模索することはありません。データ固有のニーズに最適なモデルを選択することができます。

NoSQLの統合: サーバーレスアプリの構築など

クラウドでNoSQLデータベースを使用することは、手抜きをすることではなく、高速で効率的なパフォーマンスを実現するために最適なツールを使用することです。

NoSQLを活用したサーバーレス・アプリケーション開発

サーバ管理の微妙なニュアンスを気にすることなくアプリを作ることを想像してみてください。これがクラウドベースのデータベースを使用する利点です。NoSQLデータベースは、この柔軟なテクノロジーに最適なパートナです。

その理由は以下の通り:

  • サービスの共生: クラウドとNoSQLデータベースの相乗効果は、開発者にスケーラビリティと柔軟性を提供します。
  • オンデマンドのパフォーマンス: クラウドデータベースの従量課金モデルは、アプリケーションのニーズに合わせて拡張できます。

メリット:

  • バックエンドに煩わされることなくアプリケーションを開発できるため、複雑さが軽減されます。
  • ハードウェアをより効率的に利用でき、必要なときに必要な容量だけを支払うことができます。

複製されたデータ移行が可用性を向上させる仕組み

移行は大変な作業ですが、問題にする必要はありません。しっかりとした戦略を立てれば、NoSQLデータベースへの移行はデータ・レプリケーションによって簡単に行うことができます。

NoSQLデータベースは分散データを簡単に扱えるからだ。あるデータストアが利用できない場合、アプリは単純に別のデータストアに切り替わる。時間の経過とともに、複製されたデータストアは一貫性を持つようになります。

その仕組は

  • 成功のための設計図 データモデル、インデックス、クエリーパターンを含む移行マップを作成する。
  • 潜ってみる: 互換性とパフォーマンスを確認するため、パイロット・プロジェクトでテストする。

高可用性(HA)のセットアップ

  • 複製してから運用する: サービスを中断させないために、地域間で堅牢なデータレプリケーションメカニズムを確立
  • 警戒を怠らない: 監視ツールを導入し、システムの健全性を常に把握

ボーナスは

  • レプリケートされたデータは、ユーザーの近くに置かれることで、待ち時間を短縮します。また、1つのデータストアが利用できなくなった場合のデータベースの回復力も高まります。

NoSQLは水平スケーリングとレプリケートされたデータを簡単に扱えるため、当然HAセットアップに適しています。これらの戦略を使えば、マイグレーションとHAセットアップがハードルではなく、堅牢なインフラストラクチャへの足がかりになります。マイグレーションとHAを成功させるには、必要なときに必要な場所でデータを利用できるようにするための準備と計画が重要です。

NoSQLクラウドデータベースにおけるセキュリティの課題

徹底的に設計された内部プロセスとコンプライアンス戦略によってNoSQLクラウドデータベースのセキュリティを強化することは、ほとんどすべての組織にとってミッションクリティカルです。オンプレミスでもクラウドでも、データ漏洩は起こり得ます。ここでは、NoSQLクラウドデータベースのデータを保護するための主な考慮事項を紹介します。セキュリティ上の懸念とデータガバナンスへの対応は。

社内にデータセンターを持つ組織の中には、クラウドにデータを預けることをためらう人もいる。しかし実際には、クラウドベースのデータベースは通常、独自のセキュリティ・オプションと機能を提供している。

  • 重層的な防御: クラウドベースのデータベースは通常、認証、ユーザベースの承認、転送中と保管中のデータ暗号化を提供
  • 監査可能な証跡: ログファイルは通常、誰がいつ何をしたかを追跡

メリット

  • 定期的なバックアップとレプリケーションにより信頼を醸成し、機密データをサイバー攻撃から保護します。
  • きめ細かなアクセスにより、適切な人のみが適切な情報をスキャンできるようにします。

データの専門家がデータ・セキュリティとガバナンスを管理することで、データの信頼性と完全性を守ることができます。

また、ソフトウェア・パッチのインストールやストレージ・ハードウェアの最新かつ最も信頼性の高いテクノロジーへのアップグレードなど、なぜか手が回らないメンテナンス・タスクも、クラウド・データベースのオペレーターにすべて任せることができます。

NoSQLクラウド環境におけるコンプライアンスの確保

NoSQLクラウド環境であっても、コンプライアンス要件に対応するのは難しいことですが、適切なクラウドオペレーターを選択することが役立ちます。その理由は以下の通りです。

コンプライアンスの基本

  • データ・レジデンシー: ユーザーが居住するデータ主権に関する法律を常に把握。
  • 仕様要件: SOC 2 Type 2認証、ISO 27001、SOX、HIPAA、FIPS 140-2、GDPRなどの標準に確実に準拠。

実施すべきプラクティス

  • 定期的なコンプライアンス監査による問題の発見と修正
  • スタッフに対する継続的なトレーニング

重要な理由

  • 法的要件の範囲内にとどまることで、規制上の問題や重い罰金を回避することができます。
  • これは信頼に関わることであり、顧客は貴社が規制要件を満たしていることを知りたがります。

GDPR、CCPA、HIPAAのいずれであっても、NoSQLデータベースはコンプライアンスを維持するためのトレーサビリティと暗号化を提供します。特に規制の厳しい業界にいる場合は、コンプライアンス要件をすべて満たしていることを確認することが重要です。結局のところ、コンプライアンスとは、単に罰則を回避するだけではありません。誠実な事業運営を行っていることを顧客に示すことなのです。

タグ: ,

メモリとCPUのモニタリングによるデータベースのオーバーヘッドの削減

Database Performance Analyzer(DPA)を使用すると、CPUとメモリの使用量を最適化することで、データベースのランニングコストを大幅に削減できます。

Database Performance Analyzer(DPA)は、広範なデータベースソリューションのデータベースパフォーマンスを監視、分析、最適化するための非常に堅牢なツールセットを提供します。DPAの使用方法の1つに、データベース環境のCPUおよびメモリ使用量の最適化があります。こ れを適切に実行す る こ と で、 大幅な コ ス ト 削減を実現で き ます。デー タ ベース環境を最適化 し てパフ ォーマ ン ス と リ ソ ース効率を最大化す る ための6 つの簡単な手順を説明 し ます。

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

DPA を イ ン ス ト ール し 、 必要に応 じ て設定 し た ら 、 「パ フ ォ ー マ ン ス」 ダ ッ シ ュ ボー ド を使用 し て、 CPU (中央処理装置) や メ モ リ の使用量な ど、 デー タ ベース のパフ ォーマ ン ス を包括的に監視 し ます。

 図1:DPA ダッシュボードは、データベースのパフォーマンス メトリクスの概要を提供します。

パフォーマンスのボトルネックの特定

DPA の待機時間分析機能を活用し、データベースのボトルネックを突き止めます。こ の方法に よ り 、 日付レ イ ヤー全体で最も重大な遅延が発生 し てい る箇所を特定で き ます。

図2: 待機時間分析はパフォーマンス問題の根本原因の特定に役立つ

クエリ・パフォーマンスの分析

個々のクエリにドリルダウンして、特定のパフォーマンス値を分析する。最もリソースを消費するSQL文に焦点を当てます。

図3:詳細なクエリ・パフォーマンス分析は、クエリの非効率性を理解するのに役立つ

クエリーの最適化

分析に基づき、以下のステップでクエリを最適化:

●インデックスの最適化: インデックスを作成または変更し、クエリ・パフォーマンスを向上させます。
●クエリチューニング: DPA の推奨に基づいて非効率なクエリを書き換えます。
●実行計画の見直し: 変更が最適な実行プランにつながることを確認します。

図4 :DPAはクエリ性能を向上させるためにインデックスの最適化を推奨します。

リソース使用率の監視

CPUとメモリ使用量の経時的な傾向を追跡し、パターンと潜在的な問題を特定します:

●メトリクス: リソース利用メトリクスを分析し、CPU、メモリ、ディスクIOを把握することで、十分に利用されていないインスタンスを特定します。たとえば、データベース・インスタンスが高性能インスタンスで実行されているにもかかわらず、そのリソースのごく一部しか使用していない場合、そのインスタンスはダウンサイジングの候補となる可能性があります。
●モニタリング: データベースのCPU/メモリ使用率を定期的に監視し、使用率が低いインスタンスを特定します。例えば、過去3ヶ月間の平均CPU使用率が30%未満の場合、データベースが十分に使用されていない可能性があります。
●戦略: コストを削減するために、使用率の低いデータベースを縮小する戦略を実施します。たとえば、データベース・インスタンスをより低い構成にリサイ ズしたり、より費用対効果の高いデータベース・サービスに切り替えたりします。

図 5 :リソースの利用傾向を監視することで、パフォーマンスをプロアクティブに管理できる

変更の実施とレビュー

必要な変更をデータベース環境に適用し、その影響を継続的にレビューします。DPAを使用して結果を監視し、必要に応じてさらに調整します。これらの手順を実行することで、DPAを効果的に使用してCPUとメモリーのコストを削減し、より効率的でコスト効率の高いデータベース環境を実現できます。定期的な監視、詳細な分析、積極的な最適化は、高いパフォーマンスと効率を維持するための鍵です。

タグ: ,

Gluesync 2.0: 新しい統合とパフォーマンス向上へ

Gluesync 2.0は新しいデータソースと高可用性機能のサポートを含む、新しい統合とパフォーマンス強化しました。

最新リリースであるGluesync 2.0は、多くの新機能と改善点をもたらし、データ同期と統合のための画期的なアップデートとなりました。ここでは、このバージョンで導入された主な機能強化についてご紹介します。

Gluesync 2.0 新しいインテグレーション

Gluesync 2.0は統合機能を大幅に拡張し、いくつかの新しいデータソースのサポートを追加しました。このアップデートにより、以下のデータソースとの接続が可能になりました:

●MySQL & MariaDB: binログを使ったトランザクションログの読み込みに対応し、パフォーマンスと互換性が向上しました。
●ClickHouse: 利用可能なソースエージェントからターゲットとして使用できます。
●SingleStore: ターゲットとしてサポートされ、互換性のあるデータベースの範囲が広がりました。
●SnowflakeとVertica: 両方ともターゲットとして使用できるようになり、データレプリケーションの選択肢が増えました。

Gluesync 2.0の今後の統合

MOLO17は数ヶ月のうちに、ScyllaDB、Cassandra、Parquetファイルフォーマット、CosmosDB、Azure Data Lake、Redis、バイナリファイル転送、Google Big Queryのサポートなど、さらに多くの統合機能を導入する予定です。


高可用性機能

高可用性(HA)の重要性を認識し、Gluesync 2.0のロードマップにはいくつかのHA機能が含まれています:

●プライマリ/セカンダリ・アーキテクチャ:プライマリのコア・ハブ・ノードがクライアントのリクエストを処理し、障害が発生した場合はセカンダリ・ノードが引き継ぎます。

●Active-Active パターン:複数の Core Hub ノードがパイプライン・レベルで負荷を分担し、1 つのノードに障害が発生した場合の復旧能力を確保するします

●Multi-lti-Cluster Active DR: さまざまなVPC/データセンターに異なるGluesyncを配置し、ディザスタリカバリ機能を提供します

●インテリジェント・ロードバランシングによるアクティブDR:複数のコア・ハブ・ノードがエンティティ・レベルで負荷を分担し、耐障害性と復旧性を強化。

信頼性とパフォーマンス

Guesync 2.0は、自動化された統合テストの堅牢なスイートにより、品質とパフォーマンスを重視しています。

これらのテストにより、すべてのデータベース、構成、操作が検証され、ストレステストが行われ、信頼性と効率性の高水準が維持されます。

データモデリングの強化

データモデリングは、将来のイテレーションで改善が期待される、大幅なリファクタリングが行われています。これらの機能強化は、パフォーマンスの向上とソース・データベース・レベルでのリソース・フットプリントの削減に重点を置き、プラットフォームの機能をさらに最適化します。

まとめると、Gluesync 2.0は広範な新機能、統合、パフォーマンス強化をもたらす革新的なアップデートであり、データ同期と統合の主要プラットフォームとしての地位を確固たるものにします。

タグ: , ,

Syniti Data Replication: OracleからKafka StreamsへのCDC(Change Data Capture)方法

OracleKafkaへの接続を設定し、Syniti Data ReplicationのChange Data Capture(CDC)オプションを使用してKafkaにデータをレプリケートする方法についてのビデオチュートリアル(YouTube)。

Syniti Data Replication を使用すると、プログラミングや独自の構文を必要とせず、Oracle の本番システムに影響を与えることなく、変更データキャプチャを使用して、Apache Kafka StreamsOracle のデータを簡単に統合できます!

Syniti Data Replicationの製品概要

タグ: , , ,

Oracle RAC One Node環境を構成してみました ステップ4 Oracle Grid Infrastructureの導入

前回までの記事で、Oracle RAC One nodeを構成するための環境構成が一通り完了しました。今回はいよいよOracle Grid Infrastructureを導入していきます。

ーーーーーーーーーーーーーーーーーーーーーーーーーー
▽Oracle RAC One node構成関連ブログ
 ステップ1:Oracle Linux環境の導入
 ステップ2:Oracle Grid Infrastructureインストールの準備
 ステップ3:別Oracleノードの構成と共有ディスクの設定

 ステップ4:Oracle Grid Infrastructureの導入 ← 今回の記事
 ステップ5:Oracle RAC One nodeデータベースの作成
ーーーーーーーーーーーーーーーーーーーーーーーーーー

 

Oracle Grid Infrastructureインストーラの配置

Ora01マシンに対して、あらかじめダウンロードしていたOracle Grid Infrastructureのインストーラ(LINUX.X64_193000_grid_home.zip)を配置します。今回は下記画像のように、WinSCPを使用しgridユーザでログインして、/u01/app/19.0.0/gridのパスにインストーラを配置しました。

 

配置後はgridユーザでSSHログインし、「cd /u01/app/19.0.0/grid」コマンドでインストーラ配置先のパスに移動した後、「unzip -q LINUX.X64_193000_grid_home.zip」コマンドを実行し、解凍しておきます。

cd /u01/app/19.0.0/grid
unzip -q LINUX.X64_193000_grid_home.zip

 

Oracle Grid Infrastructureインストールの実行

インストーラを配置したOra01マシンに対してvSpher ClientなどからgridユーザでGUIログインし、「/u01/app/19.0.0/grid/gridSetup.sh」コマンドを実行してOracle Grid Infrastructureインストールウィザードを起動します。最初の画面では「Configure Oracle Grid Infrastructure a New Cluster」を選択し、[Next」をクリックします。

/u01/app/19.0.0/grid/gridSetup.sh

 

次のステップでは、「Configure Oracle Standalone Cluster」を選択し、「Next」をクリックします。

 

次のステップではクラスタ名やSCAN名を指定します。今回の環境ではそれぞれ以下を指定しました。
※クラスタ名は任意で構いませんが、SCAN名はhostsファイルに記載していたものを指定します。
Cluster Name:ora-cluster
SCAN NAME:ora-scan
SCAN Port:1521

入力後、「Next」をクリックします。

 

次のステップでは、Ora02ノードを追加するために、「Add」をクリックし、Public Hostnameに「Ora02」、Virtual Hostnameに「ora02-vip」をそれぞれ入力します。

 

OK」ボタンを押下しOra02ノードを追加した後は、「SSH Connectivity」をクリックして、gridユーザのパスワードを入力し、「Setup」を実行します。これにより、gridユーザがsshキーを介した接続が行えるように構成されます。実施完了後、「Next」をクリックします。

 

次のステップでは、各ネットワークの使用用途を指定します。今回はパブリックアクセス用の100のセグメントを「Public」、プライベート(兼ASM)接続用の111のセグメントを「ASM & Private」に、それぞれ指定しています。指定後、「Next」をクリックします。

 

次のステップでは、ASMの使用有無を指定します。今回はASMを使用するので、「Use Oracle Flex ASM for storage」を選択し、「Next」をクリックします。

 

次のステップでは、Grid Infrastructure Management Repository の使用有無を指定します。今回は使用しないので「No」を選択し、「Next」をクリックします。

 

次のステップでは、ASMディスクグループを作成します。今回はASMLIBを使用して構成したOCR領域を指定するため、まずは「Change Discovery Path」を選択し、パスとして「/dev/oracleasm/disks/*」を入力します。これにより作成済みのASMディスクが表示されるようになります。

 

その後、OCR領域用のASMディスクの各種パラメータを指定します。今回はそれぞれ下記のように指定しました。
Disk Group Name:OCR
Redundancy:External

Allocation Unit Size:4MB
Select Disks:/dev/oracleasm/disks/OCR

設定後、「Next」をクリックします。

次のステップでは、SYSとASMSNMPユーザのパスワードを指定します。任意のパスワードを入力後、「Next」をクリックします。

 

次のステップでは、Intelligent Platform Management Interfaceの使用有無を指定します。今回は使用しないので「Do not use Intelligent Platform Management Interface」を選択し、「Next」をクリックします。

 

次のステップでは、Enterprise Manager Cloud Controlの設定を行います。今回は使用しないので「Register with Enterprise Manager Cloud Control」のチェックを外したまま、「Next」をクリックします。

 

次のステップでは、ASM Administrator、ASM DBA、ASM Operator用のグループを指定します。今回はそれぞれ下記のように指定しました。
ASM Administrator:asmadmin
ASM DBA:asmdba

ASM Operator:asmoper

設定後、「Next」をクリックします。

 

次のステップでは、Oracle Baseパスの設定を行います。今回は「/u01/app/grid」を入力し、「Next」をクリックします。

 

次のステップでは、Inventory Directoryパスの設定を行います。今回はデフォルトの「/u01/app/oraInventory」のまま、「Next」をクリックします。

 

次のステップでは、構成スクリプトに関する設定を行えます。今回はデフォルトの「Automatically run configuration scripts」のチェックを外したまま、「Next」をクリックします。

 

次のステップに進むと、インストール実施のための構成チェックが行われます。今回は検証用に作成しているのみですので、SwapサイズやDNS関連の問題が出力しておりますが、インストールの実施自体は可能ですので、「Ignore All」にチェックを入れ、「Next」をクリックします。

 

最後にSummary画面に遷移するので、内容を確認し「Install」をクリックします。

 

インストールプロセスが開始されます。しばらくすると「Execute Configuration Scripts」画面がポップアップされます。

 

対応として、各OracleノードにrootユーザでSSH接続し「orainstRoot.sh 」と「root.sh」をOra01→Ora02の順で実行します。

まずはOra01マシンで「/u01/app/oraInventory/orainstRoot.sh」コマンドを実行します。

/u01/app/oraInventory/orainstRoot.sh

 

Ora02マシンでも同「orainstRoot.sh 」コマンドを実行します。

 

次に、Ora01マシンで「/u01/app/19.0.0/grid/root.sh」コマンドを実行します。

/u01/app/19.0.0/grid/root.sh

 

Ora02マシンでも同「root.sh」コマンドを実行します。

 

完了後、インストールウィザード画面に戻り、「Execute Configuration Scripts」画面の「OK」ボタンを押下し、インストールを再開します。

 

そのままインストールプロセスが100%に到達するまで待ちます。インストール終了後、今回の環境ではDNSにより名前解決されていないといったエラーが出力し、一部ステータスはFailedとなってしまっていますが、HostsファイルでSCAN名等が解決できていれば問題ないため、そのまま「Next」をクリックし、最終ステップで「Close」を押下、インストールウィザードを閉じます。

Oracle Grid Infrastructureの起動状況の確認

Oracle Grid Infrastructureインストール完了後「/u01/app/19.0.0/grid/bin/crsctl stat res -t」コマンドを実行し、すべてのステータスが「Stable」となっていることを確認します。

/u01/app/19.0.0/grid/bin/crsctl stat res -t

 

これでOracle Grid Infrastructureのインストールまで完了しました。
次回のブログでは、最後の作業としてOracle RAC One Nodeをのインストールを実施します。

参考ページ:https://docs.oracle.com/en/operating-systems/oracle-linux/7/install/#Oracle-Linux-7

タグ: , , ,

待ち時間分析によるOracleからPostgreSQLへの移行のトラブルシューティング:Database Performance Analyzer(DPA)

レガシーなOracleデータベースをオープンソースのPostgreSQLに置き換えるというコスト削減計画を持っている場合、おそらく次のような疑問が沸いてくるでしょう:

1. PostgreSQLのワークロードのパフォーマンスがOracleよりも良い、あるいは悪い場合、その場所(および理由)をどのように特定すればよいだろうか?
2.現状のOracleのチューニングやトラブルシューティングのスキルはどのようにPostgreSQLに移行するのべきか?
3.PostgreSQLコミュニティには不安があります。チューニングや構成に関する質問はどこにすればよいのでしょうか。

初めてOracleからPostgreSQLへの移行プロジェクトに携われば、このような疑問を抱いくのは当たり前です。主にOracleとSQL Serverに関わっていて、それらのデータベースには精通し、その後PostgreSQLが登場し、データベースのライセンス費用を節約するために使い始めたエンジニアは最初にそれらの不安が当然頭をよぎります。

上記の最初の質問に対する答えは、つまりPostgreSQLで負荷がより良く、あるいはより悪くなる箇所をピンポイントで特定する方法は、待ち時間分析です。これは、データベース移行の機能テストと性能テストの段階を迅速化するのに役立ちます。何がうまくいっているのか、あるいはあまりうまくいっていないのかを理解しようとするとき、これは常套手段です。

 

最初のPostgreSQLツール-pgAdmin

最初のOracleからPostgreSQLへの移行プロジェクトで、最初にやらなければならないことはツールを整備することです。pgAdminから始めましす。pgAdminは、ユーザを作成したり、テーブル定義や現在のアクティビティを確認したりするような管理作業には適しています。しかし、Oracle Enterprise Managerで見慣れていたトラブルシューティング情報がありません。経時的な傾向を見たり、過去のデータに基づいてトラブルシューティングを行うことはできません。

Database Performance Analyzerへのツール切り替え

 Database Performance Analyzer(DPA)で、Oracleで使い慣れたPostgreSQL用の機能を使用できるようになります。また、OracleとPostgreSQLの両方をサポートしているため、両方のデータベースで表示されるパフォーマンスを正規化して比較できるという利点もあります。

待ち時間分析を使ってPostgreSQLのパフォーマンスを改善する

DPAはデータベースのワークロードを把握し、Wait Time Analysis(待機時間分析)を理解し、適切なツールを持っているとします。その場合、まだPostgreSQLを学習中であっても、移行したデータベースのチューニングを加速させることができます。Oracleから移行したPostgreSQLデータベースのWait分析について説明します。

注意: 待機イベントはPostgreSQL v9.6で導入されたため、これを行うにはPostgreSQL 9.6以降に移行する必要があります。

以下のDPAの Top SQL Average Wait TimeダッシュボードはPostgreSQLチューニングの道のりを示しています。トランザクションのスループットを数秒からミリ秒以下にするのに数日かかっています。

図 1: データベース・パフォーマンス・アナライザの平均待ち時間

1日目:PGTuneを使ってデフォルトのPostgreSQL構成設定から抜け出す
まず、PGTuneという無料のオンライン・サービスからワークロードとハードウェア固有の推奨値を使用して、デフォルトのPostgreSQL設定を変更。上記の12月6日と12月7日の平均待ち時間の比較でわかるようにし、これは大きな違いをもたらしました。

2~4日目:WALとバッファーのパフォーマンス問題の解決
以下のDPAの合計待ち時間ダッシュボードを見ると、PostgreSQLのライト・アヘッド・ロギング(WAL)が多くの時間を消費していることがわかります:

図2:合計待ち時間-WALの書き込みに多くの時間がかかっている(12月7日)。

ダッシュボードはまた、どのような設定の変更を検討すべきか推奨します。これは、PostgreSQLのチューニングの学習曲線を登っていくときに役に立ちます:

図3:Database Performance Analyzerのチューニング推奨事項

DPAが提供したアドバイスに従って、いくつかの変更を追加:

1.共有バッファとWALバッファのサイズを増加
2.WALを別の場所に移動した(これによって大きな違いが生じた)
3.バッファーの競合を減らすため、オートフィル係数を100から90に変更
4.同時セッション数を制限するためにアプリケーション・コードを変更

上の図1に示すように、これらの変更により、12月7日から12月10日にかけて平均待ち時間が8倍に短縮され、ミリ秒以下のトランザクション・パフォーマンス目標を達成することができました。

OracleとPostgreSQLのパフォーマンスの可視化

OracleとPostgreSQLのパフォーマンスを同じダッシュボードで表示できることは、特に並行テスト中に役立つ知見の1つです。DPAはPostgreSQLとOracle(および他の多くのDBMS)の両方をサポートしており、PostgreSQL対Oracleの待機時間履歴を確認することが可能です:

図4:OracleとPostgreSQLの待ち時間履歴の比較

1つのツールを使用して両方のデータベースのパフォーマンスを監視することで、OracleとPostgreSQLのパフォーマンスチューニングを正規化でき、パフォーマンスプロファイルの違いを理解しやすくなります。

DPAのその他の有用なOracleからPostgreSQLへの移行支援補助

DPAが提供する待機時間に関する洞察機能の中には、異常検知やテーブルチューニングアドバイスなど、役に立つと思われるものが他にもあります。

異常検知を使用してさらに診断する

DPA は異常検知にも使用できます。こ れは、 通常か ら 逸脱 し てい る と き に通知 し ます。例えば、下のグラフにある12月9日のオラクル待機時間データは、水曜日らしくない範囲外の値を起こしています。

図5:DPAにおける待機時間異常の可視化

そこから、異常が発生した日または時間帯をドリルダウンして、異常の原因となった特定のSQL文、文を発行したクライアント マシン、使用したリソースなどを調べることができます。

テーブルチューニングのアドバイス

個々のステートメントを確認したら、Table Tuning Advisor を使用して、そのステートメントをチューニングし、パフォーマンスを向上させるためにできることがあるかどうかを確認できます。高負荷のクエリを分析し、非効率なワークロードが実行されているテーブルを特定するのに役立ちます。このアドバイザは、テーブルと各テーブルの非効率なクエリに関する集計情報を表示します。どのSQL文に取り組み、どのテーブルにインデックスを作成すればブロックが軽減されるかを判断するのに役立ちます。

最後に

以上のようにOracleからPostgreSQLへのデータベース移行プロジェクトにおいて、DPAが待ち時間分析をどのように役立てるかの例をいくつか紹介しました。PostgreSQLの待機イベントと従来の統計データを比較することで、性能のボトルネックを特定し、自信を持って移行することができます。結局のところ、両方の分野の専門家であるDBAは稀です。

DPAによるOracleとPostgreSQLの両方の待ち時間を分析する単一のツールを使用することで、どこに注意を向けるべきか、何をどのようにトラブルシュートすべきかを理解しやすくなりました。待ち時間分析に加えて、DPAにあるチューニングのヒントは、移行プロセス中にPostgreSQLのIQを大いに高めてくれます。環境、リソースの利用状況、予測、変更の影響などをよりよく理解できるようになります。

Database Performance Analyzer(DPA)のお問い合わせはこちらへ

タグ: , , ,