Postgres synchronization solution P&L: -8 (≃ -71 USD)
This is a challenging computer problem, data synchronization but I have an idea
I plan to use a inefficient rolling hash and sorting to solve the problem of synchronization. This is similar to rsync
以前のデータと現在の列、および以前のハッシュを取得してデータベース全体のハッシュを生成するハッシュを実装しました。
これにより、すべてのデータを再ハッシュし、ソートされたデータのバイナリ検索のハッシュを取得するシンクロナイザー部分を作成するときに、最小限のデータ送信で同期することができます。
I implemented a hash that takes previous data and current column and the previous hash to produce a hash of the entire database.
This allows us to synchronize with the minimum of data transmissions when I write the synchronizer part which shall rehash all its own data, then retrieve the hash of a binary search of the sorted data.
19,239 2:03
「勝つ」コピーの問題を解決する方法についてのアイデアがあります。
すべての列フィールドと行をハッシュし、それにバージョンを与える別のテーブルを用意します。
比較対象のバージョンです。
I have an idea on how to solve the "winning" copy problem.
Have a separate table that hashes every column field and row and gives it a version.
This is the version that is compared.
私の vagrant セットアップでは永続ディスクを使用し、ansible を使用して cronjob と同期スクリプトをデプロイします。 YAMLファイルで構成されています。 psycopg2 もインストールしました。Postgres でデータベース内のテーブルを取得する方法に関するドキュメントを見つけました。あとは同期アルゴリズムを書くだけです。
私の問題は、どちらの側が勝者のコピーであるかを検出することです。
一方がデータを変更すると、異なるハッシュが存在し、変更された行が検出されます。この部分はわかります。
問題は、どちらの側が最新の変更であり、どちらの側が勝つべきかを検出することです。バージョン列を導入する必要があるかもしれません。
最後に更新されたタイムスタンプ フィールドがあれば、それを使用できます。またはバージョン列ですが、スキーマに新しい列を導入することを明示的に避けようとしています。それははるかに難しいことを意味します。
My vagrant setup uses persistent disks and uses ansible to deploy the cronjob and sync script. It is configured by YAML file. I've also installed psycopg2 and I found documentation on how to retrieve the tables in a database in Postgres. It's just a matter of writing the sync algorithm now.
My problem is detecting which side is the winning copy.
When one side changes the data there shall be a different hash and the changed rows are detected. This part I understand.
The problem is detecting which side is the latest change and which side should win. I might need to introduce a version column.
If I had a last updated timestamp field I could use that. Or a version column but I am expressly trying to avoid introducing new columns to the schema. It means it's a lot harder.
