Разработка офлайн-хранилища HTML5 для iOS / Android в 2011 г.

Проблема:

Мне нужно решение, не зависящее от устройства (например, HTML5), для хранения и запроса 250 000+ строк данных в автономном режиме на устройстве типа телефона или планшета (например, iOS / Android). Идея в том, что у меня есть люди, работающие в удаленных районах без подключения к сотовой сети, и им нужно выполнять запросы к этим данным и редактировать их в автономном режиме. Частично это будет основано на геолокации, поэтому, если в области, в которой они находятся (использует GPS), есть активы, он покажет эти активы и позволит их редактировать. Когда они вернутся в офис, они могут синхронизировать данные с офисным сервером.

Причина, по которой я подхожу к этому с точки зрения веб-стандартов, заключается в том, чтобы сэкономить деньги и время, написав его один раз в HTML5, а затем он будет работать на нескольких платформах, а не писать дважды в Objective C и Java. Кроме того, если вы напишете что-то, что не зависит от платформы, вы не заблокированы и не упадете вместе с кораблем, когда все перейдут на новый. У нас было аналогичное приложение, написанное для Windows Mobile 5, но теперь оно бесполезно, поскольку эта платформа мертва.

Автономная база данных на устройстве должна быть:

  • быстро (ответы менее 2 секунд)
  • потенциально выполнять соединения и иметь отношения с другими таблицами, которые могут запрашивать базу данных
  • выберите данные в пределах определенного диапазона или критериев, например по координатам x и y на основе показаний GPS.

Параметры:

Локальное хранилище HTML5:

Прекрасно подходит для небольших объемов данных ‹5000 ключей / значений, вы даже можете хранить в нем массивы / объекты, если конвертируете его в JSON.

Минусы:

  • Для более чем 10 000 строк даже на высокопроизводительном компьютере браузер замедлит сканирование.
  • Невозможно выполнять сложные запросы к данным, чтобы извлечь нужные данные, поскольку вам нужно перебирать все хранилище и вручную искать его.
  • Ограничения по объему хранилища, которое может быть сохранено

База данных SQL в Интернете:

  • Отвечает требованиям.
  • Быстро выполнить запрос на 250 000 строк (1-2 секунды)
  • Может создавать сложные запросы, объединения и т. Д.
  • Поддерживается Safari, Android и Opera, поэтому будет работать на устройствах iOS и Android.

Минусы:

  • Устарело с ноября 2010 г.
  • Недостаток безопасности при кросс-каталоговых атаках. На самом деле это не проблема, так как мы не будем на виртуальном хостинге

IndexedDB:

Хранилище объектов типа "ключ-значение" аналогично локальному хранилищу, за исключением индексов.

Минусы:

  • Медленно запускает запрос на 200000 строк (15-18 секунд)
  • Не могу выполнять сложные запросы
  • Невозможно объединиться с другими таблицами
  • Не поддерживается основным телефоном или планшетом, например iPad / Android
  • Стандарт не завершен

Остается единственный вариант - реализовать устаревший метод Web SQL, который может работать только год или около того. IndexedDB и локальное хранилище в настоящее время непригодны для использования.

Я не уверен, как Mozilla и Microsoft объявили устаревшим стандарт базы данных Web SQL и почему W3C допустил это. Предположительно, они занимают 77% рынка настольных браузеров. На продвинутые мобильные устройства Mozilla и Microsoft практически не имеют влияния, поскольку Safari, Opera и Android занимают более 90% рынка. Как Mozilla и Microsoft могут диктовать, какой стандарт следует использовать на мобильном рынке, где, скорее всего, будет использоваться автономное хранилище, не имеет никакого смысла.

