Способы хранения и чтения больших объемов данных в Java-приложении под Android

Question

[Genghis]

Доброго времени суток, уважаемые.

Почитав различные статьи нашел информацию только о том, что локально Android позволяет использовать SQLite из всех возможных БД и ни одного упоминания о других. Поскольку SQLite имеет урезанный функционал, то возникает резонный вопрос — существуют ли более расширенные аналоги или же другие способы хранения информации с быстрым доступом к чтению/записи?
В частности, больше всего интересует тема мульти-инсертов. Так как они не доступны в SQLite, то как быть с объемом данных в 20-30 тысяч строк? Такое количество инсертов в базу занимает очень много времени, а когда за день подобных процедур необходимо выполнить 3-5, то удобство использования приложения под Андроид резко снижается.
Единственным приемлемым на данный момент способом хранения и работы с данными выбрал для себя XML-файлы и, соответственно, XPath для выборки, однако, подобные запросы выполняются заметно медленее, чем аналогичные при выборке из БД (например MySQL).
Какие способы реализации функционала записи/чтения больших объемов табличных данных в Java-приложении под Андроид вы можете посоветовать?

Answer 1

[SabMakc]

Какая скорость в SQLite?
Вставки идут в рамках одной транзакции?

Использовался ли prepared statements? Он позволяет 1 раз распарсить ваш запрос, а потом только данные для вставки меняются.

P.S. странное решение — парсить XML в тех случаях, когда мало SQLite.
XPath на мой взгляд будет гораздо дольше + может памяти не хватить.

В каких целях будете использовать эти данные?
Если в выборке нужны условия, то от SQLite не уйти.
Вообще SQLite — специализированное хранилище, т.е. его скорость вряд ли удастся обойти.
Только если использование этих данных специфическое, то только тогда есть шанс построения специального хранилища, которое по скорости обойдет SQLite.

В одном проекте использовал protobuf, но не в целях ускорения выборки, в целях прототипирования — можно сразу генерировать классы для работы с данными. В результате так и остался на protobuf — скорость оказалась вполне приемлемая.

Comments

[Genghis]

На счет XML. Чтение из него с помощью XPath происходит, конечно же, медленнее, чем из SQLite, но, запись происходит быстрее. Дело в том, что чтобы вставить данные в sql нужно сделать кучу инсертов, это долго. А XML я получаю сразу с удаленного сервера и сохраняю в папке приложения, после чего обращаюсь прямо к нему, то есть для сохранения полученной информации на планшете не приходится выполнять никаких инсертов в базу, так что это делается почти мгновенно, зависит только от скорости интернета, то есть от времени, за которое скачается XML файл в несколько мегабайт.

[SabMakc]

Тогда советую попробовать protobuf — с сервера можно сразу его и отдавать, а не XML. И хранить прямо в файле. Скажем, 1 объект — 1 строчка.
Преимущества относительно XML:
1. Занимает меньше места. Что хорошо и для ускорения передачи данных.
2. Должен быстрее парсится, чем XML. Хотя бы потому, что он свою структуру «знает».

Недостатки:
1. Хуже сжимается, т.к. формат бинарный. Но с другой стороны не факт, что сжатый XML будет легче.

[LeoCcoder]

Так получайте сразу готовую базу с сервера вместо XML, с ней потом приятнее работать.

[Genghis]

А это возможно? Нет разницы в форматах файлов SQLite под андроидом и линуксом?
Но главный вопрос в том — можно ли на стороне сервера быстро сформировать этот файл, минуя кучу инсертов? Если вставки в таблицу производить так же, средствами SQLite, то такой вариант не подходит, так как таблица должна создаваться на лету, а значит времени на ее создание уйдет, опять же, много. Да и сервер нагружать такими процедурами нельзя, так как работают с ним порядка 150 устройств с этим приложением. Представьте, сколько ему придется в сутки делать таких пачек инсерт-запросов, если для каждого их по 10-30 тысяч и по 3-5 раз в день.

[SabMakc]

На сколько знаю, ни кто не гарантирует бинарную совместимость файлов SQLite.

