cstore_fdw
delta
Our great sponsors
cstore_fdw | delta | |
---|---|---|
6 | 69 | |
1,738 | 6,897 | |
0.4% | 2.5% | |
2.6 | 9.8 | |
about 3 years ago | 3 days ago | |
C | Scala | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cstore_fdw
-
Moving a Billion Postgres Rows on a $100 Budget
Columnar store PostgreSQL extension exists, here are two but I think I’m missing at least another one:
https://github.com/citusdata/cstore_fdw
https://github.com/hydradatabase/hydra
You can also connect other stores using the foreign data wrappers, like parquet files stored on an object store, duckdb, clickhouse… though the joins aren’t optimised as PostgreSQL would do full scan on the external table when joining.
-
Anything can be a message queue if you use it wrongly enough
I'm definitely not from Citus data -- just a pg zealot fighting the culture war.
If you want to reach people who can actually help, you probably want to check this link:
https://github.com/citusdata/cstore_fdw/issues
-
Pg_squeeze: An extension to fix table bloat
That appears to be the case:
https://github.com/citusdata/cstore_fdw
>Important notice: Columnar storage is now part of Citus
-
Ingesting an S3 file into an RDS PostgreSQL table
either we go for RDS, but we stick to the AWS handpicked extensions (exit timescale, citus or their columnar storage, ... ),
-
Postgres and Parquet in the Data Lke
Re: performance overhead, with FDWs we have to re-munge the data into PostgreSQL's internal row-oriented TupleSlot format again. Postgres also doesn't run aggregations that can take advantage of the columnar format (e.g. CPU vectorization). Citus had some experimental code to get that working [2], but that was before FDWs supported aggregation pushdown. Nowadays it might be possible to basically have an FDW that hooks into the GROUP BY execution and runs a faster version of the aggregation that's optimized for columnar storage. We have a blog post series [3] about how we added agg pushdown support to Multicorn -- similar idea.
There's also DuckDB which obliterates both of these options when it comes to performance. In my (again limited, not very scientific) benchmarking of on a customer's 3M row table [4] (278MB in cstore_fdw, 140MB in Parquet), I see a 10-20x (1/2s -> 0.1/0.2s) speedup on some basic aggregation queries when querying a Parquet file with DuckDB as opposed to using cstore_fdw/parquet_fdw.
I think the dream is being able to use DuckDB from within a FDW as an OLAP query engine for PostgreSQL. duckdb_fdw [5] exists, but it basically took sqlite_fdw and connected it to DuckDB's SQLite interface, which means that a lot of operations get lost in translation and aren't pushed down to DuckDB, so it's not much better than plain parquet_fdw.
This comment is already getting too long, but FDWs can indeed participate in partitions! There's this blog post that I keep meaning to implement where the setup is, a "coordinator" PG instance has a partitioned table, where each partition is a postgres_fdw foreign table that proxies to a "data" PG instance. The "coordinator" node doesn't store any data and only gathers execution results from the "data" nodes. In the article, the "data" nodes store plain old PG tables, but I don't think there's anything preventing them from being parquet_fdw/cstore_fdw tables instead.
[0] https://github.com/citusdata/cstore_fdw
-
Creating a simple data pipeline
The citus extension for postgresql. https://github.com/citusdata/cstore_fdw
delta
-
Delta Lake vs. Parquet: A Comparison
Delta is pretty great, let's you do upserts into tables in DataBricks much easier than without it.
I think the website is here: https://delta.io
-
Understanding Parquet, Iceberg and Data Lakehouses
I often hear references to Apache Iceberg and Delta Lake as if they’re two peas in the Open Table Formats pod. Yet…
Here’s the Apache Iceberg table format specification:
https://iceberg.apache.org/spec/
As they like to say in patent law, anyone “skilled in the art” of database systems could use this to build and query Iceberg tables without too much difficulty.
This is nominally the Delta Lake equivalent:
https://github.com/delta-io/delta/blob/master/PROTOCOL.md
I defy anyone to even scope out what level of effort would be required to fully implement the current spec, let alone what would be involved in keeping up to date as this beast evolves.
Frankly, the Delta Lake spec reads like a reverse engineering of whatever implementation tradeoffs Databricks is making as they race to build out a lakehouse for every Fortune 1000 company burned by Hadoop (which is to say, most of them).
My point is that I’ve yet to be convinced that buying into Delta Lake is actually buying into an open ecosystem. Would appreciate any reassurance on this front!
-
Getting Started with Flink SQL, Apache Iceberg and DynamoDB Catalog
Apache Iceberg is one of the three types of lakehouse, the other two are Apache Hudi and Delta Lake.
-
[D] Is there other better data format for LLM to generate structured data?
The Apache Spark / Databricks community prefers Apache parquet or Linux Fundation's delta.io over json.
-
Delta vs Iceberg: make love not war
Delta 3.0 extends an olive branch. https://github.com/delta-io/delta/releases/tag/v3.0.0rc1
-
Databricks Strikes $1.3B Deal for Generative AI Startup MosaicML
Databricks provides Jupyter lab like notebooks for analysis and ETL pipelines using spark through pyspark, sparkql or scala. I think R is supported as well but it doesn't interop as well with their newer features as well as python and SQL do. It interfaces with cloud storage backend like S3 and offers some improvements to the parquet format of data querying that allows for updating, ordering and merged through https://delta.io . They integrate pretty seamlessly to other data visualisation tooling if you want to use it for that but their built in graphs are fine for most cases. They also have ML on rails type through menus and models if I recall but I typically don't use it for that. I've typically used it for ETL or ELT type workflows for data that's too big or isn't stored in a database.
-
The "Big Three's" Data Storage Offerings
Structured, Semi-structured and Unstructured can be stored in one single format, a lakehouse storage format like Delta, Iceberg or Hudi (assuming those don't require low-latency SLAs like subsecond).
-
Ideas/Suggestions around setting up a data pipeline from scratch
As the data source, what I have is a gRPC stream. I get data in protobuf encoded format from it. This is a fixed part in the overall system, there is no other way to extract the data. We plan to ingest this data in delta lake, but before we do that there are a few problems.
-
Medallion/lakehouse architecture data modelling
Take a look at Delta Lake https://delta.io, it enables a lot of database-like actions on files
-
CSV or Parquet File Format
I prefer parquet (or delta for larger datasets. CSV for very small datasets, or the ones that will be later used/edited in Excel or Googke sheets.
What are some alternatives?
ZLib - A massively spiffy yet delicately unobtrusive compression library.
dvc - 🦉 ML Experiments and Data Management with Git
odbc2parquet - A command line tool to query an ODBC data source and write the result into a parquet file.
Apache Cassandra - Mirror of Apache Cassandra
zstd - Zstandard - Fast real-time compression algorithm
lakeFS - lakeFS - Data version control for your data lake | Git for data
cute_headers - Collection of cross-platform one-file C/C++ libraries with no dependencies, primarily used for games
hudi - Upserts, Deletes And Incremental Processing on Big Data.
parquet_fdw - Parquet foreign data wrapper for PostgreSQL
delta-rs - A native Rust library for Delta Lake, with bindings into Python
bzip3 - A better and stronger spiritual successor to BZip2.
iceberg - Apache Iceberg