サプリメンタルロギング設定の影響に関して[Syniti DR]

Syniti DRではOracle DBをソースとして変更追跡する際に、トランザクションログ方式、ログサーバエージェント方式、トリガー方式から選択可能ですが、このうち、トランザクションログ方式とログサーバーエージェント方式ではOracleのRedoログを利用します。

このため、REDOログ上に変更追跡のために十分な情報が記録されるようにサプリメンタルロギングを有効化する必要が有ります。

この際に、サプリメンタルロギングのレベルを最小レベルとデータベースレベルから選択できますが、以下の注意点が有ります。

テーブル単位での設定であること

サプリメンタルロギングが最小レベルとなっている場合、この設定はテーブル単位に行われます。このため、最小レベルの場合、Syniti DRはレプリケーション作成時に指定したソーステーブルに対して自動的にサプリメンタルロギングを有効にします。

しかし手動でOracle側でのテーブル再作成した場合など、Syniti DR側が検知できないような変更でサプリメンタルロギングが対象テーブルに対して無効化された場合、Syniti DR側で都度レプリケーションジョブの再ビルド作業を実施する必要があります。
※サプリメンタルロギングがデータベースレベルとなっている場合には、テーブル再作成後も特に再ビルド作業は必要ありません。

変更追跡情報の粒度

サプリメンタルロギングをSynitiから有効化した場合、Oracle REDOログへ書き込まれる情報はデータベースレベル、最小レベルともにPKと更新された値のみとなります。

この時、考慮するべき項目の1つに、補完インサート機能があります。
これは、Data Replicatorオプションから指定できる設定で、ターゲットテーブル上にUpdate対象のレコードが存在しない場合に、Updateの代わりにInsertを実行する機能です。

ただし、PKと更新されたカラムのみの情報しかREDOログに記録されていないため、上記の補完インサート機能でのInsert時にはPKと変更されたフィールドの値のみを使用し、変更されていないフィールドはNULLとなります。

このため、ターゲットテーブル上でレコードが不足している場合に、補完インサートが実施されると、不十分な情報でInsertされる場合や、ターゲットテーブルのカラムでNULLを禁止している場合にはNot NULL制約違反が発生することがあります。

また、補完インサート以外にも、通常のミラーリングレプリケーションにて、ソーステーブル/ターゲットテーブルのカラムで主キー構成が異なる場合、Missing value for the primary key fieldエラーが出力されることがあります。

そのため、テーブル構成によっては以下のクエリをOracle側で実行し、REDOログへすべてのカラムのレコード情報を書き込むように構成することで、不十分な情報でInsertされる操作や主キー構成の違いによって発生するMissing value for the primary key fieldエラーを回避できます。

・データベースレベルの場合
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS

・最小レベルの場合
ALTER TABLE テーブル名 ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS

まとめ

こうのような動作であるため、Syniti DRとしては運用での手間を減らすという意味でデータベースレベルでの運用を推奨しております。

ただ、Oracle REDOログに書き込まれる情報を抑えるため、サプリメンタルロギング設定を最小レベルで指定し運用されているお客様も、もちろんいらっしゃいます。

このような場合には、上記の2点にお気を付けください。

コメントする -->

かゆいところに手が届く、レプリケーション結果比較機能[Syniti DR]

Syniti DRは異種データベース間でのレプリケーションを提供するソリューションであり、データ連携や移行、保護など様々な用途でご利用いただいています。

このSyniti DRでレプリケーションしデータを同期している際に、例えば

  • 移行用途であれば、正常に全データが転送され、同期が取れていることを確認したい
  • 連携や保護で使用している場合には変更追跡方式によっては検出できないようなトランザクション(REDOログへの記録をパフォーマンスのためにオフにしているなど)に関しても反映したい
  • 検証環境に連携している場合に、ターゲットテーブルに対してのみ実施された変更を定期的に修正したい

などの要望をいただくことがあります。このような際に便利な機能が、結果比較です。結果比較機能では以下のようなことが可能です。

GUI上での結果比較

GUI上ではSyniti DRのコンソールから任意のレプリケーションを右クリックし、「レプリケーション結果を確認する」から結果比較を実施し、差異があるか確認できます。

左上の各ボタンから以下の操作が可能です。

比較の実行
ソーステーブルとターゲットテーブルを比較します。比較結果は表とテキストで表示されます。
停止
比較処理を停止します。テーブルのサイズが大きく予期せぬ時間が比較にかかっている場合などに使用します。
データの整合
比較の実行後、検出された差異を解消するよう、ソーステーブルを基にターゲットテーブルを変更します。
結果の保存
表と下部に表示されているテキストの情報をテキストファイルに保存します。
オプション
比較時の条件等を指定できるオプション設定を開きます。

オプション

オプションに関しても詳しく紹介していきます。まず、設定項目として、タブ以外の部分を解説します。

カウントのみ記録テーブル内のデータは比較せず、単純にレコード件数のみを比較します。この場合、各タブの設定はグレイアウトし利用できません。
WHERE条件ソーステーブルとターゲットテーブルを比較のためにSelectする際のWHERE句を設定できます。レコード数が多いテーブルなどで、一部のみ比較したい場合に有効です。
ORDER BY句デフォルトではORDERBY句は、主キーです。
ただし、データベースにより、文字列の並び替え順序が異なる場合があり、これが原因で正常に比較できないケースが有ります。
このフィールドで、単一の列名またはコンマ区切りの列名のリストを入力することにより、デフォルトのORDERBY句から変更できます。

このオプション画面で設定した項目は、GUI上でのみの設定である一般タブの内容を除き、「メタデータに設定を適用」で比較を定期的に実施する検証スケジュールでの設定にも反映できます。

レプリケーションの続いて各タブの設定を紹介していきます。

一般

具体的な比較処理には影響しませんが、GUI上での表示を設定するためのタブです。

自動的に検証を実行 「レプリケーション結果を確認する」 で検証タブを開いた際に自動的に比較を実行するための設定です。
グリッドないのソースとターゲットテーブルを表示表を表示せず、結果のテキストのみ表示する設定です。大量のレコードを持つテーブルを検証する場合には有効します。
比較の最大数表示するレコード数の上限設定です。表示のためにもメモリ、CPUリソースを消費しますのでそれに合わせて設定します。デフォルトは10,000です。
差異のみを表示異なるデータを持つカラムを含むレコードと片方にしか存在しないレコードのみを表示します。
差異を強調表示する際の色を変更できます。

比較

比較対象とするカラムを指定できます。

主キーのみ確認主キーなっているカラムのみ比較します。この場合、データの整合は利用できなくなります。
ピボット列で確認比較するレコードのフィルタリングに使用する列(日付、時刻またはタイムスタンプのみ)を指定します。指定した列で、比較時にwhere句が作成され、ターゲットテーブルよりも新しいレコードのみが比較されます。
列のサブセットで比較チェックした列のみで比較を行います。主キーではデフォルトで含まれており除外できません。

データタイプ

データ型に基づき比較対象を制限できます。

BLOB/CLOBをスキップ/無視BLOB/CLOB列のデータはサイズが大きく比較に時間がかかる可能性がるため、これらの列を比較しないように設定できます。
バイト型配列をスキップ/無視同様にバイト配列フィールドを比較しないように設定できます。
空白文字データベースやデータ型によって文字列を埋めるために空白スペースを用いるものと用いないものが有ります。このオプションを有効にすると固定長文字列から空白文字をトリミングした後に比較します。
日時をスキップ/無視Date time型を比較しないように設定できます。データベースによって格納されている形式に違いがあるケースが存在するためです。
時刻をスキップ/無視Time型を比較しないように設定できます。データベースによって格納されている形式に違いがあるケースが存在するためです。
小数点以下の桁数少数点以下で比較する桁数を設定できます。

データ整合操作

ソーステーブルのデータに基に、ターゲットテーブルのデータを修正する際の操作の種類を指定できます。

Insertsソーステーブルにのみ存在するレーコードをターゲットテーブルに挿入します。
Deletesターゲットテーブルにのみ存在するレコードを削除します。
Updates異なるデータを持つフィールドを、ソーステーブル上の値に更新します。

スケジュールで定期的に結果比較を実施

続いては、上記の比較検証や整合操作をスケジュールで実行する方法です。定期的なバッチ実行などで、ソースDB上のトランザクションログに記録されないようなケースでそれを定期的に反映する用途やソーステーブルに一致した状態であることを定期的に保証するために利用できます。

