私はWebアプリケーションを作成しており、お気に入りの履歴のようなユーザーデータをアプリケーションに保存する必要があります。この目的でIndexedDBを使用することを検討していました。これは、MySQLを使用しているサーバー側より実装する方が少し簡単です。しかし、ユーザーのお気に入りリストに保存するコンテンツのうち最も人気のあるものが何であるかなど、このユーザーデータに対して分析を実行する必要があります。 IndexedDBを使用すると、クライアント側でJavascriptを使用して、各IndexedDBストアからユーザーデータを転送して解析できるようにすることができました。私の質問は、25,000人を超えるユーザーのためにスケーラビリティがありますか？あるいは、私はちょうどこの種のアプローチの問題を尋ねています。この場合、MySQLのすべてのユーザーデータをサーバー側に保存して分析を容易にする必要があります。IndexedDBストアに対するマルチユーザー分析
これは私があなたの質問を理解するのとは異なる2つの概念です。
indexDBはローカルにユーザブラウザに保存され、ローカルユーザの動作に依存します。クリーンなキャッシュ、クッキーのリフレッシュ、有効なブラウザオプションです。
あなたのサイト/アプリがテーブル/グラフデータ/友だちリストなどのデータをユーザブラウザに読み込んで、サーバに戻ってくるいくつかのクエリに対してサーバコールなしですばやくナビゲーションできるようにするにはindexDBを使用する必要があります。
これを覚えておけば、別のユーザーセッションを保存し、小さなキー/値のデータベースを構築し、サーバーMySQLデータベースに保存してこれをあなたの側に保存して、このデータをナビゲートするか、 JS APIを使用して、ユーザーに適切なコンテンツを読み込みます。
サーバ側のMySQL DBでも同じことができますが、ユーザの場所とサーバの位置、DNS、ネットワークの待ち時間、サーバのCPU、ディスク、テーブルの構造、テーブルのサイズなどによって遅延が発生する可能性があります。 。
あなたは、サーバー側のユーザーと、ユーザーがAPPですばやく簡単に使用するために必要なデータの詳細を確認するために必要なものを決定する必要があります。これらの2つのデータフローは束縛されておらず、非同期JSコマンドを使用してコードブロッキングなしで実行できます。
スケールに関して、IndexDBは1〜2MBのデータに適しています。お気に入りのサイトのキーが1つある場合は、クレンジングプロセスやアプリケーションの主な機能を考慮する必要があります。 sitename_favorite-5 このデータはユーザーごとにのみであり、その負荷はMySqlサーバー上にあり、ユーザーの随時更新を取得します。 IndexDBはユーザーのローカルマシンによって管理され、25KのユーザーはindexDBの部分とは関係ありません。ユーザーの更新が到着すると、負荷はMySQLサーバー上にあります。