Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
本論文は、リアルタイムのデータベース同期におけるRESTポーリング、WebSocketプッシュ、およびCockroachDB CDCのアーキテクチャを比較した制御されたベンチマークを提示しており、WebSocketプッシュが最も低い中央値レイテンシを提供し、RESTポーリングが予測可能な限定的遅延を提供する一方で、CDCは競争力のある中央値を実現しているものの、バッチ処理や特定のプロトコル間の不適合性により大幅なテールレイテンシに苦しむことを明らかにしている。
原論文は CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
現代のソフトウェアの世界では、インターネットに接続されていないときでも、あたかもデバイス上で直接動作しているかのように感じられるアプリケーションへの欲求が高まっています。この「ローカルファースト」と呼ばれるアプローチでは、オフラインの状態でもドキュメントを編集したりリストを更新したりすることができ、変更内容は接続が回復した際に中央サーバーへと送信されるのを待ちます。課題は、接続が復旧した瞬間にあります。コンピュータはどのバージョンのデータが正しいのかをどのように判断し、ユーザーを待たせることなく、いかに迅速に中央サーバーを更新できるのでしょうか。これがスムーズに機能するためには、システムが新しい情報を検知し、即座に届けるための信頼できる仕組みが必要です。更新が遅すぎるとユーザーはラグを感じ、システムが複雑すぎるとバッテリーを消耗させたりクラッシュを引き起こしたりします。エンジニアにとっての核心的な問いは、このリスニング（監視）メカニズムをどのように構築すべきかという点です。デバイスが一定の間隔でサーバーに更新がないか尋ね続けるべきか、サーバーが変更を即座に叫ぶ（プッシュする）べきか、あるいはデータベース自体が後で読み取れるようにすべての操作の実行ログを保持し続けるべきでしょうか。
インド工科大学カラグプル校の研究者は、これら3つの一般的な戦略を並べてテストし、制御された環境下でどれが実際に最も優れたパフォーマンスを発揮するかを検証することに乗り出しました。研究では、クライアントが一定の時間間隔で更新を確認する方法、サーバーが永続的な接続を通じて変更を即座にプッシュする方法、そしてデータベースが購読者に変更のログをストリーミングする方法の3つを比較しました。公平なテストを行うため、研究者はユーザーには同一に見えるものの、内部の歯車が異なる3つの独立したシステムを構築しました。1つのシステムは標準的なデータベースを使用し、単純な「チェックイン」ループを備えています。もう1つのシステムは同じデータベースを使用していますが、変更が発生した瞬間に信号を発火させるトリガーを追加しています。3つ目のシステムは、自身の履歴をストリーミングするように設計された異なる分散型データベースを使用しています。目的は、ユーザーが行った変更がシステムを通り抜け、リスナーの画面に表示されるまでにかかる正確な時間を測定することであり、単一のユーザーから同時に書き込みを行う50人のユーザーまで、あらゆる条件下でテストを行いました。
結果は、各手法がプレッシャーの下でどのように振る舞うかを明確に描き出しました。永続的な接続を通じてサーバーが変更を即座に叫ぶ（プッシュする）手法に依存したシステムが、最も高速であると判明しました。最良のケースでは、変更がリスナーの画面に現れるまでわずか2ミリ秒であり、50人が同時に書き込みを行っている場合でも、遅延が63ミリ秒を超えることは滅多にありませんでした。この手法は驚くほど安定した速度を維持し、最も遅い更新であっても4分の1秒未満で到着しました。クライアントが100ミリ秒ごとに更新を確認するという手法は、予測可能ではあるものの、より低速でした。クライアントは確認を行うための順番を待たなければならないため、平均的な遅延は約60ミリ秒でしたが、チェックの間隔よりも速くなることはありませんでした。多くのユーザーが同時に書き込みを行うと、この待ち時間は増大し、平均的な遅延は100ミリ秒を超えました。データベースの内部ログを使用するシステムは、混合したパフォーマンスを示しました。典型的な更新は通常1秒未満で到着しましたが、このシステムは最も遅い数件の更新において深刻な遅延に見舞われました。時折、変更が届くまでに2秒以上かかることがあり、場合によっては遅延が3秒半以上にまで達することもありました。
研究者は、ログベースのシステムにおける最も遅い更新は、変更をログに記録するというアイデア自体の欠陥ではなく、特定のソフトウェアの接続方法の結果であることを発見しました。このシステムは、標準的な接続ツールがデータベースの言語を正しく解釈できなかったため、データベースログを読み取るための回避策を用いていました。この回避策は、接続が中断されるたびに新しいプロセスを開始する必要があり、それが遅延に対して1〜4秒という重いペナルティを与えていました。この特定の技術的な障害がなければ、ログベースの手法はもっと優れたパフォーマンスを発揮していた可能性がありますが、今回のテストにおいては、その長い遅延によりインタラクティブな使用には不向きであるという結果になりました。また、研究はチェック手法に関する単純なルールも確認しました。チェックの間隔を長くすればするほど、平均的な遅延は長くなります。システムが50ミリ秒ごとにチェックする場合、平均的な待ち時間は約36ミリ秒ですが、500ミリ秒間隔で待機する場合、平均的な待ち時間は300ミリ秒以上に跳ね上がります。
これらの知見は、同期を必要とするソフトウェアを構築するための実用的なガイドを提供します。リアルタイムで共同編集を行うツールのようにスピードが極めて重要なアプリケーションでは、サーバーが変更を即座にプッシュする手法が明確な選択肢となります。これは、多くの人々がシステムを同時に使用している場合でも、最も低い遅延と最も一貫したパフォーマンスを提供します。クライックが定期的に更新を確認する手法は、数百ミリミリ秒の遅延が許容されるよりシンプルなアプリケーションや、バッテリー節約のために接続を維持し続けることが困難なモバイルデバイスなどの場合に、堅実な選択肢となります。データベースのログをストリーミングする手法は、大量のデータを移動したりバックアップを作成したりするには強力ですが、今回テストされた具体的な実装は、インタラクティブな使用には遅すぎ、かつ予測不能でした。研究は、3つの手法すべてが機能するものの、最善の選択は、優先事項が即時の応答性にあるのか、それとも運用の簡便性にあるのかによって完全に決まるという結論を下しています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。