Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Distributed SQLite for Go applications

github.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Distributed SQLite for Go applications

#61

Post by [deleted] »

zzzcpan wrote: post #49
otoolep wrote: post #43

Earlier quoted context omitted.

I don't agree. The whole point of putting a solid Raft implementation at the center of your system is deal with the faults. I myself built a simple distributed state machine which deals with faults perfectly well. Of course I built on top of a good Raft implementation, which certainly is not a few lines of code. https://github.com/otoolep/hraftd

No, Raft doesn't deal with the faults, it deals with consensus and can help tolerate certain faults. You then deal with the faults by other means. And even on a fast and reliable local network where Raft can work well, once you have a significant amount of data replacing failing nodes, healing broken records, resyncing, rebalancing all without affecting operations is not trivial and unlikely to be done properly.

[deleted]

Re: Distributed SQLite for Go applications

#62

Post by otoolep »

otoolep wrote: post #50
zzzcpan wrote: post #49

Earlier quoted context omitted.

No, Raft doesn't deal with the faults, it deals with consensus and can help tolerate certain faults. You then deal with the faults by other means. And even on a fast and reliable local network where Raft can work well, once you have a significant amount of data replacing failing nodes, healing broken records, resyncing, rebalancing all without affecting operations is not trivial and unlikely to be done properly.

> Raft doesn't deal with the faults I'm not sure what this means. The Raft paper explicitly states that Raft is a fault-tolerant system -- and by definition this means it deals with faults. To quote the paper: "Replicated state machines are used to solve a variety of fault tolerance problems in distributed systems." Raft is a type of replicated state machine. To say that "Raft doesn't deal with faults" is not correct…

Rereading this, I see what you mean in the sense that if dealing == "fixing the fault", but tolerating == "keep going in the face of faults". So yes, you are right -- Raft doesn't fix the faults. One must still fix the network, replace the node etc. When I wrote "deal" I meant "tolerate the fault", but I think "deal" meant "fix the fault" to you.

Re: Distributed SQLite for Go applications

#63

Post by atombender »

shalabhc wrote: post #60
lobster_johnson wrote: post #59

Earlier quoted context omitted.

ActorDB is very interesting. It uses two-phase commit, similar to CockroachDB, TiDB and Spanner, but as I understand it, relies on locking to update the participating shards. I'm not sure how well ActorDB performs in a large cluster with lots of distributed transactions, but I've never tried it.

IIUC these are micro shards - e.g. one sqlite instance per user. Depending on the key, distributed transactions may be rare.

The size of the shards depends on the data. ActorDB wants you to design your application around explicit containment boundaries (the actors). For example, a social networking site might collect all of a single user profile's data in one actor. Or there might be one actor for each grouping of a user's stuff (one actor for all of user X's photos, one actor for all of their tweets, etc.). So the size of those actors might not be "micro". You could decide to shard it further, of course, e.g. shard a user's photos by date. Since ActorDB supports cross-actor queries (though not joins), you can still query multiple shards at the same time.

But ActorDB does seem to promote inter-actor transactions, and a pattern I've seen encouraged is where you use shared actors (especially with the key-value store functionality) to keep some kind of central lookup table that your app then can use to find actors. For example, if you're modeling HN with ActorDB, you'd have a global list of stories, but each story/comment tree could be a separate actor, and each user would be a separate actor. Posting a story only needs to access the story actor, but to post a comment transactionally, you have to do a transaction that inserts the comment and updates the user's comment history together.

Re: Distributed SQLite for Go applications

#64

Post by riku_iki »

bbayer wrote: 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)

> using a full featured RDBMS is not necessary

But what kind of overhead postgress adds comparing to sqlite?

Advantages are clear:

- more advanced functionality is available when you need it.

- pgsql likely has better performance comparing to sqlite

Re: Distributed SQLite for Go applications

#65

Post by shalabhc »

atombender wrote: post #63
shalabhc wrote: post #60

Earlier quoted context omitted.

IIUC these are micro shards - e.g. one sqlite instance per user. Depending on the key, distributed transactions may be rare.

The size of the shards depends on the data. ActorDB wants you to design your application around explicit containment boundaries (the actors). For example, a social networking site might collect all of a single user profile's data in one actor. Or there might be one actor for each grouping of a user's stuff (one actor for all of user X's photos, one actor for all of their tweets, etc.). So the size of those actors mig…

> The size of the shards depends on the data.

You're right. What I meant was that a 'shard' in actordb isn't meant to be 'all data on one machine/node' - which is how many other databases view sharding, but is expected to be much more fine-grained. Thanks for the other explanations.

Another interesting implementation aspect is its use of LMDB for storing the SQLite pages.

Re: Distributed SQLite for Go applications

#66

Post by free-ekanayaka »

anentropic wrote: post #57
free-ekanayaka wrote: post #19

Earlier quoted context omitted.

BedrockDB requires to operate a separate process, whereas you can embed dqlite in your Go application (pretty much in the SQLite philosophy). Also, afaik BedrockDB patches upstream SQLite with some more intrusive changes than dqlite (e.g. for supporting concurrent writes). The SQLite patch that dqlite requires is pretty minimal and just adds hooks to internal WAL events.

so the use case is: you're building a distributed Go application that needs some shared state in the form of an SQL db?

Yes, dqlite is currently used for clustering support in LXD 3.0: https://github.com/lxc/lxd

Re: Distributed SQLite for Go applications

#67

Post by PirateBay »

eloff wrote: post #23
PirateBay wrote: post #5

Projects like this(sparsely documented, tiny) always seem to be just internal tools that the company just threw out into the world just because they can. Not that I'm ungrateful, but without any sort of explanation as to why I'd use this over a clustered MySQL or Postgres it's a little hard to make heads or tails about whether I should care.

It's work someone else did and shared with you for free. It strikes me as lazy to complain about how you don't know what to do with it and want everything spoon-fed to you. It's go+sqlite+raft. That means it's an embedded database for Go that can be used across a cluster of Go processes while maintaining ACID goodness. I got that out of it in 2 minutes of looking at the readme, I think you could manage the same if yo…

I don't ever remember complaining, just saying I have no idea what it's even useful for. This is usually where a good, comprehensive, thoughtful readme helps people figure out why they should care about a project over others that do the same thing and what sets it apart. But I guess expecting explanations for libraries is spoonfeeding. Oh well!

Re: Distributed SQLite for Go applications

#68

Post by jknoepfler »

vertex-four wrote: post #56
jknoepfler wrote: post #51

Earlier quoted context omitted.

is raft a fancy name for distinguished leader multipaxos?

Raft does the things that Paxos does, using a mechanism that is much simpler for humans to understand and therefore implement correctly.

if it does the things paxos does, it's provably isomorphic to paxos. what I saw in the demo was a flavor of paxos that's been around since the early 90's, I'm pretty sure that's where the credit is due.

Re: Distributed SQLite for Go applications

#69

Post by vertex-four »

jknoepfler wrote: post #68
vertex-four wrote: post #56

Earlier quoted context omitted.

Raft does the things that Paxos does, using a mechanism that is much simpler for humans to understand and therefore implement correctly.

if it does the things paxos does, it's provably isomorphic to paxos. what I saw in the demo was a flavor of paxos that's been around since the early 90's, I'm pretty sure that's where the credit is due.

You can't think of any case, for anything, in which you can do something in two (or more!) different ways, but one of them is simpler to explain, understand, and implement?
Post reply on HN