スケジュール自体の構成は他のスケジュール設定と同様に繰り返しの設定を複数構成することも可能です。ここで「データを整合させる」にチェックを入れると差異があった際にはソーステーブルを基にターゲットテーブルを変更します。

また、GUIでの比較時と同様の設定が優先>検証から設定可能です。

また、設定したのみでは実行されないため、Verifier SchedulerをタスクトレイService Monitorアイコンから起動しておきます。

また、アラート設定で差異が検出された場合にメール送付するよう設定することも可能です。

このように、念のためソースとターゲットが一致しているのか確認したいといった要望や変更追跡できないようなデータもターゲットに反映したいといった要件などにも対応できる機能になっておりますので、メインの機能であるレプリケーションに加えて、この比較検証機能も是非ご活用ください。

コメントする -->

保護中: Syniti Data Replication (DBMoto) 9.8.1.8 リリースノート

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

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

Syniti DR 9.8新機能!パーティション(分割)リフレッシュ機能で全件転送の速度を改善

Syniti DR 9.8で追加されたリフレッシュ処理のパーティション機能を使用すると、リフレッシュ(全件転送)時の分割処理を構成でき、複数の並列スレッドがデータを処理するため、パフォーマンスを向上できます。

今回はこのリフレッシュ処理のパーティション機能を紹介していきます。

パーティションの作成

パーティション機能を利用するために、事前にレプリケーションで設定を行う必要があります。

1.メタデータエクスプローラでレプリケーションを選択します。
2.右クリックし、「プロパティ」からレプリケーションプロパティを開きます。
3.「優先」>「リフレッシュ」に移動し「パーティションを使用」にチェックを入れます。

4.「パーティションを追加」をクリックし、where句を指定し、分割条件を設定します。

これで設定は完了です、リフレッシュレプリケーションを実施するとパーティション機能を利用してリフレッシュが実施されます。ただ、デフォルトの表示では各パーティションでの処理進捗を確認できません。表示を変更するにはレプリケーションモニターで「パーティションの表示/非表示」のアイコンをクリックします。

簡易テスト

簡易的なテストとして10000000行、サイズとしては350MB程度のテーブルを従来のシーケンシャルなバルクインサートと、2、4、10分割でパーティション機能を使いバルクインサートした場合の結果を比較してみました。

分割数時間
シーケンシャル1分54秒
2分割1分32秒
4分割1分11秒
10分割1分31秒

上記のように4分割した場合が最も高速となる結果となりました。おそらく、あまりに分割数が多くなってしまうと、データベース側のリソースが飽和してしまい、効果が低くなるためと想定されます。

今回の環境はテスト用の環境であるため、このような結果となりましたが、よりパフォーマンスの高い環境であれば、分割数を増やすことでより効果が期待できます。

このため、最適な分割数といったものは環境や対象となるテーブルごとに異なり、チューニングが必要にはなりますが、大規模なテーブルであればあるほど効果が期待できる機能ですので、リフレッシュ速度でお悩みの場合には是非ご検討ください。

コメントする -->

データ活用時代到来! Syniti Data Replicationで異種RDMSからSnowflakeへのリアルタイム・レプリケーション

昨今、データ活用が注目され、企業が保有しているデータを分析用のプラットフォームへ移動する需要が増えています。
このようなデータプラットフォームに対して、Syniti Data Replication(以下Syniti)を利用することで、あらゆるRDBMSからDWHなどのデータプラットフォームへ開発を行うことなく手軽にデータ連携が可能です。
※Synitiがサポートしているデータベースについては、こちらをご覧ください。

本ブログでは、最近注目を集めているパフォーマンスチューニングを意識することなく、大量のデータを高速に処理することができるSnowflakeへのデータ連携を紹介します。

まずは、Snowflake側での準備です。
といっても、準備するものとしてはSynitiからSnowflakeへアクセスするログインユーザを定義するのみとなります。
この時ロールを指定できますが、これはどのロールを選択しても、Synitiのレプリケーション処理に影響はありません。

次に、SynitiをインストールしたWindowsマシン側での準備です。
SynitiからSnowflakeへの接続には、Snowflakeが提供しているODBCドライバーを使用します。
こちらのリンクより、Windows OS用のODBCドライバーをダウンロードし、インストールが完了すると、WindowsのODBCデータソースアドミニストレーターからSnowflakeの文言が見つかります。

