Производительность IndexedDB - PullRequest
Новая
       4

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

12 голосов
/ 13 октября 2011

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

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

Спасибо

Ответы [ 4 ]

10 голосов
/ 02 февраля 2012

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

8 голосов
/ 17 ноября 2012

Единственное описание производительности, которое я видел, это , созданный @ 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, которое заменяет сканирование таблицы поиском по индексу, может не подсчитать некоторые эпизоды, если оно не охватывает все возможные значения Status. Удаление этого пункта стирает разницу за счет удвоения времени выполнения до 40 мс.

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

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

1 голос
/ 16 июня 2017

У меня были проблемы с массивной массовой вставкой (100 000 - 200 000 записей). Я решил все проблемы с производительностью IndexedDB с помощью библиотеки Dexie. У него есть эта важная особенность:

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

Декси: https://github.com/dfahlander/Dexie.js

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

1 голос
/ 19 декабря 2012

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

...