neat. i'm pretty novice in the guts of this kind of stuff, but how does this work under the hood for blocking operators where they "cannot output a single row until the last row of their input has been seen"?
i think this is where spark shuffling comes in? but how does it work here.
So DuckDB was developed to allow queries for bigish data finally without the need for a cluster to simplify data analysis... and we now put it to a cluster?
I think there are solutions for that scale of data already, and simplicity is the best feature of DuckDB (at lest for me).
> "Forget about managing complex server infrastructure for your database needs."
So what does this run on then?
No docs, it's not possible to find any deployment guides for Ray using serverless solutions like Lambda, Cloud Functions or be it your own Firecracker.
Instead, every other post mentions EKS or EC2.
The Ray team even rejected Lambda support expressedly as far back as 2020 [0]. Uuuuuugh.
No thanks! shiver
I'd rather cut complexity for practically the same benefit and either do it single machine or have a thin, manageable layer on top a truly serverless infra like in this talk [1] " Processing Trillions of Records at Okta with Mini Serverless Databases".
12 comments
[ 0.24 ms ] story [ 31.8 ms ] threadi think this is where spark shuffling comes in? but how does it work here.
https://duckdb.org/docs/stable/guides/performance/how_to_tun...
What you need is a multi-tenancy shared infrastructure that is elastic.
I think there are solutions for that scale of data already, and simplicity is the best feature of DuckDB (at lest for me).
So what does this run on then?
No docs, it's not possible to find any deployment guides for Ray using serverless solutions like Lambda, Cloud Functions or be it your own Firecracker.
Instead, every other post mentions EKS or EC2.
The Ray team even rejected Lambda support expressedly as far back as 2020 [0]. Uuuuuugh.
No thanks! shiver
I'd rather cut complexity for practically the same benefit and either do it single machine or have a thin, manageable layer on top a truly serverless infra like in this talk [1] " Processing Trillions of Records at Okta with Mini Serverless Databases".
0: https://github.com/ray-project/ray/issues/9983
1: https://www.youtube.com/watch?v=TrmJilG4GXk