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

Dqlite – High-Availability SQLite

dqlite.io

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Dqlite – High-Availability SQLite

#51

Post by linsomniac »

peterwwillis wrote: post #46

Some thoughts: A consensus protocol is like 1/50th of what you need for a stable, reliable distributed database, and it's developed by a company, so expect it to be abandoned once they stop developing it. I wouldn't use it at work (yet) but could be fun for personal projects.

I wouldn't paint Canonical with that generalization. It's not unheard of that they have dropped projects, but I wouldn't say it's common. But looks like their primary use is LXD, which doesn't seem to be going anywhere...

Re: Dqlite – High-Availability SQLite

#52

Post by free-ekanayaka »

continuations wrote: post #38

> fully async disk I/O I thought Linux didn't support real async disk IO. Is that not the case? If Linux has no real async disk IO, how does Dqlite achieve fully async disk IO?

The support of async disk I/O in Linux differs depending on kernel version and file system type. But it is possible to get 100% async I/O with the is_submit(), and dqlite will leverage that if detected.

There is now a new async I/O API available in Linux (I'm not remembering the name right now, but it was developed by folks at Facebook). It looks promising so I'll check it at some point. (dqlite author here)

Re: Dqlite – High-Availability SQLite

#54

Post by free-ekanayaka »

maurodelazeri wrote: post #48

how is the performance running 3 nodes? how many inserts/reads can be done in average ?

Depends on how fast is your disk, what file system and kernel you use, and how low is your network latency. Difficult to predict. But it's basically as fast as it can get given 1) hardware constraints 2) raft consensus.

If you want light-speed insert/delete, you could probably don't use the disk at all: as long as a majority of your nodes don't die, you won't lose any data. You can also go somewhere in between and save to disk only at specific intervals.

Re: Dqlite – High-Availability SQLite

#56

Post by free-ekanayaka »

cyphar wrote: post #37
rockwotj wrote: post #33

Earlier quoted context omitted.

Based on the following header file, it would seem that they are using this unsupported module. https://github.com/canonical/dqlite/blob/master/src/vfs.h

Yes, you have to use a forked SQLite in order to make use of dqlite. I believe they (the LXD team) are working on upstreaming the WAL changes but due to SQLite's very strong compatibility guarantees they want to be very certain the API and protocol are correct before carving it in stone. Not to mention they are the only major users of the feature, so more widespread use would also be nice before merging it upstream.

Everything you said is very accurate (dqlite author here).

Re: Dqlite – High-Availability SQLite

#57

Post by free-ekanayaka »

rockwotj wrote: post #31

I hope the claim to being fully async I/O is just a buzz term, as it's no longer supported in SQLite. https://www.sqlite.org/asyncvfs.html

It's not a buzz term. It's really fully async disk I/O. Dqlite does not use SQLite's stock vfs implementation for writing to disk, as it's an entirely different model (based on raft).

Re: Dqlite – High-Availability SQLite

#58

Post by zzzcpan »

Since the author is in the comments, what are you planning to do about operations: keeping consistent performance while adding/removing/resyncing nodes, rebalancing, dealing with bitrot, disk errors, disk performance issues, filesystem issues, dealing with unstable network performance, etc.? It doesn't look like there is anything to address operations in the code at the moment.

Re: Dqlite – High-Availability SQLite

#59

Post by bb88 »

Interesting nugget about golang from their FAQ:

https://github.com/canonical/dqlite/blob/master/doc/faq.md

Why C?

The first prototype implementation of dqlite was in Go, leveraging the hashicorp/raft implementation of the Raft algorithm. The project was later rewritten entirely in C because of performance problems due to the way Go interoperates with C: Go considers a function call into C that lasts more than ~20 microseconds as a blocking system call, in that case it will put the goroutine running that C call in waiting queue and resuming it will effectively cause a context switch, degrading performance (since there were a lot of them happening). See also this issue in the Go bug tracker.

The added benefit of the rewrite in C is that it's now easy to embed dqlite into project written in effectively any language, since all major languages have provisions to create C bindings.

Re: Dqlite – High-Availability SQLite

#60

Post by brauner »

free-ekanayaka wrote: post #52
continuations wrote: post #38

> fully async disk I/O I thought Linux didn't support real async disk IO. Is that not the case? If Linux has no real async disk IO, how does Dqlite achieve fully async disk IO?

The support of async disk I/O in Linux differs depending on kernel version and file system type. But it is possible to get 100% async I/O with the is_submit(), and dqlite will leverage that if detected. There is now a new async I/O API available in Linux (I'm not remembering the name right now, but it was developed by folks at Facebook). It looks promising so I'll check it at some point. (dqlite author here)

Jens Axboe, io_uring :)
Post reply on HN