-
Notifications
You must be signed in to change notification settings - Fork 64
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
Add QuestDB output component #115
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for submitting this! All is looking good just some minor clarifications and suggestions.
Also, have you used QuestDB against our existing SQL components? Would be curious if it works out-the-box it and would be happy to extend them if need to do accomodate QuestDB!
Otherwise, your tests are passing on my local but I haven't (yet) tested this against a running QuestDB instance. Will do so soon 🥇
// todo: is this the correct interpretation of max-in-flight? | ||
qdb.WithMaxSenders(mif)(w.pool) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The max_in_flight
field is specifically for internal Bento messages. This WithMaxSenders
looks like it's referring to the number of QuestDB Senders which I believe are different (from QuestDB dotnet docs):
Sender is single-threaded, and uses a single connection to the database.
If you want to send in parallel, you can use multiple senders and standard async tasking.
cc @jem-davies Thoughts on this?
Reminds me that we could probably add a StreamTestOptMaxInFlight
test to the integration tests. Will comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick update here: not sure about the above. Have asked Jem to take a look.
What other value would make sense for the sender count?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pool defaults to a maximum of 64 senders. Ideally, we would use a sender per bento thread/goroutine, but it's not clear to me how many concurrent executions of WriteBatch
can happen at a single time. I'm guessing max_in_flight
is a maximum message count then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can take a look tomorrow - just busy at the moment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's a maximum message count. Happy with approving and seeing how performance looks, and iterating on this at another point
Co-authored-by: Greg Furman <31275503+gregfurman@users.noreply.github.com>
Co-authored-by: Greg Furman <31275503+gregfurman@users.noreply.github.com>
I have not. We implement pgwire and should be compatible with standard postgres clients. I'll give that a shot this week, although we really only recommend using SQL for data extraction and querying, not ingestion. |
Lastly, can you add the docs for the component? Running Once that's added I'll approve and we can ship this bad-boy |
Done! Thank you :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Just fixed the formatting of that description string.
Adds an output component for writing to QuestDB tables using ILP (Influx Line Protocol) as implemented by the official QuestDB Go Client.