Permalink
Browse files

Additional formatting and scaling notes.

  • Loading branch information...
1 parent cf32c8b commit c45b1c98c85aea53912714bfc6505c1659f4b4cf @sam committed Aug 13, 2012
Showing with 10 additions and 2 deletions.
  1. +10 −2 README.textile
View
@@ -6,11 +6,19 @@ This is just a simple benchmark to compare "Hazelcast":http://www.hazelcast.com
h4. Hazelcast
-A persistent (to disk) Key/Value store with strong availability guarantees. Turns out, it's not very fast relative to other popular Key/Value stores like Redis. At about 3.5ms for a key fetch over 10,000 keys, it's not exactly slow as that's moderately faster than you might expect for an RDBMS, but it's performance makes it the slowest K/V store I've tested so far. So if you value Durability, Consistency, and High Availability in an Embedded K/V store while still maintaining better-than-RDBMS performance, then Hazelcast might be what you're looking for. It's worth mentioning that Hazelcast should also scale horizontally very well. Hazelcast only requires a single JAR, which makes it very easy to get started with.
+A persistent (to disk) Key/Value store with strong availability guarantees. Turns out, it's not very fast relative to other popular Key/Value stores like Redis. At about 3.5ms for a key fetch over 10,000 keys, it's not exactly slow as that's moderately faster than you might expect for an RDBMS, but it's performance makes it the slowest K/V store I've tested so far.
+
+If you value Durability, Consistency, and High Availability in an Embedded K/V store while still maintaining better-than-RDBMS performance, then Hazelcast might be what you're looking for. It's worth mentioning that Hazelcast should also scale horizontally very well.
+
+Hazelcast only requires a single JAR, which makes it very easy to get started with.
h4. Infinispan
-Intended to be a straight up cache, compatible with the MemCache API. It's data set is in memory, supports locality (Hazelcast's NearCache) and a more advanced eviction algorithm (LIRS; no idea how much this contributes to overall performance really). For the embedded instance in this benchmark it's only about half the speed of a JRuby Hash, which is very impressive. Infinispan requires nine JARs to run an embedded instance, which is kind of the opposite of "impressive". Maven makes that a non-issue if you're deploying as a unified JAR, but if you intend to run as a more traditional file-based Ruby project you have to decide wether you feel like copying dependencies at deploy, or committing all those JARs to your repository.
+Intended to be a straight up cache, compatible with the MemCache API. It's data set is in memory, supports locality (Hazelcast's NearCache) and a more advanced eviction algorithm (LIRS; no idea how much this contributes to overall performance really). For the embedded instance in this benchmark it's only about half the speed of a JRuby Hash, which is very impressive.
+
+Infinispan should also scale out horizontally very well as Maps can be "sharded", nodes can be rack aware (through configuration) and keys locally cached on access.
+
+Infinispan requires nine JARs to run an embedded instance, which is kind of the opposite of "impressive". Maven makes that a non-issue if you're deploying as a unified JAR, but if you intend to run as a more traditional file-based Ruby project you have to decide wether you feel like copying dependencies at deploy, or committing all those JARs to your repository.
h3. Project Structure

0 comments on commit c45b1c9

Please sign in to comment.