localStorage и indexedDB используются для автономного хранения данных в HTML5. Каковы их основные различия и какой из них предпочтительнее в каких ситуациях?
Близкие избиратели: хотя я полностью понимаю, как это выглядело «главным образом на основе мнений» («против» в оригинальной версии не помогло), эти две технологии явно различаются, и есть объективные причины для выбора одной из них. Пользователь221287 проведет минимальное предварительное исследование по теме вопроса и получит базовое понимание концепций, которые вы используете, прежде чем вы спросите, что, скорее всего, спасет вас от отрицательных голосов и близких голосов в будущем.
На первый взгляд две технологии могут показаться сравнимыми, но если вы проведете с ними некоторое время, вы скоро поймете, что это не так. Они были разработаны для достижения аналогичной цели - хранилища на стороне клиента, но они подходят к поставленной задаче с существенно разных точек зрения и лучше всего работают с разными объемами данных.
localStorage, или, точнее, веб-хранилище , был разработан для небольших объемов данных. По сути, это хранилище ключей и значений только для строк с упрощенным синхронным API. Эта последняя часть является ключевой. Хотя в спецификации нет ничего, что запрещало бы асинхронное хранилище DOM, в настоящее время все реализации являются синхронными (т.е. блокируют запросы). Даже если вы не возражаете против использования наивного хранилища «ключ-значение» для больших объемов данных, ваши клиенты всегда будут ждать, пока ваше приложение загрузится.
indexedDB , с другой стороны, был разработан для работы со значительно большими объемами данных. Во-первых, теоретически он предоставляет как синхронный, так и асинхронный API. На практике, однако, все текущие реализации являются асинхронными, и запросы не будут блокировать загрузку пользовательского интерфейса. Кроме того, indexedDB, как видно из названия, предоставляет индексы . Вы можете выполнять элементарные запросы в своей базе данных и извлекать записи, просматривая их ключи в определенных диапазонах ключей . indexedDB также поддерживает транзакции и предоставляет простые типы (например, Date).
На этом этапе indexedDB может показаться лучшим решением для любой ситуации. Однако за все его функции есть штраф: по сравнению с DOM Storage его API довольно сложный. indexedDB предполагает общее знакомство с понятиями базы данных, в то время как с веб-хранилищем вы можете сразу приступить к работе. Если вы когда-либо работали с файлами cookie, у вас не возникнет проблем при работе с веб-хранилищем. Кроме того, в общем случае вам потребуется написать больше кода в indexedDB, чтобы достичь точно такого же результата, как в Web Storage (и больше кода = больше ошибок). Кроме того, эмуляция веб-хранилища для браузеров, которые его не поддерживают, относительно проста. С indexedDB задача не будет стоить своего времени. Наконец, прежде чем погрузиться в indexedDB, вы должны сначала взглянуть на API квоты .
В конце концов, это полностью зависит от вас, если вы используете веб-хранилище или indexedDB, или оба, в вашем приложении. Хорошим вариантом использования веб-хранилища будет хранение простых данных сеанса, например имени пользователя, и сохранение некоторых запросов в вашей реальной базе данных. С другой стороны, дополнительные функции indexedDB могут помочь вам сохранить все данные, необходимые для работы приложения в автономном режиме.
Также работники сферы обслуживания могут использовать indexedDB, но не localStorage
Fabich
10
@yannis ответ превосходен. Просто хочу добавить пару вещей.
В некоторых ситуациях, таких как Service Workers, вы не можете использовать блокирующий код, следовательно, вы не можете использовать localStorage и должны использовать что-то вроде indexedDB.
API для indexedDB сложен и утомителен (я бы сказал, что «ужасающий», YMMV). Существует несколько библиотек-оболочек для упрощения API, я настоятельно рекомендую вам взглянуть на них.
Вы не можете использовать localStorage и блокирующий код, не могли бы вы обернуть блокирующий код Обещанием и сделать его неблокирующим?
joedotnot
3
Для меня, я обнаружил , что я могу хранить капли в IndexedDB в LocalStorage я могу хранить только строки. Это означает, что IndexdDB лучше подходит для двоичных данных, таких как изображения, аудио, видео. Да, мы можем хранить изображения в base64 в localStorage, но большие двоичные объекты будут меньше и быстрее, потому что нам не нужно их декодировать.
Any objects supported by the structured clone algorithm can be stored:
All primitive types However not symbols
Boolean object
String object
Date
RegExp The lastIndex field is not preserved.
Blob
File
FileList
ArrayBuffer
ArrayBufferView This basically means all typed arrays like Int32Array etc.
ImageData
Array
Object This just includes plain objects (e.g. from object literals)
Map
Set
Ответы:
На первый взгляд две технологии могут показаться сравнимыми, но если вы проведете с ними некоторое время, вы скоро поймете, что это не так. Они были разработаны для достижения аналогичной цели - хранилища на стороне клиента, но они подходят к поставленной задаче с существенно разных точек зрения и лучше всего работают с разными объемами данных.
localStorage, или, точнее, веб-хранилище , был разработан для небольших объемов данных. По сути, это хранилище ключей и значений только для строк с упрощенным синхронным API. Эта последняя часть является ключевой. Хотя в спецификации нет ничего, что запрещало бы асинхронное хранилище DOM, в настоящее время все реализации являются синхронными (т.е. блокируют запросы). Даже если вы не возражаете против использования наивного хранилища «ключ-значение» для больших объемов данных, ваши клиенты всегда будут ждать, пока ваше приложение загрузится.
indexedDB , с другой стороны, был разработан для работы со значительно большими объемами данных. Во-первых, теоретически он предоставляет как синхронный, так и асинхронный API. На практике, однако, все текущие реализации являются асинхронными, и запросы не будут блокировать загрузку пользовательского интерфейса. Кроме того, indexedDB, как видно из названия, предоставляет индексы . Вы можете выполнять элементарные запросы в своей базе данных и извлекать записи, просматривая их ключи в определенных диапазонах ключей . indexedDB также поддерживает транзакции и предоставляет простые типы (например, Date).
На этом этапе indexedDB может показаться лучшим решением для любой ситуации. Однако за все его функции есть штраф: по сравнению с DOM Storage его API довольно сложный. indexedDB предполагает общее знакомство с понятиями базы данных, в то время как с веб-хранилищем вы можете сразу приступить к работе. Если вы когда-либо работали с файлами cookie, у вас не возникнет проблем при работе с веб-хранилищем. Кроме того, в общем случае вам потребуется написать больше кода в indexedDB, чтобы достичь точно такого же результата, как в Web Storage (и больше кода = больше ошибок). Кроме того, эмуляция веб-хранилища для браузеров, которые его не поддерживают, относительно проста. С indexedDB задача не будет стоить своего времени. Наконец, прежде чем погрузиться в indexedDB, вы должны сначала взглянуть на API квоты .
В конце концов, это полностью зависит от вас, если вы используете веб-хранилище или indexedDB, или оба, в вашем приложении. Хорошим вариантом использования веб-хранилища будет хранение простых данных сеанса, например имени пользователя, и сохранение некоторых запросов в вашей реальной базе данных. С другой стороны, дополнительные функции indexedDB могут помочь вам сохранить все данные, необходимые для работы приложения в автономном режиме.
источник
@yannis ответ превосходен. Просто хочу добавить пару вещей.
В некоторых ситуациях, таких как Service Workers, вы не можете использовать блокирующий код, следовательно, вы не можете использовать localStorage и должны использовать что-то вроде indexedDB.
API для indexedDB сложен и утомителен (я бы сказал, что «ужасающий», YMMV). Существует несколько библиотек-оболочек для упрощения API, я настоятельно рекомендую вам взглянуть на них.
источник
Для меня, я обнаружил , что я могу хранить капли в IndexedDB в LocalStorage я могу хранить только строки. Это означает, что IndexdDB лучше подходит для двоичных данных, таких как изображения, аудио, видео. Да, мы можем хранить изображения в base64 в localStorage, но большие двоичные объекты будут меньше и быстрее, потому что нам не нужно их декодировать.
Цитата из MDN :
О IndexedDB :
источник