Hacker News Reader

Comment by thanatos_dem | Hacker News Reader

Digging through the docs, I can't find any actual information of the consistency and isolation guarantees other than "consistent" and "ACID". That's an immediate red flag for me. What are the actual isolation characteristics of the database?

Does it use snapshot isolation? Is it serializable? Is it linerizable? With all the great work Kyle Kingsbury (aka Aphyr) has done on the Jepsen tests, it's pretty clear that claiming to be "ACID" with no additional info isn't sufficient for a modern database.

View on HN

Most docs for technical projects are written that way these days. The author of an api, project or solution will assume an unquestioned adoption "because it's free" from the randome audience with no specifics on how they are solving and more importantly what's different from other cases. I don't know if this is by laziness and writing procrastination, but assuming that your users will know as much as you do on your journey to assemble a solution has become a frustration when I discover new projects like this one.

Likely has a lot more to do with the fact that the intersection between the population that can create such projects and the population that can write clear effective documentation is exceedingly small.

I would also point to Paul Grahams insight around hackers and painters[0]: the population who wants to create such projects is fantasizing about coding, hacking, publishing, bug squashing, and launches. Documentation isn't necessarily pulling them to their PC after a heavy dinner.

[0] http://www.paulgraham.com/hp.html

I feel as if you have a bit of a tone against these authors.

Would you rather the software not exist at all?

SQLite uses serializable isolation by default, this is built on top of that.

I'm also curious how Raft is used and what the resulting guarantees on distributed table operations are, but I'm coming at it assuming good faith, since SQLite is... robust.

Explained in the docs [1]. They replaced the SQLite WAL with one that uses Raft.

Each actor has its own WAL, and so I suppose only operations within a single actor are consistent. Multi-actor transactions use two-phase commits.

[1] http://www.actordb.com/docs-howitworks.html

> SQLite uses serializable isolation by default, this is built on top of that.

That's sort of a meaningless statement tho. Everything in the world is built on top of RAM which is serializable. The real complexity comes in how those foundational blocks are abstracted and combined.

We know that it's not performant at scale to represent an entire database log a single Raft group. So how are the Raft groups structured organized, and how and when do they cross-communicate?

See the docs [1]. As I understand it, each actor is a Raft group. Each actor has its own independent SQLite WAL.

[1] http://www.actordb.com/docs-howitworks.htmlhttp://www.actord...

Reply on news.ycombinator.com