Estou voltando a retomar o InceptionDB após dois meses focando o tempo livre que me resta em tirar adiante o flowtest.io (quero pensar que será o serviço que vai revolucionar a forma de testar APIs).

Apesar do tempo que passou, lembro com total clareza que estava trabalhando em otimizar o desempenho, tinha a meta psicológica de superar o milhão de inserts por segundo (em um único nó). O milhão não foi difícil de superar, mas com a IA eu estava empenhado em passar o milhão folgadamente. Na verdade, estava empenhado em levá-lo um pouco além do absurdo e do necessário, explorando várias alternativas e atacando as diferentes camadas de abstração do Inception.

Voltei a repetir os últimos testes e o resultado é tão selvagem que parece que algo está errado. Seleciono o primeiro benchmark: INSERT, executo e quase ao mesmo tempo termina. Tem que estar errado! O log é claro: inseriu 1 milhão em menos de 200ms, mas eu não acredito, penso que devo ter deixado a persistência desativada e estará trabalhando só em memória, ou que não há controle de concorrência e os dados estão se sobrepondo, ou que contou os dados enviados mas o servidor os jogou no /dev/null.

sent: 1000000 took: 182.928406ms Throughput: 5466619.55 rows/sec Closing 'col-1779494946505865611'... http: Server closed

Desconfio, posso pensar em mil motivos a mais, mas coloco um break point logo antes de eliminar a base de dados e volto a executar. Resultado quase idêntico apesar de estar depurando, mas agora tenho isso: /tmp/inceptiondb_bench_811457574/col-1779494946505865611 e não está vazio, mas ocupa apenas 41MiB. Sem pensar muito, movo para o diretório de dados do meu Inception local, inicio, carrego a página e lá está, 1M. E parece que os dados estão corretos inclusive.

Coleção do benchmark com 1M de documentos
Coleção do benchmark com 1M de documentos

Ainda não acredito, crio um índice, lanço query com ordem ascendente e encontro o primeiro documento, o 0. Mudo a ordem e também está o último documento, o 999999. Parece que está tudo em ordem. Deixo de prestar atenção à tela para verificar que ainda estou respirando.

Me ocorre escrever um artigo no blog, mas antes repito o teste. Desta vez com 10 milhões.

sent: 10000000 took: 1.078983549s Throughput: 9267981.90 rows/sec Closing 'col-1779498339775263815'... http: Server closed

Quase 10 milhões por segundo, que estimo serem 410 MiB. Claramente ainda está muito longe de alcançar o gargalo de disco que em testes reais chega a 9.4 GiB/s, não chega nem a 5%.

O benchmark possui vários testes para medir o desempenho de cenários específicos: INSERT, PATCH, REMOVE mas há outros que não lembrava: INSERTPK, INSERTBTREE, RETRIEVEBTREE, RETRIEVEFS.

Vou executar todos e registro o desempenho de cada um.

INSERT Throughput: 8785855.31 rows/sec Throughput Open: 8780487.73 rows/sec INSERTPK Throughput: 5890949.19 rows/sec Throughput Open: 2374067.17 rows/sec INSERTBTREE Throughput: 1766108.26 rows/sec Throughput Open: 3165092.19 rows/sec RETRIEVEBTREE Throughput: 5412335.80 docs/sec RETRIEVEFS Throughput insert: 9249222.80 rows/sec Throughput Full scan (no filter): 13145243.10 docs/sec Throughput Full scan with filter: 4265889.26 docs/sec PATCH Throughput: 2735628.98 rows/sec Throughput Open: 9973488.60 rows/sec REMOVE Throughput: 1622765.40 rows/sec Throughput Open: 14321483.85 rows/sec

Em geral, supera-se o milhão por segundo em todas as operações. A propósito, deixe-me lembrá-lo de que o Throughput Open é a mesma operação mas ao iniciar a base de dados. Isso é relevante porque o Inception se baseia unicamente em journal para persistir dados, portanto para recuperar o estado novamente é preciso ler todo o journal antes de ficar operacional outra vez.