TimescaleDB é uma extensão de código aberto do Postgres desenvolvida pela Timescale Inc
que tem como objetivo melhorar o desempenho de consultas analíticas sem precisar deixar o Postgres. Isso é obtido por meio da
criação de “hipertabelas”, que são gerenciadas pela extensão e oferecem suporte ao particionamento automático em “chunks”.
As hipertabelas também oferecem suporte à compressão transparente e ao armazenamento híbrido linha-colunar (conhecido como “hypercore”), embora esses
recursos exijam uma versão da extensão com licença proprietária.
A Timescale Inc também oferece dois serviços gerenciados para o TimescaleDB:
Managed Service for TimescaleTimescale Cloud.
Há fornecedores terceirizados que oferecem serviços gerenciados que permitem usar a extensão TimescaleDB, mas, por questões de
licenciamento, esses fornecedores oferecem suporte apenas à versão de código aberto da extensão.
As hipertabelas do Timescale se comportam de forma diferente das tabelas comuns do Postgres em vários aspectos. Isso traz algumas complicações
para o processo de replicação, razão pela qual a capacidade de replicar hipertabelas do Timescale deve ser considerada como
best effort.
Versões compatíveis do Postgres
Habilitar replicação lógica
- Se você estiver usando um serviço gerenciado e seu provedor estiver listado na barra lateral, siga o guia desse provedor.
- Se você estiver implantando o TimescaleDB por conta própria, siga o guia genérico.
Para outros serviços gerenciados, abra um chamado de suporte com seu provedor para obter ajuda para habilitar a replicação lógica, caso
ela ainda não esteja habilitada.
O Timescale Cloud não oferece suporte à habilitação da replicação lógica, que é necessária para pipes do Postgres no modo CDC.
Como resultado, os usuários do Timescale Cloud só podem fazer uma carga única dos seus dados (Initial Load Only) com o
Postgres ClickPipe.
_timescaledb_internal. Para executar consultas nas hipertabelas, isso não é um
problema. Mas, durante a replicação lógica, em vez de detectarmos alterações na hipertabela, nós as detectamos na tabela chunk
correspondente. O ClickPipe do Postgres tem lógica para remapear automaticamente as alterações das tabelas chunk para a hipertabela pai,
mas isso exige etapas adicionais.
Se você quiser apenas realizar uma carga única dos seus dados (Initial Load Only), pule a etapa 2 e as seguintes.
-
Crie um usuário dedicado para o ClickPipes:
CREATE USER clickpipes_user PASSWORD 'some-password';
-
Conceda acesso de somente leitura no nível do schema ao usuário que você criou na etapa anterior. O exemplo a seguir mostra as permissões para o schema
public. Repita esses comandos para cada schema que contenha tabelas que você deseja replicar:
GRANT USAGE ON SCHEMA "public" TO clickpipes_user;
GRANT SELECT ON ALL TABLES IN SCHEMA "public" TO clickpipes_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT ON TABLES TO clickpipes_user;
-
Conceda privilégios de replicação ao usuário:
ALTER USER clickpipes_user WITH REPLICATION;
-
Como superusuário/admin do Postgres, crie uma publicação com as hipertabelas que você deseja replicar. A publicação também deve incluir todo o schema
_timescaledb_internal para que o pipe possa receber alterações dos chunks subjacentes. Recomendamos fortemente incluir na publicação apenas as tabelas de que você precisa para evitar sobrecarga de desempenho.
Qualquer tabela incluída na publicação deve ter uma chave primária definida ou ter sua replica identity configurada como FULL. Consulte as FAQs do Postgres para orientações sobre escopo. -- Ao adicionar novas tabelas ao ClickPipe, você também precisará adicioná-las à publicação manualmente.
CREATE PUBLICATION clickpipes FOR TABLE table_to_replicate, table_to_replicate2, TABLES IN SCHEMA _timescaledb_internal;
publicação clickpipes conterá o conjunto de eventos de alteração gerados pelas tabelas especificadas e, posteriormente, será usada na ingestão do fluxo de replicação.
Alguns serviços gerenciados não concedem aos usuários administradores as permissões necessárias para criar uma publicação para um schema inteiro. Se esse for o caso, abra um ticket de suporte com seu provedor. Como alternativa, você pode pular esta etapa (e as próximas) e, em vez disso, fazer uma carga única dos seus dados.