ここまで完了したら、あとはSynitiコンソールより接続定義とレプリケーション設定を行うだけとなり、ターゲット接続追加ウィザードを起動し、Snowflakeを選択します。
※この画面からの、Synitiが多くのデータプラットフォームをサポートしていることがわかります。

次に、Connection Stringの項目を選択し、右下の編集ボタンをクリックします。

すると、ODBC接続を定義するポップアップ画面が出力されます。

ここでは、以下のような文字列で接続を定義します。

Driver={SnowflakeDSIIDriver};UID=ユーザ名;PWD=パスワード;DATABASE=データベース名;SERVER=サーバ名

例えば、ユーザ名がsdruser、パスワードがSql123456、データベース名がDEMO_DB、サーバ名がaa1234.ap-northeast-1.aws.snowflakecomputing.comの場合、以下のように定義します。

Driver={SnowflakeDSIIDriver};UID=sdruser;PWD=Sql123456;DATABASE=DEMO_DB;SERVER=aa1234.ap-northeast-1.aws.snowflakecomputing.com

これらの文字列を入力したら、画面をOKで閉じ、テストボタンを押してSynitiマシンからSnowflakeへの疎通が取れるか確認することも可能です。

次に、レプリケーション先のテーブル選択を行います。
今回はすでにテーブルが存在しておりますが、テーブルが存在しない場合にはSynitiの機能で
連携元となるソーステーブル構造を参考にテーブルを作成する機能も用意しています。

あとは画面を次へで進めて、完了をクリックすることでSynitiへのSnowflake接続登録が完了します。
このようにGUIベースで、簡単にSnowflakeへの接続設定が完了します。

ここまで設定が完了すれば、あとはレプリケーションジョブを作成し、ソーステーブルのデータをSnowflakeのテーブルに同期するのみです。
もちろん、Snowflakeへの初期同期(全件転送)が終わった後は、ソースデータベースのトランザクションログを参照して差分レコードのみを転送することも可能です。

これら一連の操作感については、こちらの動画にもまとめておりますので、ぜひご覧ください。

Snowflakeへのテーブル作成、全件および差分レプリケーション実行

 

タグ: , , ,

保護中: Syniti Data Replication (DBMoto) 9.8.0.19 リリースノート

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

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

データを制する企業がビジネスを制する — 企業のデータ戦略に変革をもたらす注目テクノロジー

近年のITイノベーションはすべて「データ」を中心に進行しています。いかにデータを集めるか、いかに良いデータを振り分けるか、どう保管するか、どう処理するか、どのように分析してビジネスに生かすのか、など。オンラインの普及でデータの量と種類が爆発的に急増し、それをどうするか⁉がITの最重要課題になって久しいですが、近年、それに対応する新しい技術が次々と生まれてきました。

2020年代は、企業がその新しい技術の実用化をいかに進め、より効果的に「データドリブン」となるかが試される10年間になるのではないでしょうか。2020年代が始まって一年半が経過した現在は、企業のデータ戦略が大きな変革を遂げる過渡期に差し掛かっていると言えます。ここでは、データドリブンを目指す企業の近年の取り組みや、データ戦略の変革に向けてゲームチェンジャーとなりうる注目テクノロジーをいくつか見ていきたいと思います。

デジタルスレッド(Digital Thread)

デジタルスレッドとは、製品やそれを取り巻くデータエンティティ(多種多様なデータの発生元となる主体、つまり開発者やユーザーなど)の、企画、設計から納品、サポート、廃版に至るまでのライフサイクル全体にわたるデータのつながりを指します。それをリアルタイムでトラッキングおよびモニタリングできるデータの統合リポジトリを、デジタルスレッドと呼ぶこともあります。

最先端技術を取り入れたプリンタの開発で知られるLexmark社では、「デジタルスレッドの統合的なデータ管理アプローチがIoTやクラウドベースのas-a-service戦略を補完し、バリューチェーン全体にわたってクローズド ループ アナリティクスを拡大する機会となる」と捉えています。具体的には、デジタルスレッドによって「リアルタイムのユーザー傾向にもとづき、何を、いつ、どこで開発すべきかが判断でき、サプライチェーンの強化につながる(製品技術責任者Andy Kopp氏)」ことが期待されています。

データカタログ(Data Catalog)

