Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 303 Vote(s) - 3.57 Average
  • 1
  • 2
  • 3
  • 4
  • 5
High performance persistent key value store for huge amount of records

#1
The scenario is about 1 billion records. Each record has 1kb data size and is store in SSD.
Which kv store can provide best random read performance? It need to reduce disk access to only 1 time per query and all of the data index will be stored in memory.

Redis is fast but it's too expensive to store 1 TB data in memory.
LevelDB reads disk several times per query.
The closest one I found is fatcache but it's not persistent. It's an SSD-backed memcached.

Any suggestions?
Reply

#2
Have you looked at aerospike ? I haven't use it, but they claim to have good performances on SSD.
Reply

#3
You may want to try [RocksDB][1], it's a facebook library which optimized for SSD storage. You can also try [Ardb][2], it's a redis protocol compatible NoSQL DB build on RockDB/LevelDB/LMDB.


[1]:

[To see links please register here]

[2]:

[To see links please register here]

Reply

#4
[RocksDB][1] might be the choice for you, which is optimized for fast storage like memory and flash-disk, and its highly customizable. If your application is read-only after initial bulk-load, then you can config RocksDB to compact everything in one single big file. In that way, reads are guaranteed to have at most single I/O. However, if your application handles both reads and writes, then in order to have at most one I/O per read, you will need to sacrifice the write performance as you need to config rocksdb to compact very often, and that hurts write performance.

Tuning guide for RocksDB can also be found [here][2].


[1]:

[To see links please register here]

[2]:

[To see links please register here]

Reply

#5
LMDB is faster than RocksDB and uses 1/3rd as much memory. Also LMDb requires no tuning; RocksDB requires careful tuning of over 40 parameters to get performance that approaches LMDB's.

[To see links please register here]


Also LMDB is fully transactional and 100% crash-proof, RocksDB is neither.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through