Isto parece uma pergunta longa por causa de todo o contexto. Há duas perguntas dentro do romance abaixo. Obrigado por ler e fornecer assistência.

Situaçã

Estou trabalhando em uma implementação de armazenamento de dados escalável que pode oferecer suporte ao trabalho com arquivos de dados de alguns KB a um TB ou mais em um sistema de 32 ou 64 bit

O armazenamento de dados utiliza um design Copy-on-Write; sempre anexando dados novos ou modificados ao final do arquivo de dados e nunca fazendo edições no local dos dados existentes.

O sistema pode hospedar um ou mais bancos de dados; cada um representado por um arquivo em disco.

Os detalhes da implementação não são importantes; o único detalhe importante é que preciso anexar constantemente ao arquivo e aumentá-lo de KB, MB, GB para TB e, ao mesmo tempo, ignorar aleatoriamente o arquivo para que as operações de leitura atendam às solicitações do client

Primeiros Pensamentos

À primeira vista, eu sabia que queria usar arquivos mapeados na memória para poder sobrecarregar o gerenciamento eficiente do estado dos dados na memória no sistema operacional host e fora do meu códig

Então todo o meu código precisa se preocupar em serializar as operações de anexar ao arquivo durante a gravação e permitir que qualquer número de leitores simultâneos procure no arquivo para responder às solicitaçõe

Projet

Como os arquivos de dados individuais podem crescer além do limite de 2 GB de um MappedByteBuffer, espero que meu design tenha que incluir uma camada de abstração que aceite um deslocamento de gravação e o converta em um deslocamento dentro de um segmento específico de 2 G

Por enquanto, tudo bem..

Problemas

oi aqui que comecei a me desligar e acho que usar um design diferente (proposto abaixo) pode ser a melhor maneira de fazer iss

De ler 20 perguntas relacionadas ao "mapeamento de memória" aqui no SO, parece que as chamadas mmap são sensíveis a querer execuções contíguas de memória quando alocadas. Assim, por exemplo, em um sistema operacional host de 32 bits, se eu tentar mapear um arquivo de 2 GB, devido à fragmentação da memória, minhas chances são pequenas de que o mapeamento seja bem-sucedido e, em vez disso, devo usar algo como uma série de mapeamentos de 128 MB para obter um inteiro arquivo em

Quando penso nesse design, mesmo usando tamanhos de mmap de 1024 MB, para um DBMS hospedando alguns bancos de dados enormes, todos representados por arquivos de 1 TB, agora tenhomilhare de regiões mapeadas na memória na memória e em meus próprios testes no Windows 7, tentando criar algumas centenas de mmaps em um arquivo com vários GB, não apenas encontrei exceções, mas na verdade fiz com que a JVM falhasse sempre que tentei alocar demais e, em um caso, o vídeo na minha máquina Windows 7 foi cortado e reinicializado com um pop-up de erro do sistema operacional que eu nunca tinha visto antes.

Independentemente do argumento de "você provavelmente nunca manipulará arquivos tão grandes" ou "este é um exemplo artificial", o fato de eu poder codificar algo assim com esses tipos de efeitos colaterais coloca meu alarme interno em alerta máximo e fez considerar um impl alternativo (abaixo).

lém disso, meu entendimento dos arquivos mapeados na memória é que eu preciso recriar o mapeamento toda vez que o arquivo for aumentado. Portanto, no caso desse arquivo que é apenas anexado no design, ele literalmente cresce constantement

Eu posso combater isso, em certa medida, aumentando o arquivo em pedaços (digamos 8 MB de cada vez) e recriar apenas o mapeamento a cada 8 MB, mas a necessidade de recriar constantemente esses mapeamentos me deixa nervoso, especialmente sem explícitosecurso @unmap suportado em Java.

Questão 1 de

De todas as minhas descobertas até esse ponto, eu descartaria os arquivos mapeados na memória como uma boa solução para soluções principalmente pesadas para leitura ou soluções somente leitura, mas não soluções pesadas para gravação, dada a necessidade de recriar o mapeamento constantemente .

Mas, em seguida, olho para a paisagem ao meu redor com soluções como o MongoDB que abraça arquivos mapeados em memória em todo o lugar e sinto que estou perdendo algum componente principal aqui (eu sei que ele se aloca em algo como extensões de 2 GB por vez, então, imagino que eles estejam trabalhando com o re-mapeamento de custos com essa lógica e ajudando a manter execuções seqüenciais no disco

Neste momento, não sei se o problema é a falta de uma operação unmap do Java que torna isso muito mais perigoso e inadequado para meus usos ou se meu entendimento está incorreto e alguém pode me apontar para o nort

Alternative Design

Um design alternativo ao mapeado em memória proposto acima, com o qual eu irei se meu entendimento do mmap estiver correto é o seguinte:

Definira ByteBuffer direto de um tamanho configurável razoável (2, 4, 8, 16, 32, 64, 128 KB), tornando-o facilmente compatível com qualquer plataforma host (não precisa se preocupar com o próprio DBMS causando cenários de debulhamento) e usando o FileChannel original , execute leituras de deslocamento específico do arquivo 1 parte da capacidade do buffer de cada vez, abandonando completamente os arquivos mapeados na memóri

desvantagem é que agora meu código precisa se preocupar com coisas como "eu li o suficiente do arquivo para carregar o registro completo?&quo

Outra desvantagem é que não consigo usar a lógica da memória virtual do sistema operacional, permitindo que ele mantenha automaticamente mais dados "quentes" na memória para mim; em vez disso, só espero que a lógica do cache de arquivos empregada pelo sistema operacional seja grande o suficiente para fazer algo útil para mim aqu

Question # 2 de 2

Eu estava esperando obter uma confirmação do meu entendimento de tudo isso.

or exemplo, talvez o cache de arquivos seja fantástico, pois nos dois casos (memória mapeada ou leituras diretas), o sistema operacional host manterá o máximo de meus dados disponíveis, e a diferença de desempenho para arquivos grandes é insignificant

Ou talvez minha compreensão dos requisitos confidenciais para arquivos mapeados na memória (memória contígua) esteja incorreta e eu possa ignorar tudo iss