データカタログは、企業全体のデータ資産をメタデータとして中央管理するインベントリです。SASのデータ管理ソリューション責任者Kim Kaluba氏はデータカタログの役割をこう説明しています。

「複雑なデータエコシステムから正しいデータを簡単に見つけ出し、ビジネスの課題に迅速かつ正確に答えられるようにします。今後、データカタログはさらに成熟し、企業はデジタル資産をすべて一か所でカタログ化し、識別できるようになるでしょう」

データカタログの強化が、企業のデジタル資産のガバナンスを徹底させ、ビジネスの成否を視覚化するのに役立つ、と同氏は強調しています。データカタログのコンセプトは新しいものではありませんが、あらゆる企業に共通する課題であり、その強化があらゆるデータ戦略の基本になることは十分に期待できます。

データ インテリジェンス ソフトウェア(Data Intelligence Software)

データカタログをさらに進化させたのがデータ インテリジェンス ソフトウェアで、企業の戦略的意思決定やプランニングに重要なデータインサイトをもたらす一連の技術を指します。つまり、データ インテリジェンス ソフトウェアは、企業のデータ資産からビジネス価値を見い出すための統合プラットフォームとなります。AIや機械学習は、すでに大小さまざまな企業がビジネスに積極的に取り入れていますが、それらを一括管理する統合プラットフォームの重要性は今後ますます高まっていくに違いありません。

スケールアウト データベース(Scale-Out Databases)

データベースを実装する環境は、これまでになく多様で変化の激しいものとなっています。今日のデータベースは、継続的な容量の拡大や、内外のさまざまなソースから取り込まれるデータの種類の多様化に対応できなくてはなりません。そのため、スケールアウト データベースを採用する企業が増えています。

同時に、データベースは用途の専門化(ニーズの特化)が進んでいます。「どのようなデータを扱うのかを見極め、正しいデータベースを選択するのが重要だ」と、Splice Machine社CEOのMonte Zweben氏は指摘しています。「データベースの要件は、リアルタイムではないアナリティクスから、機械学習やリアルタイムのトランザクション クエリをともなうアナリティクスなど、多岐にわたり、スケーリング方法、レイテンシ、スループット、可用性、一貫性など、さまざまな基準を考慮する必要がある」と、Zweben氏は強調しています。

インサイト エンジン(Insight Engine)

企業内の検索システムをAIや機械学習と組み合わせ、インサイト エンジンを導入する企業が増えています。今日の検索エンジンは、キーワードを調べるだけでなく、文脈や背景を理解し、先を見越した全方位的な知見を提供してくれ、社員の生産性を向上させるツールとして期待されています。あらゆる企業にとって、DXのゲームチェンジャーとなりうる技術です。

ローコード、自動データ ディスカバリー(Low-Code and Automated Data Discovery)

データ ディスカバリーの自動化とローコード テクノロジーが、企業のデータ競争力を高める技術として注目されています。「企業が短時間でより多くのことをデータから引き出すための技術」と、Dell傘下のデータ管理ソフトウェア会社Boomiの副社長Ayush Parashar氏が評価しています。同氏によれば、企業には平均850のアプリケーションがあり、そのうち連携されているのは30%程度だそうです。コロナ禍では、各社員が使用するアプリケーション数がさらに増えており、それらを統合してデータを見つけやすくすることが企業の競争力を高めます。統合的なデータ管理でビジネスのインサイトを引き出し、プロセスの合理化を進めるのは、IT部門に限らず、企業全体のあらゆる部門に求められる課題です。だからこそ、開発者ではなくビジネスユーザーが直接管理できるローコードでインテリジェントなデータ ディスカバリーの重要性が、今後ますます高まると予想されます。

DataOps

DataOpsとは、簡単に言えば、データアナリティクスのアジャイル アプローチです。企業内のデータ プロセスを統合・自動化してデータアナリティクスの質を高め、プロセスの効率化を図ります。DataOpsは、「リーン生産方式のデータアナリティクス版であり、無駄を省いてエラーをなくすためのリーン データアナリティクス」だと称するのは、DataOpsソフトウェア会社DataKitchenのCEO、Chris Bergh氏です。程度の差こそあれ、ほとんどの企業がデータアナリティクスをビジネスに活用している今日、他社に先んずることができるのは「DataOpsドリブンのワークフローを自動化」する企業だと、Bergh氏は説いています。「アナリティクスのアジリティは、ビジネスのアジリティに通ずる」のだそうです。

