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チームがデータベースの健康状態とパフォーマンスを最適化するためのツールを確実に提供できます。

タグ:

Gluesync for MySQL 8+:リアルタイム同期のための高性能な変更データキャプチャ(CDC)の実装

MySQLデータベースをリアルタイムで同期することは、最新のアプリケーション、分析、クラウド統合にとって不可欠です。さらに、最新のMySQL 8+アップデートにより、リアルタイム分析、災害復旧、クラウド移行をサポートするために、より高速で信頼性が高く、コスト効率の良いデータ複製が求められています。

Gluesync MySQL8+

Gluesync for MySQL 8+は、オンプレミスとクラウド環境間の低レイテンシで高速なデータ移動を保証する最適化された変更データキャプチャ(CDC)ソリューションを提供します。従来のETLツールとは異なり、GluesyncはMySQLのBin Logとネイティブに統合され、最小限のオーバーヘッドと最大限のデータ可用性を実現します。

さらに、この更新されたMySQLコネクタにより、企業はEnterprise、Percona、AWS RDS、MaxScale、またはコミュニティエディションを使用しているかどうかに関わらず、MySQLデータベースをシームレスに同期することができます。

MySQL用の高度な変更データキャプチャ(CDC)

GluesyncのMySQLエージェントは、組み込みのJDBCドライバを使用してデータベースに接続し、直接かつ高速な接続を実現します。 また、Bin Logスクレイピングを活用してリアルタイムの変更を追跡し、すべての挿入、更新、削除操作が即座にキャプチャされることを保証します。

今回の更新における主な改善点のひとつは、Bin Log処理の最適化であり、これによりデータ抽出がさらに高速化され、効率的になりました。マスター、レプリカ、MaxScaleインスタンスのいずれを使用している場合でも、Gluesyncはシームレスな互換性とスムーズなデータ移動を保証します。

さらに、パフォーマンスを向上させるため、Gluesyncは最適化されたTCPソケット接続を使用するようになり、待ち時間を短縮し、データ転送を高速化します。単一のマスターノードと専用Server IDをサポートしているため、セットアップは簡単で、不必要な複雑さを排除できます。

その結果、企業はミッションクリティカルなアプリケーション、分析、バックアップ戦略にリアルタイムかつ低レイテンシのデータ複製を利用することができます。高可用性システムを運用している場合でも、クラウドへの移行や災害復旧の確保を行っている場合でも、Gluesyncは必要な信頼性を提供します。

クラウドベースのMySQL(DBaaS)とのシームレスな統合

AWS、Google Cloud、Azure、Oracle Cloud 上のマネージドMySQLサービスに移行する企業が増える中、これらの環境におけるスムーズなデータ同期の確保は不可欠です。Gluesyncは、マスキング対応のトランザクションログ(Bin Log)が有効になっている場合、クラウドベースのMySQLデータベースを完全にサポートします。

Gluesyncは、サードパーティのJDBCドライバに依存する従来のETLツールとは異なり、MySQLのAPIと直接通信するため、不要なライセンスコストを排除し、効率性を向上させます。クラウドベースのMySQLユーザーは、リアルタイムの監視、最適化されたネットワーク利用、即時アラート機能の恩恵を受け、遅延なくデータの同期を維持することができます。

GluesyncをクラウドベースのMySQLと併用するメリット

大規模なデータレプリケーションを扱う企業にとって、Gluesyncは高性能で拡張性のあるソリューションを提供します。ネイティブCDCをサポートすることで、レイテンシの問題を排除し、分散システム全体でデータの整合性を確保します。

Gluesyncを使用することで、企業は以下を実現できます。

  • データが常に最新の状態に保たれるため、リアルタイム分析を強化
  • 業務を中断することなく、シームレスなクラウド移行を実現
  • 継続的なデータ同期により、高い可用性を維持
  • セカンダリデータベースを完全にミラーリングすることで、災害復旧への備えを確保

アプリケーションへの即時データ更新、効率的なレポート作成、信頼性の高いバックアップ戦略など、どのようなニーズにも対応します。Gluesyncは、最新のMySQL環境に必要なスピードと柔軟性を提供します

Gluesync for MySQL 8+の試用について

Gluesyncは、高速かつリアルタイムのデータ移動を必要とする企業向けに開発されました。MySQLをオンプレミスまたはクラウドで実行している場合でも、Gluesyncはシームレスで安全かつ効率的なデータ同期を実現します。是非お問合せ下さい

タグ: , , , ,

[Druva] Oracle RMAN イメージコピー + SBT ストリームバックアップ 重複排除

はじめに

DruvaのOracleデータ保護ソリューション(Phoenix Backup StoreおよびDirect-to-Cloud)は、Oracleのスタンドアロン環境だけでなく、クラスタ化(RAC)環境の保護にも役立ちます。DTC(Direct-to-Cloud)テクノロジーにより、データセンターまたはクラウドで稼働するOracleデータベースのバックアップを、AWS S3のDruvaの重複排除ストレージに直接ストリーム配信することができます。このソリューションは、ソース側重複排除テクノロジーをサポートし、Oracle SBT APIを実装しています。PBSソリューションは、バックアップの最新コピーをローカルストレージに保持し、RTOを改善します。

SBTベースのフルおよび増分ストリームバックアップに関しては、Oracle Recovery Manager (RMAN) の多重化により、重複排除が非常に困難になります。ここでは、DruvaのOracle DTCソリューションの開発において、この問題にどのように対処し、非常に予測可能な重複排除率を達成したかについて説明します。

RMANイメージコピー

