pdet
Joined 8 years ago
Karma
152
Submissions
9
Member since
Dec 8
Recent submissions
Comment · 10 days ago
Comment · 22 days ago
The main reason was due to a much easier tight-integration with the DuckDB internals, so we can take the most of the DuckDB engine (and existing code) to use. As the extension must interact with table scanners, casting functions and whatnot.
However, DuckLake doesn't need to be implemented in C++ at all, I believe that whatever fits the engine that will be performing the reads/writes in Parquet and the connectors for the DBMSs should be a good fit.
For example https://github.com/borchero/ducklake-sdk - Rust https://github.com/datafusion-contrib/datafusion-ducklake - Rust https://github.com/motherduckdb/ducklake-spark - Scala https://github.com/brikk/trino-ducklake - Kotlin
Disclaimer: I'm the lead developer of DuckLake.
Comment · 22 days ago
The fundamental requirements of DBMS so it can be a DuckLake catalog are the following:
1. It must support primary keys
2. It must support basic data types (INTEGER,VARCHAR,TIMESTAMP)
3. ACID
There are ofc some quirks from the SQL supported on each DBMS. Hence, the DuckLake extension from DuckDB currently supports DuckDB, SQLite, Postgres, DuckDB + Quack and MySQL. With MySQL being in a rather experimental state.
Disclaimer: I'm the lead developer in DuckLake.
Comment · 2 months ago
DuckDB uses a speculative parallel CSV parsing technique. The basic idea is that the parser speculates about the state the CSV parser is in at a random byte (e.g., whether it is inside a quoted field) and tries to figure out where the next row starts based on that.There are validation steps during finalization as well, to ensure the parser did not got anything wrong in its speculation.
I've never gotten around to writing a blog post about it, but I go quite in-depth on the technique in this presentation: https://www.youtube.com/watch?v=YrqSp8m7fmk
(Disclaimer: I'm the author of the blog post and also the developer who implemented the entire CSV parser in DuckDB.)
Comment · 2 months ago
I've run quite a few benchmarks on that as well, on a few different machines, and oversubscribing ASYNC threads demonstrated very little performance downside. In the end, the memory governor also keeps these threads "in check" while still allowing full utilization when possible.
There is still something to gain from tuning it further (as you can see in the async I/O tuned benchmark), but having that network saturation by default is still a work in progress.
(Disclaimer: I'm the author of the blogpost)
Comment · 2 months ago
The main reason I decided to use a beefier machine is that it gives me flexibility when benchmarking, without the need to set up different environments. The CSV data, for example, is >80 GB. We can also “scale down the machine” for experiments where we want to stress-test lower-memory scenarios or use fewer threads by configuring DuckDB’s settings (e.g., SET memory_limit = '10GB'; or SET threads TO 1;).
(Disclaimer: I’m the author of the blog post.)
Comment · 5 months ago
I think that Quack will become the primary option for a DuckLake catalog in the future, for several reasons. To list a few:
1. No type mismatches for inlining. If you use a non-DuckDB catalog, many types do not have a 1:1 mapping, which introduces additional overhead when operating on those data types.
2. You get the raw performance of DuckDB analytics (and now transactions) over the catalog. DuckDB reading DuckDB is simply faster than any of our Postgres/SQLite scanners.
3. No round-trip for retries. We can easily(tm) run the full retry logic on the DuckDB server side. Right now, these retries trigger multiple round trips for Postgres, making it a performance bottleneck for high-contention workloads.
Disclaimer: I'm a duckdb/ducklake developer.
Disclaimer: I'm the DuckDB developer who implemented Async I/O for parquet, csvs and the DuckDB Format.