Производительность технологии IndexedDB

может ли кто - нибудь указать мне на статью или предпочтительно предоставить некоторый опыт работы с IndexedDB (в идеале в Chrome) - какова производительность выборки, вставки и обновления?

кажется, есть разумное количество мнений, что его в значительной степени непригодно для наборов данных более нескольких тысяч записей, но я не уверен, что это не только из - за отсутствия индексирования-конечно, концептуально это не может быть медленнее, чем веб-хранилище, поскольку оба предположительно используют хранилище ключей внутренне?

спасибо

12
html5 indexeddb

4 ответов

недавно я провел некоторые сравнения производительности между WebSQL и IndexedDB. Удивительно, но IndexedDB выиграл (чего я не ожидал).

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

Edit: вышеуказанный URL вниз, но доступен на archive.org: http://web.archive.org/web/20160418233232/http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

в итоге:

WebSQL занимает в среднем между ~750-850ms для завершения запроса и рендеринга результатов; и IndexedDB занимает в среднем ~300-350ms для рендеринга тех же результатов.

10

единственная запись производительности, которую я видел, это тот, который производится @Scott (автор другой ответ на этот вопрос). К сожалению, его статья не делает справедливость базы данных SQL Web, поскольку она использует неэффективное предложение HAVING для ограничения размера результирующего набора. Я настроил SQL Скотта, заменив HAVING, GROUP BY и LEFT JOIN (почти) эквивалентом WHERE и sub-selects:

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 ms vs 560 ms на моем компьютере - что, путем экстраполяции из чисел Скотта, делает его примерно в 10 раз быстрее, чем эквивалентный IndexedDB. Я не смог подтвердить это, потому что код IndexedDB не работает в моем браузере, по-видимому, из-за изменений API.

Я должен объяснить "(почти)", который я написал выше. Оригинальный SQL Скотта и мой имеют тонко разные значения: безвозмездное предложение WHERE на моем EpisodeCount , которое имеет эффект замены сканирования таблицы поиском индекса - может не сосчитать некоторые эпизоды, если он не охватывает все возможные значения состояния. Удаление этого пункта стирает разницу за счет удвоения времени выполнения до 40 мс.

обратите внимание, что ранее я обсуждали со Скоттом меньшее изменение его SQL, которое также достигает времени 40 мс.

обновление: большое спасибо Скотту за обновление его статьи отметить нашего обсуждения.

8

выполнение некоторого сравнения производительности между IndexeDB и другими клиентскими и серверными базами данных. Производительность зависит от браузера, поскольку реализация Firefox API IndexeDB намного опережает Chrome или IE. Firefox использует SQLlite в качестве бэкэнд-базы данных, поэтому IndexedDB реализован поверх нее. Вы можете найти много статей производительности IndexedDB, но в основном reserches и разработчики говорят, что IDB работает быстрее с SQL в качестве бэкэнда. В сравнении с Chrome реализация, где IDB реализован на верхней части LevelDB (который является NOSQL) гораздо медленнее по сравнению с 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-Side.pdf

1

У меня были проблемы с массивной объемной вставкой (100.000-200.000 записей). Я решил все проблемы с производительностью IndexedDB, используя библиотеку Dexie. Он имеет эту важную особенность:

Dexie имеет kick-ass производительность. Это массовые методы используют преимущества не очень известная функция в indexedDB, которая позволяет хранить материал без прослушивания каждого события onsuccess. Это ускоряет производительность по максимуму.

Dexie: https://github.com/dfahlander/Dexie.js

BulkPut() -> http://dexie.org/docs/Table/Table.bulkPut()

0