Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: meetreks on July 27, 2015, 12:12:49 PM



Title: Level DB vs VSAM KSDS
Post by: meetreks on July 27, 2015, 12:12:49 PM
Hi,

Just wondering what people think about Level DB and its comparisons to VSAM KSDS files.

KSDS files are ordered in key & data value pairs same as Level Db does.

Regards,
Meetreks


Title: Re: Level DB vs VSAM KSDS
Post by: mustyoshi on July 29, 2015, 10:14:28 PM
You should create a wrapper for Level DB calls to the VSAM KSDS library and do some benchmarks.



Title: Re: Level DB vs VSAM KSDS
Post by: hexafraction on July 29, 2015, 10:17:50 PM
You should create a wrapper for Level DB calls to the VSAM KSDS library and do some benchmarks.



Benchmarks alone are not sufficient. Testing failure cases such as crashes, power loss, etc and seeing how they affect the integrity of the data in overt or subtle ways is also important.


Title: Re: Level DB vs VSAM KSDS
Post by: 2112 on July 30, 2015, 12:46:55 AM
Nobody in the core development team has any significant experience with databases.

By not providing a database abstraction layer for the various storage pools (including mempool) they can have a better grip on the whole project.

Check out the historical perspective from 3 years ago:

blah blah blah blah
Gentle reminder to the other bitcoin developers: it is generally best not to feed trolls.  Use the ignore button.

Edit: Actually I just realized that you've asked about VSAM, which would mean that you've compiled it on the (big-endian) IBM mainframe. Does it work at all?


Title: Re: Level DB vs VSAM KSDS
Post by: jonas.schnelli on July 30, 2015, 08:06:27 AM
Nobody in the core development team has any significant experience with databases.
By not providing a database abstraction layer for the various storage pools (including mempool) they can have a better grip on the whole project.

Would it make sense to store the mempool on-disk?

--snip--

LevelDB (kv store) seems pretty much the thing we need for bitcoin-core (there is no need for extensiv querying if you don't want to run a block explorer). What alternatives would you propose today? Would it be worth implementing (balance between (implementation-time+risks <==> benefits-of-a-new-database)? How would you handle migration, testing on serval filesystems?