Introdução à arquitetura básica e princípios do RocksDB

rocksdb

O Flink fornece computação de estado baseada em fluxo. Além de fornecer recursos de processamento de fluxo de dados em tempo real, ele também precisa armazenar o estado gerado pelo cálculo.
Para atender aos requisitos de acesso de estado, três tipos de mecanismos de armazenamento de estado são fornecidos: memória, sistema flye e rocksdb.
O acesso à memória é eficiente e tem espaço limitado e baixa disponibilidade;
o sistema de arquivos fornece capacidade de persistência de estado, mas baixo desempenho de acesso;
rocksdb fornece recursos rápidos de gravação e persistência de dados.
Este artigo apresenta a arquitetura básica do projeto Rocksdb.

Introdução ao RocksDB

O Rocksdb é um mecanismo de armazenamento persistente kv de alto desempenho desenvolvido com base no Google LevelDB. Ele é incorporado ao programa como um componente de biblioteca e fornece otimização para aplicativos distribuídos em larga escala executados em ssd. RocksDB não fornece operações de alto nível, como backup, balanceamento de carga, instantâneos, etc., mas opta por fornecer suporte de ferramenta e entregar a implementação para aplicativos de camada superior. É esse alto grau de personalização que permite que o RocksDB seja adaptado a uma ampla gama de requisitos e cenários de carga de trabalho.

Arquitetura RocksDB

O RocksDB usa árvores Log-Structured Merge (LSM) como a estrutura básica de armazenamento de dados.

Componentes principais do RocksDB e diagrama de fluxo das operações de leitura, gravação e compactação

escreve

Quando os dados são gravados no RocksDB, eles são gravados primeiro no cache de gravação MemTable na memória e no Write-Ahead-Log (WAL) no disco.
Sempre que a quantidade de dados em cache na MemTable atingir o valor predefinido, MemTable e WAL serão convertidos em um estado imutável, e novos MemTable e WAL serão alocados para gravação subsequente e, em seguida, a mesma chave na MemTable imutável será mesclada e liberada para
o disco No arquivo Sorted String Table (ssTable) acima, e descarte os dados MemTable e WAL associados.

1. Para garantir a ordem dos dados e a eficiência da inserção e busca de dados (O(log n)), a MemTable é implementada com base em skipList.
2. O WAL é usado para recuperação de dados quando ocorre uma falha e pode ser desativado.
3. Além do bloco de dados (DataBlock), cada ssTable também possui um bloco de índice (IndexBlock) para pesquisa binária

Compactação

A árvore LSM tem vários níveis e cada nível consiste em várias ssTables. A ssTable mais recente é colocada no nível 0 (o nível mais alto) e a ssTable inferior é criada por meio da operação de compactação
. O tamanho total da ssTable de cada nível é determinado pelos parâmetros de configuração. Quando o tamanho dos dados do nível L exceder o valor predefinido, a SSTable do nível L será selecionada para mesclar com a parte sobreposta da SSTable do L Nível +1 Através deste processo, os dados gravados serão transferidos do Nível
0. Empurre gradualmente para a última camada. Com base nessas operações, a exclusão e a substituição de dados são concluídas, enquanto o espaço para dados e o desempenho de leitura são otimizados.

As operações de compactação são eficientes para E/S, porque a compactação pode ser executada em paralelo e os arquivos de dados são lidos e gravados em lotes.

As chaves em uma única ssTable no Nível-0 são ordenadas e há sobreposições de chaves em diferentes ssTables. As chaves na camada inferior são ordenadas em geral.

RocksDB suporta vários tipos de compactação:

