2017-02-21 19 views
2

私のアプリはまずオフラインであり、レルムはデータの永続化とアクセスに優れています。大好きです。しかし、私はまた、クラウドにユーザーデータを保存したい(バックアップのために、しかし私が後でウェブサポートを追加する場合に備えて)。 Realm Object Serverがそうであることは分かりますが、私はDynamoDBを次のような理由で使用したいと考えています。Amazon DynamoDBでレルムを使用する

1)私は既にDynamoDBとAmazonの認証(Cognito)に投資しました。

2)クライアントから複雑なクエリを実行する必要があるため、Realmは事実上リレーショナルデータベースです。しかし、バックエンドでは、ほとんどすべてのデータを簡単にアクセスし、必要に応じてラムダ関数を使って操作できる方法でデータをバックアップしたいだけです)。私はこのためにNoSQLソリューションを使用しても問題ありませんが、DynamoDBは費用効果の高いデータベースで、水平スケーリングが可能で、魅力的です。 Realm Object Serverでこのような方法でデータにアクセスしたいと思ったら、少なくとも1500ドルのコストがかかります。

3)Realmチームには嫌な思いはしませんが、Parseがシャットダウンしてしまったので、私が信頼できるものをバックエンドとして5年以上使用したいと考えています。とにかく

は、道のうちそれと、ここで私は現在、この作品を作ってるんだ方法は次のとおりです。

1)私が作成またはレルムのオブジェクトを編集するたびに、私は私のDynamoDBのスキーマにその変更をマッピングしますロジックを持っています(これはRealmよりはるかに少ないテーブルで構成されています)。

2)私はこれらの更新をと呼びます。必要に応じてそれらをキューに入れてマージします(たとえば、同じプロパティを複数回変更した場合など)。

3)私は待ち行列を通り、UpdateTasksのチャンクを私が書き込んだラムダ関数に渡します。この関数は、更新を繰り返し、DynamoDBに必要なputまたはupdateコマンドを実行します。

4)私はあなたがオフラインまたは要求が

5を失敗した場合には所定の位置に再試行ロジックを持っている)すべてはあなたが新しい携帯電話を持って、サインインした場合、私は別のラムダ関数を持って適切に同期されると仮定すると、以前と同じようにユーザーのすべてのデータを取得し、レルムファイルに移入します。

私が言ったように、これはすべて現在作業中ですが、壊れやすいと感じています。私はこれを間違った方法でやっているように感じることはできません。さらに、ソーシャルフィーチャを追加したい場合は、双方向同期やリアルタイム通信をサポートしていません。

これは、RealmとDynamoDBを同期させるための合理的なアプローチであるか、頑丈な方法?また、Realm Object ServerまたはDynamoDBの代わりに何かを再考する必要がある場合、私はなぜそれを聞くことに興味があるでしょう。

私にとっては大きな決断ですので、私が得ることができるすべての助けに感謝します!ありがとうございました

+0

私はDynamoDB(または他のDB)があなたに求めている柔軟性を提供すると思います。そう、はい、カスタムビルドAPIを使用して、デバイス間のデータを管理します。リアルタイムの同期やコミュニケーション、特にチャットやその他のものに関しては、sync APIのアプローチは理想的ではありませんでした。リアルタイムsocket.ioに焦点を当てる方が良い考えです。 – Orlando

+0

「Realmチームには嫌なことはしませんが、Parseに嫌われました」---しかし、ROSはホスト・イット・ユアーの解決策であることに注意してください。ドードーの道を行く人でもそれをあなたから奪うことができます:)。 – teotwaki

答えて

1

免責事項:私はROSのリードですので、私は明らかに偏っています。私はこれを答えとしてではなく、コメント形式に合わない一般的なコメントとして投稿しています。

クライアントからは複雑なクエリを実行する必要があるため、Realmは事実上リレーショナルデータベースです。

あなたはレルムをリレーショナルデータベースと呼んで神を怒らせます。私たちは、クエリやリンク、そしてそれをサポートしていますが、リレーショナルデータベースとはまったく異なります。

また、DynamoDBの代わりにRealm Object Serverなどを使用することを再検討する必要がある場合、私はその理由を聞くことに興味があります。

Realm Mobile Platformが提供するいくつかの非常に重要な機能は、自分自身で再実装することで欠けています。

主に、複数のクライアントが同じレルムにデータを書き込んでいる間に、すべてのオフラインで、コンフリクトのないマージの解決を処理するコードが数千行あります。さらに:

  • 私たちはあなたのためにネットワークを扱います。接続の設定、クライアントとサーバー間のプロトコルの設定、およびシリアル化が正しく行われているかどうかを心配する必要はありません。
  • 私たちのプロトコルはRealmデータベースからトランザクションログだけを転送できるため、非常に軽量です。シリアル化されたオブジェクトやそのようなものではありません。
  • 同期は非常に高速です。私たちがRMPを立ち上げたとき、あなたはおそらくドローデモビデオを見たことがあります。私たちの同期はRealmに直接統合されているため、余分なパフォーマンスを圧迫することができます。私たちは数多くのチャットアプリを作りましたが、内部ではないものがあり、メッセージが転送されるスピードで人々は絶えず驚いています。
  • サーバーとクライアントで同じSDKとAPIを使用します(別の言語でも可能です)。
  • 手動で作成する必要のない機能(頻繁に要求される部分レプリケーションやオブジェクトレベルの権限など)を継続的に追加しています。一方

あなたは非常に密接に組み込まれているシステムでは、我々は、サーバーのバックエンドに注文/要求を送信するために採用する技術に似ています。通常、クライアント上でFooRequestというオブジェクトを作成し、それらのオブジェクトを同期させ、イベントハンドラがそれらを取得して処理し、クライアントに同期されるFooResponseオブジェクトを作成します。

全体的に、私はあなたがこれをvanilla-Realmの上に構築したことに非常に感心しています。私たちがいつか機会を得たら、あなたの全体のスタックを見てみたいと思います。

最後に、価格ポイントに関するご意見は一意ではありません(しかし、非常に参考になります)。

関連する問題