В комментариях Mozilla о том, почему они хотели пойти с IndexedDB, в основном это касается «эстетики разработчика», и им не нравится идея запуска SQL в JavaScript. Я не куплюсь на это.

  1. В настоящее время предлагаемый стандарт является худшим и представляет собой чрезвычайно простую реализацию NoSQL, которая работает медленно и даже не поддерживает расширенные функции, которые нужны людям в базе данных. Существует много шаблонного кода для создания базы данных и получения данных, но они утверждают, что люди напишут поверх него несколько хороших библиотек абстракции, которые обеспечат более продвинутые функции. По состоянию на октябрь 2011 года их нигде не видно.

  2. Они устарели от существующего стандарта Web SQL, который фактически работает и реализован в основных браузерах для мобильных устройств и планшетов. В то время как их «новый» и «лучший» стандарт недоступен в основных мобильных браузерах.

  3. Что мы, как разработчики, должны использовать в следующие 3-5 лет, когда спецификация IndexedDB может быть стандартизирована, будет иметь больше функций, реализованных в основных браузерах для мобильных устройств и планшетов, и появятся несколько хороших библиотек, которые упростят задачу?

W3C должен поддерживать параллельную работу стандарта Web SQL Database и просто исправлять проблемы. Он уже поддерживает основные мобильные платформы и работает довольно хорошо. Тот факт, что Mozilla и Microsoft, как два игрока с наибольшим объемом общего доступа к браузеру для настольных компьютеров, смогли отказаться от этого стандарта, довольно сомнительный и может рассматриваться как попытка помешать развитию мобильных веб-платформ до тех пор, пока они не смогут наверстать упущенное и предложить конкурирующие решения с iOS / Safari и Android.

В заключение, есть ли у кого-нибудь решение моей проблемы, которое будет работать на iOS / Android для телефонов / планшетов. Может быть, хороший API-оболочка, который может использовать несколько реализаций базы данных в фоновом режиме с возможностью запросов и позволяет вам выбирать, какая база данных имеет приоритет. Я видел такие вещи, как lawnchair, но я почти уверен, что он позволяет использовать только локальное хранилище по умолчанию и возвращается к другие. Думаю, я бы предпочел использовать Web SQL (по умолчанию), чем более медленные варианты.

Любая помощь в решении очень ценится, спасибо!


person zuallauz    schedule 12.10.2011    source источник
comment
Хорошо написанная статья! Это одна из тех ситуаций, когда «родные» приложения выигрывают в споре между «родными» и веб-приложениями, но я знаю, что вы не хотите этого слышать. В этом случае, насколько мне известно, Web SQL - лучший вариант - я бы также заставил пользователя загружать строки, относящиеся к местам, в которые они собирались, а не ко всей базе данных - если вы считаете, что им может потребоваться обновить где-то ужасным соединение, не говоря уже об увеличении скорости поиска по БД на 1/5 размера (не уверен в масштабе вашей БД)   -  person amcc    schedule 12.10.2011
comment
Они не могут «просто исправить проблемы» с WebSQL, потому что одним из требований для перехода стандарта до статуса рекомендации W3C является наличие «независимых и совместимых реализаций». Поскольку спецификация в основном «делайте то, что делает SQLite», этого никогда не произойдет.   -  person robertc    schedule 12.10.2011
comment
@Vanthel Спасибо, да, лучшие регионы уже разделены, поэтому они загружаются в подмножество всех данных, но самые большие по-прежнему составляют ~ 250 000 строк. Я полагаю, что они могут еще больше распасться.   -  person zuallauz    schedule 12.10.2011
comment
@robertc Почему для развития стандарта нужны независимые и совместимые реализации? Разве это не реализовано уже в трех браузерах? Или эти 3 браузера используют один и тот же исходный код? Что плохого в том, чтобы «делать то, что делает SQLite»? Это само по себе уже является хорошим стандартом. Разве редакторы не могут просто скопировать и вставить то, что они хотят, из спецификации SQLite в спецификацию WebSQL? Хотя я думаю, что было бы разумнее просто сослаться на ту же спецификацию, чтобы она развивалась / улучшалась, как SQLite.   -  person zuallauz    schedule 12.10.2011
comment
Привет, вы только что описали мой финальный экзамен-проект :) Насколько я понимаю, есть 2 варианта, если вам нужен офлайн и спуск; 1. Используйте локальное хранилище и сократите данные до абсолютного базового уровня. или 2. Создайте собственное приложение (с масштабируемым пользовательским интерфейсом?), а затем клонируйте его на другую платформу (вы уже установили спецификации первой, так что гораздо быстрее разработать ее снова для других платформ. обратная сторона - вам придется поддерживать более одного)   -  person Michael Olesen    schedule 13.10.2011
comment
Потому что раньше они требовали, чтобы у нас были Рекомендации W3C, которые фактически не реализовывались ни одним браузером. Все три браузера используют SQLite. Спецификации SQLite не существует, это одна из причин, почему она не является хорошей основой для стандарта.   -  person robertc    schedule 13.10.2011
comment
@robertc Как вы имеете в виду, что спецификации нет? Он основан на стандарте SQL92 с несколькими незначительными упущениями. Я нашел эту страницу, которая выглядит как спецификация. А как насчет всей другой документации на веб-сайте SQLite, которая, по сути, является частью спецификации, не является? т это? Что еще нужно, чтобы оно было действительным?   -  person zuallauz    schedule 13.10.2011
comment
Oracle, MS-SQL и PostgreSQL заявляют о соответствии стандарту SQL-92, пробовали ли вы когда-нибудь написать умеренно сложный SQL, который работает без изменений на всех трех?   -  person robertc    schedule 13.10.2011
comment
Кстати, вы можете пользоваться этой веткой в открытом доступе Список рассылки -webapps в марте.   -  person robertc    schedule 13.10.2011
comment
@robertc Я не думаю, что целью Web SQL является поддержание соответствия или совместимости с Oracle, MySQL, MS-SQL или реализацией SQL-92 Postgres. Это просто для поддержания совместимости с собственной реализацией SQLite, поскольку это то, что является базовым механизмом хранения.   -  person zuallauz    schedule 13.10.2011
comment
У меня сейчас очень похожий сценарий +1 на хорошо написанный вопрос! :)   -  person Tilo    schedule 19.10.2011
comment
Интересный тест для IndexedDB. Интересно, изменится ли проблема с производительностью, которую вы видите, для предстоящей реализации LevelDB в Chrome thechromesource.com/   -  person buley    schedule 21.11.2011


Ответы (7)


Я бы порекомендовал проверить библиотеку JayData, которая на самом деле имеет точную цель создания уровня доступа к данным, не зависящего от хранилища, для мобильных устройств. JayData предоставляет уровень абстракции с поддержкой JavaScript Language Query (JSLQ) и JavaScript CRUD, и вы можете работать точно так же с разными типами автономных и онлайн-хранилищ данных. JayData поддерживает работу со сложными объектами, а также отношениями между объектами как локально, так и удаленно.

На момент написания JayData поддерживает следующие хранилища или протоколы: webSQL (sqLite) / IndexedDB / OData / YQL / FBQL.

Ваша конкретная проблема с разными системами, предоставляющими разные механизмы хранения, может быть легко решена с помощью резервной функции поставщика JayData: она будет использовать любой уровень хранения, который сможет найти, но при этом будет предоставлять тот же API для кода потребителя.

Что касается устаревания WebSQL к 2012 году: на момент написания именно WebSQL все еще покрывает 95% устройств, включая Samsung SmartTV и amazon Kindle. Ознакомьтесь с kindle, выполняющим модульные тесты WebSQL с помощью JayData .

person Peter Aron Zentai    schedule 18.05.2012
comment
Я согласен, поддержка и модель поставщика языковых запросов JavaScript делают библиотеку JayData хорошим вариантом для автономного хранилища HTML5. - person ; 18.05.2012
comment
Обновление: JayData теперь поддерживает HTML5 localStorage. Библиотека JayData выполняет задание по преобразованию / синтаксическому анализу JSON и предоставляет чистый, унифицированный API и концепцию управления данными. - person Robesz; 01.10.2012
comment
Я был бы рад дать ваш ответ как принятый, поскольку он звучит именно так, как нужно, но есть ли у вас какие-либо тесты производительности для большой базы данных, например. 250 000 строк? Мне было бы интересно узнать, может ли он обрабатывать такое количество строк, используя как IndexedDB, так и базовое хранилище WebSQL (в зависимости от устройства), а затем подсчитайте, сколько времени потребуется, чтобы выполнить базовый запрос типа 'where', чтобы найти одну из строк на основе некоторых критериев. . - person zuallauz; 31.05.2013
comment
@zuallauz Я только что сделал такой тест. Получение 5-10 элементов из 250 тыс. Элементов заняло у меня 60 мсек на websql с использованием Android nexus 2 и 25 мсек на Lumia 920 с Windows Phone. (IndexedDB определенно быстрее). - person Peter Aron Zentai; 31.05.2013
comment
Я использовал версии Pro с поддержкой индекса, и я запрашивал поля, использующие этот индекс. Без индексов он, вероятно, гораздо менее эффективен. - person Peter Aron Zentai; 31.05.2013
comment
Хорошо, это очень быстро! Хорошая работа. Хороший график сравнения / тестов на сайте JayData был бы хорошим дополнением ИМХО. - person zuallauz; 01.06.2013
comment
@zuallauz Вы совершенно правы, и мы это сделаем. IndexedDB, как правило, намного быстрее во всех аспектах, за исключением сложных многополевых запросов. Однако вставка данных в WebSQL может быть медленной. Транзакция, открытая для записи, может быть дорогостоящей (60–120 мс). - person Peter Aron Zentai; 01.06.2013