[Maccimo]

SabMakc, на сайте SQLite пишут прямо противоположное:

The SQLite file format is cross-platform. A database file written on one machine can be copied to and used on a different machine with a different architecture. Big-endian or little-endian, 32-bit or 64-bit does not matter. All machines use the same file format. Furthermore, the developers have pledged to keep the file format stable and backwards compatible, so newer versions of SQLite can read and write older database files.

sqlite.org/different.html#onefile

[SabMakc]

Спасибо Maccimo за подробности.
Просто встречал упоминания (на StackOverflow), что формат файлов SQLite у разных производителей может быть разный.
А тут сама SQLite гарантирует совместимость.

Answer 2

[timka05]

Ну для SQLITE при вставке больших объемов играться с PRAGMA.
PRAGMA synchronous=OFF — отключает проверку записи данных на файловую систему
ну и перенос файла транзакций и временного буфера в память (экономим на обращениях к диску (встроенной/карте памяти)
PRAGMA journal_mode=MEMORY
PRAGMA temp_store=MEMORY

Подробнее sqlite.org/pragma.html

Answer 3

[Genghis]

Заранее благодарю за приведенные варианты решений. Опробую их и отпишусь по результатам.

Answer 4

[Владимир Смирнов]

Способы хранения и чтения больших объемов данных

Это именно то, ради чего и разрабатываются СУБД, и именно их и следует использовать.

Единственным приемлемым на данный момент способом хранения и работы с данными выбрал для себя XML-файлы

Непонятно, причем тут вообще XML. Стандарт разрабатывался для унификации форматов при обмене информацией, с уклоном в человекочитаемость, в связи с чем избыточен, ресурсоемок и абсолютно не приспособлен для оптимального хранения данных. Даже если решили велосипед изобретать, то XML, пожалуй, худший из всех возможных вариантов. Тогда уж сливайте все в файл с разделителями и пишите собственные механизмы сохранения и выборки. Работать будет быстрее, чем XML, и ресурсов потребует во много раз меньше. При этом, что XML, что файлы с разделителями, что угодно — если вы не используете СУБД для "хранения и чтения больших объемов данных", то с 90% вероятностью можно предположить, что вы делаете что-то не так (если только вы не Гугл, конечно).

Да и сервер нагружать такими процедурами нельзя, так как работают с ним порядка 150 устройств с этим приложением. Представьте, сколько ему придется в сутки делать таких пачек инсерт-запросов, если для каждого их по 10-30 тысяч и по 3-5 раз в день

Большинство современных СУБД, будучи установлены на средний современный сервер, с легкостью проглотят пару миллионов инсертов в сутки. Да что там в сутки, буквально позавчера у меня Oracle за час отработал 15 млн инсертов в таблицу с тремя десятками полей, причем в тестовом окружении.

на планшете…… по 10-30 тысяч и по 3-5 раз в день

Если это планшет, значит данные генерирует пользователь, а не какой-нибудь автоматизированный датчик. Тут вопрос, что же там такого может нагенерить пользователь? Может вам следует пересмотреть архитектуру приложения? Или нормализовать сохраняемые данные? Это я так, на всякий случай спрашиваю, а то мало ли… У вас ведь грамотный архитектор на проекте есть, да?

Answer 5

[quarantino]

SQLite должна без напряга вставлять 20-30 тысяч записей. Не помню точных цифр, но на добавление миллиона записей у меня уходило порядка десяти секунд — минуты (правда, на десктопе, а не на планшете). Зависит от структуры базы и т.п., но — как писали выше — prepared statement + все добавление в рамках одной транзакции. Затем можно обсуждать конкретные цифры — сколько времени тратится, и сколько должно быть.

Еще один момент — по каким полям нужен поиск, а по каким нет. Был опыт — в таблицу писали несколько полей (даже не так, на каждую «основную» запись добавлялось несколко записей в дополнительную таблицу), но писался/вычитывался обьект со всем своим хозяйством целиком. В итоге — оставили несколько индексированных полей, по которым строятся запросы, а все остальное спрятали в блоб. Разница — на порядок.