0

さまざまなユーザー間で大量のデータ交換を必要とするアプリケーションを構築しています。SQLite を使用して情報を保存し、Rest API を使用してサーバーとデータを交換しています。

高いパフォーマンスを確保し、CPU やメモリの浪費を抑えながら、優れたユーザー エクスペリエンスを維持するには、次の提案が必要です。

1 30 秒の頻度で同期を実行しようとしましたが、リソースを浪費します。sqlite を MySQL と同期するために使用できるクライアント側のフレームワークはありますか、または同じためにすべての可能なイベントのみを計画する必要があります

2 Gmail や Twitter などのアプリケーションはどのように機能しますか?オンデマンドでのみ同期するのか、バックグラウンドで同期し続けるのか. オンデマンドだと思いますが、よくわかりません。

3 通知はサーバー側またはクライアント側である必要があります (sqlite の更新に基づく)。whatsapp では、クライアント側のみであることがわかりました。受信したメッセージをクリックしないと、同じことに関する通知を受け取り続けます

4 通知をサーバー側に保持し、オンデマンドで同期する場合。次に、新しい通知をクリックすると、その時点でアプリが開き、同期呼び出しを行う必要があります

このようなアプリケーションは、リソースを占有せず、顧客にオンラインのようなエクスペリエンスを提供するような方法で同期と通知を管理するように設計する必要があるという専門家の意見が必要です

4

1 に答える 1

0

あなたの質問はかなり広いですが、少なくとも最初の方向性を示します。

iOS と Android で 100 MB を超えるローカル データベースを問題なく実行しました。SQLite を正しく使用すれば、SQLite が問題になることはありません。100,000 行のデータでも、高速で効率的です。問題が発生するのは、データを適切にインデックス付けしていないか、データを過度に正規化していないことです。簡単な検索を行うと、インデックスを使用してクエリを最適化する方法がわかるので、これ以上は説明しません。オーバーノーマライゼーションは完全には理解されていないようですので、もう少し詳しく説明します。

サーバー データベースを設計するときは、重複データの量を最小限に抑えることが重要です。多くの場合、これは単一のレコードを複数のテーブルに分割し、外部キーを使用することによって行われます。1 GB のデータベースでは、このタイプのデータ正規化によって 20% の節約が可能であり、これはかなり重要です。このストレージの向上には、パフォーマンスが犠牲になります。完全なデータを取得するには、シーケンシャル ルックアップと結合が必要になることがよくあります。サーバー上には十分な CPU サイクルとメモリがあり、リクエストに 1 ミリ秒または 2 ミリ秒余分にかかっても誰も気が付きません。

モバイル アプリは完全なデータベース サーバーではありません。ユーザーは、アプリが応答するのを待って画面をじっと見つめています。さらに、使用可能な CPU とメモリが最小限であるため、遅延がさらに長くなります。さらに厄介なことに、モバイル データベースはサーバー データベースのサイズのごく一部にすぎず、重複データはすでに最小限に抑えられています。200 MB (1 GB の 20%) のサーバー サイズを節約できた同じデータ正規化は、10 MB の 5%、つまり 500 KB しか節約できない可能性があります。その小さな利益は、努力やパフォーマンスの低下に見合うものではありません。

同期する場合、毎回完全なデータ セットは必要ありません。最後の同期以降に変更されたデータのみを取得する必要があります。多くの場合、それはまったく変化しません。デバイスが現在何を持っているかを特定し、変更のみを取得する方法を見つける必要があります。

UI がネットワーク リクエストの待機中に失速しないようにすることが重要です。すべてのネットワーク アクティビティはバックグラウンド スレッドで実行し、同期が完了したら更新するように UI に通知する必要があります。

最後に、SQLite はスレッドセーフではありません。データベース アクセスの同時実行を制限することが重要です。

于 2013-11-10T13:21:43.107 に答える