Я бы посмотрел CouchBase Lite. Это почти полнофункциональная реализация CouchDB, работающая на Android и iOS.

iOS

Android

Если вы обернули свое приложение чем-то вроде PhoneGap, вы могли бы создавать собственные приложения HTML 5 для обеих платформ, и вам нужно было бы только Чтобы реализовать CouchDB, придется немного программировать под Android / iOS.

Плюсы:

  • Механизм Fast View для запросов по многим строкам данных.
  • Запеклась простая и мощная поддержка репликации.

Минусы:

  • Хранилище ключей и значений - потребуется некоторое время, чтобы к нему привыкнуть.
person rwilliams    schedule 15.10.2011
comment
Спасибо, похоже, это может сработать, однако вам нужна система Mac, которую я считаю для разработки для него и изготовить ключи и тд? У нас нет Mac. - person zuallauz; 19.10.2011
comment
CouchDB довольно интересен, но я не уверен, что его модель ленивых обновлений индекса (представления) (запускаемых запросом или пакетным процессом) действительно работает хорошо. Большинство приложений, которые я видел, предполагают, что после того, как вы добавили некоторые данные, их можно будет эффективно запросить, а большинство других баз данных NoSQL помещают больше работы в транзакции записи, чтобы транзакции чтения выполнялись быстрее. - person RichVel; 28.07.2012
comment
@RichVel: По моему опыту, обновления представлений никогда не были проблемой на мобильных устройствах. Тем не менее, одна из главных причин использовать CouchDB или TouchDB - это сверхмощная, но простая в использовании репликация. - person rwilliams; 30.07.2012
comment
Я начал искать CouchDB для репликации на мобильные устройства, но мне действительно не хотелось открывать серверную БД для мобильных устройств или использовать CouchDB на сервере для репликации. Итак, я сейчас смотрю на облачную службу синхронизации данных под названием Simperium, см. simperium.com и simperium - person RichVel; 31.07.2012

Я провел еще несколько исследований, пока искал решение для своего собственного проекта. Похоже, эта библиотека весьма перспективна: http://nparashuram.com/IndexedDBShim/

Это позволяет использовать IndexedDB API, имея за кулисами WebSQL.

Тесты проходят на последних iPad, iPhone 5, Android 4.2.2.

Надеюсь, это кому-то поможет.

person KIR    schedule 06.06.2013
comment
Поздно к вечеринке, но я также рекомендую indexeddbshim.js. Он отлично работает в среде Cordova / PhoneGap, обеспечивая единое решение для IOS и Android. - person Douglas Timms; 23.12.2015

Я бы посоветовал вам использовать для этого Corona. Это частная платформа, используемая для перекрестных мобильных приложений с поддержкой SQLite.

Плюсы

  • Это просто и имеет большую поддержку SQLite, и вам не нужно делать странные вещи с хранилищем Html5.

