3 ms·
One thing to keep in mind with LevelDB is that it has been created with web browsers and mobile devices as the main use case, NOT as a high-performance data sto
by krenoten 13y ago
One thing to keep in mind with LevelDB is that it has been created with web browsers and mobile devices as the main use case, NOT as a high-performance data store. If the features of LevelDB appeal to you, however, you may want to check out Basho's fork of it that they have tuned for use in a server environment: https://github.com/basho/leveldb https://github.com/basho/leveldb . If this is interesting to you, check out Matthew Von-Maszewsky's recent talk at the Ricon East conference about his work tuning it: http://www.youtube.com/watch?v=vo88IdglU_8 http://www.youtube.com/watch?v=vo88IdglU_8
- kposehn 13y agoThanks for posting the follow-up info on tuning!
- rescrv 13y agoThere's also the HyperLevelDB fork which outperforms the Basho one by quite a bit for random write workloads. Here's a write up about it: http://hackingdistributed.com/2013/06/17/hyperleveldb/ http://hackingdistributed.com/2013/06/17/hyperleveldb/
- DAddYE 13y agobasho and hyperlevel should be two easy targets for this gem, this week I'll plan to adapt the code (if necessary)
- rvagg 13y agoThis is such a silly meme. It IS a high performance data store, forget what you THINK it is/was designed for or what people say about it in that respect, rely on actual data to see if it works for your data & load. There's no competition if you want to compare it to an external data store it'll beat the alternatives easily. Comparing to other embedded data stores and the 2 main forks (basho and HyperDex) and alternatives like MDB is a different matter and this is where the nature of your data, the way you access the store (single thread? multi?) and your real load are much more relevant than heresay and benchmarks that bear no relation to your actual needs.