Feature: Redis as database (instead/along of LevelDB)

[ajunge]

We are setting a cluster of geth nodes but we need to separate the database from the geth node, so all the geth nodes share the database. We need to bootstrap new nodes fast, and the sync is the bottelneck right now. Moving the "blockchain database" from LevelDB to a concurrent key/value data store like Redis could solve this problem.

Salu2
An3

[fjl]

Which version are you using? We have addressed many sync issues in the latest release, 1.4.6.

[ghost]

The normal (as opposed to fast) sync is still is a 20GB+ directory per node. A separation of concerns (i.e. cluster of geth-server in one layer, cluster of geth-data in a layer below) would open a huge gate for scalation.

[fjl]

Reading more carefully now, I see that you are specifically talking about bringing nodes online quickly.
One thing you can do is to simply copy the <datadir>/chaindata directory after sync. You can do this while the node is not running.

Is there a specific reason why you need to run an archive node (without --fast sync)?

[ghost]

@fjl Today, copying the /root/.ethereum/chaindata is a lengthy process (i.e. you can't do it in less than a minute in the cloud).

My users asked me to have nodes with full synchronisation, I couldn't find yet a clear document explaining me what I'm really losing if I just do a --fast sync. But, it is worth to mention that I feel that we are just "kicking the can forward", in the end, as we need to provision a directory larger than 1GB (Still a slow spinning of nodes).

So, the question is, if there have been discussion on extending the supported databases of geth. We put this issue here, in order to propose this development to be done and add it into our roadmap.

[ajunge]

Hi,
Because we need to start a fresh node in a couple of seconds. Even if we do fast-sync, it takes hours to sync.

The copy chain data approach it also takes like 30 minutes to copy from one node to the other, we are seeking faster times

[ghost]

So @fjl , just to clarify: We want to take over the supporting of Redis (And maybe, postgreSQL) as databases. We see in it a key component for scalation of geth.

[ghost]

@fjl If we make this PR, what do you see will be the stoppers to have it merged?

[fjl]

Sharing a database among several active nodes might work, but some edge cases come to mind. You can try implementing the Database interface in package ethdb and see how it goes.

I think what you're after is some kind of read-only RPC server that can execute contract calls and that you can send transactions to. Is that right?

My users asked me to have nodes with full synchronisation, I couldn't find yet a clear document explaining me what I'm really losing if I just do a --fast sync.

You 'lose' the computed state of very old blocks. This state is almost never useful in practice unless you want to access contract storage from the past. We are looking into implementing 'state pruning' which will delete this state unless you explicitly ask to keep it.

[fjl]

If we make this PR, what do you see will be the stoppers to have it merged?

We will definitely consider merging it if it actually works.

[ghost]

Cool. Glad to have had this conversation. We are closing this issue and start the planning for this PR.

[ajunge]

Working on it!

[sandys]

@hermanjunge - sorry to ping you, but has there been any progress made on this ? we would love to use postgresql jsonb (or anything postgresql) for geth.

[ghost]

@sandys Nice you are mentioning it. We had a code read with a couple of colleagues recently. If we don't go too sophisticated with the schema (i.e. go with just one table), I think we can start with a shy pull request, and try to comply with the tests. I'll let you know if I can manage to write that PR this weekend.

[sandys]

@hermanjunge thanks for following up on this - looking forward to it!

[sandys]

@hermanjunge quick question (since im curious) - are you basing it to be on top of jsonb ? because that would be conceptually very similar to leveldb... instead of structuring them as a relational table

[vnwarrior]

@ajunge @hermanjunge sorry to ping old thread - but you did any work for redis or other database ? we trying same thing out and would like see your code if possible.

[takashi]

@ajunge @hermanjunge sorry for pinging old thread, but there is any progress of this topic? I'd strongly like to solve this problem too.

[sandys]

Here's our attempt to build a version that uses postgresql as the backing store. https://github.com/RedCarpetUp/go-ethereum/tree/dev The Ethereum codebase used here is older - so you might have to do some merging before it works with latest master. If you do get it working with latest eth, please do send a pull request.

…

On Fri, 6 Jul, 2018, 09:02 Takashi Nakagawa, ***@***.***> wrote: @ajunge <https://github.com/ajunge> @hermanjunge <https://github.com/hermanjunge> sorry for pinging old thread, but there is any progress of this topic? I'd strongly like to solve this problem too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2690 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEsU4EejrUAAeT33rBLqc11IR9k6-g3ks5uDto9gaJpZM4I0sN6> .