Comments 8
Самое интересное в поддержке браузерами IndexedDB это отсутствие поддержки в iOS даже 7 версии.
Я вот хотел написать мобильное веб-приложение, а теперь ломаю голову, как обойти это ограничение не переписывая дважды логику локального репозитория объектов
Я вот хотел написать мобильное веб-приложение, а теперь ломаю голову, как обойти это ограничение не переписывая дважды логику локального репозитория объектов
Использовать полифилл или обертку типа PouchDB.
Можно, к примеру, использовать IndexedDBShim. iOS поддерживает WebSQL.
Спасибо, добрый человек!
А то мне уже с десяток писем написали, что статья устарела, а самим написать — руки отвалятся :)
А то мне уже с десяток писем написали, что статья устарела, а самим написать — руки отвалятся :)
Думаю, ни о какой скорости речи даже быть не может, по сравнению с тем же sqlite.
Ведь данные идут по циклу и цикл снаружи, и применяется фильтрация на стороне клиента.
О ужас.
Чем им sqlite то не понравился.
То есть, получается, что это какая-то помесь localstorage + индексы. И ничего более.
Читаем:
По сути, они приговорили к смерти будущие клиентские приложения.
Ибо они будут медленными и/или ограниченными в чём то (из-за низкой скорости работы по поиску данных).
Хорошо, если sqlite не выкинут из браузеров. Ибо я не вижу вообще смысла использовать indexeddb, если конечно, это не простой список дел на 100 элементов =))
Например, для серьёзного проекта может понадобиться поиск по слову для 1 миллион записей. Представляю, как это будет тормозить при этом самом внешнем цикле и проверке даже строковыми функциями =))
Конечно, кто-то скажет, что можно сделать индекс по словам в отдельную таблицу, приводить-нормализировать, выбирать сначала оттуда, потом по индексам из основной таблицы (ведь обычно на странице бывает не более 10...20...50 элементов, поэтому тормозить не будет так сильно). По идее, правильно, в стиле сфинска для mysql.
Но основной фокус в том, что страничник показать будет возможно, только узнав полное количество записей по данному ключу, а это можно будет сделать, только перебрав все *миллионы* записей =))
Ибо какого-то возвращения количества записей в этих курсорах нет.
Конечно, кто-то скажет, что нужно завести ещё одну таблицу и там хранить индекс количества записей по каждому слову, по каждому сочетанию слов и т.д. до бесконечности (таблица может быть очень огромная).
В общем, ребята тут что-то намудрили. Неужели не проще использовать уже готовый продукт в виде sqlite и мощных универсальных языков запросов SQL?
Конечно, скорости процессора и js повышаются, но всему есть предел.
У кого-нибудь есть реальные замеры скорости на реальном серьёзном приложении, которое использует indexeddb и fulltext search на > 10000 записей?
Ведь данные идут по циклу и цикл снаружи, и применяется фильтрация на стороне клиента.
О ужас.
Чем им sqlite то не понравился.
То есть, получается, что это какая-то помесь localstorage + индексы. И ничего более.
Читаем:
18 ноября 2010 г. консорциум W3C объявило прекращении поддержки СУБД Web SQL. В связи с этим разработчикам более не рекомендуется использовать эту технологию, так как выпуск обновлений для нее прекращен, а поставщики браузеров не заинтересованы в ее дальнейшем развитии.
Заменой для Web SQL являются индексированные базы данных (которым, собственно, и посвящено данное руководство), предлагаемые разработчикам для хранения и обработки данных в клиентских приложениях.
По сути, они приговорили к смерти будущие клиентские приложения.
Ибо они будут медленными и/или ограниченными в чём то (из-за низкой скорости работы по поиску данных).
Хорошо, если sqlite не выкинут из браузеров. Ибо я не вижу вообще смысла использовать indexeddb, если конечно, это не простой список дел на 100 элементов =))
Например, для серьёзного проекта может понадобиться поиск по слову для 1 миллион записей. Представляю, как это будет тормозить при этом самом внешнем цикле и проверке даже строковыми функциями =))
Конечно, кто-то скажет, что можно сделать индекс по словам в отдельную таблицу, приводить-нормализировать, выбирать сначала оттуда, потом по индексам из основной таблицы (ведь обычно на странице бывает не более 10...20...50 элементов, поэтому тормозить не будет так сильно). По идее, правильно, в стиле сфинска для mysql.
Но основной фокус в том, что страничник показать будет возможно, только узнав полное количество записей по данному ключу, а это можно будет сделать, только перебрав все *миллионы* записей =))
Ибо какого-то возвращения количества записей в этих курсорах нет.
Конечно, кто-то скажет, что нужно завести ещё одну таблицу и там хранить индекс количества записей по каждому слову, по каждому сочетанию слов и т.д. до бесконечности (таблица может быть очень огромная).
В общем, ребята тут что-то намудрили. Неужели не проще использовать уже готовый продукт в виде sqlite и мощных универсальных языков запросов SQL?
Конечно, скорости процессора и js повышаются, но всему есть предел.
У кого-нибудь есть реальные замеры скорости на реальном серьёзном приложении, которое использует indexeddb и fulltext search на > 10000 записей?
То есть, получается, что это какая-то помесь localstorage + индексы. И ничего более.
localstorage + таблицы + индексы + большой объем + курсор
Чем им sqlite то не понравился.
Думаю можно найти статью где подробно описываются недостатки sqlite. Скорее всего где-то на MDN, т.к. основными противниками были ребята из Mozilla и MS. В первую очередь в голову приходит сложный механизм блокировок, относительно низкая скорость записи и возможно какие-то нюансы кросс-платформенности. Но скорее всего проблема чисто идеологическая. Вы уверены, что хранить миллион записей на клиенте это нормально? Приложение обязательно должно работать автономно и без этой фичи полностью теряет свой смысл?
Обертка поддерживающая язык запросов не проблема. Использую либу поддерживающую операторы сравнения, логические связки, сортировку, contains, distinct, различные агрегаторы (max, min, sum) и прочее счастье. Но все это счастье на массивах. Вот думаю расширять ли ее на IndexedDB, но операции с таблицами не очень в синтаксис вписываются.
У кого-нибудь есть реальные замеры скорости на реальном серьёзном приложении, которое использует indexeddb и fulltext search на > 10000 записей?
Сейчас проверил простейшим performance.now() — у меня like по сто тысячной коллекции проходит примерно за 400мс. Но это инструмент абстрактных запросов, заточки под текстовый поиск в нем нет. На Хабре проскакивали различные JS-фильтры, возможно, они еще быстрее. Не знаю сколько к этому добавит выборка из базы. С выборкой малого количества больших записей (текстовые файлы) проблем по скорости не замечал. В принципе полная выборка и не нужна, есть же курсор, чтобы итерироватся по таблице. Тогда будет один цикл, не знаю где вы три штуки насчитали. Но повторюсь: работа с таким объемом данных на клиенте выглядит странно.
Sign up to leave a comment.
Готовим IndexedDB