Littlest database that could(run-node.com)
run-node.com
Littlest database that could
http://run-node.com/littlest-database-that-could/
8 comments
You are relying on disk io for each update, which can easily be slower than a web request. Either that, or you aren't flushing to disk, which could mean data loss. Modern databases use a write-ahead log to store data that hasn't been flushed to disk yet. If you aren't doing that, you don't have a database, you have a cache.
I'm writing to disk on every insert - mainly just for simplicity for this article. Same with semicolon delim string, normally I serialize to/from JSON. Normally, I only flush to disk periodically using setInterval.
I'll try and do a followup post with actual load tests. I load test using loader.io 35k requests total (increasing to 500 clients) in 20 seconds, I go from 50ms response to 200ms but no higher than that. I'd have to do more specific tests.
This is on a tiny $1/mo 128MB ram VPS but with SSD.
Granted this isn't your native-C powerhouse database, but I would bet 95% of websites get less than 10k requests a day and this could easily handle that load.
I'll try and do a followup post with actual load tests. I load test using loader.io 35k requests total (increasing to 500 clients) in 20 seconds, I go from 50ms response to 200ms but no higher than that. I'd have to do more specific tests.
This is on a tiny $1/mo 128MB ram VPS but with SSD.
Granted this isn't your native-C powerhouse database, but I would bet 95% of websites get less than 10k requests a day and this could easily handle that load.
If database/redis is too heavy and plain json too light then one could use something like Strata [1].
It stores json documents on disk using a b-tree.
[1] http://bigeasy.github.io/strata/
It stores json documents on disk using a b-tree.
[1] http://bigeasy.github.io/strata/
By this measure Memcached offers a greater feature set, an infinitely more robust parser, request concurrency, and doesn't really on a garbage collector. The very fact that this "db" relies on HTTP requests already makes me cringe.
What you have here is a rudimentary persistent cache. "Database" is a bit of a stretch. Could you elaborate on what your production load is?
Dumping the entire database to disk on every write? I can't imagine more than 1 qps.
Hah, nice. But I do not see support for any form of escaping the semicolon, which might happen sooner or later with arbitrary data.
JSON on the wire would clean that up.