connector-x VS datafusion-ballista

This was originally a blocker, however, we managed to set up a multi-stage Docker build to build from source. Here is the Github issue where we, along with community members, managed to solve it.

There's packages like connector-x and polars that do a lot of what you're mentioning out of the box. I used these two to massively speed up an SQLalchemy + Pandas based ETL in the past as well.

Thanks for sharing connector-x, I will also start to use it. I wonder if there are a list of tools like that. I know Ruff, Polars, pydantic-core.

I was trying https://github.com/sfu-db/connector-x and hacking around with this https://github.com/spitz-dan-l/postgres-binary-parser but it turned out that a COPY to csv using asyncpg and then converting to parquet was the fastest.

if you store the OHLC data in a relational database, use connector-x to load the data into pandas dataframe

For SQL reading I'd really recommend connector-x, they do a great job preventing unneeded serialization and don't have to go through python.

Indeed, currently we do not support persistent connections among different queries. We target more on the bulk loading scenario where the bottleneck is caused by the data size and the connection construction overhead is negligible. However, one possible solution to the problem is to expose our connection pool object that we use inside Rust to users, so the next call could reuse the same pool. We do not plan for this yet, but happy to see whether this is a common need! Feel free to open an issue in our github repo: https://github.com/sfu-db/connector-x

Feel free to ask any questions here or open an issue in our github repo: https://github.com/sfu-db/connector-x . You can also join our discord community: https://discord.com/invite/xwbkFNk and ask question under connector channel!

Not super on topic because this is all immature and not integrated with one another yet, but there is a scaled-out rust data-frames-on-arrow implementation called ballista that could maybe? form the backend of a polars scale out approach: https://github.com/apache/arrow-ballista

> Is Rust's compile-time GC about something other than performance somehow?

AFAIK, memory safety and language features as RAII is also available in C++, for instance. About the reasons for slow compilation, take a look at https://www.reddit.com/r/rust/comments/xna9mb/why_are_rust_p...

Not having a GC is also about not having a runtime as you mention (e.g. nice for creating Python extensions and embedded systems programming) and also more runtime deterministic performance: on that, if I'm not mistaken that was the reason for Discourse switching to Rust and also, e.g.: "the choice of Rust as the main execution language avoids the overhead of GC pauses and results in deterministic processing times" https://github.com/apache/arrow-ballista/blob/main/README.md

Ballista (Arrow-Rust), which is largely inspired by Apache Spark, there are some interesting differences.

https://github.com/jorgecarleitao/arrow2 https://github.com/apache/arrow-datafusion https://github.com/apache/arrow-ballista https://github.com/pola-rs/polars https://github.com/duckdb/duckdb

Source: https://github.com/apache/arrow-ballista

Can you explain how this might differ from something like https://github.com/apache/arrow-ballista

I've seen several variants of "next-gen" spark, but nowhere have I really seen the different tradeoffs/advantages/disadvantages between them.

Rust has amazing integration with Python through PyO3 [1] so see it like a safe alternative for high performance calculations. The ecosystem itself is starting to come together exciting projects like Polars [2] (Pandas alternative), nalgebra [3], Datafusion [4] and Ballista [5]

[1] https://github.com/PyO3/pyo3

[2] https://github.com/pola-rs/polars/

[3] https://docs.rs/nalgebra/latest/nalgebra/

[4] https://github.com/apache/arrow-datafusion

[5] https://github.com/apache/arrow-ballista