Druvaは、Oracleの2つの保護ソリューション、Oracle DTCとPBS(Phoenix Backup Store)をサポートしています。PBSソリューションはダンプ・アンド・スイープソリューションであり、DruvaはユーザにRMANテンプレートスクリプトを提供し、Oracle本番サーバー上で実行できるようにしています。NFSマウントポイントはPBSからエクスポートされ、保護対象のOracleサーバーにマウントされます。Druvaが提供するテンプレートスクリプトは、増分マージ技術とともにRMANイメージコピーを使用して、RMANバックアップをNFSマウントポイントに書き込みます。RMANイメージコピージョブが完了すると、PBS上にファイルシステムレベルのスナップショットが作成され、スナップショットのデータがDruvaクラウドの重複排除ストレージにアップロードされます。

イメージコピーバックアップの場合、RMANはOracleデータ、コントロール、アーカイブされたREDOログファイルのコピーをNFSマウントに書き込みます。このコピーはOSのコピーコマンドと似ています。データ、コントロール、アーカイブされたREDOログファイルのフォーマットに変更はありません。RMANはコピープロセス中にネイティブファイルフォーマットを保持します。

イメージコピーバックアップの性質上、このデータをクラウドにアップロードすると、優れた重複排除が実現します。重複排除率は、Druva FSエージェントを使用したファイルバックアップと比較できます。

RMAN多重化の問題

DruvaのOracle DTCソリューションは、Oracleが提供するSBTストリームAPIの実装を使用しています。Oracle RMANがバックアップ中にストレージにバックアップピースを書き込む際に使用するブロックサイズは、データファイルとアーカイブログファイルでは通常256KBです。Druvaで使用する重複排除ブロックサイズは、Oracleでは1MBです。初期の開発段階では、以下の理由により予測不可能な重複排除率が見られました。

  • SBTストリームバックアップの場合、複数のOracleスレーブプロセスが複数のファイルから同時にデータを読み取り、1つ以上のストリームにバッファを送信します。Oracle RMANの書き込みブロックサイズが256KBで、Druvaのブロックサイズが1MBであるため、バックアップごとにブロックの順序が変わり、重複排除に影響を与えます。
  • RMANのマルチセクションバックアップを使用している場合は、問題がさらに悪化します。

RMANの多重化およびマルチセクションバックアップの影響を回避する

FILESPERSETは、Oracle RMANがバックアップピースへのファイルの多重化を制御するために使用するオプションです。このオプションは、特定のバックアップピースに書き込まれるデータファイルまたはアーカイブされたREDOログファイルの数を制御します。前のセクションで説明したように、ファイルは同時に非同期で読み取られるため、バックアップストリーム内のブロックの順序は毎回異なります。私たちは自動生成されたRMANバックアップスクリプトでFILESPERSET = 1を使用しています。この設定により、1つのバックアップピースには1つのデータファイルまたはアーカイブされたREDOログファイルのみが書き込まれるようになります。これにより、ブロックが同じ順序で書き込まれることも保証されます。これまでのところ、調査環境のデータファイルのサイズはそれほど大きくないため、マルチセクションバックアップは使用していません。通常、データファイルのサイズは数GBの範囲です。

ローカルフィンガープリントキャッシュ

次に取り組んだ問題は、ローカル指紋キャッシュに関するものでした。Druva Phoenixは、重複排除サーバーへのネットワークの往復を回避するために、ローカル指紋キャッシュを使用します。指紋キャッシュはファイル名ベースです。ファイルが重複排除ストレージに初めてバックアップされると、ブロック境界でチャンク化され、クラウドで実行中の重複排除エンジンにプローブコールが送信され、フィンガープリントがすでに存在するかどうかを確認します。フィンガープリントがすでに存在する場合は、重複排除サーバーにデータは送信されず、フィンガープリントの参照カウントのみが増加します。重複排除エンジンが以前に見たことのないフィンガープリントの場合は、ブロックが重複排除サーバーに送信されます。このプロセス中、ファイルのすべてのブロックのフィンガープリントもローカルシステムにキャッシュされます。その後のバックアップでは、まずローカルのフィンガープリントキャッシュが確認されます。フィンガープリントがローカルキャッシュで見つかれば、重複排除サーバーにプローブを送信する必要はありません。これによりネットワークの往復が削減され、全体的なパフォーマンスが向上し、クラウドで実行される重複排除インデックスの計算コストも削減されます。

しかし、RMANでは、独特な問題に直面しました。RMANを使用してデータファイルのバックアップを行うと、バックアップごとに一意の名前が付けられます。これにより、ファイルが重複排除キャッシュに新しいファイルとして表示されるため、すべてのプローブがクラウドで実行されている重複排除サーバーに送信され、パフォーマンスに影響を与え、重複排除インデックスの検索コストが増加します。

この問題に対処するために、Druva Oracle DTCはRMANデータファイルとアーカイブログストリームを開くRMANストリームハンドラを実装しています。ストリームハンドラは、デフォルトではOracleのデータファイルでは8K、アーカイブログファイルでは512バイトであるデータファイルのブロックサイズを識別します。ブロックサイズが識別された後、さらに多くのストリームブロックが検査され、Druvaがバックアップピースとバックアップストリームに含まれるデータファイル間の関係を確立するのに役立ちます。ローカルフィンガープリントキャッシュは、ファイル番号と相対ファイル番号を使用して、フィンガープリントキャッシュ内で一意のIDを作成します。

重複排除率

FILESPERSETとOracle RMAN SBTストリームハンドラを組み合わせたOracle DTCソリューションでは、非常に優れた重複排除率が得られました。ストリームハンドラを追加した後でも、RMANによる最適化が重複排除に影響を与える可能性があるため、ファイルとフォルダのバックアップと直接比較することはできません。

Druvaは100%のSaaSベースのソリューションであるため、インデックスの検索コストとネットワークが非常に重要になります。Druvaの重複排除ストレージインデックスはAWS Dynamo DBを使用しており、インデックスの検索にはすべて原価がかかります。データセンターではLANではなくWAN経由でデータを移動させるため、ネットワークの使用状況は重要です。全体として、これらの機能により、クラウドにおける重複排除サーバーへのネットワーク往復回数とインデックス検索コストが削減され、予測可能な重複排除率を実現できるようになりました。

 

