Show HN: ScratchDB - ClickHouse üzerinde açık kaynak Snowflake

 (github.com/scratchdata)
4 puan yazan GN⁺ 2023-10-29 | 1 yorum | WhatsApp'ta paylaş
  • Scratch Data, veriyi analitik veritabanlarına akış halinde alıp çıkarmayı ve rastgele JSON girdileri üzerinde analitik sorgular çalıştırmayı sağlayan bir sarmalayıcıdır
  • Yapılandırma olmadan çalıştırıldığında okuma ve yazma yapılabilen yerel bir DuckDB veritabanını otomatik olarak hazırlar
  • JSON verisini POST /api/data/insert/events?api_key=local ile gönderdiğinizde events tablosunu ve sütunları otomatik oluşturur
  • Eklenen verileri sorgulamak için SQL sorgusunu GET /api/data/query adresine ileten bir HTTP API kullanım akışı vardır
  • Sorgu sonuçlarını paylaşma veya kopyalama işlevi sunar
    • share API’si bir sorgu kimliği oluşturur, belirtilen saniye cinsinden duration sonrasında süresi dolar ve veriler CSV ya da JSON bağlantısı olarak paylaşılabilir
    • Birden fazla veritabanı yapılandırıldıktan sonra kaynak veritabanında SQL sorgusu çalıştırır; hedef tablo oluşturma ve veri ekleme işlemlerini otomatik olarak gerçekleştirir

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-29
Hacker News yorumları

  • open-source Snowflake ifadesinin ne anlama geldiğini açıklasanız iyi olur. Açıklama metninde, depoda ya da sitede bunun açılmış hâli yok gibi görünüyor
    Hedefin Snowflake’in tüm özelliklerini açıkça yeniden üretmek olup olmadığını merak ediyorum: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

    • Net bir mesaj yazmak için iyi bir geri bildirim; memnuniyetle kabul ediyorum
      Bu projenin hedefi, bir analitik veritabanı üzerinde mükemmel bir geliştirici deneyimi oluşturmak. Bunun Snowflake’in birçok değer önerisinden biri olduğunu düşünüyorum. Ayrıca kullanıcıların kendi verileri ve işleme biçimleri üzerinde tam kontrol sahibi olmasını ve hesaplama kaynaklarını ekonomik şekilde kullanabilmesini sağlamak da hedefler arasında
      Hedefimiz başka bir ürünün özelliklerini birebir yakalamak değil; ancak büyüdükçe şirketler için önemli olan özellikleri geliştireceğiz

  • ClickHouse’ta çalışıyorum
    Gerçek zamanlı OLAP veritabanlarının, şu anda Postgres veya bulut veri ambarlarının üstlendiği işler içinde gerçek zamanlı veri alımı ve analitik sorgu gerektiren durumları daha iyi destekleme potansiyeli olduğunu düşünüyorum. Güçlü bir veritabanının tüm ayrıntılarını öğrenmeye gerek bırakmadan geliştirici deneyimini sadeleştirmek, geliştirme hızını da ciddi ölçüde artırır
    Bu projenin GraphJSON(https://www.graphjson.com/) ve Tinybird(https://www.tinybird.co/) ile nasıl farklılaştığını merak ediyorum

    • GraphJSON’u ilk kez görüyorum, inceleyeceğim. Tinybird’ü de seviyorum; insanların OLAP benimsemesini kolaylaştırma hedefi açısından benzer olduğumuzu düşünüyorum
      Teknik olarak veri alımı ve işleme tarafında farklı tasarım kararları aldık. Örneğin tablo oluşturulduktan sonra farklı sütunlara sahip yeni JSON’lar gönderebilir ve manuel migration olmadan ingest edebilirsiniz. JSON dizilerini de ClickHouse dizileri kullanmak yerine birden fazla ClickHouse satırına bölebilecek şekilde farklı ele alıyoruz
      Felsefi olarak, iyi bir UI ve geliştirici deneyimine sahip açık kaynak yazılımlar için büyük bir alan olduğunu düşünüyorum. Uzun süredir açık kaynak yazıyorum ve başarılı geliştirici araçları üretmenin en iyi yolunun bu olduğuna inanıyorum
    • Orijinal paylaşımı yapan kişi değilim ama GraphJSON ve Tinybird’ün ikisi de açık kaynak gibi görünmüyor

  • Güzel ürün, paylaştığınız iyi oldu
    ClickHouse’un JSON düzleştirmeyi zaten yerel olarak desteklediğini biliyordum[1]. Bu, yakın zamanda 22.3.1 sürümünde gelen bir özellik olsa da acaba siz bundan önce mi çalışmaya başlamıştınız[2], yoksa bu farklı bir yaklaşım mı? Her birinin artılarını ve eksilerini de bilmek isterim
    [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
    [2] https://scratchdb.com/blog/flatten-json/

    • Oldukça iyi bir soru. Biraz alaycı cevap şu olurdu: “Bizim JSON ingest etme biçimimizi açıklamak için 50 sayfa ve n tane ayar değeri gerekmiyor”
      Daha olgusal söylemek gerekirse, iç içe JSON için tuple kullanmıyoruz; anahtarlarda parent_child ilişkisini alt çizgiyle gösteriyoruz. Dizileri de kullanmıyoruz; normal SQL kullanılabilsin diye birden fazla satıra bölmeyi kolaylaştırıyoruz
      ClickHouse’un çeşitli JSON işleme yöntemleriyle doğrudan karşılaştırmadık, ama hedefimiz çalıştırıldığında beklediğiniz gibi doğrudan çalışan bir şey yapmaktı
    • İç içe JSON nesneleri için şema çıkarımı ClickHouse 23.9 özelliği. Bununla ilgili bir video hazırladım: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

  • Merak edenler için lisans AGPL-3.0

  • Lansman için tebrikler. Bunu log verileri için kullanıp kullanamayacağımı ve alınan verilerin ne kadar süre saklandığını merak ediyorum

    • Loglar için kullanabilirsiniz. Temel bir örnek burada: https://scratchdb.com/blog/fly-logs-to-clickhouse/
      Sonuçta veritabanında saklanıyor, yani istediğiniz kadar tutabilirsiniz. Barındırılan sürümde sıkıştırılmış veri GB’ı başına ücretlendirme var; bu yüzden çok log olsa da saklayabilir, disk alanından tasarruf etmek isterseniz eski verileri silebilirsiniz

  • Paylaşım için teşekkürler; oldukça temiz ve kullanımı kolay görünüyor
    Ekleme sırasında JSON dışı veri formatlarını da destekleme planınız var mı? Örneğin CSV dosyaları, Parquet dosyaları, Avro ya da Protobuf mesajları gibi

  • Benchmark’ları ClickBench’e gönderseniz iyi olur

  • Sağladığınız kodu değiştirmeden bunu kullanarak herkese açık bir servis sunarsam bunun lisans açısından ne anlama geldiğini merak ediyorum
    Örneğin bir forumda kullanmak, ama ScratchDB’ye veri yazıp veriyi oradan çeken ayrı bir kod parçası kullanmak gibi

  • Depolamanın neden BigQuery’den 10 kat pahalı olduğunu merak ediyorum. Hesaplama fiyatının BigQuery ile karşılaştırıldığında nasıl olduğunu da bilmek isterim
    Düzenleme: Bigtable → BigQuery

    • Bigtable gibi hesaplama ve depolamayı ayrı ayrı ücretlendirmiyoruz. Veri GB’ı başına fiyata hesaplama dahil. Hedefimiz DynamoDB’ye benzer şekilde, kullandıkça öde modelinde bir fiyatlandırma. Bir diğer ücretlendirme yöntemi de sorgunun gerçek geçen süresine göre; yani 30 saniyelik bir sorgu 500 ms’lik bir sorgudan daha pahalı
      Bigtable kullanmadım ama veri olmasa bile minimum ücret yaklaşık 300 dolar seviyesinde görünüyor. ScratchDB’de 30 GB için minimum 10 dolar
      Ek olarak, ortalama veri sıkıştırma oranı %25. 1 TB veri yalnızca 250 GB yer kaplıyorsa sadece o kadarının ücretini ödersiniz
      Bigtable OLAP olmadığı için aynı kullanım için tercih etmezsiniz. Bu, GCP’nin BigQuery’siyle daha doğrudan rekabet ediyor
      Fiyatlandırma geri bildirimleriyle çok ilgileniyorum. Geliştirmeyi sürdürebilmemiz gerektiği için makul bir yön bulmak istiyorum

  • Lansman için tebrikler, iyi görünüyor. Anında şema çıkarmak hızlı başlamak için harika; ama isterseniz şemayı açıkça tanımlamanın bir yolu da var mı merak ediyorum
    Örneğin sütun bazında sıkıştırma ayarlarını düşünüyorum

    • Şu anda yok, ancak bunu ayarlanabilir hâle getirme fikrine açığız
      Anında ayarlamak ya da daha iyisi, gerçek verilere bakarak kullanıcıya hangi sıkıştırma yöntemini kullanması gerektiğini söyleyen bir özellik faydalı olabilir. GitHub issue’larında da memnuniyetle tartışırım