2017-08-17 27 views
0

私は、クライアントがオフラインでデータストレージへのブラウザアクセスを必要とするWebアプリケーションを構築しています。 FirebaseやPouchDBのいずれかのデータベースを使用してアプリケーション内でこれを実現しようと考えています。SQL ServerとFirebase/PouchDBの同期

ただし、バックエンドではSQL Serverを使用しています。 Firebase/PouchDBからのデータをms SQLサーバエンジンに同期させて永続的に保存できますか? MS SQL ServerのJSONサポートにより、これを行うことができますか、私はこのルートを辿る時間を無駄にしていますか? アプリケーションはNode.JSを使用して書かれています

助けと助言は素晴らしいでしょう。

+0

https://pouchdb.com/faq.html#sync_non_couchdb – Phonolog

答えて

1

PouchDBはオフラインサポートに最適です!しかし、PouchDBが本当の強みを発揮できるように、サーバ側の同等機能を提供する必要があります:複製。 CouchDB(安定しており、実績のある「オリジナル」のテスト済み)、IBM Cloudant(サービスとして互換性のあるDB)、PouchDB Serverを使用してください(JavaScriptでCouchDBを実装しています。

かもしれない次に、CouchDBからSQL Serverにデータを取得しようとしますが、2つのデータベースのアーキテクチャ上の違いが多すぎるため、あなたのソースは常にCouchDBにする必要があります。ドキュメントをCouchDBに書き込むことはAPI呼び出しのようなものなので、CouchDBに試してみることをお勧めします!

+1

有益な回答ありがとう! – Donal5

+0

私のお店では、SQL ServerのデータをCouchDBに同期させるNode.jsプロセスを設定した後、CouchDBはクライアントPouchDBにレプリケートされます。重要な点は、これが「一方向の同期」であり、データベースへの書き込みはまずノードapiレイヤーを介してSQL Serverに移動することです。そうすることで、一方向のデータフローを維持し、同期の競合は発生しません。 –

+0

@JeffBarnesは素晴らしいですね!しかし、オフラインでサポートされているこの特定のシナリオでは、クライアントからAPIへの書き込みを実行できないと考えています。クライアントがオフラインのときにデータを変更することを許可されていない場合、ソリューションは完璧な意味を持ちます。 –

0

PouchDb Serverにはsupport for LevelUpがあります。これにより、バックエンドサーバーを別のものに置き換えることができます。一部のSQLデータベース(MySQLやPostgresなど)がサポートされていますが、SQL Serverはその1つではありません。

代替SQLソリューションを検討する準備ができていれば、ローカルのPouchDbデータベースを持ち、PouchDb Server経由でSQLデータベースにレプリケートすることができます。私はこれを試していない!

+0

誰かがこれに関する経験がありますか、リンクする例はありますか? – Alex

0

を使用するMSSQL < - > CouchDB < - > PouchDBメソッドを使用するといくつかの重大な利点と欠点があります。私はちょうどこのアプローチに私たちのアプリの一部を移行することを完了し、私が見つけたものを概説します。

80個のテーブル(古いメソッド)に約400,000レコード、3個のテーブル(新しいメソッド)に約6000個のレコードを同期させています。

古い方法:MSSQL < - > RESTのAPI < - > SQLiteの(モバイル)PHPで書かれた

  • カスタムAPI '最後に保存した誰' で扱わ
  • 時折同期の競合。
  • 約20K-40K行/秒の速度でモバイルに保存できます。
  • 携帯側で私のカスタム作成した同期部分に起因するさまざまな不具合。 > CouchDBの< - - > PouchDB < - データの小さなサブセットでテスト> LokiJS

    • (6000 MSSQL <:

    新しい方法(書き込み安定した同期ソフトウェアは、隠された課題の多くを持っています)行)、アプリの一部のみ。

  • PouchDBはIndexedDBアダプタを使用しています。(次にSQLiteネイティブアダプタをテストします)
  • MSSQL - > CouchDBは20秒ごとに発生します(クエリ)。
  • CouchDB - > MSSQLは、CouchDBの変更(フィードの変更)が行われるたびに発生します。
  • CouchDB < - > PouchDBは非常に安定しています!そして遅い(約300行/秒)!
  • PouchDB自体は、ネイティブSQLiteと比較して、インデックスであってもクエリが非常に遅いです。私たちは、5000レコード程度のクエリの場合は10秒、SQLiteの場合は数ミリ秒です。
  • 私はLokiJSをクエリ部分だけに使用します。速度はSQLiteとほぼ一致します。これは、PouchDBの変更フィードを使ってLokiJSを最新の状態に保つことを意味します。ロックされた電話やバックグラウンドプロセスからの復元時に失敗することがあります。
  • PouchDBが同期を再開すると(アプリを開いたり、バックグラウンドから再オープンしたとします)、追いつくにはしばらく時間がかかります。これは、良い日に約300またはそれ以上の行を同期させるようです。この同期は、アプリ起動後5〜15秒後に開始されることがあります。つまり、ユーザーが最新のデータを見ていない可能性があります。同期が実行されると、オフラインの時間によって、PouchDBがキャッチアップしている間に1分間ほどユーザーが「立ち往生」する可能性があります。
  • PouchDBがキャッチアップされると、変更のフィードは魔法のように機能し、モバイルデバイスで行われた変更はすぐにCouchDBにプッシュされ、他のすべてのデバイス(およびサーバー)にプッシュされます。私は変更に基づいて更新するようにUIを書いたので、誰もが最新の情報を得ることができます。この部分はかなりうまくいく。私のセットアップ

    • CouchDBの& PouchDBの同期の安定性のCouchDB & PouchDBの

    利点。

  • レコードをJSONとして保存すると、JavaScriptで作業するのが簡単になります。いくつかの記録よりも、それ以上の同期のCouchDBの&の

デメリットPouchDB

  • 速度が遅いです。
  • PouchDBクエリの速度が遅い(ネイティブSQLiteと比較して)。
  • PouchDBの変更の変更は、PouchDBからLokiJSへの再同期を必要としているようです。これは、復元または再オープンされているアプリに関連しているようです。

これまでの私の経験です。あなたのアプリに記録が少なく、瞬時に更新が必要な場合を除き、私はそれをお勧めしません。

関連する問題