5 ms·
It's scales so perfectly we are deploying it across 3 datacenters, each with four 384 core machines with 3 terabytes of RAM. I can't speak highly enough about
by quinthar 8y ago
It's scales so perfectly we are deploying it across 3 datacenters, each with four 384 core machines with 3 terabytes of RAM. I can't speak highly enough about sqlite and the team behind it.
- gregmac 8y agoWhat sort of volume is this handling? Is the dataset in memory, or if not, what size and type of I/O is backing this? It seems like a ton of CPU, whereas in my experience typically I/O is the primary bottleneck for database loads.
- nutjob2 8y ago"in my experience typically I/O is the primary bottleneck for database loads" Not when you have potentially neatly 3TB of memory cache. Of course it all depends on the dataset.
- basilgohar 8y agoNote the second comment in the following thread: https://news.ycombinator.com/item?id=12739771 https://news.ycombinator.com/item?id=12739771 quinthar posted in quite a lot of detail there as well, so it may provide some context.
- charleslmunger 8y agoThe link says that it requires turning synchroous off, which means that you won't be waiting for real I/O on transactions, since no fsync calls are emitted. Add that to a huge amount of RAM for cache, and it's very reasonable to be CPU bound... So long as you don't mind data loss or corruption on power loss or kernel panic...
- latch 8y agoDoesn't a BBU Raid controllers largely address the power loss concern? And, I always thought BBU Raid controllers were just absolute common sense for any serious database (until everyone went cloud and suddenly basics like dual network card, dual PSU and raid controllers didn't fit Amazon's desire to sell complexity).
- singron 8y agoWithout fsync, the dirty page can sit in RAM and not even be sent to the disk, so a battery backup for the disk wouldn't solve data loss.
- latch 8y agoRight..but you leave fsync on in this case, no? This might be incompatible with the locking required by this server-process edition though (I guess, no clue). But more generally speaking, fsync=on with a proper raid controller gives massive performance boost (like orders of magnitude) while being relatively resilient to power loss.
- nh2 8y agoWell, data will be lost if anything below the OS buffer cache crashes (source http://sqlite.1065341.n5.nabble.com/How-dangerous-is-PRAGMA-Synchronous-OFF-tp4250p4256.html http://sqlite.1065341.n5.nabble.com/How-dangerous-is-PRAGMA-...). The BBU protects from power loss of the HDs, but not power loss or general failure of the mainboard or any other important component. PAlso BBUs can run out of battery so a flash backed BBU is generally recommended.
- le-mark 8y agoYou are using this particular branch in production, deployed as you mention, or sqlite in general? Some more info about this use case would be very interesting if you can share!
- da_chicken 8y agoI don't understand why you'd use SQLite for a deployment this heavy over PostgreSQL or MySQL. Yes, SQLite is fantastic, but why would you choose to do it this way?
- emn13 8y agoIt's faster? Simpler? Conversely, why would you choose one of those alternatives? (I don't actually think there aren't any reasons to do so, mind you, but I can well imagine that if you really KISS, well - even at impressive sizes sqlite makes sense).
- vesak 8y agoSQLite's typing is rather weak, is it not? That might be a tad scary for someone used who relies on that part of PostgreSQL.
- kjax 8y agoIt sure is. After recently porting a large application from SQLite to Postgres, much of my time was spent casting types and ensuring code was updated to input the correct types into Postgres. All in all, the changes were for the better, as many bugs were discovered and resolved in the process.
- da_chicken 8y agoWell, the historic one is, "because you need multiple concurrent data writers." But, that's what this branch is supposed to be for. So now the reason is: "because you need multiple concurrent data writers from multiple processes." And it might also be "you need multiple concurrent data writers and care about your data enough to not risk loss in the event of a system crash or power failure" since it uses PRAGMA synchronous=OFF.
- andrewguenther 8y agoBecause SQLite is often the right tool for the job, more so than Postgres and MySQL. It scales insanely well and requires minimal configuration and near zero administration. I try to use SQLite for as long as is feasible in my projects purely because it "just works". Don't let the "Lite" fool you. Depending on your needs, you can scale to 10s of thousand of users using just SQLite. Or not! It is all about knowing your system and properly evaluating your options. I choose to use SQLite because it often fits the use case of small to medium projects the best.
- viburnum 8y agoSo is there one SQLite process running on each of the 384 cores?
- est 8y agoomg is this Expensify? https://news.ycombinator.com/item?id=16118776 https://news.ycombinator.com/item?id=16118776