タグ: , , , , ,

Druvaのブロックレベル自動リカバリ:データベースリカバリの世界に革新を

データの整合性を維持し、ダウンタイムを最小限に抑えることは、企業にとって最も重要な課題です。オラクルのブロックメディアリカバリ(BMR)機能は、データベース管理者(DBA)がデータベース全体をリストアすることなく破損したデータブロックを修復できる先進的なソリューションです。これにより、迅速かつ効率的なリカバリプロセスが保証され、企業は業務を滞りなく円滑に継続することができます。

ブロックメディアリカバリ(BMR)の利点

Oracleデータベース環境では、データベースファイル全体の破損はまれですが、高頻度のトランザクションや高負荷のデータベースではブロックレベルの破損がよく発生します。この種の破損はデータベースファイルに部分的な影響を与え、特定のトランザクションで予期せぬ動作を引き起こす可能性があります。このような場合、データベース全体の復旧は過剰な対応となり、ダウンタイムやリソースの無駄遣いにつながる可能性があります。

データベースの完全復旧を行うのではなく、BMR を使用して破損したブロックのみを復元することで、貴重な時間とリソースを節約できます。 BMR は、データベース操作への影響を最小限に抑えることで、ビジネスの継続性を確保します。

Druva の自動ブロックレベル復旧 (BLR) ソリューション

Druva のブロックレベル復旧 (BLR) ソリューションは、破損したブロックのみを復旧するプロセスを自動化することで、BMR をさらに進化させます。 その仕組みは次の通りです。

データブロックが破損した場合、最新のフルバックアップ、差分バックアップ、またはログバックアップから、破損したデータブロックのみを復元することができます。最新のポイントインタイム(PIT)スナップショットを選択するだけで、この処理を開始できます。これにより、データベース全体の復元が不要になり、復元時間を短縮し、ダウンタイムを大幅に削減できます。

Block media recovery 1

DruvaのBLRソリューションの主な機能

DruvaのソリューションがBMR(ブロックメディアリカバリ)をさらに強力にする仕組みは次の通りです。

  1. 完全自動化プロセス:手動操作を一切必要としない完全自動化プロセスにより、企業は破損したデータブロックの管理とリカバリを容易に行うことができます。
  2. データベース全体の復旧が不要:影響を受けたデータブロックのみを復旧することで、データベース全体の復旧に伴う手間を省き、時間とリソースを節約できます。
  3. ダウンタイムゼロで高速な復旧:破損したデータブロックをターゲットとして復旧することで、復旧プロセスが高速化されます。これにより、データベースの稼働が維持され、進行中のトランザクションや操作が中断されることなく継続できます。
  4. プロセス全体を明確に可視化:Druvaは復旧プロセス中に詳細な進捗ログを提供し、どのデータファイルが破損しているか、復旧がどのように進んでいるかについて、DBAに明確な洞察を提供します。

Block media recovery 2

BMRにDruvaを選ぶ理由とは?

競争が激しく、変化の速い今日の環境では、ダウンタイムを最小限に抑え、ビジネス継続性を確保することが極めて重要です。DruvaのBLRソリューションは、時間のかかるデータベース全体のリストアを必要とせずに、破損したデータブロックのみを自動的に、効率的かつ効果的に復旧する方法を提供します。

この機能は時間を節約するだけでなく、ダウンタイムゼロを実現することでシームレスなビジネス継続性を保証します。スピードと効率性の完璧なバランスです。

結論:データ復旧のための非常に効率的なアプローチ

Druvaのブロックレベル復旧は、データ破損のより効率的な管理方法を求める企業にとって画期的なソリューションです。破損したブロックのみを自動的に復旧することで、ダウンタイムゼロを実現し、データ復旧プロセスに革命をもたらしました。

 

タグ: , , , , , ,

Web UI日本語化でもっと簡単にデータ同期[Gluesync 2.0.9]

先日、リリースされた2.0.9でUIの日本語化がサポートされました。

https://molo17.com/gluesync/gluesync-2-0-9-update-multilingual-support-developer-tools-sdks-and-tight-grafana-integration

特に設定をする必要はなく、Webブラウザの言語に基づいて表示されますので、通常は2.0.9へアップデート後、Gluesyncへアクセスすると日本語のログイン画面に変わっています。※逆に英語のUIへアクセスする場合にはブラウザの言語設定を英語に変更してください。

説明等は英語のままですが、基本的には日本語化されています。いくつかサンプルとして取得したスクリーンショットです。

このようにより使いやすくなったGluesync、RDBMSやNoSQL間でのリアルタイム同期をお試しください。

30日間無償評価のお申し込みやお問い合わせはクライムまで!

https://www.climb.co.jp/soft/gluesync

タグ: , , , ,

DruvaのOracle DTCリダイレクト・リストア(復元):シームレスな効率性でデータベースのクローニングに革命を

企業は、開発やテスト、データベースのアップグレード、バックアップ、災害復旧、システム移行など、さまざまな目的でデータベースを複製します。しかし、データベースを手動で複製することは、非常に面倒で複雑な作業です。このブログでは、Oracleデータベースのクローニング(Cloning)の概念、企業がデータベースを手動で複製する際に直面する一般的な課題、そしてDruvaのOracle DTC Redirected Restore(データベースのクローニング)ソリューションがこのプロセスをどのように合理化するかについて詳しく説明します。

Oracle Database Cloningとは?

