Neki agora disponível em visualização da plataforma. Neki construído a partir das lições aprendidas em oito anos executando algumas das maiores clusters MySQL fragmentadas do mundo. Milhares de cargas de trabalho de produção com milhões de queries por segundo para empresas onde mesmo alguns segundos de inatividade é um evento público.

Sabemos o que significa alimentar as maiores cargas de trabalho tier 0 do mundo. Quando lançamos o Planet Scale Postgres há um ano e meio, sabíamos que precisávamos fazer mais. Nesse tempo, onboardamos vários milhares de clientes no Planet Scale, alguns deles rivalizando no tamanho com nossos maiores clientes MySQL.

Time and time again, vimos equipes atingir o teto de uma única máquina com Postgres. Metal lhes deu tempo, mas com os clientes atingindo o limite superior do que uma única máquina é capaz de fazer, descobrimos que não havia uma boa opção para entregá-los. Entre Neki.

O que é Neki? Neki é Postgres fragmentado do Planet Scale. Permite escalar um banco de dados Postgres em muitas máquinas mantendo Postgres real em cada fragmento. Sua aplicação conecta a um roteador Neki sobre o protocolo wire padrão do Postgres, então seus drivers ORMs existentes e strings de conexão continuam funcionando.

Cada fragmento é um cluster Postgres completo com um primário e pelo menos duas réplicas em 3 zonas de disponibilidade. Não há motor de armazenamento personalizado, então extensões, suporte SQL e desempenho se comportam como o Postgres faz. Você escolhe a chave de fragmentação e controla como as tabelas são agrupadas e distribuídas através de um dados JSON topologia.

Mudanças de esquema, atualizações de versão, failover, imports e resharding executam como fluxos de trabalho integrados totalmente online. Você também obtém os recursos Planet Scale nos quais já confia, incluindo Insights, recomendações de esquema, branches e MCP. Você não precisa fragmentar no primeiro dia.

Execute Neki como um primário com réplicas, e quando você superar uma máquina, o resharding é um workflow que você executa contra o cluster que já tem. Por que Neki? Você já conhece os problemas que vêm com bancos de dados Postgres de crescimento rápido: tabelas muito grandes para vacuum ou indexar sem afetar o tráfego, backups levando horas, limites de conexão, janelas de manutenção para alterações de esquema, wraparound de transação e muito mais. Você pode mudar para uma instância maior, mas eventualmente ficará sem máquinas grandes o suficiente, e os problemas não escalam linearmente à medida que você adiciona mais núcleos e IOPS.

As respostas existentes cada uma pede que você desista de algo. A fragmentação no nível da aplicação empurra o roteamento para o seu código. Bancos de dados "compatíveis" Postgres distribuídos escondem a chave de fragmentação de você, tiram suas extensões e adicionam complexidade e latência que se torna difícil de lidar e depurar.

Então construímos Neki com alguns princípios, o maior sendo: adira ao Postgres, não trabalhe ao redor dele, não o faça de conta, não se afaste dele. Como funciona Neki? Arquitetamos Neki desde os princípios fundamentais para Postgres, com Postgres real em cada fragmento. Há quatro partes móveis.

Neki routers Sua aplicação primeiro se conecta a um roteador Neki. O roteador fala o protocolo wire do Postgres então seus drivers ORMs existentes continuam funcionando com uma única string de conexão. Um roteador tem um parser de consulta Postgres, um planejador de consultas distribuído, buffer de consultas e mais.

Ele analisa sua consulta, constrói um plano que decide quais fragmentos devem executá-la, envia o trabalho para fora, e combina os resultados de volta em um único fluxo. Os roteadores podem escalar vertical e horizontalmente, então nenhum roteador único se torne o gargalo. Fragmentação e grupos de fragmentos Cada fragmento no Neki é Postgres real com 1 primário e pelo menos 2 réplicas, espalhadas em 3 zonas de disponibilidade.

Não há motor de armazenamento modificado. Extensões, suporte SQL e desempenho se comportam como o Postgres faz, porque é Postgres. Os fragmentos são organizados em grupos de fragmentos, então diferentes tabelas ou cargas de trabalho podem viver em diferentes conjuntos de fragmentos.

Cada fragmento usa um perfil de configuração que define seu tamanho de instância, conta de réplica, armazenamento, parâmetros Postgres e extensões, assim você pode dimensionar cada grupo para i...