Compactação nivelada: aprimorada com a migração do LevelDB, o tamanho de cada camada cresce exponencialmente de cima para baixo e a compactação começa quando a quantidade de dados atinge o tamanho especificado.
Compactação em Camadas: Também chamada de Compactação Universal, é semelhante à compactação atrasada usada pelo Apache Cassandra/HBase. A compactação começa quando o número de execuções/ssTables de uma determinada camada excede o valor predefinido ou a proporção do tamanho do banco de dados para o tamanho de a maior camada excede o
coeficiente predefinido.
Compactação FIFO Quando a quantidade de dados atingir o valor predefinido, os dados antigos serão descartados e a compactação leve será executada, que é usada principalmente em cenários de cache de memória.

A escolha do modo de compactação torna o RocksDB adequado para uma ampla variedade de cenários. Ao ajustar a estratégia de compactação, o RocksDB pode ser configurado para ser amigável para leitura, gravação ou extremamente amigável para trabalhos de cache especiais.
Os desenvolvedores precisam pesar as configurações do indicador de acordo com os cenários de uso. O algoritmo de compactação atrasada pode reduzir a amplificação de gravação e a taxa de transferência de gravação, mas o desempenho de leitura será afetado; enquanto a estratégia de compactação agressiva afetará o desempenho de gravação, mas a eficiência de leitura será maior.
Os serviços de processamento de log e fluxo podem usar regravação lateral, enquanto os serviços de banco de dados precisam equilibrar entre leitura e gravação.

Comparação do impacto de três principais estratégias de compressão em vários indicadores

leituras

Comece a pesquisar em MemTables e, em seguida, pesquise do nível 0 para a camada inferior até que a chave especificada seja encontrada, se não for encontrada, não existe.
A pesquisa em cada camada do LSM usa a pesquisa binária para pesquisar as ssTables de destino, depois usa o filtro Bloom para filtrar as sssTables pesquisadas desnecessárias e, finalmente,
encontra o valor da chave especificada na ssTable por pesquisa binária.

estrutura central

MemTable

MemTable é uma estrutura de dados na memória usada para manter os dados recém-gravados até que sejam liberados para o arquivo SST.
Ele serve para leituras e gravações: as novas gravações sempre inserem dados na memtable; enquanto os processos de leitura consultam a memtable primeiro porque os dados na memtable são mais recentes.

Quando uma memtable está cheia, ela se torna imutável e substituída por uma nova memtable. O thread em segundo plano atualizará o conteúdo da tabela de memória para o arquivo SST e, em seguida, destruirá a tabela de memória que foi colocada no disco.

memtable é implementado usando SkipList por padrão. Você também pode escolher HashLinkList, HashSkipList, Vector para acelerar algumas consultas.

As leituras e gravações de SkipList MemTable
, acesso aleatório e varreduras sequenciais fornecem bom desempenho geral e também fornecem alguns outros recursos úteis não suportados atualmente por outras implementações de tabela de memória, como inserções simultâneas e inserções com ocorrências
HashSkipList MemTable
HashSkipList organiza os dados em uma tabela de hash, cada balde de hash é um SkipList ordenado e a chave é a chave de prefixo interceptada pela chave original por meio de Options.prefix_extractor. É usado principalmente para reduzir o número de comparações durante a consulta. Geralmente usado em conjunto com o formato PlainTable SST para armazenar dados em RAMFS.
A maior limitação das memtables baseadas em hash é que a varredura em vários prefixos requer cópia e classificação, o que é muito lento e consome muita memória.

Cenários que acionam o Memtable para atualizar o disco:

O tamanho da tabela de memória excede ColumnFamilyOptions::write_buffer_size após a gravação
O uso da tabela de memória de todas as famílias de colunas excede DBOptions::db_write_buffer_size ou write_buffer_manager envia um sinal de atualização. A maior MemTable será descarregada
O tamanho do arquivo WAL excede DBOptions::max_total_wal_size

Bloquear Cache

Onde RocksDB armazena dados em cache na memória para leitura. Um objeto Cache pode ser compartilhado por várias instâncias do RocksDB no mesmo processo, e os usuários podem controlar a capacidade geral do cache.
O cache de bloco armazena blocos não compactados. Os usuários podem, opcionalmente, configurar um cache de bloco secundário que armazena blocos compactados. Uma leitura buscará o bloco de dados primeiro do cache de bloco não compactado e, em seguida, do cache de bloco compactado. Se estiver usando Direct-IO , o cache de bloco compactado pode substituir o cache de página do sistema operacional.

