Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADBC connection standard feature #7464

Open
simonaubertbd opened this issue Feb 25, 2024 · 4 comments
Open

ADBC connection standard feature #7464

simonaubertbd opened this issue Feb 25, 2024 · 4 comments
Labels
Client interfaces enhancement New feature or request

Comments

@simonaubertbd
Copy link

Is your feature request related to a problem? Please describe.
Hello all,

ADBC is a database connection standard (like ODBC or JDBC) but specifically designed for columnar storage (so database like DuckDB, Clickhouse, MonetDB, Vertica...). This is typically the kind of stuff that can make MonetDB way faster in user experience.

more info in https://arrow.apache.org/blog/2023/01/05/introducing-arrow-adbc/

Describe the solution you'd like
Implementation of ADBC for monetdb

Describe alternatives you've considered
N/A

Additional context
Here the benchmark with DuckDB
https://duckdb.org/2023/08/04/adbc.html
image

@njnes
Copy link
Contributor

njnes commented Feb 25, 2024

That column orientation helps when ingesting large tables is known (thats basically why the ongoing projects on copy into and binary data shipping are done). Having yet another interface could for some cases help. But in many cases (output through odbc/adbc) is small, which should reduce the difference a lot. This benchmark your looking at isn't that fair in that sense. For which application/use case are you looking into ADBC.

@simonaubertbd
Copy link
Author

Hello @njnes
Well, you answered that fast :)
So, I have two use cases in mind :
-first one would be an etl/data preparation tools that have to insert huge amount of data. ADBC can improve the performance without having to implement a bulk load logic which seems more specific.
-second one is when you have to retrieve thousands of rows with a select in your tool, especially on datavis software. On Tableau, the user experience is awful. (and yes, I perfectly know as of today Tableau does not support ADBC yet)

Am I wrong with that?

Best regards,

Simon

@njnes
Copy link
Contributor

njnes commented Feb 25, 2024

Both indeed require ADBC on both ends, for the later (visualisation) I'd expect the data transfer to improve from this (allthough I'm not so agreeing on the huge volumes going over the line). But on the etl I'd expect you to transfer from an row store, which I guess will put more strain on your production system, which your dba's will not like.
Still its a nice api, still cleaner etc than the odbc, looking for people to take this up ;-)

@arjenderijke
Copy link

For Go there is a package available, that helps with starting an implementation. I had a quick look and there is a part that maps easily on the existing Go driver. But that only part of the adbc spec. But there is a lot of functionality that is different than the existing drivers. Trying to make a Go implementation might be a nice way to figure out how ADBC really works. But first i will need to implement the some additional features in the MonetDB-Go package, such as the binary resultset. That would be required anyway, for adbc. I cannot promise anything, but it is an interesting challenge

@mvdvm mvdvm added enhancement New feature or request Client interfaces labels Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Client interfaces enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants