Show HN: ScratchDB - Snowflake open source sobre ClickHouse

• Scratch Data é um wrapper para banco de dados analítico que permite fazer streaming de entrada e saída de dados e executar consultas analíticas sobre entradas JSON arbitrárias
• Ao executar sem configuração, ele prepara automaticamente um banco de dados local DuckDB com leitura e escrita habilitadas
• Ao enviar dados JSON para POST /api/data/insert/events?api_key=local, ele cria automaticamente a tabela events e suas colunas
• O fluxo de uso da HTTP API consiste em passar consultas SQL para GET /api/data/query para consultar os dados inseridos
• Oferece recursos para compartilhar ou copiar resultados de consultas
  • A API share cria um ID de consulta e expira após a duration especificada em segundos, permitindo compartilhar os dados por links em CSV ou JSON
  • Após configurar vários bancos de dados, executa consultas SQL no banco de origem e processa automaticamente a criação da tabela de destino e a inserção dos dados

[GN⁺]

Opiniões no Hacker News

• Seria bom explicar o que significa open-source Snowflake. Não parece haver uma explicação detalhada na descrição, no repositório ou no site
  Fico curioso se o objetivo é reproduzir explicitamente todos os recursos do Snowflake: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

  • É um bom feedback para escrever uma mensagem mais clara, e aceito com gratidão
    O objetivo deste projeto é criar uma excelente experiência de desenvolvedor em cima de um banco de dados analítico. Vejo isso como uma das várias propostas de valor do Snowflake. Também queremos permitir que os usuários tenham controle total sobre seus próprios dados e sobre a forma de processamento, além de usar recursos de computação de maneira econômica
    Nosso objetivo não é igualar os recursos de outro produto, mas, à medida que crescermos, vamos criar funcionalidades importantes para empresas

• Trabalho na ClickHouse
  Acho que bancos de dados OLAP em tempo real têm potencial para atender melhor a parte das cargas de trabalho que hoje rodam em Postgres ou em data warehouses na nuvem, quando há necessidade de ingestão em tempo real e consultas analíticas. Simplificar a experiência de desenvolvimento, sem exigir que se aprendam todos os detalhes de um banco de dados poderoso, também acelera muito o desenvolvimento
  Fico curioso sobre como este projeto difere do GraphJSON(https://www.graphjson.com/) e do Tinybird(https://www.tinybird.co/)

  • Foi a primeira vez que vi o GraphJSON; vou conferir. Também gosto do Tinybird, e acho que temos um objetivo parecido de facilitar a adoção de OLAP pelas pessoas
    Tecnicamente, tomamos decisões de design diferentes na ingestão e no processamento de dados. Por exemplo, mesmo depois de criar uma tabela, você pode enviar um novo JSON com colunas diferentes, e ele será ingerido sem migrações manuais. Também tratamos arrays JSON de forma diferente: em vez de usar arrays do ClickHouse, permitimos dividi-los em várias linhas do ClickHouse
    Filosoficamente, acho que há muito espaço para software open source com uma ótima UI e uma ótima experiência de desenvolvedor. Escrevo open source há muito tempo e acredito que essa é a melhor forma de criar ferramentas de desenvolvedor bem-sucedidas
  • Não sou o autor do post original, mas tanto o GraphJSON quanto o Tinybird não parecem ser open source

• Bom produto, e fico feliz que tenha compartilhado
  Eu achava que o ClickHouse já tinha suporte nativo a achatamento de JSON[1]. É um recurso que saiu recentemente na versão 22.3.1, mas fiquei curioso se vocês começaram a trabalhar nisso antes[2], ou se é uma abordagem diferente. Também gostaria de saber os prós e contras de cada uma
  [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
  [2] https://scratchdb.com/blog/flatten-json/

  • Pergunta muito boa. Uma resposta um pouco sarcástica seria: “a nossa forma de ingerir JSON não exige 50 páginas e n valores de configuração para ser explicada”
    Falando de maneira mais factual, não usamos tuplas para JSON aninhado; indicamos a relação parent_child nas chaves usando sublinhado. Também não usamos arrays, e os tornamos fáceis de dividir em várias linhas para que seja possível usar SQL comum
    Não fizemos uma comparação direta com as várias formas de processamento de JSON do ClickHouse, mas o objetivo era criar algo que, ao rodar, simplesmente funciona como você esperaria
  • A inferência de esquema para objetos JSON aninhados é um recurso do ClickHouse 23.9. Fiz um vídeo sobre isso: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

• Para quem estiver curioso, a licença é AGPL-3.0

  • https://github.com/scratchdata/ScratchDB/blob/main/LICENSE

• Parabéns pelo lançamento. Fico curioso se isso pode ser usado para dados de logs e por quanto tempo os dados ingeridos são retidos

  • Pode ser usado para logs. Há um exemplo básico aqui: https://scratchdb.com/blog/fly-logs-to-clickhouse/
    Como os dados são simplesmente armazenados no banco de dados, eles ficam pelo tempo que você quiser. Na versão hospedada, cobramos por GB de dados compactados, então é possível reter mesmo um grande volume de logs, ou apagar dados antigos se quiser economizar espaço em disco

• Obrigado por compartilhar; parece muito limpo e fácil de usar
  Fico curioso se há planos para dar suporte a formatos de dados que não sejam JSON na inserção. Por exemplo, arquivos CSV, arquivos Parquet, mensagens Avro ou Protobuf

  • Vamos dar suporte. Há uma issue relacionada: https://github.com/scratchdata/ScratchDB/issues/19
    Fico curioso sobre como você gostaria que isso fosse

• Seria bom enviar os benchmarks para o ClickBench

• Fico curioso sobre as implicações da licença se eu usar isso para oferecer um serviço público sem modificar o código fornecido
  Por exemplo, usá-lo em um fórum, mas com um trecho de código separado para colocar e retirar dados do ScratchDB

• Fico curioso por que o armazenamento é 10 vezes mais caro que o BigQuery. Também gostaria de saber como o preço de computação se compara ao BigQuery
  Correção: Bigtable → BigQuery

  • Não cobramos computação e armazenamento separadamente como o Bigtable. A computação está incluída no preço por GB de dados. O objetivo é ter um modelo de preços parecido com o do DynamoDB, em que você paga apenas pelo que usa. Outra forma de cobrança é baseada no tempo real decorrido da consulta, então uma consulta de 30 segundos custa mais que uma de 500 ms
    Não usei o Bigtable, mas parece que a cobrança mínima é de cerca de US$ 300 mesmo sem dados. No ScratchDB, o mínimo é de US$ 10 por 30 GB
    Além disso, em média, a taxa de compactação dos dados é de 25%. Se 1 TB de dados ocupar apenas 250 GB, você paga apenas por isso
    Como o Bigtable não é OLAP, você não o usaria para os mesmos dados. Isto concorre mais diretamente com o BigQuery, do GCP
    Tenho muito interesse em feedback sobre preços. Precisamos conseguir continuar o desenvolvimento, então queremos encontrar um caminho razoável

• Parabéns pelo lançamento; parece bom. Inferir o esquema na hora é ótimo para começar rapidamente, mas fico curioso se também há uma forma de definir o esquema explicitamente, caso se queira
  Estou pensando, por exemplo, em configurações de compactação por coluna

  • No momento não há, mas estamos abertos à ideia de permitir configuração
    Configurar isso na hora, ou, melhor ainda, informar ao usuário qual método de compactação usar com base nos dados reais, poderia ser útil. Também ficaremos felizes em discutir isso em uma issue no GitHub