Block Cache tem duas implementações de cache, ou seja, LRUCache e ClockCache. Ambos os tipos de cache usam sharding para aliviar a contenção de bloqueio. A capacidade é alocada igualmente para cada estilhaço e os estilhaços não compartilham a capacidade. Por padrão, cada cache é dividido em até 64 fragmentos e a capacidade de cada fragmento não é inferior a 512k bytes.

LRUCache: A implementação de cache padrão. Usa um cache baseado em LRU de 8 MB. Cada fragmento do cache mantém sua própria lista de LRU e sua própria tabela de hash para pesquisas. A sincronização é obtida por meio do mutex de cada estilhaço, e tanto a pesquisa quanto a inserção precisam bloquear o estilhaço.

Em casos raros, ao ler ou iterar em blocos e o tamanho total fixo do bloco exceder o limite, o tamanho do cache pode ser maior que a capacidade. Se o host não tiver memória suficiente, isso pode levar a erros inesperados de OOM, que podem causar a falha do banco de dados

ClockCache: ClockCache implementa o algoritmo CLOCK. Cada fatia do cache do relógio mantém uma lista circular de entradas do cache. O manipulador de relógio percorre a lista round-robin, procurando por entradas não fixadas para remover, mas também dando a cada entrada uma segunda chance de permanecer no cache se tiver sido usada desde a última verificação.

ClockCache ainda não está estável, não recomendado

Gerenciador de buffer de gravação

O Write Buffer Manager é usado para controlar o uso total da tabela de memória de várias famílias de colunas ou várias instâncias de banco de dados.
Como usar: O usuário cria um objeto gerenciador de buffer de gravação e passa o objeto para a família de colunas ou instância de banco de dados que precisa controlar a memória.

Existem duas restrições:

1. Limite o uso total de memória de memtables

Acionar uma dessas condições acionará uma operação de limpeza na família de colunas da instância:

Se o uso de tabelas de memória ativas exceder 90% do limite
Quando a memória total excede o limite e o uso de mamtables ativos excede 50% do limite.

2. O uso de memória do memtable é transferido para o cache de bloco

Na maioria dos casos, os blocos realmente usados no cache do bloco são muito menores do que aqueles armazenados no cache do bloco, portanto, quando o usuário habilitar esta função, a capacidade do cache do bloco cobrirá o uso de memória do cache do bloco e da tabela de memória.
Se o usuário ativar cache_index_and_filter_blocks ao mesmo tempo, o uso de memória das três principais áreas de memória do RocksDB (cache de índice e filtro, memtables e cache de bloco) estará todo no cache de bloco.

formato de arquivo SST

BlockBasedTable é o formato de tabela padrão para SSTables.

<beginning_of_file>
[data block 1]
[data block 2]
...
[data block N]
[meta block 1: filter block]                  (see section: "filter" Meta Block)
[meta block 2: index block]
[meta block 3: compression dictionary block]  (see section: "compression dictionary" Meta Block)
[meta block 4: range deletion block]          (see section: "range deletion" Meta Block)
[meta block 5: stats block]                   (see section: "properties" Meta Block)
...
[meta block K: future extended block]  (we may add more meta blocks in the future)
[metaindex block]
[Footer]                               (fixed size; starts at file_size - sizeof(Footer))
<end_of_file>

Bloco de dados DataBlock: A sequência de pares chave-valor é organizada de acordo com as regras de classificação e dividida em uma série de blocos de dados (blocos de dados). Esses blocos são organizados um após o outro no início do arquivo e cada bloco de dados é opcionalmente compactado.

