Mapeie a carga de trabalho para um ponto de partida
Consulte a documentação do produto vinculada para verificar disponibilidade, regiões e limitações atuais. O ClickHouse Managed Postgres está atualmente em beta público; consulte seu quickstart.
Para um ClickHouse server autogerenciado ou outras opções locais, consulte modos de implantação.
Exemplo: resultados de relatórios e histórico de execuções
Suponha que uma aplicação processe arquivos enviados, gere relatórios e precise manter resultados consultáveis e um histórico de execuções. Antes de escolher um banco de dados, distinga as linhas de resultado dos registros de execução:- Resultados: as consultas recuperam poucas linhas de um único relatório ou agregam dados de muitos relatórios, conjuntos de dados e intervalos de tempo? Qual tabela deve chegar a centenas de milhões de linhas?
- Registros de execução: um único registro imutável é gravado ao término de uma execução ou a aplicação precisa coordenar a propriedade de jobs ativos e as transições de status?
- Correção: vários registros precisam ser alterados em uma única transação? O banco de dados precisa impor unicidade ou impedir que dois workers reivindiquem o mesmo job?
- Atualidade: em quanto tempo uma gravação bem-sucedida precisa estar visível e as consultas toleram uma cópia analítica incompleta ou defasada?
Execuções concluídas e resultados analíticos
Um serviço ClickHouse no ClickHouse Cloud é uma opção adequada quando a carga de trabalho predominante é a análise de linhas de resultado e os registros de execução podem ser anexados no momento da conclusão. Uma pequena tabela de metadados não justifica, por si só, um segundo banco de dados. Projete e teste como os leitores distinguem uma execução completa de uma parcialmente ingerida. Defina identificadores de execução estáveis, o comportamento de nova tentativa e como as linhas de resultado duplicadas são tratadas. Inserções separadas em uma tabela de resultados e em uma tabela de histórico de execuções não devem ser tratadas como uma única transação entre tabelas. Se você armazenar múltiplas versões de um registro de execução, defina como as consultas selecionam a versão atual. O ReplacingMergeTree oferece suporte à desduplicação em tempo de consulta comFINAL; a correção não deve depender de os merges em segundo plano já terem ocorrido. A referência de update descreve outro mecanismo de atualização e suas limitações. Não se deve presumir que qualquer um desses padrões ofereça garantias transacionais no estilo do PostgreSQL.
Estado transacional do job
Avalie o ClickHouse Managed Postgres quando a tabela de execuções também funcionar como fila de trabalho transacional ou sistema de registro: por exemplo, quando um worker precisa reivindicar um job de forma atômica enquanto outros workers competem por ele, ou quando vários registros da aplicação precisam ser alterados em conjunto, com constraints sendo aplicadas. O Postgres também pode atender consultas de relatórios. Adicione um serviço analítico quando os requisitos representativos de desempenho de consultas, concorrência ou isolamento justificarem, em vez de presumir que toda aplicação de relatórios precisa de dois bancos de dados.Transações e analytics em conjunto
Quando ambas as cargas de trabalho justificam services separados, mantenha o estado transacional no Postgres e replique as tabelas necessárias para o ClickHouse usando ClickPipes ou WalShadow. Leve em conta a defasagem de replicação e continue usando a fonte transacional para decisões que exigem o estado atual da aplicação. A replicação não faz com que uma escrita no Postgres e uma leitura no ClickHouse passem a fazer parte de uma mesma transação. A extensão pg_clickhouse pode fornecer acesso ao ClickHouse por meio do Postgres. Um entry point de consultas compartilhado não transforma os dois services em um único motor de banco de dados nem elimina a necessidade de levar em conta a atualidade dos dados.Verifique a adequação antes do provisionamento
Escreva um pequeno conjunto de consultas representativas e teste-as com volumes de dados realistas. Inclua tanto lookups pontuais quanto agregações que abrangem todo o histórico, a carga concorrente esperada e os casos de correção que importam para sua aplicação. Ao relatar qualquer resultado de benchmark, informe também o schema, as shapes das consultas, o tamanho do hardware ou do service e o comportamento de ingestão. Para uma implantação gerenciada, verifique também:- Requisitos de region, rede, access control e recovery.
- Tempo ativo esperado, dados armazenados, backups e cobranças de transferência no guia de billing do ClickHouse Cloud ou no guia de preços do Managed Postgres.
- Se uma carga de trabalho analítica intermitente tolera o atraso de connection associado ao automatic idling.
- A responsabilidade da equipe pelo design do schema, pelas novas tentativas da aplicação, pelo ajuste de consultas e pelos controles de custo, mesmo quando o service gerencia a infrastructure.