Oracle Database Cloningとは、既存のOracleデータベースを再作成するプロセスです。クローン化されたデータベースは、以下のような幅広い用途で使用できます。

  1. 開発とテスト:開発者や品質保証(QA)チームは、アプリケーションや新機能のテスト、問題のデバッグを行うために、本番環境のレプリカを必要とすることがよくあります。クローン化により、本番環境に影響を与えず、本番データベースを危険にさらすことなく、データを使用して作業を行うことができます。
  2. データベースのアップグレードと移行:Oracleデータベースのアップグレードや新しいプラットフォームへの移行の際には、本番環境に変更を加える前に、クローンを使用してアップグレードや移行プロセスのテストや検証を行うことができます。
  3. 災害復旧とバックアップ:クローニングの最も重要な用途のひとつは、災害復旧による事業継続性の確保です。クローン化されたデータベースは、障害発生時の迅速な復旧に使用することができます。また、特定時点での復旧テストを実施してバックアップの有効性を検証し、災害復旧戦略を強化することも可能です。
  4. パフォーマンスチューニングと負荷テスト:本番環境に変更を適用する前に、データベースのベンチマークとストレステストを行うことが重要です。クローンデータベースは実際の負荷をシミュレートするため、DBAはライブユーザーに影響を与えることなくクエリとインデックスを最適化することができます。
  5. データマスキングとセキュリティテスト:クローンデータベースを使用することで、コンプライアンステスト、規制監査、セキュリティ評価のために機密情報をマスキングし、本番データの安全なコピーを作成することができます。
  6. トレーニングおよび教育:本番データベースのクローンは、データベース管理、レポート作成、分析に関するトレーニング用の現実的なデータセットを提供します。
  7. 事業継続およびレポート作成:大量の分析クエリを本番データベース上で直接実行すると、深刻なパフォーマンス問題が発生する可能性があります。クローンデータベースをレポート作成に使用することで、本番環境の負荷を軽減できます。

手動によるOracle Database Cloningの課題

Oracle Database Cloningには多くの利点がありますが、RMAN、Data Pump、ホットバックアップなどの使用する手法によっては、手動によるクローニングプロセスが極めて複雑になり、いくつかの課題が生じる可能性があります。以下は、手動によるデータベース・クローニングの一般的な課題です。

  1. ストレージとパフォーマンスの問題:大規模なデータベースのクローニングには膨大なストレージリソースが必要であり、REDOログ、ARCHIVEログ、または一時テーブルスペース用のスペースが不足すると、パフォーマンスの問題が生じることがあります。
  2. ネットワークおよびリソースの制約:低速のネットワークを介したリモートでのデータベースのクローニングは、時間がかかるだけでなく、CPUやメモリの使用率が高くなると、ソースサーバー上で実行中の他のアプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。
  3. 構成および互換性の問題:ソースデータベースとターゲットデータベースのOracleのバージョン、パッチレベル、またはオペレーティングシステムの構成に相違があると、クローニングに失敗する可能性があります。
  4. クローニング後のタスク:データベースのクローニング後、DB_NAMEやDB_UNIQUE_NAMEなどのデータベースパラメータを更新するなど、いくつかの追加の手動タスクが発生します。さらに、競合を防ぐために、ネットワーク設定やリスナーを更新する必要がある場合もあります。
  5. 自動化とスクリプトのエラー:要件に合わせてクローニングスクリプトを修正する必要がある場合があり、これらのスクリプトにエラーがあると、クローンの一部が失われたり、クローン化に失敗したりすることがあります。

DruvaによるOracle DTCリダイレクト復元の課題解決方法

DruvaのOracle DTCリダイレクト復元ソリューションは、代替ホストサーバー上でデータベースを復元および再作成するオプションを提供することで、上記の課題をすべてシームレスに解決します。このオプションにより、お客様は、データベースのエアギャップコピーを使用して、本番データベースやその他のユーティリティデータベースを他のホスト上で簡単にクローン作成でき、安全で効率的なクローニングプロセスを実現できます。

oracle dtc 1

以下にその仕組みを説明します。

  1. ソースデータベースのターゲットサーバーでの作成:このプロセスは、ターゲットサーバー上にソースデータベースのコピーを作成することから始まります。
  2. データの復元とリカバリ:Druvaのクラウドスナップショットからデータを復元し、ターゲットサーバーにリカバリします。
  3. データベースの名前変更:復元されたデータベースは、ユーザーが指定したターゲット名に変更されます。

代替データベースのクローニングオプション

Druvaは、さまざまなクローニングオプションを提供しています。

  • 代替データベースサーバー上で、最小限のサーバーパラメータ(SPファイルの復元は除外)を使用して新しいデータベースを再作成します。
  • ソースデータベースからすべてのサーバーパラメータ(SPファイルの復元を選択)を使用して新しいデータベースを再作成します。
  • 復元されたデータベースの既存のサーバーパラメータを更新するか、新しいサーバーパラメータを追加します。
  • 既存のデータベースの名前を変更します。

oracle dtc 2

主な利点

  • 実行中のソースデータベースは不要:DruvaのOracle DTCソリューションの主な利点の1つは、クローニングプロセスがDruva Cloudのスナップショットからデータを活用するため、ソースデータベースを実行する必要がないことです。これにより、ライブ運用に影響を与えるという負担から解放されます。
  • 最小限のストレージ要件:データはクラウドから直接復元されるため、ターゲットサーバーに追加のストレージは必要なく、クローニングに伴う複雑性とコストを大幅に削減できます。

Oracle DTC リダイレクト復元の機能

DruvaのOracle DTCソリューションがシームレスで効率的かつ安全なデータベースのクローニングを実現する理想的な選択肢である理由となる強力な機能の一部をご紹介します。

  • 簡単なリダイレクト復元: 以前のフルまたは増分Druvaバックアップを活用して、迅速かつシームレスな復元プロセスを実現します。
  • ポイントインタイムのクローニング: PIT復元オプションを使用して、特定のポイントインタイムでデータベースをクローニングします。
  • プロアクティブなリストア事前チェック:データベースをリストアする前に、弊社のソリューションは一連の事前チェックを実行し、ターゲットサーバーがソースデータベースと互換性があることを確認し、潜在的なリストアの失敗を回避します。これには以下が含まれます。
    • 既存のデータベースに影響を与えないことを確認するためのソースおよびターゲットデータベース名のチェック
    • 互換性のあるOSおよびOracle Databaseインスタンスのバージョン
    • デバイス接続
    • 空き領域およびメモリの可用性
    • Oracle HomeおよびOracle Baseパス
    • リストア先とその権限