Bloco de metadados MetaBlock: seguido por um bloco de dados é um grupo de blocos de metadados (bloco de meta), os blocos de metadados incluem: bloco de filtro (bloco de filtro), bloco de índice (bloco de índice), bloco de dicionário de compactação (bloco de dicionário de compactação), intervalo Excluir bloco (bloco de exclusão de intervalo), bloco de atributo (bloco de propriedades).

Meta índice 3 blocos MetaIndexBlock: O bloco meta índice contém uma tabela de mapeamento apontando para cada bloco meta, a chave é o nome do bloco meta, o valor é o ponteiro para o bloco meta e o ponteiro aponta para o bloco de dados por meio do deslocamento e tamanho.

Rodapé: o final do arquivo é um rodapé de comprimento fixo. Incluindo um ponteiro para o bloco metaindex, um ponteiro para o bloco de índice e um número mágico.

Tipos específicos de Meta Block:

Bloco de Índice Bloco de Índice

O bloco de índice é usado para localizar o bloco de dados que contém a chave especificada. É uma estrutura de dados baseada em pesquisa binária. Um arquivo pode conter um único bloco de índice ou um conjunto de blocos de índice particionados , dependendo da configuração de uso. Ou seja, existem dois métodos de índice: índice global e índice de partição.

Bloco de filtro Bloco de filtro

Filtros globais e filtros de partição são implementados por filtros Bloom

Filtro Global Filtro Completo: Neste filtro, há apenas um bloco de filtro para todo o arquivo SST.
Filtro particionado: O filtro completo é dividido em vários blocos de subfiltros e, no topo desses blocos, há um bloco de índice para mapear as chaves para os blocos de subfiltros correspondentes.

Bloco de Dicionário de Compressão Bloco de Dicionário de Compressão

Contém um dicionário usado para preparar a biblioteca de compactação antes de compactar/descompactar cada bloco.

Bloco de exclusão de intervalo Bloco de exclusão de intervalo

O bloco de exclusão de intervalo contém o intervalo de exclusão na chave e o número de série no arquivo. Quando a solicitação de leitura é enviada para sst, pode-se julgar a partir da área especificada em sst se a chave está dentro do intervalo de deleterange e, se existir, retornará diretamente NotFound. Há também uma área na memtable que executa a mesma função.
Os dados obsoletos da lápide serão apagados durante a compactação ou descarga.

Bloco de propriedades Bloco de propriedades

Contém informações de atributo.
Formato do bloco de estatísticas:

 [prop1] 每个property都是一个键值对    
 [prop2]
 ...
 [propN]

As informações do atributo são garantidamente sequenciais e não repetidas. Por padrão, as seguintes informações são incluídas:

 data size               // data block总大小
 index size              // index block总大小
 filter size             // filter block总大小
 raw key size            // 所有key的原始大小
 raw value size          // 所有value的原始大小
 number of entries
 number of data blocks

otimização

O processo de evolução da otimização do RocksDB:

Otimizando a amplificação de gravação: Log-Structure Merge Tree
Ampliação do espaço: operação de compactação
Reduza a carga da CPU causada pela compactação: otimize o lsm, controle a granularidade da frequência de compactação
cpu, equilíbrio de recursos ssd: armazenamento dividido, uso de armazenamento remoto (hdfs, s3, oss)

amplificação de gravação

O RocksDB concentrou-se desde o início na redução da amplificação de gravação, salvando os ciclos de apagamento do flash. A amplificação de gravação ocorre principalmente em dois níveis:

1. A amplificação de gravação introduzida pelo próprio SSD, a faixa de amplificação é de 1,1 a 3;

2. O software de armazenamento e banco de dados também gerará amplificação de gravação, às vezes até 100 (por exemplo: quando uma alteração de 100 bytes causa a gravação de uma página de 4 kB/8 KB/16 KB)

