DB: reduce supported dbs

[tac0turtle]

Summary

Currently, the SDK uses tm-db which supports 4 different DBs. While this is a nice feature I believe it is actually a determinant to performance.

Problem Definition

Supporting multiple databases leads to not taking advantage of specific DB features that could lead to a good amount of performance gains.

Proposal

Reduce the amount of supported DBs and test multiple different options with the chosen DBs. If a user wants to use a previously supported DB, the SDK should prevent it and provide a reason as to why it's not recommended for use.

If one or two DBs are chosen then the features they offer can be taken advantage of.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[fedekunze]

I think it's better to write docs for the tradeoffs of each DB instead of reducing the support for existing DBs

[tac0turtle]

I think it's better to write docs for the tradeoffs of each DB instead of reducing the support for existing DBs

the problem is people are using dbs for different reasons but in order to actually use the functionality that different DBs offer they need to fork the sdk.

For context, there is a high likely hood that tm-db will move to support less DBs in the future

One example is that IAVL could be simplified and made to have better performance by using some database features, but we aren't really able to do so because there isn't a pre-existing knowledge of what the db will be.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[robert-zaremba]

Many projects are using LevelDB or RocksDB. Here is a feature comparison: https://github.com/facebook/rocksdb/wiki/Features-Not-in-LevelDB

Libra is using RocksDB. I guess there was no real analysis except taking on the home grown technology from Facebook.

[alexanderbez]

There are tradeoffs to each. As long as we can support a common interface easily, I don't see the reason to drastically limit what DBs we support.

[robert-zaremba]

InfluxDB (high performance time series DB) used LevelDB in it's early versions, but they run into small issues with hot backups, and tested other DB. Here is there story.

Geth (go-ethereum) and AVA is using LevelDB.

TurboGeth found that LevelDB was not optimal. They are using LMDB. Monero is also using LMDB.
LMBD note from Wikipedia:

LMDB makes novel use of well-known computer science techniques such as copy-on-write semantics and B+ trees to provide atomicity and reliability guarantees as well as performance that can be hard to accept, given the library's relative simplicity and that no other similar key-value store database offers the same guarantees or overall performance, even though the authors explicitly state in presentations that LMDB is read-optimised not write-optimised.

[robert-zaremba]

Reposting from the IAVL issue (#7100 ). I've reviewed the solutions for state commitments and storage engines: #7100 (comment)

[tac0turtle]

closing in favor of #9092