3年前、Yandex.Diskが起動されたとき、彼らはコンピューター間でファイルを同期するだけでなく、一般的にすべての人間のデバイス間でデータを同期したかったので、私たちは本当に幸せです。 私たちのデジタルライフは、ファイルだけでなく、地図上のポイント、ルート、ブラウザーのブックマーク、コンピューターゲームのレコードのリストなどでもあります。
2年以上、Yandex.BrowserはYa.Diskの同期技術に取り組んできました。 近い将来、他の主要なYandexサービスがDataSyncでプラットフォームを統合し始めます。 カットの下-それがどのように編成されているか、なぜそれが必要なのか、そしてすべてがどのように機能するかを見て試してみることができる例についての詳細。
むかしむかし、Webサーバーはインターネットの基本的なインフラストラクチャ要素になりました。これなしでは、世界的なネットワークの存在を想像することは不可能になりました。 現在、時代は変わりました。自己同期型クラウドデータベースは、現代のマルチプラットフォームインターネットの等しく重要な要素になると確信しています。
以前は、ユーザーにはデバイスが1つしかなく、インターネットサービスとやり取りする方法は1つしかありませんでした。サイトにアクセスしてください。 開発者にとっては、すべてがシンプルでした。 基本コードWebインターフェイス。 サイトの腸内のどこかに、開発者が必要なデータを保存するデータベースがあり、そこからデータを取得して、単一のユーザーデバイス、またはコンピューターのブラウザーに表示します。
しかし、時代は大きく変わり、今では人が多くのデバイスを持つことができ、1つのサービスをアプリケーションのセット全体で表すことができます。 これは開発者の生活を大きく複雑にしました。 インターフェース、ベース、ロジック、さらにはプログラミング言語まで、彼はさらに増えました。 しかし、最悪なのはデータです。 一部のデバイスには、サーバーおよび他のデバイスに存在するデータのローカルコピーがあり、それらはすべて互いに同期する必要があります。 これはまったく簡単な作業ではありません。競合、データ損失、通信の損失が発生する可能性があり、すべてのデバイスで通常の作業速度が必要です。
開発者がアプリケーションとクラウドストレージを同期するタスクを最初から解決するたびに、最初から実際に何をしようとしていたのかを忘れてしまうか、まもなくこれに到達することは明らかです。
もちろん、記述された問題を解決するための問題は、Yandexに現れました。 開発を日常的な同期タスクから解放し、アプリケーションの作成に集中できる「クラウドデータベース」の作成に取り組み始めました。
通常のデータベースは1台のコンピューターで退屈な生活を送っていますが、クラウドとすべてのユーザーデバイスで同時に存在するデータベースを作成しました。 もちろん、これはターンキーソリューションとして、マルチプラットフォームアプリケーションの開発作業を根本的に簡素化します。 そのようなデータベースのどこにデータが保存されていても-電話、ブラウザ、サーバー-何も失われず、関連するデータが至る所に表示されます。
プロジェクトの内部ドキュメントには、「DataSync APIは、ユーザーまたはユーザーとアプリケーションのペアに関連付けられた任意の構造化データのリポジトリです。 貧弱なモバイルネットワークでのユーザーデバイスと通常の操作との間の同期のために設計されています。
外部開発者にとって、私たちのデータベースは人気のあるnoSQL MongoDBデータベースに非常に似ています -本質は同じです。 コレクション、オブジェクトのコレクションで構成されます。 オブジェクトは、キーと値のフィールドのコレクションです。 しかし、開発者がさまざまなデバイスやクラウドでデータを接続する方法について考えず、単にAPIを使用して、すべてのデータ同期が魔法のように行われるようにするというタスクを設定しました。 もちろん、「同期」SDKのクラウド部分とクライアント部分の両方を使用すると、このような「マジック」が可能になります。
そして、ここで、どの問題が発生し、どのようにそれを解決したかを詳細に説明したいと思います。
対立
提案されている世界のデバイスでは、データベースの多くのインスタンスがあり、それらはすべてローカルで変更されます。 このような状況では、データが異なる場所で同時に変更されると、競合が避けられません。 また、データをまったく失いたくありません。 この問題を解決するアルゴリズムは非常に伝統的です。
- すべてのデータインスタンスには、すべてのデバイスとサーバーが認識しているバージョンがあります。
- 変更を送信するとき、サーバー上で送信およびチェックされます。
- バージョンが一致しない場合、クライアントは知らない変更のリストを受け取り、競合を正しく解決できます。
ネットワークなしの透過的な作業
モバイルアプリケーション（および他の多くのアプリケーション）は安定した接続に依存できず、サービスデータはいつでも変更される可能性があります。 これは、当社のクラウドベースを使用している人にとっては問題にならないはずです。 これは、SDKで考慮することも非常に重要です。 次の手順でこの問題を解決しました。
- サーバーとのすべての通信はSDKに引き継がれます。
- サーバーとの通信は完全に非同期であり、バックグラウンドで行われます。
- SDKが開発者に提示するメソッドは、ネットワークからの読み取り/書き込みが完了するのを待つことはありません。
DataSync APIドキュメントでは、独自のSDKを使用するすべてのメソッドについて説明しています。 独自のライブラリを、プラットフォームの競合や切断から保護する必要はありません。
最初に、各「アプリケーション」が他のプラットフォームおよびサーバー上で同じものと同期されることを確認しました。 しかし、同じデバイス上の異なるアプリケーション間でデータを同期することが重要な場合の例がありました-大まかに言って、共通のデータベースを持つためです。 そして、それを実現しました。 これで、たとえば、ライトアプリケーションと完全なアプリケーションがある場合、あるアプリケーションから別のアプリケーションにアップグレードすることを決めたユーザーのデータを簡単に転送できます。 または、パートナーアプリケーションからデータを送受信します。
APIの仕組み
APIを使用するプロセスでは、クライアントは主に次のような概念で動作します。
- データベース（DB）
- 更新デルタ、
- スナップショット
- 紛争。
データベースは、APIの同期ユニットです。 これには、コレクションに結合されたオブジェクト（レコード）が含まれます。 ただし、すべての操作は本質的に別個のオブジェクトで実行されます。 オブジェクトを一意に識別するには、オブジェクトの識別子とコレクションを指定する必要があります。
データベースステータス識別子はリビジョン番号です。 APIは、競合状況を追跡および記録できるリビジョン管理スキームを実装しています。 データベースを作成すると、リビジョンはゼロになります;このデータベースの変更をさらに受信すると、リビジョン番号が1つ増えます。 変更は、デルタ更新を送信することにより行われます。 その助けを借りて、エントリを作成、削除、編集できます。
競合とは、クライアントが既存のリビジョンよりも新しいリビジョンをサーバーに送信する状況です。 この場合、サーバーはリビジョン番号を確認し、既存のバージョンに一連の変更を送信します。
クライアントのリビジョンが古すぎてサーバーが必要な変更のリストを提供できない場合、クライアントはデータベースのスナップショットを受け取り、それ自体で現在のリビジョンにアップグレードする必要があります。 競合解決スキームは、開発者の裁量に任されています。
ベーススナップショットには、サーバー上の現在のデータベースリビジョンのステータスが反映されます。 デバイスでローカルデータベースを作成するとき、または競合状態を解決するときに要求する必要があります。
独自のアプリケーションのフレームワーク内でのみデータを共有するには、データを共有するために、アプリケーションデータを保存するためのアクセス権（一般ユーザーデータへのアクセス）を要求する必要があります。
おわりに
HTTP APIとJS SDKの使用を今すぐ開始できます 。 近い将来、AndroidおよびiOS用のSDKをリリースします。
テストブラウザーアプリケーションでアドレス帳の例を使用して、すべてがどのように機能するかを確認できます 。 20秒単位でユーザーの電話番号を同期する方法を示しています。 データは、クラウドおよびWebアプリケーションのインスタンスと同期されます。 これを確認する最も簡単な方法は、ブラウザーで2つのタブを開くことです。