Is the SDB dependency necessary?

[ghost]

Is your feature request related to a problem? Please describe.
SDB is not well tested. A custom database is not a good idea.

Describe the solution you'd like
Remove the use of a database in Rizin.

Describe alternatives you've considered
Use alternatives such as:

• SQLite
• Unqlite
• Upscaledb
• ...

Additional context

Also relevant to #209

[XVilka]

The unqlite looks interesting, thanks!

UnQLite is a standard key/value store similar to BerkeleyDB, Tokyo Cabinet, LevelDB, etc. but, with a rich feature set including support for transactions (ACID). Under the KV store, both keys and values are treated as simple arrays of bytes, so content can be anything from ASCII strings, binary blob and even disk files. The KV store layer is presented to host applications via a set of interfaces, these includes: unqlite_kv_store(), unqlite_kv_append(), unqlite_kv_fetch_callback(), unqlite_kv_append_fmt(), unqlite_kv_delete(), etc.

A transactional database is one in which all changes and queries appear to be Atomic, Consistent, Isolated, and Durable (ACID). Like SQLite, UnQLite implements serializable transactions that are atomic, consistent, isolated, and durable, even if the transaction is interrupted by a program crash, an operating system crash, or a power failure to the computer.

UnQLite is released under the 2-Clause BSD license

It even has the fully-featured query/scripting language - Jx9!

//Declare two JSON objects and perform their union.
$a = {
  a : "apple",
  b : "banana"
 };
$b = {
  a : "pear",
  b : "strawberry",
  c : "cherry"
};
$c = $a + $b; // Union of $a and $b
print "Union of \$a and \$b: \n";
print $c;
$c = $b + $a; // Union of $b and $a
print "Union of \$b and \$a: \n";
print $c;

1.1.9 - 2019-05-22	unqlite-db-119.zip	431 KB	This ZIP archive contains all C source code for UnQLite combined into a single source file (the amalgamation). This production-ready package is available for a one-time fee of $20.

Not even an issue to buy the production-ready if it's the same license, etc.

They are also seem to be active in the corresponding GitHub repository.

[XVilka]

upscaledb also should be much faster than SDB:

upscaledb is about 90 times faster than leveldb, and about 140 times faster than BerkeleyDB.

On the other hand, it's not well-maintained:

• Last release was 3 years ago: https://github.com/cruppstahl/upscaledb/releases/tag/release-2.2.1
• Only 15 commits since...

[thestr4ng3r]

I don't think switching sdb to something else makes sense if the new database's code is more complex than sdb. In particular since we are in the process of moving things out of sdb into C structures anyway so queries on the database would be superfluous.
What I would do is to strip down sdb to its very core, i.e. a string hashtable, optionally on top of a cdb. I would completely remove all the json, cas, and everything else that is not needed for rizin. Then the whole thing will also be simple enough to be considered stable.

[XVilka]

I am closing this since we pursued path on cleaning up SDB and removing unnecessary parts. Moreover, in many places we switched to use either hashtable or RzVector for better performance.