I have the same grandfathered plan. I wish I had bought more storage when it was available. It looks like we aren't getting any upgrades not that I blame them.
I would be really surprised to find that a tree is faster then a fast cryptographic hash function like SIP hash. Cache misses to main memory are worth 10s of instructions and that number is going up in many cases. Hash functions can be pretty efficient at allowing the processor to run multiple instructions in parallel.
If you know the tree will be cached and/or the keys you have to hash are large then sure a tree might be a win, but hashing a small key might only be the same as two or three cache misses. Comparing tree nodes is not instruction free either.
I think it is really a case by case sort of thing, but there is no substitute for measuring (and nailing down the comparison to specific hash functions).
This is actually an important topic for me. I am implementing a sharding distribution based on consistent hashing using MurmurHash3 as hash function.
I am taking the first 4-bytes of the hash function output and using that. I checked and MurmurHash3 mixes the first and last 8 bytes of hash output as a last step, but I am not sure how much differentiation there is in the first 4-bytes.
A secret seed is not sufficient to prevent DoS vulnerabilities. That is one of the things the creators of SIP hash demonstrated. You can create collisions with MurmurHash3 that work regardless of the seed.
Is comparing a hex-core to a quad-core apples to apples? Haswell per core performance is still better although it will be a long time before we see a hex-core part.
The intent of the test was to measure throughput. Since the API is asynchronous that means the client was submitting as much work as would fit in the queues at both client and server and any latency measurement would be a measurement of how long it takes to execute all queued requests in the pipeline and the pipeline is always kept full.
I am able to get sub-millisecond offsets (as reported by ntpq -p) with m1.large instances, but I have never left them running long. I am not sure what Henning got when he ran. I pointed him to my blog post on the topic http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt...
On bare metal ntpdate reports offsets that are sub microsecond.
I find that nodes sync up quickly if only one of them polls the public pool.
NoSQL doesn't mean NoDurability. Many of them offer better multi-datacenter durability and availability by dropping ACID for BASE. I suspect that most data by volume belongs in a BASE database. Some of them also support a mixture of immediate and eventual consistency in the same database.
kbd+ is a column store (analytic database) and does not partition horizontally. The two things they have in common is that they are both in memory (and kdb+ not necessarily) and support SQL as a query language (kdb+ only supports SQL like stuff). kbd+ does not emphasize stored procedures as a means of bringing multiple queries and arbitrary logic to the data. Nor does it need to since it doesn't partition.
Redis does not support partitioning so it is even more apples to oranges then VoltDB vs. Cassandra. Both VoltDB and Cassandra rely on adding nodes to scale.
"Cassandra's example configuration shows CommitLogSync set to periodic, meaning that we sync the commitlog every CommitLogSyncPeriodInMS ms, so you can potentially lose up to that much data in a crash ... You can also select "batch" mode, where Cassandra will guarantee that it syncs before acknowledging writes, i.e., fully durable mode"
Cassandra has very fine grained control over just about everything to do with consistency and durability. I believe you can pick your desired level of consistency at access time.
"Cassandra writes to disk. VoltDB is an in-memory database. So I gave both systems plenty of RAM to hold the data set and turned Cassandra's consistency settings pretty low."
So in memory in both cases. Cassandra has to write a log, but not synchronously.