My<cod/>.net
Лучший способ хранения больших объемов данных с помощью J2ME
Я разрабатываю приложение J2ME, которое имеет большой объем данных для хранения на устройстве (в области 1 МБ, но переменной). Я не могу полагаться на файловую систему, поэтому я застрял в системе управления записями (RMS), которая позволяет использовать несколько хранилищ записей, но каждый из них имеет ограниченный размер. Моя начальная целевая платформа, Blackberry, ограничивает каждый из них до 64 КБ.
Мне интересно, приходилось ли кому-то еще решать проблему хранения большого количества данных в RMS и как им это удалось? Я думаю о том, чтобы вычислить размеры записей и разделить один набор данных на несколько хранилищ, если он слишком большой, но это добавляет много сложностей, чтобы сохранить его в целости.
Существует множество различных типов данных, которые хранятся, но только один набор, в частности, превысит предел в 64 КБ.
Для всего, что превышает несколько килобайт, вам нужно использовать либо JSR 75, либо удаленный сервер. Записи RMS чрезвычайно ограничены по размеру и скорости, даже в некоторых телефонах более высокого класса. Если вам нужно жонглировать 1 МБ данных в J2ME, единственный надежный и портативный способ-это хранить их в сети. Класс HttpConnection и методы GET и POST всегда поддерживаются.
На телефонах, поддерживающих JSR 75 FileConnection, это может быть допустимой альтернативой, но без подписи кода это кошмар для пользователя. Почти каждый отдельный вызов API вызовет запрос безопасности без выбора общего разрешения. Компаниям, которые развертывают приложения с JSR 75, обычно требуется полдюжины двоичных файлов для каждого порта, чтобы покрыть небольшую часть возможных сертификатов. И это только для сертификатов производителя; некоторые телефоны имеют только сертификаты с блокировкой несущей.
RMS производительность и реализация сильно различаются между устройствами, поэтому, если проблема заключается в переносимости платформы, вы можете обнаружить, что ваш код хорошо работает на некоторых устройствах, а не на других. RMS предназначен для хранения небольших объемов данных (таблицы высокого балла или что-то еще), а не больших объемов.
Вы можете обнаружить, что некоторые платформы быстрее работают с файлами, хранящимися в нескольких хранилищах записей. Некоторые из них быстрее работают с несколькими записями в одном магазине. Многие из них подходят для хранения, но становятся непригодно медленными при удалении больших объемов данных из хранилища.
Лучше всего использовать вместо этого JSR-75, где это возможно, и создать свой собственный интерфейс хранилища файлов, который возвращается к RMS, если ничего лучшего не поддерживается.
К сожалению, когда дело доходит до JavaME, вы часто втягиваетесь в написание специфичных для устройства вариантов вашего кода.
Я думаю, что наиболее гибким подходом было бы реализовать свою собственную файловую систему поверх RMS. Вы можете обрабатывать записи RMS аналогично блокам на жестком диске и использовать структуру индексов или аналогично распределять логические файлы по нескольким блокам. Я бы рекомендовал реализовать байтовый или потоковый интерфейс поверх блоков, а затем, возможно, сделать еще один слой API поверх этого для записи специальных структур данных (или просто сделать ваши объекты сериализуемыми в поток данных).
Классическая книга Таненбаума по операционным системам описывает, как реализовать простую файловую систему, но я уверен, что вы можете найти другие ресурсы в интернете, Если вам не нравится бумага.
Для чтения только я прибываю в приемлемое время (в пределах 10 секунд), индексируя файл ресурсов. У меня есть два экспорта прейскуранта ~800KB CSV. Классы программ и оба эти файла сжимаются до 300KB JAR.
При поиске я показываю a List и запускаю два Thread s в фоновом режиме, чтобы заполнить его, поэтому первые результаты приходят довольно быстро и сразу видны. Сначала я реализовал простой линейный поиск, но это было слишком медленно (~2 минуты).
Затем я проиндексировал файл (который отсортирован по алфавиту), чтобы найти начало каждой буквы. Теперь, прежде чем разбирать строку за строкой, я сначала InputStreamReader.skip() до нужной позиции, основываясь на первой букве. Я подозреваю, что задержка происходит в основном из-за распаковки ресурса, поэтому разделение ресурсов еще больше ускорит его работу. Я не хочу этого делать, чтобы не потерять преимущество легкого обновления. CSV экспортируются без какой-либо предварительной обработки.
В соответствии с Blackberry OS 4.6 ограничение на размер магазина RMS было увеличено до 512 Кб, но это не очень помогает, поскольку многие устройства, скорее всего, не будут поддерживать 4.6. Другой вариант на Blackberry-это постоянное хранилище, которое имеет ограничение на размер записи 64 Кб, но не ограничивает размер хранилища (кроме физических ограничений устройства).
Я думаю, что Карлос и изб правы.
Спасибо всем за полезные комментарии. В конечном итоге самым простым решением было ограничить объем хранимых данных, реализовав код, который настраивает данные в соответствии с размером хранилища, и получая данные с сервера по требованию, если они не хранятся локально. Вот интересно, что лимит увеличивается в OS 4.6, если повезет мой код просто подстроится под себя и сохранит больше данных :)
Разработка приложения J2ME для Blackberry без использования компилятора .cod ограничивает использование JSR 75 кое-что, так как мы не можем подписать архив. Как отметил Карлос, это проблема на любой платформе, и у меня были подобные проблемы с использованием PIM ее части. RMS кажется невероятно медленным на платформе Blackberry, поэтому я не уверен, насколько полезной будет файловая система inode/b-tree сверху, если только данные не были кэшированы в памяти и записаны в RMS в фоновом потоке с низким приоритетом.