html - IndexedDBのパフォーマンス

Question

誰かが私にIndexedDB（理想的にはChrome）のパフォーマンスに関する記事を教えてもらえますか？フェッチ、挿入、更新のパフォーマンスはどのようなものですか？

数千レコードを超えるデータセットにはほとんど使用できないというかなりの意見があるようですが、これがインデックス作成の欠如だけが原因ではないかどうかはわかりません-確かに概念的には、Webストレージよりも遅くなることはありません。どちらもおそらく内部でKey-Valueストレージを使用していますか？

ありがとう

score 13 · Accepted Answer

最近、WebSQLとIndexedDBのパフォーマンスを比較しました。驚いたことに、IndexedDBが勝ちました（私は予想していませんでした）。

http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

編集：上記のURLはダウンしていますが、archive.orgで入手できます：http： //web.archive.org/web/20160418233232/http ：//blog.oharagroup.net/post/16394604653/a-performance-comparison-websql -vs-indexeddb

要約すれば：

WebSQLは、クエリを完了して結果をレンダリングするのに平均で約750〜850ミリ秒かかります。IndexedDBは、まったく同じ結果をレンダリングするのに平均で約300〜350ミリ秒かかります。

score 11 · Accepted Answer

私が見た唯一のパフォーマンスの記事は、@ Scott （この質問に対する他の回答の著者）によって作成されたものです。残念ながら、彼の記事は、非効率的なHAVING句を使用して結果セットのサイズを制限しているため、WebSQLデータベースの正義を示していません。スコットのSQLを微調整し、HAVING、GROUP BY、LEFT JOINを（ほぼ）同等のWHEREとサブ選択に置き換えました。

SELECT p.Name AS ProgramName,
       s.rowid,
       s.Name,
       s.NowShowing,
       s.ProgramID,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Watched', 'Recorded', 'Expected') OR STATUS IS NULL) AS EpisodeCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Watched') AS WatchedCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Recorded') AS RecordedCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Expected') AS ExpectedCount
  FROM Program p
  JOIN Series s ON p.rowid = s.ProgramID
 WHERE s.NowShowing IS NOT NULL OR
       EXISTS (SELECT * FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Recorded', 'Expected'))
ORDER BY CASE
           WHEN s.NowShowing IS NULL THEN 1
           ELSE 0
         END,
         s.NowShowing,
         p.Name

これは、元のコンピューターの約28倍の速度（私のコンピューターでは20ミリ秒対560ミリ秒）です。これは、スコットの数値から推定すると、同等のIndexedDBの約10倍の速度になります。どうやらAPIの変更が原因で、IndexedDBコードがブラウザで機能しないため、これを確認できませんでした。

上で書いた「（ほぼ）」について説明する必要があります。スコットの元のSQLと私のものは微妙に異なる意味を持っています：私のEpisodeCountの無償のWHERE句（テーブルスキャンをインデックス検索に置き換える効果があります）は、すべての可能なステータス値をカバーしていない場合、一部のエピソードをカウントできない可能性があります。この句を削除すると、実行時間が2倍の40ミリ秒になるという犠牲を払って、違いが消去されます。

以前、私はスコットと彼のSQLへの小さな変更について話し合ったことに注意してください。これも40ミリ秒の時間を達成します。

更新：私たちが行った議論を認めるために彼の記事を更新してくれたスコットに感謝します。

score 2 · Accepted Answer

IndexeDBと他のクライアント側およびサーバー側のデータベースとの間でパフォーマンスの比較を行います。IndexeDB APIのFirefox実装は、ChromeやIEよりもはるかに進んでいるため、パフォーマンスはブラウザによって異なります。FirefoxはバックエンドデータベースとしてSQLliteを使用しているため、IndexedDBはその上に実装されています。IndexedDBのパフォーマンスに関する多くの記事を見つけることができますが、ほとんどの研究者や開発者は、バックエンドとしてSQLを使用するとIDBのパフォーマンスが向上すると言っています。IDBがLevelDB（NOSQL）の上に実装されているChromeの実装と比較すると、Firefoxに比べてはるかに低速です。もう一方の端では、WEBSQL（減価償却済み）はChromeで高速に実行されていますが、Firefoxではサポートされなくなりました。

IndexedDBのパフォーマンス結果を掲載した論文を公開しました。https://www.researchgate.net/profile/Stefan_Kimak/publication/281065948_Performance_Testing_and_Comparison_of_Client_Side_Databases_Versus_Server_Side/links/55d3465c08ae0a3417226302/Performance-Testing-and-Comparison-of-Client-Side-Databases-Versus-Server