oracle dtc 3

問題が発生した場合は、必要な修正を行い、チェックを再実行し、クローニングプロセスを続行できます。

DruvaのOracle DTCを選ぶ理由

DruvaのOracle DTCデータには、以下のような幅広い利点があります。

  • 完全自動化プロセス:クローニングプロセスが自動化されているため、手動介入が減り、時間を節約できます。
  • 事前チェック: 組み込みの事前チェック機能により、クローニングプロセスを開始する前にDBAが情報を得た上で意思決定を行うことができるため、時間を節約し、リスクを低減できます。
  • 余分なストレージオーバーヘッドなし: 復元するデータベースのサイズ以上の余分なストレージは必要ありません。
  • クラウドからの直接復元: これにより、中間ストレージソリューションが不要になり、より効率的な復元プロセスが実現します。
  • スナップショットとポイントインタイムリカバリ:テスト、アップグレード、災害復旧など、さまざまな目的で特定のポイントインタイムでデータベースをクローン化します。
  • RACとスタンバイデータベースのサポート:当社のソリューションは、必要に応じて、スタンドアロンインスタンスとしてRACデータベースを復元したり、スタンバイデータベースをプライマリデータベースに変換したりすることもサポートしています。

結論

Oracle DTC Redirected Restoreは、Oracleデータベースのシームレスなクローニングを組織に提供する効率的な完全自動ソリューションです。Druvaのクラウドベースのバックアップおよびリストア技術を活用することで、組織は手動のクローニングプロセスに伴う複雑性、時間、コストを削減できます。

タグ: , ,

4つの重要なデータベースの課題と、その解決策

今日の急速に変化するデジタル環境において、データベース管理者はかつてないほど複雑な状況に直面しています。 最も差し迫ったデータベースの課題4つについて掘り下げ、堅牢なデータベースの可視化が運用にどのような変化をもたらすかを考察します。

マルチデータベース環境の複雑性

現代のビジネスでは、それぞれに独自の特性と要件を持つさまざまなデータベースを管理することがよくあります。MySQLやPostgreSQLなどのリレーショナルデータベースから、MongoDBやCassandraなどのNoSQLデータベースまで、その種類は多岐にわたります。さらに、これらのデータベースがオンプレミスとクラウドプラットフォームに分散している場合には、問題はさらに複雑になります。 それぞれのプラットフォームには、往々にして異なる時代に開発されたツールや監視ソリューションが存在します。 このような多様なエコシステムを管理するための運用コストは膨大です。 データベース管理者やITチームは、全体像を把握できず、制御もできないまま、断片的なシステム全体像を提供する複数の監視ツールを同時に使用しなければなりません。

マルチデータベース環境では、1つのデータベースに障害が発生すると、それが連鎖反応を起こしてシステム全体に影響を及ぼす可能性があります。これにより、パフォーマンスと信頼性に影響が及びます。 これらの問題に対処するために、企業はデータベースの監視ソリューションにますます注目するようになっています。 これらのツールは、すべてのデータベースの完全なビューを提供します。 チームは、1か所からすべてのデータベースを監視および管理することができます。 オンプレミス環境とクラウド環境の両方に統合することで、監視ソリューションは、最適なデータベースパフォーマンスを維持するために必要な包括的な可視性を提供します。 運用上の負担とSLAの未達成が減少し、チームは迅速に問題を診断し、解決することができます。

遅いデータベースの問題の診断

データベースの動作が極端に遅くなると、診断に時間がかかります。 1秒1秒が重要です。 データベースチームにとっての課題は、問題を特定し、その正確な原因を突き止めることです。 複雑な最新のマルチデータベース環境では、この問題がさらに深刻化します。 パフォーマンスのボトルネックは、非効率的なクエリからネットワークの遅延まで、さまざまな原因で発生します。 データベースの動作が遅い場合の診断における主な障害の1つは、ITエコシステム全体に対する可視性の欠如です。 この点において、フルスタックの可視化はDBAにとって唯一の真実の源として機能します。統合されたITビューは、複数のソースからのデータを統合し、従来のモニタリングを凌駕します。データベースの可視化は、他のシステムコンポーネントとのデータベースの相互作用に関する深い洞察を提供します。データベースの遠隔測定値を相関させることで、チームはパフォーマンス低下の根本原因を迅速に特定し、修正することができます。また、診断時間の短縮はパフォーマンスを向上させ、SLAの達成を支援し、顧客満足度を高めます。

遅い問題解決によるSLAの未達成

この複雑性は問題の積み残しにつながり、各問題の診断と解決に時間がかかり、最終的にSLAの未達成につながります。 問題解決の遅れがもたらす波及効果は、SLAの未達成につながり、顧客の信頼と業務の整合性を損なうことにもなりかねません。迅速に解決されない問題は、広範囲にわたる影響を及ぼします。顧客は一貫したパフォーマンスと信頼性を期待しており、サービスの遅れはブランドの信頼を損なうことにつながります。これは、SLAがサービス契約の要となる金融、ヘルスケア、eコマースなどの業界では特に重要です。この問題を解決するには、次のような戦略が有効です。

  • 日常的な監視とアラートを自動化することで時間を確保
  • AI 搭載のデータベース分析で異常を検出
  • 定期的なパフォーマンス評価とキャパシティプランニングで潜在的なボトルネックを特定

データベースパフォーマンスに焦点を当て、チームが着実に改善できるような戦略を使用することが重要です。これは、急いで修正を行うという意味ではなく、緊急性と徹底性のバランスを取る構造化されたアプローチを採用するという意味です。

過労のチーム

