Hacker News Reader

Comment by timg | Hacker News Reader

SQL Databases are so astonishingly slow that I just switched my most intensive app to only use the database for backing up the data to disk and reloading from on startup.

This arrangement is so much faster and easy to understand/measure/optimize for me that I can't see myself going back.

View on HN

Can you be more detailed about what you're doing and the application? Has your solution opened your app to corruption or data loss in the event of app or server crashes?

I have a separate thread that writes changes back to disk at its leisure. There is also a special shutdown/restart mode that I can trigger which stops accepting input from the user and flushes everything to the db.

This can be implemented very simply and has lots of advantages all around.

You're fortunate your data fits in RAM. And it seems you don't have to worry about machine failure causing unwritten data to be lost despite having accepted it from the user?

Cheers, Ralph.

"your data fits in RAM"

Not so. It's not too hard to check if you have some data and then retrieve it from the db as necessary.

Oh, you said earlier "I just switched my most intensive app to only use the database for backing up the data to disk and reloading from on startup" so I thought you meant you only read data from the database on start-up, hence all data fitting in core.

If you're reading data from it whenever you find the data isn't in core then aren't you using the database?

As for the "thread that writes changes back to disk at its leisure", how do you guard against machine failure after accepting data for writing but before it's been written?

Cheers, Ralph.

Reply on news.ycombinator.com