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

Question

Я занимаюсь разработкой приложения J2ME, которое имеет большой объем данных для хранения на устройстве (размером около 1 МБ, но с переменной). Я не могу полагаться на файловую систему, поэтому я застрял в Системе управления записями (RMS), которая позволяет хранить несколько записей, но каждый имеет ограниченный размер. Моя начальная целевая платформа, Blackberry, ограничивает каждую до 64 КБ.

Мне интересно, сталкивался ли кто-нибудь еще с проблемой хранения большого количества данных в RMS и как им это удалось? Я подумываю о том, чтобы рассчитать размеры записей и разделить один набор данных по нескольким хранилищам, если он слишком велик, но это значительно усложняет его сохранение.

Существует много различных типов данных, которые хранятся, но только один конкретный набор превысит ограничение в 64 КБ.

Answer 1

Для всего, что превышает несколько килобайт, вам нужно использовать либо JSR 75, либо удаленный сервер. RMS-записи чрезвычайно ограничены по размеру и скорости, даже в некоторых более дорогих телефонах. Если вам нужно манипулировать 1 МБ данных в J2ME, единственный надежный и портативный способ - сохранить их в сети. Класс HttpConnection и методы GET и POST поддерживаются всегда.

На телефонах, поддерживающих JSR 75 FileConnection, это может быть допустимой альтернативой, но без подписи кода это кошмар для пользователя. Почти каждый вызов API будет вызывать приглашение безопасности без полного разрешения. Компании, которые развертывают приложения с JSR 75, обычно нуждаются в полудюжине двоичных файлов для каждого порта, чтобы покрыть небольшую часть возможных сертификатов. И это только для сертификатов производителя; Некоторые телефоны имеют только сертификаты, заблокированные оператором.

Answer 2

Производительность и реализация RMS сильно различаются между устройствами, поэтому, если переносимость платформы является проблемой, вы можете обнаружить, что ваш код хорошо работает на некоторых устройствах, а не на других. Служба управления правами предназначена для хранения небольших объемов данных (таблицы рекордов и т. Д.), А не больших объемов.

Вы можете обнаружить, что некоторые платформы работают быстрее с файлами, хранящимися в нескольких хранилищах записей. Некоторые быстрее с несколькими записями в одном магазине. Многие из них подходят для хранения, но становятся необычайно медленными при удалении больших объемов данных из хранилища.

Лучше всего вместо этого использовать JSR-75 там, где это возможно, и создать собственный интерфейс хранилища файлов, который использует RMS, если ничего не поддерживается.

К сожалению, когда дело доходит до JavaME, вас часто тянет к написанию специфичных для устройства вариантов вашего кода.

Answer 3

Я думаю, что наиболее гибкий подход - реализовать собственную файловую систему поверх RMS. Вы можете обрабатывать записи RMS аналогично блокам на жестком диске и использовать структуру inode или аналогичную для распределения логических файлов по нескольким блокам. Я бы порекомендовал реализовать байт или ориентированный на поток интерфейс поверх блоков, а затем, возможно, сделать еще один уровень API поверх этого для написания специальных структур данных (или просто сделать ваши объекты сериализуемыми для потока данных).

Классическая книга Таненбаума по операционным системам описывает, как реализовать простую файловую систему, но я уверен, что вы можете найти другие ресурсы в Интернете, если вам не нравится бумага.

Answer 4

Только для чтения. Я прибываю в подходящее время (в течение 10 секунд), индексируя файл ресурса. У меня есть два ~ 800KB экспорта цен в CSV. Классы программы и оба этих файла сжимаются до 300 КБ JAR.

При поиске я отображаю List и запускаю два Thread s в фоновом режиме, чтобы заполнить его, поэтому первые результаты появляются довольно быстро и сразу же отображаются. Сначала я реализовал простой линейный поиск, но он был слишком медленным (~ 2 минуты).

Затем я проиндексировал файл (который отсортирован по алфавиту), чтобы найти начало каждой буквы. Теперь, прежде чем разбирать строку за строкой, я сначала InputStreamReader.skip() в желаемую позицию, основанную на первой букве. Я подозреваю, что задержка происходит в основном из-за декомпрессии ресурса, поэтому разделение ресурсов ускорит его. Я не хочу этого делать, чтобы не потерять преимущество простого обновления. CSV экспортируются без предварительной обработки.

Answer 5

Это довольно просто, используйте JSR75 (FileConnection) и не забудьте подписать свой мидлет действительным (доверенным) сертификатом.

Answer 6

В Blackberry OS 4.6 ограничение размера хранилища RMS было увеличено до 512 КБ, но это не сильно помогает, так как многие устройства, скорее всего, не будут поддерживать 4.6. Другим вариантом в Blackberry является постоянное хранилище, которое имеет ограничение размера записи в 64 КБ, но без ограничения размера хранилища (кроме физических ограничений устройства).

Я думаю, что Карлос и Изб правы.

Answer 7

Спасибо всем за полезные комментарии. В итоге самым простым решением было ограничение количества хранимых данных, реализация кода, который корректирует данные в соответствии с размером хранилища, и выборка данных с сервера по требованию, если они не хранятся локально. Интересно, что в OS 4.6 лимит увеличен, и, если повезет, мой код просто подстраивается и сохраняет больше данных:)

Разработка приложения J2ME для Blackberry без использования компилятора .cod ограничивает использование JSR 75, поскольку мы не можем подписать архив. Как отметил Карлос, это проблема на любой платформе, и у меня были похожие проблемы при использовании PIM-части. RMS кажется невероятно медленным на платформе Blackberry, поэтому я не уверен, насколько полезной будет файловая система inode / b-tree в верхней части, если только данные не были кэшированы в памяти и записаны в RMS в фоновом потоке с низким приоритетом. 1003 *

Answer 8

Я только начинаю кодировать для JavaME, но у меня есть опыт работы со старыми версиями PalmOS, где все блоки данных имеют ограниченный размер, что требует проектирования структур данных с использованием индексов записей и смещений.