データベース管理の絶え間ない要求に対応しようと奮闘する過労気味のチームは、燃え尽き症候群になる可能性があります。 問題を迅速に解決し、データベースのパフォーマンスを維持しなければならないという絶え間ないプレッシャーは、長時間労働やストレスの増大、士気の低下につながります。 複数のデータベース環境では、DBAはそれぞれ独自の課題やパフォーマンス指標を持つ複数のシステムを管理しなければならないため、複雑さが増します。 データベースの監視は、この負担を軽減する最も効果的な方法の1つであり、チームは以下を実現できます。

  • アラートをキャッチして重大な問題や時間外の電話を回避する
  • データベース運用に関するリアルタイムの洞察を得る(高度な監視ツールを使用)
  • SLAの未達成を防止し、戦略的なタスクに集中する

データベース監視ソリューションは包括的な可視性を提供し、診断プロセスを合理化します。ログを精査して手動で問題を追跡する代わりに、DBAは自動化されたアラートと詳細なレポートに頼り、パフォーマンスのボトルネックの根本原因を特定することができます。この効率性はデータベースのパフォーマンスを向上させ、チームがより健全なワークライフバランスを維持するのに役立ちます。

タグ: , , , , , ,

データベース監視 – システム管理者からデータベースの達人

データベース管理に取り組む際の次の IT 技術者の重要な違いについて考察してみます。

  • 偶発的/強制的/不定期 DBA
  • ジュニアDBA
  • 知識豊富なフルDBA

まず、データベースに関する知識が最も少ないものの、状況、熱意、または隠蔽能力の欠如により、重要なビジネス IT リソースの管理を任された人物から始めましょう。前の文から、彼らが偶然または強制的に臨時の DBA と呼ばれる理由と、彼らが直面する特有の課題、そして適切なツールが知識のギャップを埋める方法についての洞察がわかります。

偶然の DBA とは?

偶然 DBA になった人は、選択ではなく必要に迫られてデータベースを管理することになった IT プロフェッショナルです。これは、組織に専任のデータベース管理者がいない場合、IT ゼネラリストまたは開発者に責任が委ねられる場合に発生します。多くの場合、データベース管理の正式なトレーニングを受けずに、データベースの運用、問題のトラブルシューティング、パフォーマンスの確保などの任務を負います。これらの人々は、文字通り深いところに放り込まれ、泳ぐことを学んだり、実際にはデータベース サーバーを浮かせ続けることを学んだりする必要があります。

偶然の DBA にとっての主な課題

  1. 知識のギャップ: 偶然 DBA になった人は、トランザクション ログ、バックアップ、SQL 言語、パフォーマンス チューニングなどのデータベース固有の概念に精通していないことがよくあります。これにより、問題のトラブルシューティング時に混乱が生じる可能性があります。
  2. 時間の制約: 管理すべき他の責任があるため、偶然 DBA になった場合、多くの場合、より積極的なアプローチを取るのではなく、緊急の問題に対処するという消火モードで作業します。これは、プラットフォームの安定性、セキュリティ、およびパフォーマンスの最適化の向上につながることは誰もが認めるところです。
  3. 複雑な環境: 多くの組織では、SQL Server、PostgreSQL、Oracle、MySQL など複数のデータベース プラットフォームを使用しているため、専門知識のない人にとっては複雑さが増しています。熟練した DBA であっても、複数のデータベース テクノロジの管理に苦労する可能性があることについて説明しました。

適切なツールの役割

  • データベース パフォーマンス アナライザー (DPA) : クエリ パフォーマンス、待機時間、データベースの動作に関するより深い洞察を提供します。AI を活用してデータベースを分析し、パフォーマンスのボトルネックを解決するための実用的な推奨事項を提供し、DBA の経験がなくても問題を解決しながら学習できるようにします。

偶発的な DBA に対する推奨事項

  • 役割の可視性を簡素化: ツールが深すぎると、ユーザーはより複雑になり、学習要件が増えるだけです。ソリューションをシンプルに保ち、複数のデータベース プラットフォームからのメトリックを統合してトラブルシューティングと管理を効率化する、一貫性のある統合ダッシュボード UI を提供します。
  • ガイド付きインサイトの活用: DPA などのツールは直接的な推奨事項を提供し、知識のギャップを埋めてデータベース メンターのような役割を果たし、個人の能力をより高いレベルに引き上げて、単に浮かんでいるだけでなく適切に「泳ぐ」ことを可能にします。
  • プロアクティブな監視に重点を置く: 異常検出や動的ベースラインなどの機能を使用して、問題が拡大する前に潜在的な問題を特定します。

偶然 DBA になった人は組織で重要な役割を果たし、データベースが効果的に機能することを保証する陰の功労者となることがよくあります。適切なツールを使用すれば、偶然 DBA になった人も課題を克服し、受動的な問題解決者から積極的な管理者へと転身できます。SAM や DPA などのツールは、データベース管理を簡素化するだけでなく、時間をかけて専門知識を構築するために必要な教育的価値も提供します。

ジュニアDBAの役割

組織がデータベースの管理に専任のエンジニアを置く理由は、データが組織にとって極めて重要であることを理解しているからです。アプリケーションによるデータの利用方法、社内および社外のユーザーやシステムによるアクセス、セキュリティとコンプライアンスの重要性など、この機能をサポートするリソースを持つことで、価値が生まれます。

ジュニアDBAは、基礎的な学習とデータベースの円滑な運用とのバランスを取るという課題に直面しています。組織がジュニアDBAを採用する理由はさまざまです。予算、より経験豊富なDBAをサポートするため、業務の規模が理由、より高度な能力を開発するためのプログラムなどです。したがって、適切なツールは、学習支援と能力開発の補助の両方の役割を果たし、管理業務においてより積極的かつ直接的な行動を取るための可視性を提供することができます。直感的なダッシュボード、ガイド付きトラブルシューティング、教育的な洞察を備えたツールは特に役立ちます。

