So since Hashicorp survived Aphyr test, it should be fine.
And once I did: https://github.com/rqlite/rqlite/issues/5
aphyr himself chimed in.
Some people don't use it for the distribution, but just like a HTTP API in front of SQLite.
Suggestion: have you considered running office hours and inviting your users to chat to you about what they're doing with it?
I've been doing that for six months for my Datasette project and I've had over 60 conversations now, it's been a revelation - it almost completely solved the "I don't know how people are using this" problem for me, and gave me a ton of ideas for future directions for the project.
I wrote more about that here: https://simonwillison.net/2021/Feb/19/office-hours/
Now that I know two folks do it, I'll have to give it serious thought. Thanks for the blog post ref
RQlite was perfect as our software is an addon for a legacy platform. We needed an easy low-access way of installing a distributed datastore.
Just asking so that I can piggyback on your research :)
I feel like this post is leaving out critical pieces of information, like why the URL can't be deterministic or data about comparisons of different approaches.
At what cluster size and concurrency does asking every node break down?
I have been meaning to take a closer look at rqlite and want to understand more about it.
Yes, you're right every node knows the Raft network address of every other node. But Raft network addresses are not the network address used by clients to query the cluster. Instead every node also exposes a HTTP API for queries.
So code needs exist to share information -- in this case the HTTP API addresses -- between nodes that the Raft layer doesn't handle.
None, a follower only needs to ask the leader. So regardless of the size of the cluster, in 6.0 querying a follower only introduces a single hop to the leader before responding to the client. While this hop was not required in earlier versions, earlier versions had to maintain state -- and stateful systems are generally more prone to bugs.
- stateful system, with extra data stored in Raft. Always a chance for bugs with stateful systems.
- some corner cases whereby the state rqlite was storing got out of sync with the some other cluster configuration. Finding the root cause of these bugs could have been very time-consuming.
- certain failure cases happened during automatic cluster operations, meaning an operator mightn't notice and be able to deal with them. Now those failures cases -- while still very rare -- happen at query time. The operators know immediately sometime is up, and can deal with the problem there and then, usually by just re-issuing the query.
I remember building a janky version of sqlite+raft for Stripe's 2014 CTF. I'm sure others here have made a similar comment when rqlite gets posted to HN.
One key principle of rqlite has always been quality, clean design, and simplicity of operation. So I've been reluctant to add a feature -- in this case Request Forwarding -- until I was sure it would be a clear win and not make rqlite less robust. After years of experience with the system now, I'm happy it can be added in a high-quality manner.
Having proxies be aware of the leader, or having clients being able to access nodes directly instead of behind said proxies, is a lot more complexity.
By the way, when I ask about "the browser" I'm also thinking of stuff like electron apps and progressive web apps.