Производительность с индексомDB

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

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

Спасибо

Ответ 1

Недавно я провел несколько сравнений производительности между 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 мс, чтобы получить точные результаты.

Ответ 2

Единственная запись производительности, которую я видел, это тот, который был создан @Scott (автор другой ответ на этот вопрос). К сожалению, в его статье не говорится о справедливости базы данных Web SQL, поскольку она использует неэффективное предложение HAVING, чтобы ограничить размер набора результатов. Я изменил Скотта 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 мс на моем компьютере - что, экстраполяция из чисел Скотта, делает его примерно в 10 раз быстрее, чем эквивалент IndexedDB. Я не смог подтвердить это, потому что код IndexedDB не работает в моем браузере, похоже, из-за изменений API.

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

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

ОБНОВЛЕНИЕ: Большое спасибо Скотту за то, что он обновил статью , чтобы подтвердить наше обсуждение.

Ответ 3

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

Ответ 4

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

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

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

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