ジュニアDBAの主な課題

  • 不完全な知識:日常的な業務はジュニアDBAの能力や理解度に合わせて行うことができますが、データベース技術は本質的に複雑であり、基本的な知識を習得するだけでも時間がかかります
  •  
  • 対応と事前対応のバランス:ジュニアDBAは、突発的な問題への対応に追われ、事前対応的な作業、つまり最適化、リソースの適切なサイジング、高度なサービス設計に割く時間が限られていることがよくあります

注目すべき主な機能

  1. ユーザーフレンドリーなインターフェース:ツールはデータをわかりやすく表示し、ジュニアDBAがメトリクスを素早く把握できるようにする必要があります。
  2. ガイド付きアラートと異常検知:異常検知と実行可能なアラートは非常に有益であり、ジュニアDBAが問題を発見し、修正措置を学ぶことを可能にします。
  3. 教育的な洞察Database Performance Analyzer (DPA) に搭載されているアドバイザーのような内蔵アドバイザーは、ジュニアDBAが業務でベストプラクティスを習得するのに役立つ推奨事項を提供します。
  4. リアルタイムの可視性:リアルタイムおよび履歴の洞察を提供するツールは、ジュニアDBAが変更の影響を理解し、データベースのパフォーマンスを向上させるのに役立ちます。通常のベースラインと異常な動作の違いを特定することで、最適化に貢献し、学習経路を強化します。
  5. 負荷ソースとの相関:データベースを使用しているアプリケーション、ユーザー、ソースを明確に把握することで、パフォーマンスやリソース消費に関するその他の要因を理解することができます。

推奨事項

  • 学習できるツールを選択:ガイド付きトラブルシューティングや教育用アラートなどの機能を探しましょう。
  • 異常検出を使用:安全策として機能し、信頼性を高めます。
  • 安全に実験:テスト環境を使用して、リスクなしに学習しましょう。

ジュニアDBAの旅は、学習と成長の旅であり、同時に組織に機能的な役割で真の価値をもたらす旅でもあります。適切な監視ツールは、不可欠なパートナーとなり、リアルタイムの洞察、問題への迅速かつ正確な対応能力を提供し、この役割に教育的価値をもたらします。SolarWinds DPAのようなツールは、ジュニアDBAが効率的な対処能力を発揮し、プロアクティブな管理へと進歩するのを支援します。

データベース管理の習得:フルタイムDBAの役割

その技術を習得し、組織の最も重要な資産であるデータを管理する人々!

現代の企業において、フルタイムDBAはデータベース管理の専門知識の頂点に立ち、ミッションクリティカルなデータベースシステムのパフォーマンス、セキュリティ、回復力を任されています。突発的な問題やジュニアDBAとは異なり、フルDBAは長年の経験と専門知識を備えています。最後のペルソナでは、彼ら特有の課題、ツールの差別化要因、そして組織の成功への影響について取り上げます。

フルDBAの役割

フルDBAは組織のデータの守護者であり、多様な環境において高い可用性、災害復旧、最適なパフォーマンスを確保する責任を担っています。彼らは、SQL Server から Oracle、PostgreSQL など、多種多様なデータベースの膨大な資産を管理することが多い。 また、パフォーマンスチューニングやクエリの最適化、Always On Availability Groups のような高可用性構成などの高度な機能も担当する。 近年では、クラウドに配置されたデータソリューションやクラウドネイティブなデータソリューションにも対応する必要があり、選択肢の増加、設計や技術の複雑化につながっている。

フルDBA管理の課題

  1. 規模と複雑さ:多様な構成を持つ数百ものデータベースを管理するには、統一された可視性と深い洞察力を提供するツールが必要です。データベースのサイズは、数百ギガバイト、テラバイト、さらにはペタバイトに達することもあります。
  2. クロススタックの依存関係:フルDBAは、データベースからOS、仮想化、ストレージレイヤーに至るまで、スタック全体にわたって根本原因を特定する必要があります。
  3. 精度と応答時間:システムの重要性を考慮すると、フルDBAは業務を中断することなく迅速に問題を解決するための実用的な洞察力が必要です。
  4. パフォーマンスの最適化:データベースサーバーからデータを消費するユーザーやシステムにとって、クエリ応答時間の短縮は組織に大きな利益をもたらします。アプリケーション画面のロード時間の短縮、プロセス自動化の迅速化による人的コストの削減は、すべて具体的なビジネス上の利益です。
  5. コスト管理:基盤となるコンピューティングリソースの消費を最適化することで、純粋な財務面で数千ドル/ポンド単位の節約につながります。

DBAを強化するツール

  • データベースパフォーマンスアナライザー(DPA):AWS RDS、Azure SQL Managed Instancesなどのクラウドネイティブを含む複数のデータベース技術をサポートするモニタリングプラットフォームを提供し、リソース消費量と異常およびAIベースの検知をマッピングすることで、クエリーパフォーマンスに関する洞察を提供します。

DBAへの推奨事項

  • 高度なツールを活用する:この人物像には高度なツールオプションのみが適切です。複雑なエンタープライズ環境に完全に適合する能力や、SQL Sentryのような高度なツールがもたらす深い洞察力により、このリソースを効果的に管理できるようになります。
  • 高度なアラートを導入する:DBAが実行する作業に即して、高度な戦略的作業に時間を割けるようにし、質の高いアラートを導入して、事後対応に追われる時間を最小限に抑えます。
  • チーム間のコラボレーション:アプリケーションの所有者やインフラチームなど、データベースインフラストラクチャを利用するチームとデータベースの健全性とパフォーマンスに関する可視性を共有することで、協調的な問題解決と効率化に向けた共同イニシアティブが可能になります。
  • ビジネス価値の向上:パフォーマンスチューニングに対するより深い洞察と集中、他者への可視性の向上、SLAの遵守により、データベース管理機能をビジネス目標に一致させることができます。

ツールが重要な理由

