4 ms·
> It seems as if it's designed for situations where you're doing a lot of table scans. This is not quite true. Lockfree data structure work exceptionally well
by nikita 14y ago
> It seems as if it's designed for situations where you're doing a lot of table scans.
This is not quite true. Lockfree data structure work exceptionally well for a lot of small concurrent reads and writes. If you look at the benchmarking code: https://github.com/memsql/bench/blob/master/sql_database.py https://github.com/memsql/bench/blob/master/sql_database.py you will notice that there are a lot of queries like "fetch by pk/guid".
The trade-offs are: taking a hit the first time you run the query, being limited to the amount of RAM, limited set of features for this release. The benefits are throughput for "fetch by pk/guid" transactions and predictably low latencies.
- heretohelp 14y agoExcellent, you've answered my question! Thank you. :)
- continuations 14y ago> being limited to the amount of RAM What will happen if the data grows to larger than the RAM?
- nikita 14y agoWe stop accepting write queries. We also work on sharding. RAM gets you pretty far 12K buys a terabyte these days.
- malkia 14y agoSo you are only safe, as the speed of HDD writing sequentially to the disk (it could be even directly to the volume, not even running from fs)?
- moe 14y agoOut of curiosity, where do you get an 1T-box for 12K? Spec'ing those out at Dell I arrive at >40k. I know channel-partner or own build can trim that significantly, but your price sounds pretty amazing.