A compactação nivelada geralmente traz amplificação de gravação entre 10-30, inferior às árvores B na maioria dos casos, mas ainda muito alta para aplicativos sensíveis à gravação.
Portanto, com a compactação em camadas, o desempenho de leitura é sacrificado para reduzir a amplificação de gravação entre 4 e 10. Cenários com altas taxas de gravação de dados usam estratégias de compactação, como compactação em camadas, para reduzir a amplificação de gravação, e
cenários com baixas taxas de gravação usam estratégias, como compactação nivelada, para reduzir o uso de espaço e melhorar a eficiência de leitura.

Efeito da amplificação de gravação na taxa de gravação

ampliação do espaço

A observação subseqüente da maioria dos programas mostra que o ciclo de gravação e a sobrecarga de gravação da memória flash não são restritas e a carga de E/S é muito menor do que a capacidade que o SSD pode fornecer.
A utilização do espaço se torna mais importante do que a amplificação de gravação, então comece a otimizar o espaço em disco.

Graças ao layout de dados não fragmentados da estrutura de árvores LSM, ele também pode desempenhar um papel eficaz na otimização do espaço em disco. A compactação nivelada pode ser otimizada reduzindo dados sujos (excluir/substituir) em árvores LSM.
Daí a nova estratégia de compressão de dados:

Compactação nivelada dinâmica: o tamanho dos dados de cada camada é ajustado dinamicamente de acordo com o tamanho real da camada anterior, obtendo uma eficiência de espaço melhor e mais estável do que a compactação nivelada

Conforme mostrado nos dados de teste na figura inferior direita, a Compactação nivelada usa 25,6% do espaço, enquanto a estratégia de Compactação nivelada dinâmica precisa apenas de 12,4%.
Em casos extremos, o uso do disco da Compactação nivelada pode chegar a 90%, enquanto a Compactação nivelada dinâmica ainda pode permanecer em uma faixa relativamente estável.

Uso de espaço e tamanho de dados de duas estratégias de compactação a uma taxa de gravação constante de 2 MB/s

utilização da CPU

Reduzir a carga da CPU pode melhorar o desempenho de um pequeno número de aplicativos vinculados à CPU. Mais importante, reduzir a sobrecarga da CPU pode economizar custos de hardware.
As primeiras formas de reduzir a sobrecarga da CPU incluem: introdução de filtros Bloom de prefixo, aplicação de filtros Bloom antes de consultas de índice, otimização de filtros Bloom

Adapte-se à nova tecnologia de hardware

SSD: Melhorias na arquitetura relacionadas ao SSD podem afetar o RocksDB. Por exemplo, SSDs de canal aberto, multi-stream e SSDZNS prometem melhorar a latência de consulta e economizar ciclos de apagamento de flash.
Como a maioria dos softwares que usam o RocksDB é limitada pelo espaço em disco, em vez de ciclos de apagamento e latência, essa nova alteração técnica melhorará apenas o desempenho de um pequeno número de softwares que usam o RocksDB.
A adaptação do RocksDB diretamente às novas tecnologias de hardware desafiará a experiência consistente com o RocksDB. No momento, a comunidade não tem nenhum plano de pesquisa e otimização em computação de armazenamento.

Armazenamento desagregado (remoto): O armazenamento remoto é uma prioridade atual. A otimização atual é predefinir a memória flash no ambiente local, mas a rede atual permitiu suportar mais E/S remotas.
Portanto, para mais e mais programas, o desempenho do RocksDB para suportar armazenamento remoto está se tornando cada vez mais importante. O armazenamento remoto pode ser configurado sob demanda, facilitando a reutilização de recursos de CPU e SSD.
As otimizações atuais para armazenamento separado incluem: integração e paralelização de E/S para otimizar a latência de E/S, passar requisitos de QoS para o sistema subjacente e relatar informações de análise