監視をスクリプトだけに頼るのは限界があります。特にデータベース環境が進化するにつれ、その傾向が強くなります。しかし、データベースリソースの管理と維持を担当する人物の能力に適したツールを揃えることは重要です。トレーニングを受けていない人が使用するには複雑すぎる場合、そのツールは無視され、その役割の機能の質は著しく低下します。データベースサーバーの複雑な部分に深く立ち入らないツールを提供すると、経験豊富なDBAは、高品質なツールが達成できるレベルの最適化やレスポンスを実現するために、より時間のかかる不完全な洞察方法に頼ることになります。

DPAのようなツールは、日常的なチェックを自動化することで生産性を向上させるだけでなく、他に類を見ないレベルのトラブルシューティングを提供し、あらゆるタイプのDBAが真の価値の付加に集中できるよう支援します。

DBAとしての経験が浅い方、中堅の方、ベテランの方など、どのような段階にあるかに関わらず、適切なツールを使用することで、課題をチャンスに変え、データベースの存続だけでなく、その発展を確実にすることができます。

タグ: , , , , , ,

Gluesyncのレプリケーションソース(CDC付)およびレプリケーションターゲットとしてのDynamoDBのサポート

GlueSyncのサポートをさらに強化:AmazonのDynamoDBをMOLO17のクラウドネイティブなデータレプリケーターであるGlueSyncのCDCソースおよびターゲットとして利用可能に

MOLO17はクラウドネイティブなリアルタイムRDBMSおよびNoSQLデータレプリケーターであるGluesyncのデータベースラインナップに新たにDynamoDBをCDCソースおよびターゲットとして追加しています。この互換性を明らかにし、Gluesyncのバージョン1.4から開始しです。

データオフロード、キャッシュ、分析、またはモバイルユースケースのためのオンプレミスまたはクラウドインフラストラクチャ向けのプラグアンドプレイソリューションであるGluesyncは、DynamoDBを使用して、主要なRDBMSまたはNoSQLデータベースとの間でデータをリアルタイムにレプリケートすることができます。

DynamoDBとは

DynamoDBは、Amazon Web Services(AWS)が提供する完全マネージド型のNoSQLデータベースサービスで、スピードと柔軟性を重視して設計されています。シームレスなスケーラビリティを提供し、アプリケーションのニーズに応じて、ダウンタイムやパフォーマンスの低下なしにデータベースを自動的に拡張または縮小することができます。DynamoDBはキーバリュー型とドキュメント型のデータモデルをサポートしており、単純なストレージリポジトリから複雑な高トラフィックのウェブアプリケーションまで、さまざまなアプリケーションに対応できます。 1桁ミリ秒単位の応答時間を実現するように設計されており、高速なデータアクセスを保証し、リアルタイムアプリケーションやゲームアプリケーション、IoTシステム、その他多くの用途に最適です。DynamoDBは、組み込みのセキュリティ機能、バックアップおよび復元機能、DynamoDB Accelerator (DAX) によるインメモリキャッシングも提供しており、読み取り中心のアプリケーションのパフォーマンスを向上させます。AWSがハードウェアのプロビジョニング、セットアップおよび構成、レプリケーション、ソフトウェアのパッチ適用、スケーリングなどの運用タスクを処理するため、開発者はデータベース管理ではなくアプリケーション開発に集中することができます。

Gluesync CDCでDynamoDBとの間でデータを複製

Gluesync for DynamoDBは、DynamoDBと20以上の他のデータソースおよびターゲットとの間で、リアルタイムかつ双方向のデータレプリケーションを可能にします。 DynamoDB Streamsを活用して効率的な変更データキャプチャ(CDC)を実現し、リアルタイム同期を可能にします。Gluesyncは、Kubernetesサポート付きのDockerコンテナとして展開でき、高いスループットと柔軟なデータモデリングを最適化します。多くのデータベースをサポートし、オンザフライのデータモデリング、トランザクションログベースのCDC、エンタープライズグレードの監視、アラート、およびログ機能などの機能を提供します。この統合により、DynamoDBの機能が強化され、さまざまなユースケースに対応できるようになります。

DynamoDB replication from any major RDBMS or NoSQL

DynamoDBの主要なRDBMSまたはNoSQLとの双方向レプリケーション

オンザフライのデータモデリング機能、毎分数百万件のドキュメントのスループット、数分で完了するセットアップにより、GluesyncはNoSQLへの移行に理想的なパートナーとなります。今回新たに追加されたターゲットは、MOLO17のビジョンである、最新の高速かつ低価格なデータベース技術をエンタープライズ顧客に接続するというビジョンを裏付けるものです。

AmazonのDynamoDBにワークロードを複製する必要がある場合でも、あるいは、Aerospike、Couchbase、MongoDBなどの他のNoSQLテクノロジーにDynamoDBから移行したい場合でも、Gluesyncは理想的なソリューションです。DynamoDBをホットストレージとして維持し、AWS S3またはGoogle Cloud Storageのターゲットにデータを同期してコスト効率の高いデータレイクを実現したい場合にも、コールドオブジェクトストレージが可能です。

MOLO17は:

MOLO17はNoSQLソリューションのパートナー企業であり、このような技術を使用した複数のプロジェクトを開発しています。当社の使命は、NoSQLデータベースの導入を安全かつスムーズなアプローチで容易にし、リアルタイムのイベント駆動型、サードパーティのツールに依存しない、高可用性、高スループットのアプローチなど、包括的な機能セットをすぐに使える状態で提供することです。

MOLO17は、ダウンタイムや業務継続への影響なしに、企業のデータの潜在能力を安全に引き出します。MOLO17の製品とソリューションは、クラウド、オンプレミス、またはすべてのモバイルデバイスを問わず、ミッションクリティカルなアプリケーションに対して、常に利用可能で一貫性のあるデータと高品質な結果を保証する最高のNoSQLデータベース技術を提供します。

お問い合わせは

 

タグ: , , , , ,