Google Groups

Re: leveldb


overred Jul 30, 2011 3:32 AM
Posted in group: NoSQL Databases
HI,
  Added benchmark for nessDB,(https://github.com/shuttler/nessDB/blob/
v1.3/src/nessdb_bench.c).
  It seems better than LevelDB in Random-Reads and Sequential-Writes.

  Benchmark results are here:
  https://github.com/shuttler/nessDB#readme

  BTW:
  If set entries to 1000,0000,LevelDB becomes very slow,time consuming
nonlinear.


 nessDB Benchmark(100,0000 entries)
   ===========================
        Keys:                16 bytes each
        Values:                84 bytes each
        Entries:        1000000
        RawSize:        95.4 MB (estimated)
        FileSize:        103.0 MB (estimated)
        ----------------------------------------------------------------------------------------------------------
        nessDB:                version 1.3
        Date:                Sat Jul 30 17:01:18 2011
        CPU:                2 *  Intel(R) Pentium(R) Dual  CPU  T3200  @ 2.00GHz
        CPUCache:        1024 KB

        +-----------------------+-------------------
+----------------------------------------+-------------------+
        |write:                        1.100000 micros/op; |        909090.909091 writes/sec(estimated);
|        93.633478 MB/sec |
        +-----------------------+-------------------
+----------------------------------------+-------------------+
        |readseq:                1.280000 micros/op; |        781250.000000 reads /sec(estimated);
|        65.565109 MB/sec |
        +-----------------------+-------------------
+----------------------------------------+-------------------+
        |readrandom:                4.920000 micros/op; |        203252.032520 reads /
sec(estimated); |        17.057589 MB/sec |
        +-----------------------+-------------------
+----------------------------------------+-------------------+


   nessDB Benchmark(1000,0000 entries)
   ===========================
        Keys:                16 bytes each
        Values:                84 bytes each
        Entries:        10000000
        RawSize:        953.7 MB (estimated)
        FileSize:        1030.0 MB (estimated)
        ----------------------------------------------------------------------------------------------------------
        nessDB:                version 1.3
        Date:                Sat Jul 30 17:12:05 2011
        CPU:                2 *  Intel(R) Pentium(R) Dual  CPU  T3200  @ 2.00GHz
        CPUCache:        1024 KB

        +-----------------------+-------------------
+----------------------------------------+-------------------+
        |write:                        1.265000 micros/op; |        790513.833992 writes/sec(estimated);
|        81.420416 MB/sec |
        +-----------------------+-------------------
+----------------------------------------+-------------------+
        |readseq:                1.327000 micros/op; |        753579.502638 reads /sec(estimated);
|        63.242909 MB/sec |
        +-----------------------+-------------------
+----------------------------------------+-------------------+
        |readrandom:                5.123000 micros/op; |        195198.126098 reads /
sec(estimated); |        16.381679 MB/sec |
        +-----------------------+-------------------
+----------------------------------------+-------------------+

On Jul 11, 1:29 pm, overred <over...@gmail.com> wrote:
> HI,
>    recommend this paper:
>   《Cache Conscious Indexing for Decision-Support in
> Main Memory》,LevelDB is a diskstore implementation and Redis is main
> in memory,if Redis implemented as LevelDB's LSM,it will be
> complex.Simple is beautiful,and performance are also good.For examplenessDB(https://github.com/shuttler/nessDB/tree/v1.3)
>
> On Jul 10, 3:55 pm, Didier Spezia <didier...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > my understanding is leveldb use an implementation of
> > log-structured-merge (LSM) trees. Here is a good
> > academic paper about them:
>
> >http://nosqlsummer.org/paper/lsm-tree
>
> > They are mostly useful to optimize random I/Os at
> > insertion/delete time at the price of a slightly
> > degradation of read access time. They are extremely
> > efficient at indexing data in random order stored on
> > rotational disks (i.e. better than b-trees)
>
> > A disk-based storage solution is not anymore the
> > priority for Redis anyway, but should a "diskstore"
> > project be initiated again, I would expect it to
> > focus on modern storage solutions (i.e. SSD featuring
> > fast random I/Os). In this context, I'm not convinced
> > LSM trees are so interesting.
>
> > Leveldb seems to be a nice library though ...
>
> > Regards,
> > Didier.
>
> > On Jul 9, 6:53 am, Tyler Fryman <tfry...@gmail.com> wrote:
>
> > > I came across leveldb ->http://code.google.com/p/leveldb/onhigh
> > > scalability, it claims to be able to get:
>
> > > "readrandom : 9.775 micros/op; (approximately 100,000 reads per second
> > > before compaction
> > > readrandom : 5.215 micros/op; (approximately 190,000 reads per second after
> > > compaction)"
>
> > > Has anyone used this and/or have any other benchmarks? I also wonder if they
> > > are doing anything that could be used to speed Redis up :]

--
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.