グラフデータベース(Graph Databases

グラフデータベースは、データを取り巻く関係を瞬時に把握するためのデータベースで、リレーショナル データベースと違い、表ではなくグラフ構造でデータを管理します。見た目はグラフというより、ネットワーク構造に近く、データがネットワークのように構成する相互関係をたどるのが、表を結合させるのに比べて格段に効率的なのが特長です。グラフデータベース自体は新しいものではありませんが、近年、リアルタイム環境における検索スピードの重要性が増したのと、データの多様化が進んだのとで、改めて注目され出しています。特に、コロナ禍の停滞を機にサプライチェーンの管理システムにグラフデータベースを導入する企業が増えつつあるようです。

もちろん、従来型のリレーショナル データベースが現在も主流であることに変わりはありませんが、単一ソリューションですべてに対応する時代はとうに終わり、新しいデータ システムやテクノロジーが次々に生まれています。「データを制する企業がビジネスを制する時代」に入り、2020年代が進むにつれてビジネスの勢力図を塗り替えるようなゲームチェンジャーとなるデータ テクノロジーのさらなる躍進が見られるはずです。ポスト コロナのビジネス変革は要注目です。

 

 

コメントする -->

保護中: PostgreSQLでのミラーリングにおけるパーティションテーブルの使用

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

タグ:

保護中: Syniti Data Replication (DBMoto) 9.7.4.5 リリースノート

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

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

Heroku Postgres と 異種DB間でのリアルタイム・レプリケーションを検証・確認[Syniti DR]

Heroku は簡単にアプリケーションの開発から実行、運用までのすべてをクラウドで完結できる PaaSです。このHeroku が使用しているデータベースである Heroku Postgres とオンプレミスの異種データベースとのデータの連携を簡単に行いたいという声をよく聞きます。

今回は実際にSyniti DR(Data Replication)による、Heroku Postgres を使用したレプリケーションを試してみました。

Syniti DRとは:
異種データベース間のレプリケーションを行えるソフトウェアSyniti DR。エージェントレスなアーキテクチャを採用しているので、データベースのプラットフォームに依存せず、例えばHeroku Postgresのデータベースであってもレプリケーションを実施することができます。
また、Syniti DR は、オンプレミス上にある、Oracle, SQL Server,DB2 (AS/400)といった異種データベースであってもレプリケーションを行うことが可能です。

 

こちらより、Heroku Postgres データベースを紐づける仮のアプリケーションを作成し、Heroku Postgres データベースの作成をします。

まずは、仮のアプリケーションを作成してみました。
Create new app をクリックし、新規のアプリケーションを作成します。
任意のアプリ名(herokupostgres-app)を入力し、Create app をクリックして仮のアプリケーションが完成です。

次にHeroku Postgres データベース作成してみました。
右上のタブより、Data をクリックします。
その後、Heroku Postgres を作成するため、Create one をクリックします。
次に、Install heroku Postgres をクリックします。
次に、Heroku Postgres と紐づけを行うアプリケーションを選択します。
今回は先ほど作成した、仮のアプリケーション(herokupostgres-app)を指定し、Submit Order Form をクリックすることで、Heroku Postgres データベースの作成が完了しました。


Heroku Postgres データベースの作成が完了したので、認証情報を確認します。
先ほど紐づけを行った、Heroku Postgres をクリックして、
Setting タブより、View Credentials… をクリックします。
データベースに接続が必要な認証情報(Host,Database,User,Port,Password) を確認します。

これにて、Heroku Postgres の認証情報の確認ができました。

後は、先ほど確認した認証情報を元にSyniti DRの画面で接続設定を行い、レプリケーションの設定を行うだけです。

このように、Syniti DRを使用することで、オンプレミスのあらゆるデータベースをHeroku Postgres に移行することや、Heroku Postgres のデータをオンプレミスのデータベースに移行することが可能です。
他にも、ほぼリアルタイムなレプリケーションにより、オンプレミスDBのデータを利用して、Heroku上でアプリケーション開発が可能です。
また、双方向の差分のレプリケーションも実施でき、ハイブリッドクラウドの運用が可能となっております。
Syniti DRの詳細に関しては、こちらよりお問い合わせください。

タグ: , , , ,

Heroku Connectを使用してユーザはHeroku Postgresと Salesforce のデータを同期

HerokuSalesforceの子会社で、アプリケーションの開発から実行、運用までのすべてをクラウドで完結できる PaaS(サービスとしてのプラットフォーム)です。

https://jp.heroku.com/

Heroku Connectを使用してユーザはHeroku と Salesforce のデータを同期が可能です。

https://jp.heroku.com/connect

Heroku Connect では、Salesforce 環境とデータを共有する Heroku アプリを簡単に開発できます。Salesforce と Heroku Postgres を双方向に同期することによって、Postgres データベースのデータと、Salesforce データベースの連絡先や取引先、カスタムオブジェクトなどのデータを統合できます。

Heroku Postgres (PostgreSQL) は、Heroku が直接提供するマネージド SQL データベースサービスです。 PostgreSQL ドライバーを使用して、​Heroku がサポートする​すべての言語を含むどの言語の Heroku Postgres データベースにもアクセスできます。

https://jp.heroku.com/postgres

これによってSalesforce データベースの連絡先や取引先、カスタムオブジェクトなどのデータを各種アプリケーションと連携することが可能です。

タグ: , , ,

保護中: Syniti Data Replication (DBMoto) 9.7.3.3 リリースノート

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

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

初期同期(リフレッシュ)がより便利に! ステージングリフレッシュ機能

Syniti Data Replication (以下Syniti DR)では初回のレプリケーション時や任意のタイミングで全件転送を行うリフレッシュ機能が提供されています。
この全件転送の流れとしては、まずターゲットテーブルをキレイにするため、ターゲットテーブルのデータをすべて削除(TruncateまたはDelete)し、その後ソーステーブルのデータをSelect、ターゲットテーブルにInsertするものとなります。

ざっくりと、以下のような流れになります。
===============================
① ターゲットテーブルのデータを削除(TruncateやDelete)
② ソーステーブルのデータを取得(Select)
③ Syniti DRサーバ内部でInsertクエリの生成
④ ターゲットテーブルにデータを挿入(Insert)
===============================

上記④では、ターゲットデータベース側でバルクインサート機能が提供されている場合、
ブロックサイズタブで指定された数値に基づいて、複数レコードを1つのSQLクエリにまとめることで、大量レコードを転送する場合でも、ある程度高速な処理が可能です。

ただ、バルクインサート使用時でもSyniti DRサーバとデータベースサーバ間のネットワークトラフィックの負荷状況や、データベースサーバ自身のI/Oパフォーマンスなど環境に依存する部分が大きく、環境によってはレコードの処理に時間かかかることがあります。
つまり、上記①~③の間には、ターゲットテーブル側でコミットされるまでレコードが存在しない、またブロックサイズに基づいてコミットが発行されるため、別アプリケーションなどからターゲットテーブルをSelectした時に一部データしか確認できない状況は想定されます。

この影響を少しでも軽減するため、Syniti DR 9.7.2.28より、ステージングリフレッシュ機能が追加されました。
レプリケーションジョブのリフレッシュオプションにて、リフレッシュステージングタブをTrueとすることで機能が使用できます。

この機能を使用する場合、リフレッシュ時には通常のリフレッシュとは異なり以下のような流れになります。
通常のリフレッシュには無い部分は赤文字にしています。
====================================
① ステージングテーブルが存在しない場合には、
Create Tableクエリからステージング
テーブルを作成
② ソーステーブルのデータを取得(Select)
③ Syniti DRサーバ内部でInsertクエリの生成
④ ステージングテーブルに対してデータを挿入(Insert)
⑤ ステージングテーブルへのデータ挿入完了後、コミット
⑥ ターゲットテーブルのデータを削除(TruncateやDelete)
⑦ ⑤のステージングテーブルをデータソースとして、
ターゲットテーブルにデータを挿入(Insert into Select)
====================================

このように、処理自体は増えていますが、通常同一データベース内部で実行される操作(Insert into Select)処理は高速に実行されるため、特にネットワークトラフィックが要因となり、ターゲットテーブルにレコードがすべて存在しない時間が長引いている場合には、このステージングリフレッシュ機能を使用することで影響を軽減することができます。

タグ: , , , ,

ビッグデータのAIとDX

AIという言葉は数年前からあちこちで見かけるようになりましたが、最近はDXの勢いが増しています。IT関連のニュースだけでなく、SNSの投稿でも、「DX」という文字が入った見出しが目白押しです。

以前から気になっていたのですが、とにかく「AI」か「DX」を差し込んでバズろうとする傾向はあると思います。

でも、DXには罪はないです。デジタル トランスフォーメーションに厳密な定義を設けているDXコンソーシアムみたいなのが存在するのかもしれませんが、「デジタル」も「トランスフォーメーション」も昔からある言葉だし、言葉だけの意味でいったら、DXの範囲は相当に広いです。経理担当者がそろばん弾くのをやめて電卓を使いだしたら、その会社がDX宣言しても、まったくの噓というわけではありません。

昔、学校で教室を掃除するときに使うほうきを「文明の利器」と呼ぶ先生がいましたが、あれが掃除機に変わってもDXかどうかは微妙ですが、ルンバに変わったら間違いなくDXでしょう。

先日、某外食チェーンの新サービスを取り扱った記事に『コロナ禍で加速する朝外食DX』というタイトルを見かけました。レストランにもDXの波が押し寄せているのか、と感心しながら目を通したら、どうもDXの要素が見当たらない… ただ、メニューは朝食のわりにやたら豪華でDX(デラックス)でした。

これも決して間違ってはいません。『コロナ禍で加速するDX』なんて言われたら、あっちのDXかなと勝手に先入観を持った自分が悪いだけで、マツコ デラックスさんのDXのほうが、本来よく使われていた元祖DXです。

DXよりも、むしろ気になるのはAIです。AIが将棋でプロ棋士に勝ったとか、AIが接客してくれるとか、そういう人間の知能に代わる作業を「人工知能」がやるという話題なら、なるほど、すごい世の中になったなぁ、とひとしきり感心したりもするのですが、時々どの部分が人工知能の作業なのかわかりにくいものもあります。

先日、NHKドキュメンタリーでAIにコロナ関連の膨大な論文を徹底解読させるという番組を観ました。番組自体は非常にためになる素晴らしいものです。ただ、素人目にはAIの用途がいまいち理解できませんでした。世界中の最新論文を人間が読むのは大変だし、時間がかかるからAIにやってもらう、という部分は完璧なAIフル活用です。まさに究極のDXで、AIの真骨頂と言えるでしょう。

仮に、AIがロボットだったら、人間とこんな会話をするでしょう。

AI:「論文、全部読んだよ」

人間:「もう、読んだの!? さすが、AI」

AI:「・・・」

人間:「で、どうだった?」

AI:「読みごたえがあったよ」

人間:「どのへんが?」

AI:「ファイザー、アストラゼネカ、キラーT細胞、免疫回避…」

人間:「おー、そんなキーワードがでてきたのか!それで?」

AI:「・・・」

人間:「たとえば、その… ワクチンは変異種にも効くの?」

AI:「・・・」

というような会話が展開されたような感じです。もちろん、実際には会話はなく、人間からの質問はAIにではなく、専門家に向けられて、専門家が丁寧に回答していました。だから、情報番組としては十分に役立つ、良質のプログラムでした。

でも… そのAIって、検索エンジンでは?論文読んだAIが、質問にも答えてくれたら、まさにAI様様だったのに、論文読んだのは、疑問に答えるためではなく、キーワード洗い出しのためだったようです。まぁ、キーワード洗い出しでもAI様様です。そのあとで、専門家がどの論文を優先的に読むべきかとか、とか、どの順番で読むべきかがわかるのですから。

ただ、『AIが徹底解読!』と銘打つのなら、AIが論文の内容にもっと踏み込んでくれるような展開を期待してしまいました。

このAIは、論文を厳密には「解読」していないけど、仕分けはしてくれているようでした。番組では、個々の論文の相関関係がネットワークデータベースのようにイメージ化されていました。膨大すぎる論文がビッグデータを構成する場合に、それをAIが仕分けしてネットワークデータベース化してくれるなら、大変便利に違いありません。AIがデータレイクをデータウェアハウスに自動変換してくれる感じでしょうか。それはそれでかなりのDXです。デジタル トランスフォーメーションという意味でも、デラックスという意味でも。

 

コメントする -->

保護中: Syniti Data Replication (DBMoto) 9.7.2.28 リリースノート

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

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