Mejores prácticas para almacenar grandes cantidades de datos con J2ME

Question

Estoy desarrollando una aplicación J2ME que tiene una gran cantidad de datos para almacenar en el dispositivo (en la región de 1 MB pero variable).No puedo confiar en el sistema de archivos, así que estoy atascado en el Sistema de gestión de registros (RMS), que permite múltiples almacenes de registros, pero cada uno tiene un tamaño limitado.Mi plataforma de destino inicial, Blackberry, limita cada una a 64 KB.

Me pregunto si alguien más ha tenido que abordar el problema de almacenar una gran cantidad de datos en el RMS y cómo lo gestionaron.Estoy pensando en tener que calcular el tamaño de los registros y dividir un conjunto de datos en varias tiendas si es demasiado grande, pero eso agrega mucha complejidad para mantenerlo intacto.

Se almacenan muchos tipos diferentes de datos, pero solo un conjunto en particular excederá el límite de 64 KB.

Answer 1

Para cualquier cosa que supere unos pocos kilobytes, deberá utilizar JSR 75 o un servidor remoto.Los registros RMS son extremadamente limitados en tamaño y velocidad, incluso en algunos teléfonos de gama alta.Si necesita hacer malabarismos con 1 MB de datos en J2ME, la única forma confiable y portátil es almacenarlos en la red.La clase HttpConnection y los métodos GET y POST siempre son compatibles.

En los teléfonos que admiten JSR 75 FileConnection, puede ser una alternativa válida, pero sin la firma de código es una pesadilla para el usuario.Casi todas las llamadas a la API invocarán un mensaje de seguridad sin opción de permiso general.Las empresas que implementan aplicaciones con JSR 75 normalmente necesitan media docena de binarios para cada puerto sólo para cubrir una pequeña parte de los posibles certificados.Y esto es sólo para los certificados del fabricante;Algunos teléfonos solo tienen certificados bloqueados por el operador.

Answer 2

El rendimiento y la implementación de RMS varían enormemente entre dispositivos, por lo que si la portabilidad de la plataforma es un problema, es posible que su código funcione bien en algunos dispositivos y no en otros.RMS está diseñado para almacenar pequeñas cantidades de datos (tablas de puntuación alta o lo que sea), no grandes cantidades.

Es posible que descubra que algunas plataformas son más rápidas con archivos almacenados en varias tiendas de discos.Algunos son más rápidos con múltiples registros dentro de una tienda.Muchos están bien para el almacenamiento, pero se vuelven inutilizables cuando se eliminan grandes cantidades de datos del almacén.

Lo mejor que puede hacer es utilizar JSR-75 cuando esté disponible y crear su propia interfaz de almacén de archivos que recurra a RMS si no se admite nada mejor.

Desafortunadamente, cuando se trata de JavaME, a menudo te ves obligado a escribir variantes de tu código específicas para cada dispositivo.

Answer 3

Creo que el enfoque más flexible sería implementar su propio sistema de archivos además del RMS.Puede manejar los registros RMS de manera similar a los bloques en un disco duro y usar un estructura de inodo o similar para distribuir archivos lógicos en varios bloques.Recomendaría implementar una interfaz orientada a bytes o flujos encima de los bloques, y luego posiblemente crear otra capa API encima para escribir estructuras de datos especiales (o simplemente hacer que sus objetos sean serializables al flujo de datos).

El libro clásico de Tanenbaum sobre sistemas operativos. Cubre cómo implementar un sistema de archivos simple, pero estoy seguro de que puedes encontrar otros recursos en línea si no te gusta el papel.

Answer 4

En Blackberry OS 4.6, el límite de tamaño de la tienda RMS se ha aumentado a 512 Kb, pero esto no es de mucha ayuda ya que muchos dispositivos probablemente no serán compatibles con 4.6.La otra opción en Blackberry es la Tienda persistente, que tiene un límite de tamaño de registro de 64 kb pero no tiene límite en el tamaño de la tienda (aparte de los límites físicos del dispositivo).

Creo que carlos e izb tienen razón.

Answer 5

Es bastante simple, use JSR75 (FileConnection) y recuerde firmar su midlet con un certificado válido (confiable).

Answer 6

Para solo lectura, llego a tiempos aceptables (dentro de 10 segundos) al indexar un archivo de recursos.Tengo dos exportaciones de lista de precios CSV de ~800 KB.Las clases de programa y ambos archivos se comprimen en un JAR de 300 KB.

Al buscar, muestro un List y corre un dos Threads en segundo plano para llenarlo, por lo que los primeros resultados llegan bastante rápido y se pueden ver de inmediato.Primero implementé una búsqueda lineal simple, pero fue demasiado lenta (~2min).

Luego indexé el archivo (que está ordenado alfabéticamente) para encontrar el comienzo de cada letra.Ahora, antes de analizar línea por línea, primero InputStreamReader.skip() a la posición deseada, según la primera letra.Sospecho que el retraso se debe principalmente a la descompresión del recurso, por lo que dividir los recursos lo aceleraría aún más.No quiero hacer eso, para no perder la ventaja de una actualización sencilla.Los CSV se exportan sin ningún procesamiento previo.

Answer 7

Recién estoy comenzando a codificar para JavaME, pero tengo experiencia con versiones antiguas de PalmOS, donde todos los fragmentos de datos tienen un tamaño limitado, lo que requiere el diseño de estructuras de datos utilizando índices y compensaciones de registros.

Answer 8

Gracias a todos por los comentarios útiles.Al final, la solución más sencilla fue limitar la cantidad de datos almacenados, implementar un código que ajuste los datos según el tamaño del almacén y obtener datos del servidor a pedido si no están almacenados localmente.Es interesante que el límite aumente en OS 4.6; con un poco de suerte, mi código simplemente se ajustará por sí solo y almacenará más datos :)

Desarrollar una aplicación J2ME para Blackberry sin usar el compilador .cod limita un poco el uso de JSR 75 ya que no podemos firmar el archivo.Como señaló Carlos, este es un problema en cualquier plataforma y he tenido problemas similares al usar la parte PIM.El RMS parece ser increíblemente lento en la plataforma Blackberry, por lo que no estoy seguro de qué tan útil sería un sistema de archivos de inodo/árbol b en la parte superior, a menos que los datos se almacenen en caché en la memoria y se escriban en RMS en un subproceso en segundo plano de baja prioridad.