Live data from Hacker News

Distributed SQLite for Go applications

github.com

31–40 of 69 posts

Re: Distributed SQLite for Go applications

#31
post #9

Earlier quoted context omitted.

It looks like a dependency of lxd, the successor to lxc, which is being developed by Canonical (of Ubuntu fame). You can see how they're using it in https://github.com/lxc/lxd/tree/master/lxd/cluster . Dqlite and rqlite are not in the same space as postgres and mysql, they're more comparable to tools like Zookeeper, etcd, or Consul[0] - low throughput CP data stores that are generally used for coordinating distribute…

Just what the world needs, yet another would-you-like-my-version-of-clustering-with-that virtual environments tool...

Hopefully someone more acquainted with the ecosystem can respond, but docker is built on lxc, and it appears that the intention of lxd is to do something similar - provide a low-level tool for docker and related tools to use, with some extra tools and security guarantees.

Re: Distributed SQLite for Go applications

#32

Earlier quoted context omitted.

All great points. I was just responding to what seemed like a defeated perspective. By all means contribute to this project. Everything starts somewhere!

I implemented dqlite in Go for convenience (a production-ready raft library was available, github.com/hashicorp/raft). It'd be interesting to implement something similar in C or event batter in rust, so you can link the library from languages than just Go. But not sure there'd be good use cases for that.

Rust is exactly what I wanted to implement mine in -- I figure any performance savings can go towards making SQLite look more performant :)

I've been looking at https://github.com/pingcap/raft-rs

Re: Distributed SQLite for Go applications

#33

Damn it, I was going to work on exactly this -- my goals were slightly different but basically the same paxos/raft/gossip + sqlite and see how far I could take it. Note for those who are interested in cool-stuff-with-SQLite, there's a similar project called RQLite (mentioned in the README): https://github.com/rqlite/rqlite The main differences are laid out in the README, but IMO it really all boils down to the fact t…

Hello, author of dqlite here. Things are still in flux, but yes, I plan to publish benchmarks before making a 1.0 release, as well as improving documentations and introduce some more abstractions to make it easier to use. The reason it might be slower is some cases is that RQlite replicates statements and dqlite replicates WAL frames (where "frames" roughly means "disk pages"), which are typically bigger. I didn't ru…

Hey thanks for putting this out there, it's a pretty cool project.

I see what you meant by it being slower, but that's only replication speed right? maybe that should be pointed out in the documentation when you find time to update it.

Does it seem like the replication patch is going to land in Sqlite? I sure would like it to...

Re: Distributed SQLite for Go applications

#34

Earlier quoted context omitted.

All great points. I was just responding to what seemed like a defeated perspective. By all means contribute to this project. Everything starts somewhere!

I implemented dqlite in Go for convenience (a production-ready raft library was available, github.com/hashicorp/raft). It'd be interesting to implement something similar in C or event batter in rust, so you can link the library from languages than just Go. But not sure there'd be good use cases for that.

There's a Raft implementation in Rust to help get started:

https://github.com/pingcap/raft-rs

Re: Distributed SQLite for Go applications

#35

Damn it, I was going to work on exactly this -- my goals were slightly different but basically the same paxos/raft/gossip + sqlite and see how far I could take it. Note for those who are interested in cool-stuff-with-SQLite, there's a similar project called RQLite (mentioned in the README): https://github.com/rqlite/rqlite The main differences are laid out in the README, but IMO it really all boils down to the fact t…

I'm in the same boat mate. Kudos for getting this far this quickly

Re: Distributed SQLite for Go applications

#36
post #12

sqlite is fantastic piece of software. I am using it in every single side projects of mine. I can not describe how I satisfied with results even in relatively high load (300K pages/day on $5 Linode VPS). I found that most of time using a full featured RDBMS is not necessary depending on use case.(I am doing mostly reads)

> 300K pages/day Does that qualify as "high load"? That's just below 4 pages/second. Given how beefy server CPUs and SSDs are, I would consider something like 100+ requests/second "high load".

You are right. That is why I said "relatively". It is relatively high for my setup.($5 linode with 2gb ram that runs 4 instance gunicorn server.)

Re: Distributed SQLite for Go applications

#37

It's fascinating how Raft has democratized distributed computing -- writing a consistent, distributed state machine now can be done in a few lines of code, assuming you have a Raft implementation lying around, like Hashicorp's excellent Go library. What this project (and similar projects such as Rqlite) doesn't address is the hard problem -- sharding. Raft makes it quite trivial to write a master/slave system where e…

An excellent interactive explanation of Raft can be found here: http://thesecretlivesofdata.com/raft/. It would be interesting as hell to build a small implementation in the language of choice (elixir?, pony?).

Re: Distributed SQLite for Go applications

#38
post #12

sqlite is fantastic piece of software. I am using it in every single side projects of mine. I can not describe how I satisfied with results even in relatively high load (300K pages/day on $5 Linode VPS). I found that most of time using a full featured RDBMS is not necessary depending on use case.(I am doing mostly reads)

> 300K pages/day Does that qualify as "high load"? That's just below 4 pages/second. Given how beefy server CPUs and SSDs are, I would consider something like 100+ requests/second "high load".

Try accounting for peak load times.

Re: Distributed SQLite for Go applications

#39

Earlier quoted context omitted.

Hello, author of dqlite here. Things are still in flux, but yes, I plan to publish benchmarks before making a 1.0 release, as well as improving documentations and introduce some more abstractions to make it easier to use. The reason it might be slower is some cases is that RQlite replicates statements and dqlite replicates WAL frames (where "frames" roughly means "disk pages"), which are typically bigger. I didn't ru…

Hey thanks for putting this out there, it's a pretty cool project. I see what you meant by it being slower, but that's only replication speed right? maybe that should be pointed out in the documentation when you find time to update it. Does it seem like the replication patch is going to land in Sqlite? I sure would like it to...

"slower" means this:

when you perform a SQLite write, SQLite writes a new page on disk to the its write-ahead log. dqlite needs to replicate that page write across all nodes. A page is typically 4kb, so when you do a write on the leader node you need to transfer 4kb across the wire to all other follower nodes and wait for a quorum of them to come back and say "I got it" (which includes writing the page to disk). On the contrary rqlite just needs to transfer and store the SQL text, which is typically less than 4kb.

In practice it's still pretty performant, but I'll publish benchmarks later on.

I plan to submit the patch to SQLite upstream too, yes.

Re: Distributed SQLite for Go applications

#40
post #12

sqlite is fantastic piece of software. I am using it in every single side projects of mine. I can not describe how I satisfied with results even in relatively high load (300K pages/day on $5 Linode VPS). I found that most of time using a full featured RDBMS is not necessary depending on use case.(I am doing mostly reads)

> 300K pages/day Does that qualify as "high load"? That's just below 4 pages/second. Given how beefy server CPUs and SSDs are, I would consider something like 100+ requests/second "high load".

If only it worked like that, we would avoid so many problems.

Sadly you cannot extrapolate at all the load of a server with their numbers of pages seen per day, depending on the use you can easily have peaks of more than 10x that.

Post reply on HN