Memória de classe de armazenamento (SCM: memória de classe de armazenamento, que tem as vantagens da memória e as características do armazenamento. Atualmente, existem várias ideias de aplicativos:

Como uma expansão de memória, o SCM envolve como projetar uma estrutura de dados que se encaixe nos dois tipos de armazenamento
O SCM é usado como o armazenamento principal do banco de dados
Aplicar SCM ao WAL

Otimização do uso do Rocksdb em grandes sistemas

interface de chave-valor

Quase qualquer carga de trabalho de armazenamento pode ser atendida por um armazenamento de dados com uma API KV. A interface KV é genérica.
Tanto a chave quanto o valor são compostos de matrizes de bytes de comprimento variável. O aplicativo é responsável por analisar e interpretar a chave e o valor e pode escolher livremente quais informações compactar no valor da chave, incluindo o esquema de codificação.
Outro benefício da interface KV é a portabilidade, facilitando a migração de dados entre sistemas chave-valor.

No entanto, a interface KV pode limitar o desempenho de alguns programas. Por exemplo, construir o controle de simultaneidade fora do RocksDB é difícil para obter um desempenho eficiente, especialmente em cenários que precisam oferecer suporte a confirmação de duas fases, e alguns dados precisam ser persistidos antes de confirmar uma transação, portanto, o RocksDB fornece suporte a transações.

versão e carimbo de data/hora

O controle de versão dos dados é muito importante. As informações de versão são a primeira coisa no RocksDB para oferecer suporte adequado a recursos como controle de simultaneidade de várias versões (MVCC), leituras pontuais, etc.
O RocksDB também precisa oferecer suporte ao acesso eficiente a diferentes versões.

Atualmente, o RocksDB usa internamente números de sequência de 56 bits para identificar pares chave-valor de diferentes versões. Os números de sequência são gerados pelo RocksDB e são incrementados cada vez que um cliente escreve, para que todos os dados estejam em uma ordem lógica.
O RocksDB permite que os aplicativos tirem instantâneos do banco de dados. O RocksDB garante que todos os pares chave-valor existentes no momento do instantâneo persistirão até que o programa libere explicitamente o instantâneo. Portanto, vários pares chave-valor com a mesma chave podem coexistir, distinguidos por seus números de sequência.

Esse tipo de controle de versão também tem limitações e não pode atender aos requisitos de muitos programas.

Como não há API para especificar um ponto no tempo, o RocksDB não oferece suporte à criação de instantâneos anteriores. Além disso, o suporte a leituras pontuais é ineficiente
Cada instância do RocksDB mantém seu próprio número de sequência e os instantâneos só podem ser obtidos por instância. A complexidade do controle de versão do programa que leva ao aumento da fragmentação de vários dados. É basicamente impossível fornecer versões de dados que são lidas de forma consistente em estilhaços.

Os aplicativos podem contornar essa limitação codificando o erro de tempo de gravação na chave/valor. No entanto, esse método levará à degradação do desempenho. A codificação na chave sacrificará o desempenho da pesquisa de ponto (a chave se torna maior); a codificação no valor
sacrificará o desempenho da gravação fora de ordem da mesma chave , e complicam a leitura da chave da versão antiga (valor de decodificação compara carimbo de data/hora). Essas limitações podem ser melhor resolvidas permitindo que o aplicativo especifique o carimbo de data/hora, e o aplicativo pode marcar os dados com um carimbo de data/hora global além da chave/valor.

gestão de recursos

Para serviços de dados distribuídos em grande escala, os dados geralmente são divididos em vários fragmentos e distribuídos em vários nós para armazenamento. Uma instância RocksDB separada é usada para atender a cada estilhaço.
Isso significa que haverá muitas instâncias do RocksDB em execução no host. Todas essas instâncias podem ser executadas em um único espaço de endereço ou cada uma pode ser executada em seu próprio espaço de endereço.

1. RocksDB precisa gerenciar recursos de forma eficaz para garantir que eles sejam usados de forma eficaz. Ao executar no modo de processo único, ele precisa ter a capacidade de limitar os recursos globais. Os recursos incluem:

Memória para buffer de gravação, cache de bloco
Largura de banda de E/S compactada
rosca para compressão
recursos de disco
Taxa de exclusão de arquivos
O RocksDB permite que os aplicativos criem um ou mais controladores de recursos para cada tipo de recurso, suportando a priorização entre as instâncias do RocksDB para garantir que os recursos recebam prioridade para as instâncias que mais precisam.

2. No modo de usar várias instâncias, haverá problemas em usar threads agrupados sem thread sem restrição. Muitos threads aumentam a probabilidade de carga da CPU, causam sobrecarga excessiva de troca de contexto e tornam a depuração extremamente difícil e aumentam a carga de E/S. RocksDB é melhor usar um pool de threads que pode facilmente limitar o tamanho e o uso de recursos.

3. Cada fragmento possui apenas informações locais. Quando a instância do RocksDB é executada em um processo separado, o gerenciamento de recursos globais é mais desafiador. Existem duas estratégias de enfrentamento:

Use uma estratégia conservadora de recursos: como reduzir a frequência de compactação.A desvantagem dessa estratégia é que os recursos globais podem não ser totalmente utilizados;
As informações de uso de recursos são compartilhadas entre as instâncias e ajustadas de acordo em uma tentativa de otimizar o uso de recursos de maneira mais global. Isso requer mais trabalho para melhorar o gerenciamento de recursos em todo o host no RocksDB

Processamento WAL

Os bancos de dados tradicionais tendem a forçar um log write-ahead (WAL) em cada operação de gravação para garantir a durabilidade. E sistemas de armazenamento distribuído em larga escala geralmente replicam dados para desempenho e disponibilidade, e possuem várias garantias de consistência.

Portanto, é útil fornecer opções para ajustar o comportamento de sincronização do WAL para atender às necessidades de diferentes aplicativos.
Especificamente, o RocksDB introduz modos de operação WAL diferenciados: (1) gravações WAL síncronas (2) gravações WAL em buffer (3) nenhuma gravação WAL. Para o processamento do WAL em buffer, o WAL é gravado periodicamente no disco com baixa prioridade em segundo plano para não afetar a latência do tráfego do RocksDB

Limite a velocidade de exclusão de arquivos

O RocksDB geralmente interage com o dispositivo de armazenamento subjacente por meio do sistema de arquivos, e o sistema de arquivos está ciente da memória flash (SSD). A exclusão de arquivos no ssd pode acionar a coleta de lixo interna do SSD, causando movimentação massiva de dados e impactando negativamente a latência de E/S.
Limitação da taxa de exclusão de arquivo introduzida para evitar que vários arquivos sejam excluídos ao mesmo tempo (durante a compactação)

Formato de dados compatível

É importante que os dados no disco permaneçam compatíveis com versões anteriores e futuras entre as diferentes versões de software.

gerenciamento de configurações

O RocksDB é altamente configurável para que os aplicativos possam ser otimizados para suas cargas de trabalho. No entanto, o gerenciamento de configuração é um desafio:
a configuração inicial é herdada do LevelD e um grande número de configurações é associado ao código. RocksDB ajustou e atualizou seu método de configuração.

controle de qualidade

P: Por que MemTable usa uma tabela de salto em vez de uma árvore balanceada?
R: 1. A implementação da tabela de salto é mais simples que a da árvore; 2. Ocupa menos espaço, exceto os dados, todo o resto é um ponteiro; 3. Os dados são ordenados, o que é conveniente para consulta de intervalo .
P: Por que o MySQL usa árvores B+ sem pular tabelas?
R: 1. As páginas da árvore B+ correspondem naturalmente aos blocos do disco, o que é mais amigável ao disco; enquanto a tabela de salto é implementada com base na lista encadeada, a distribuição física dos dados é relativamente dispersa e não é amigável para E/S 2. A tabela de salto não pode implementar índice clusterizado e
índice de cobertura 3. A dispersão de dados não pode utilizar a pré-leitura do disco, que não é amigável para o cache do disco
. Resumindo, o design da tabela de salto é simples, não se ajusta às características do disco e é adequado para uso de memória.