Melhores práticas para armazenar grandes quantidades de dados com J2ME

Question

Estou desenvolvendo uma aplicação J2ME que possui uma grande quantidade de dados para armazenar no dispositivo (na região de 1 MB, mas variável).Não posso confiar no sistema de arquivos, então estou preso ao Record Management System (RMS), que permite vários armazenamentos de registros, mas cada um tem um tamanho limitado.Minha plataforma alvo inicial, Blackberry, limita cada uma a 64 KB.

Estou me perguntando se alguém mais teve que resolver o problema de armazenar uma grande quantidade de dados no RMS e como eles conseguiram isso.Estou pensando em calcular o tamanho dos registros e dividir um conjunto de dados em vários armazenamentos, se for muito grande, mas isso adiciona muita complexidade para mantê-lo intacto.

Existem muitos tipos diferentes de dados armazenados, mas apenas um conjunto em particular excederá o limite de 64 KB.

Answer 1

Para qualquer coisa além de alguns kilobytes, você precisa usar o JSR 75 ou um servidor remoto.Os registros RMS são extremamente limitados em tamanho e velocidade, mesmo em alguns aparelhos de última geração.Se você precisar manipular 1 MB de dados no J2ME, a única maneira confiável e portátil é armazená-los na rede.A classe HttpConnection e os métodos GET e POST são sempre suportados.

Nos aparelhos que suportam JSR 75 FileConnection, pode ser uma alternativa válida, mas sem assinatura de código é um pesadelo para a experiência do usuário.Quase todas as chamadas de API invocarão um prompt de segurança sem opção de permissão geral.As empresas que implantam aplicativos com JSR 75 geralmente precisam de meia dúzia de binários para cada porta apenas para cobrir uma pequena parte dos certificados possíveis.E isso é apenas para os certificados do fabricante;alguns aparelhos possuem apenas certificados bloqueados pela operadora.

Answer 2

O desempenho e a implementação do RMS variam muito entre os dispositivos; portanto, se a portabilidade da plataforma for um problema, você poderá descobrir que seu código funciona bem em alguns dispositivos e não em outros.O RMS foi projetado para armazenar pequenas quantidades de dados (tabelas de pontuação alta ou qualquer outra coisa), e não grandes quantidades.

Você pode descobrir que algumas plataformas são mais rápidas com arquivos armazenados em vários armazenamentos de discos.Alguns são mais rápidos com vários registros em um armazenamento.Muitos são adequados para armazenamento, mas tornam-se inutilmente lentos ao excluir grandes quantidades de dados do armazenamento.

Sua melhor aposta é usar o JSR-75, quando disponível, e criar sua própria interface de armazenamento de arquivos que retorne ao RMS se nada melhor for suportado.

Infelizmente, quando se trata de JavaME, muitas vezes você é levado a escrever variantes de seu código específicas para dispositivos.

Answer 3

Acho que a abordagem mais flexível seria implementar seu próprio sistema de arquivos no RMS.Você pode manipular os registros RMS de maneira semelhante aos blocos em um disco rígido e usar um estrutura do inode ou similar para espalhar arquivos lógicos em vários blocos.Eu recomendaria implementar uma interface orientada a bytes ou fluxo sobre os blocos e, possivelmente, criar outra camada de API além disso para escrever estruturas de dados especiais (ou simplesmente tornar seus objetos serializáveis ​​para o fluxo de dados).

O livro clássico de Tanenbaum sobre sistemas operacionais aborda como implementar um sistema de arquivos simples, mas tenho certeza de que você poderá encontrar outros recursos online se não gostar de papel.

Answer 4

No Blackberry OS 4.6, o limite de tamanho do armazenamento RMS foi aumentado para 512 KB, mas isso não ajuda muito, pois muitos dispositivos provavelmente não terão suporte para 4.6.A outra opção no Blackberry é a Loja Persistente que tem um limite de tamanho de registro de 64kb, mas não tem limite de tamanho da loja (além dos limites físicos do dispositivo).

Acho que Carlos e Izb estão certos.

Answer 5

É bem simples, use JSR75 (FileConnection) e lembre-se de assinar seu midlet com um certificado válido (confiável).

Answer 6

Para somente leitura, estou chegando em horários aceitáveis ​​(dentro de 10s), indexando um arquivo de recursos.Tenho duas exportações de lista de preços CSV de aproximadamente 800 KB.As classes do programa e ambos os arquivos são compactados em um JAR de 300 KB.

Na pesquisa eu exibo um List e execute um dois Threadestá em segundo plano para preenchê-lo, então os primeiros resultados aparecem rapidamente e podem ser visualizados imediatamente.Implementei primeiro uma pesquisa linear simples, mas foi muito lenta (cerca de 2 minutos).

Em seguida, indexei o arquivo (que é classificado em ordem alfabética) para encontrar o início de cada letra.Agora, antes de analisar linha por linha, primeiro InputStreamReader.skip() para a posição desejada, com base na primeira letra.Suspeito que o atraso vem principalmente da descompactação do recurso, portanto, a divisão dos recursos aceleraria ainda mais.Não quero fazer isso, para não perder a vantagem da atualização fácil.CSV são exportados sem qualquer pré-processamento.

Answer 7

Estou apenas começando a codificar para JavaME, mas tenho experiência com versões antigas do PalmOS, onde todos os blocos de dados são limitados em tamanho, exigindo o design de estruturas de dados usando índices de registro e deslocamentos.

Answer 8

Obrigado a todos pelos comentários úteis.No final, a solução mais simples foi limitar a quantidade de dados armazenados, implementando um código que ajusta os dados de acordo com o tamanho do armazenamento e buscando dados do servidor sob demanda, caso não estejam armazenados localmente.É interessante que o limite tenha aumentado no OS 4.6, com alguma sorte meu código simplesmente se ajustará sozinho e armazenará mais dados :)

Desenvolver um aplicativo J2ME para Blackberry sem usar o compilador .cod limita um pouco o uso do JSR 75, já que não podemos assinar o arquivo.Conforme apontado por Carlos, este é um problema em qualquer plataforma e tive problemas semelhantes ao usar a parte PIM dela.O RMS parece ser incrivelmente lento na plataforma Blackberry, então não tenho certeza de quão útil seria um sistema de arquivos inode/b-tree no topo, a menos que os dados fossem armazenados em cache na memória e gravados no RMS em um thread de segundo plano de baixa prioridade.