Google Groups

Re: HyperDex vs Redis


Salvatore Sanfilippo Feb 23, 2012 6:21 AM
Posted in group: Redis DB
Hello Jack,

whatever is the design, you'll be able to run using just one thread
with the same performances, so we'll never have lower results per core
if we run with a single core. However there are no alternatives to
key-based locking in Redis, accessing with different threads to the
same data structure means to kill the performance with locking, to
make the implementation more complex, and so forth.

I mean, everything else is the same: Redis Cluster, and so forth,
Redis API, atomicity. The only difference is that it will be good if
we can specify to Redis to use more cores to serve requests.

If we handle with threads just the networking side, it is just like to
have a global locking to the key space, since a single request is
performed at a given time. Exactly like now, but the networking side
handled by multiple threads can improve performances if we see the
memcached experience about it.

If we have a way to also serve queries about different keys with
threads maybe it is an improvement over the above model, maybe not,
it's a matter of performing tests.

I can't see how introducing support for multiple cores may make Redis
worse than that, if the implementation used can "scale down" to a
single thread with the same performances of today.

Salvatore

On Thu, Feb 23, 2012 at 3:06 PM, Jak Sprats <jaks...@gmail.com> wrote:
> Hi Salvatore,
>
> Just a warning: key based locking is analagous to row based locking in
> a RDBMS and it has all sorts of issues, the biggest one is deadlock
> (e.g. 1000 concurrent connections need Key88, the connections pile up
> and when key88 is unlocked, they need to be awakened efficiently).
> Alot of RDBMSes went to MVCC for this reason, and MVCC in redis (or
> anywhere) will be a lot of work.
>
> A cluster can run efficiently on many cores, in many ways better than
> a multithreaded application, as clusters can taskset to a core, have
> fewer context switches, higher L1/L2 hit ratios (lower L3), optimal
> NUMA memory placement, possibilities to isolate NIC to core via IRQ
> affinity, and biggest and best, no deadlocks/mutexes, nothing thread-
> wise.
>
> The huge downside to a cluster on a single machine is the cross-node-
> intersection/union, here a multi-threaded app would have all the ZSETs
> in a single memory space and it would be a normal (key locking)
> intersection/union.
>
> Also w/ multiple threads serving the network layer, command based
> replication becomes tricky, there needs to be a consistent (w/ what
> happened across many threads on a single machine) ordering to the
> slave replication log, which adds another very trick thread mutex
> dimension to the whole equation, and the slave must replay them
> serially (to guarantee ordering), so it may not be able to keep up.
>
> Why not a cluster as a single machine multi threaded app, w/ an
> efficient way to handle cross-node-intersections/joins?
>
> - jak
>
> On Feb 23, 7:06 am, Salvatore Sanfilippo <anti...@gmail.com> wrote:
>> On Thu, Feb 23, 2012 at 10:49 AM, Dvir Volk <d...@doat.com> wrote:
>> > you mention there that redis is going to be able to use multiple cores soon.
>> > what do you mean by that?
>>
>> Hi Dvir,
>>
>> I want to use threads in Redis to improve the performances for the
>> single instance case, but at the same time I want to have a design
>> that will not make it slower when using a single core.
>>
>> The idea is to start with the networking layer that is where a lot of
>> time is lost, we could have N threads reading and parsing requests
>> from clients, and then serving the result back to clients. A further
>> step can be to also call commands in the context of different threads
>> with key-based locking.
>>
>> After Redis 2.6 RC1 release I'll start experimenting with a few
>> branches to see what is the best balance to internal simplicity and
>> ability to use more threads, but I think it is a change we can't
>> avoid, the future appears to really belong to computers with many many
>> cores, and Redis should try to take advantage of this in the best way.
>> If there are 4 cores in a computer it is fine to run four instances,
>> but maybe in two or three years we'll start to commonly see computers
>> with 16, 64, 128 cores... and it starts to be not practical :)
>>
>> Salvatore
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On Thu, Feb 23, 2012 at 11:31 AM, Salvatore Sanfilippo <anti...@gmail.com>
>> > wrote:
>>
>> >> My investigation on those benchmarks ->
>> >>http://news.ycombinator.com/item?id=3622888
>>
>> >> Basically YCSB is an epic fail in the way it is conceived, instead of
>> >> giving use cases and try the best implementation with different DBs,
>> >> Different DBs are forced to a given data model using a layer. For most
>> >> DBs this is the native data model, in others (like Redis) it is
>> >> simulated using native operations.
>>
>> >> The benchmark was also comparing single-core Redis against multi-core
>> >> Hyperdex.
>>
>> >> Cheers,
>> >> Salvatore
>>
>> >> On Wed, Feb 22, 2012 at 10:47 PM, Salvatore Sanfilippo
>> >> <anti...@gmail.com> wrote:
>> >> > Reality is extremely less interesting, as usually:
>>
>> >> > Redis and memcached provide more or less the upper limit figure in
>> >> > queries per second per core.
>> >> > Memcached can also use more cores automatically (something that Redis
>> >> > will do at some point), and with Redis you need multiple instances,
>> >> > but that's an upper level for a networked server, since both this
>> >> > systems serve data from memory, and are reasonably well optimized.
>>
>> >> > What I mean is, I can modify Redis to just return always "foo", and
>> >> > I'll still get 150k ops/sec per core.
>>
>> >> > So what is happening here is that:
>>
>> >> > 1) Benchmark "E" is just a primitive that Redis does not provide, the
>> >> > comparison here is just a bit of useless marketing material.
>> >> > 2) In all the other tests, probably they are comparing single-core
>> >> > Redis with multi-core HyperDex, or multi-node HyperDex. To give you an
>> >> > example Redis LPUSH can easily insert 1 million items per second into
>> >> > lists, but if you push against four instances at the same time, one
>> >> > per core, you can reach 3/4 million inserts per second. This does not
>> >> > mean we should write "four millions operations per second11!1!!!one"
>> >> > in our home page.
>> >> > 3) Probably data set fits in memory anyway in the benchmark test case.
>> >> > 4) Methodology is not shown at all, so everything in this page is more
>> >> > or less useless.
>>
>> >> > I think that to provide false illusions is also bad when marketing a
>> >> > product, it can help the first three months, but then what happens?
>>
>> >> > "He who chases two rabbits, catches neither one."
>>
>> >> > (Sicilian proverb, kindly translated by Ted Nyman).
>>
>> >> > Salvatore
>>
>> >> > On Wed, Feb 22, 2012 at 7:54 PM, Riyad Kalla <rka...@gmail.com> wrote:
>> >> >> HyperDex (http://hyperdex.org/ ) is the new K/V store out of Cornell
>> >> >> that
>> >> >> uses some unique hashing to allow searching and retrieving records
>> >> >> without
>> >> >> key values (I haven't dug deep, this is all high-level blurbs at this
>> >> >> point).
>>
>> >> >> They just added Redis performance comparisons today (bottom graph):
>> >> >>http://hyperdex.org/performance/
>>
>> >> >> Curious what "Workload E" was, but they claim better performance in
>> >> >> every
>> >> >> case with instant consistency across multiple nodes (no idea how) as
>> >> >> well as
>> >> >> failover that sounds similar to a Cassandra/Riak/HBase at least using
>> >> >> the
>> >> >> word-pictures from the site.
>>
>> >> >> Anybody know more about HyperDex?
>>
>> >> >> --
>> >> >> You received this message because you are subscribed to the Google
>> >> >> Groups
>> >> >> "Redis DB" group.
>> >> >> To post to this group, send email to redi...@googlegroups.com.
>> >> >> To unsubscribe from this group, send email to
>> >> >> redis-db+u...@googlegroups.com.
>> >> >> For more options, visit this group at
>> >> >>http://groups.google.com/group/redis-db?hl=en.
>>
>> >> > --
>> >> > Salvatore 'antirez' Sanfilippo
>> >> > open source developer - VMware
>>
>> >> >http://invece.org
>> >> > "We are what we repeatedly do. Excellence, therefore, is not an act,
>> >> > but a habit." -- Aristotele
>>
>> >> --
>> >> Salvatore 'antirez' Sanfilippo
>> >> open source developer - VMware
>>
>> >>http://invece.org
>> >> "We are what we repeatedly do. Excellence, therefore, is not an act,
>> >> but a habit." -- Aristotele
>>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups
>> >> "Redis DB" group.
>> >> To post to this group, send email to redi...@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> redis-db+u...@googlegroups.com.
>> >> For more options, visit this group at
>> >>http://groups.google.com/group/redis-db?hl=en.
>>
>> > --
>> > Dvir Volk
>> > System Architect, The Everything Project (formerly DoAT)
>> >http://everything.me
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Redis DB" group.
>> > To post to this group, send email to redi...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > redis-db+u...@googlegroups.com.
>> > For more options, visit this group at
>> >http://groups.google.com/group/redis-db?hl=en.
>>
>> --
>> Salvatore 'antirez' Sanfilippo
>> open source developer - VMware
>>
>> http://invece.org
>> "We are what we repeatedly do. Excellence, therefore, is not an act,
>> but a habit." -- Aristotele
>
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele