java - programacion - La mejor práctica para almacenar grandes cantidades de datos con J2ME
java me sdk linux (8)
Creo que el enfoque más flexible sería implementar su propio sistema de archivos sobre el RMS. Puede manejar los registros RMS de forma similar a los bloques en un disco duro y usar una estructura de inode o similar para distribuir archivos lógicos en varios bloques. Recomendaría implementar una interfaz de bytes o orientada a flujos en la parte superior de los bloques, y luego posiblemente hacer otra capa API además de la escritura de estructuras de datos especiales (o simplemente hacer que los objetos sean serializables a la secuencia 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 puede encontrar otros recursos en línea si no le gusta el papel.
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 me quedo atascado en el Sistema de administración de registros (RMS), que permite múltiples tiendas de discos, pero cada una tiene un tamaño limitado. Mi plataforma de destino inicial, Blackberry, limita cada uno a 64 KB.
Me pregunto si alguien más tuvo que abordar el problema de almacenar una gran cantidad de datos en el RMS y cómo lo lograron. 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.
Hay muchos tipos diferentes de datos almacenados, pero solo un conjunto en particular excederá el límite de 64 KB.
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 puntaje alto, o lo que sea) cantidades no grandes.
Puede encontrar 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 inusualmente lentos al eliminar grandes cantidades de datos de la tienda.
Su mejor opción es usar JSR-75 en su lugar, donde esté disponible, y cree su propia interfaz de tienda de archivos que vuelva a RMS si no se admite nada mejor.
Lamentablemente, cuando se trata de JavaME, a menudo se ve obligado a escribir variantes de su código específicas para cada dispositivo.
Para cualquier cosa que supere algunos kilobytes, necesita usar JSR 75 o un servidor remoto. Los registros RMS son extremadamente limitados en tamaño y velocidad, incluso en algunos terminales de gama más alta. Si necesita manipular 1MB de datos en J2ME, la única manera confiable y portátil es almacenarlo en la red. La clase HttpConnection y los métodos GET y POST siempre son compatibles.
En los teléfonos compatibles con JSR 75 FileConnection puede ser una alternativa válida, pero sin la firma de código es una experiencia de pesadilla para el usuario. Casi todas las llamadas a API invocarán un mensaje de seguridad sin opción de permiso general. Las empresas que implementan aplicaciones con JSR 75 generalmente necesitan media docena de binarios para cada puerto solo para cubrir una pequeña parte de los posibles certificados. Y esto es solo para los certificados del fabricante; algunos teléfonos solo tienen certificados de operador bloqueado.
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 es probable que muchos dispositivos no tengan soporte para 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 (que no sean los límites físicos del dispositivo).
Creo que Carlos e izb tienen razón.
Es bastante simple, use JSR75 (FileConnection) y recuerde firmar su midlet con un certificado válido (de confianza).
Estoy empezando a codificar JavaME, pero tengo experiencia con las versiones anteriores de PalmOS, donde todos los fragmentos de datos tienen un tamaño limitado, lo que requiere el diseño de estructuras de datos mediante el uso de índices y compensaciones de registros.
Gracias a todos por los comentarios útiles. Al final, la solución más simple fue limitar la cantidad de datos almacenados, implementar código que ajusta los datos de acuerdo con el tamaño de la tienda y obtener datos del servidor a pedido si no se almacena localmente. Es interesante que el límite se incremente en OS 4.6, con algo de suerte mi código simplemente se ajustará solo y almacenará más datos :)
El desarrollo de una aplicación J2ME para Blackberry sin utilizar el compilador .cod limita 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 con la parte de PIM. El RMS parece ser increíblemente lento en la plataforma Blackberry, así que no estoy seguro de cuán útil sería un sistema de archivos inode / b-tree en la parte superior, a menos que los datos estuvieran guardados en la memoria y escritos en RMS en una cadena de baja prioridad.
Solo para lectura, estoy llegando a tiempos aceptables (dentro de los 10 s), indexando un archivo de recursos. Tengo dos exportaciones de lista de precios de ~ 800KB CSV. Las clases de programa y ambos archivos se comprimen en un JAR de 300 KB.
Al buscar, muestro una List y ejecuto dos Thread en segundo plano para completarla, de modo que los primeros resultados llegan bastante rápido y se pueden ver de inmediato. Primero implementé una búsqueda lineal simple, pero eso fue demasiado lento (~ 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 la demora proviene principalmente de descomprimir el recurso, por lo que dividir los recursos lo aceleraría aún más. No quiero hacer eso, no perder la ventaja de una actualización fácil. CSV se exportan sin ningún preprocesamiento.