Show HN: ScratchDB: Snowflake open source sobre ClickHouse

 (github.com/scratchdata)
4 puntos por GN⁺ 2023-10-29 | 1 comentarios | Compartir por WhatsApp
  • Scratch Data es un wrapper que permite transmitir datos de entrada y salida en una base de datos analítica, y ejecutar consultas analíticas sobre entradas JSON arbitrarias
  • Si se ejecuta sin configuración, prepara automáticamente una base de datos local DuckDB con capacidad de lectura y escritura
  • Al enviar datos JSON a POST /api/data/insert/events?api_key=local, crea automáticamente la tabla events y sus columnas
  • Flujo de uso de la API HTTP: enviar consultas SQL a GET /api/data/query para consultar los datos insertados
  • Ofrece funciones para compartir o copiar los resultados de consultas
    • La API share crea un ID de consulta, expira después del duration especificado en segundos y permite compartir datos mediante enlaces CSV o JSON
    • Después de configurar varias bases de datos, ejecuta una consulta SQL en la base de datos de origen y gestiona automáticamente la creación de la tabla de destino y la inserción de datos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-29
Opiniones en Hacker News

  • Sería bueno que explicaran qué significa open-source Snowflake. No parece haber una explicación desarrollada en la descripción, el repositorio ni el sitio
    Me pregunto si el objetivo es reproducir explícitamente todas las funciones de Snowflake: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

    • Es buen feedback para escribir un mensaje más claro, y lo recibimos con gusto
      El objetivo de este proyecto es crear una excelente experiencia de desarrollo sobre una base de datos analítica. Vemos eso como una de las varias propuestas de valor de Snowflake. También buscamos que los usuarios tengan control total sobre sus datos y sobre cómo se procesan, y que puedan usar recursos de cómputo de forma económica
      Nuestro objetivo no es igualar las funciones de otro producto, pero a medida que crezcamos construiremos funciones importantes para las empresas

  • Trabajo en ClickHouse
    Creo que las bases de datos OLAP en tiempo real tienen el potencial de soportar mejor parte del trabajo que hoy se hace en Postgres o en data warehouses en la nube, cuando se requiere ingesta en tiempo real y consultas analíticas. Simplificar la experiencia de desarrollo sin tener que aprender todos los detalles de una base de datos potente también acelera mucho el desarrollo
    Me da curiosidad en qué se diferencia este proyecto de GraphJSON(https://www.graphjson.com/) y Tinybird(https://www.tinybird.co/)

    • No conocía GraphJSON y voy a revisarlo. También me gusta Tinybird, y creo que el objetivo de facilitar que la gente adopte OLAP es similar
      Técnicamente tomamos decisiones de diseño distintas para la ingesta y el procesamiento de datos. Por ejemplo, incluso después de crear una tabla, se puede enviar un JSON nuevo con columnas distintas y se ingiere sin migraciones manuales. También tratamos los arrays JSON de forma diferente: en vez de usar arrays de ClickHouse, permitimos dividirlos en varias filas de ClickHouse
      Filosóficamente, creo que hay mucho espacio para software open source con una gran UI y experiencia de desarrollo. Llevo mucho tiempo escribiendo open source y creo que es la mejor forma de crear herramientas exitosas para desarrolladores
    • No soy el autor del post original, pero ni GraphJSON ni Tinybird parecen ser open source

  • Buen producto, gracias por compartirlo
    Tenía entendido que ClickHouse ya soporta de forma nativa el aplanamiento de JSON[1]. Es una función que salió hace poco, en la versión 22.3.1; me pregunto si empezaron a trabajar en esto antes de eso[2], o si es un enfoque distinto. También me gustaría conocer los pros y contras de cada uno
    [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
    [2] https://scratchdb.com/blog/flatten-json/

    • Muy buena pregunta. Una respuesta un poco sarcástica sería: “nuestra forma de ingerir JSON no requiere 50 páginas y n valores de configuración para explicarse”
      Hablando de forma más factual, no usamos tuplas para JSON anidado, sino que representamos la relación parent_child en las claves con guiones bajos. Tampoco usamos arrays; hacemos que sea fácil dividirlos en varias filas para poder usar SQL normal
      No lo hemos comparado directamente con las distintas formas en que ClickHouse procesa JSON, pero el objetivo era crear algo que, al ejecutarlo, simplemente funcione como esperas
    • La inferencia de esquema para objetos JSON anidados es una función de ClickHouse 23.9. Hice un video al respecto: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

  • Para quienes tengan curiosidad, la licencia es AGPL-3.0

  • Felicitaciones por el lanzamiento. Me pregunto si esto puede usarse para datos de logs y cuánto tiempo se conservan los datos ingeridos

    • Se puede usar para logs. Hay un ejemplo básico aquí: https://scratchdb.com/blog/fly-logs-to-clickhouse/
      Como simplemente se almacenan en la base de datos, se mantienen tanto tiempo como quieras. En la versión alojada se cobra por GB de datos comprimidos, así que puedes conservar muchos logs y también borrar datos antiguos si quieres ahorrar espacio en disco

  • Gracias por compartirlo; se ve muy limpio y fácil de usar
    Me pregunto si tienen planes de soportar también formatos de datos que no sean JSON al insertar. Por ejemplo, archivos CSV, archivos Parquet, mensajes Avro o Protobuf

  • Sería bueno que enviaran los benchmarks a ClickBench

  • Me pregunto qué implicaciones tiene la licencia si uso esto para ofrecer un servicio público sin modificar el código proporcionado
    Por ejemplo, usarlo en un foro, pero con un fragmento de código separado que mete y saca datos de ScratchDB

  • Me pregunto por qué el almacenamiento es 10 veces más caro que BigQuery. También quisiera saber cómo se compara el precio del cómputo con BigQuery
    Edición: Bigtable → BigQuery

    • No cobramos cómputo y almacenamiento por separado como Bigtable. El cómputo está incluido en el precio por GB de datos. El objetivo es un modelo de precios similar a DynamoDB, donde pagas solo por lo que usas. Otra modalidad de cobro se basa en el tiempo real transcurrido de la consulta, así que una consulta de 30 segundos cuesta más que una de 500 ms
      No he usado Bigtable, pero parece que tiene una tarifa mínima de unos 300 dólares incluso sin datos. ScratchDB tiene un mínimo de 10 dólares por 30 GB
      Además, en promedio la compresión de datos es de 25%. Si 1 TB de datos ocupa solo 250 GB, pagas solo por eso
      Bigtable no es OLAP, así que no se usaría para los mismos datos. Esto compite más directamente con BigQuery de GCP
      Nos interesa mucho el feedback sobre precios. Necesitamos poder seguir desarrollando, así que queremos encontrar un camino razonable

  • Felicitaciones por el lanzamiento; se ve bien. Inferir el esquema sobre la marcha es excelente para empezar rápido, pero me pregunto si también hay una forma de definir el esquema explícitamente si uno quiere
    Estoy pensando, por ejemplo, en configuraciones de compresión por columna

    • Actualmente no, pero estamos abiertos a la idea de permitir configurarlo
      Poder configurarlo sobre la marcha, o mejor aún, una función que recomiende al usuario qué método de compresión debería usar según los datos reales, podría ser útil. También me encantaría discutirlo en un issue de GitHub