Минусы

  • вы должны заплатить за него, если хотите использовать его в Android Market или iOS Market.

Я вставляю здесь то, что они говорят об этом:

Corona включает поддержку баз данных SQLite на всех платформах. Это основано на встроенной поддержке sqlite на iPhone и скомпилированной версии SQLite на Android. Обратите внимание, что это увеличивает размер двоичного файла Android на 300 КБ.

SQLite доступен во всех версиях Android, iPhone и iPad, а также в Corona Simulator ...

person A.Quiroga    schedule 15.10.2011

"Я видел такие вещи, как кресло-газон, но я почти уверен, что он позволяет вам использовать только локальное хранилище по умолчанию и возвращается к другим. Думаю, я бы предпочел использовать Web SQL (по умолчанию), а не более медленные варианты . "

Это настраивается, каждый из `` адаптеров '' для механизмов хранения является автономным, вы можете передать адаптер конструктору Lawnchair или, альтернативно, изменить порядок, в котором он возвращается к другим параметрам хранения, по-разному объединяя файлы javascript, когда создание библиотеки. например для indexed-db, затем возвращается к sqlite, затем передает sqlite:

git clone https://github.com/brianleroux/lawnchair.git  
cd lawnchair  
cat src/Lawnchair.js src/adapters/indexed-db.js src/adapters/webkit-sqlite.js src/adapters/gears-sqlite.js > my_lawnchair.js

Конечно, как предполагают другие ответы, вы можете обернуть свой html5 в собственное приложение, используя телефонную связь и т.д., тогда у вас будет много вариантов, но если вы хотите придерживаться веб-стандартов, это может быть хорошим способом до тех пор, пока у нас есть широкое распространение IndexedDB.

person user1022475    schedule 03.02.2012

Почему бы не написать простой механизм хранения на javascript (который охватывает «основанную на стандартах» часть)? По-видимому, вам не нужно ничего особенного, поэтому не нужно прилагать слишком много усилий, чтобы все заработало.

Я бы сделал следующее:

  • Храните все в bson или подобном двоичном формате.
  • Разбирать и создавать индексы в файлах и читать при запуске.
  • Выполните запрос с использованием javascript и прочтите большой файл из вашего (очевидно, автономного) веб-приложения.
  • Храните обновленные объекты отдельно.

Это решение возможно только в том случае, если база данных достаточно проста. Но я думаю, что это может сработать - поддержка javascript хороша на мобильных устройствах.

Для вдохновения здесь представлена ​​реализация Btree + на javascript.

Для чтения локальных файлов вам понадобится файловый API, который можно использовать для доступ к локальным файлам. Он поддерживается в большинстве современных браузеров, даже в Safari 6 < / а>. Однако мне не удалось определить, поддерживают ли текущие браузеры iPhone этот API.

person alexfernandez    schedule 15.10.2011
comment
Как JavaScript на телефоне имеет доступ для чтения / записи в / из файловой системы на устройствах? - person zuallauz; 19.10.2011
comment
Хорошая точка зрения. Судя по всему, File API не так далеко, как кажется, но мой ответ может быть слишком оптимистичным. CouchBase выглядит более безопасным вариантом. - person alexfernandez; 20.10.2011

Стоит проверить мою библиотеку с открытым исходным кодом https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

Модуль базы данных Javascript для механизмов хранения Indexeddb, WebDatabase (WebSQL) и WebStorage (localStorage), поддерживающих миграцию версий, расширенные запросы и транзакции.

Поскольку это библиотека NoSQL, присоединение выполняется вручную, но не невозможно. В библиотеку уже встроены алгоритмы объединения ключей.

person Kyaw Tun    schedule 30.05.2013
comment
Если в коде мне нужно выполнить SQL-запрос для получения некоторых данных и их сортировки, но на моем устройстве работает IndexedDB, может ли ваша библиотека преобразовать этот SQL-запрос, который получит данные из базы данных IndexedDB? - person zuallauz; 31.05.2013
comment
Нет. Поддержка SQL в моей библиотеке очень проста. См. Здесь возможности dev.yathit.com/ydn-db/sql- query.html - person Kyaw Tun; 31.05.2013