Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a single badgerdb instance #283

Closed
liamsi opened this issue Apr 17, 2021 · 9 comments
Closed

Use a single badgerdb instance #283

liamsi opened this issue Apr 17, 2021 · 9 comments
Labels
C:store DB / store related

Comments

@liamsi
Copy link
Member

liamsi commented Apr 17, 2021

Currently, we are using two stores: one for tendermint related data and one for IPLD related data.

original discussion: #211 (comment)

ref: #182

@liamsi liamsi added the C:store DB / store related label Apr 17, 2021
@tzdybal
Copy link
Member

tzdybal commented Apr 19, 2021

To be honest, I have no experience using multiple badger instances in single process.
I would expect that it may impact memory usage negatively.

On the other hand, with single instance we will need to double-check that keys are not conflicting.

@tac0turtle
Copy link
Collaborator

We do use multiple DBs within ll-core on its own. We should look at cleaning up ll-core before merging the ipfs and state.

@Wondertan
Copy link
Member

@marbar3778, can you pls point to the places where we use multiple DBs in ll-core? Optionally with short descriptions of their purposes.

@Wondertan
Copy link
Member

@tzdybal, I had an experience using multiple Badgers at the same time. I needed kinda independent namespaced KV storages, but that was a lot of overhead. Badger spawned goroutines ate CPU, RAM was bloated, also every instance did a disk footprint, so overhead is on every dimension. Unfortunately, I don't have any real number logged.

@tac0turtle
Copy link
Collaborator

Ah I was thinking about the light client and the node. Within a single node it is a sinlge instance of badger

@liamsi
Copy link
Member Author

liamsi commented May 21, 2021

IMO, we should also consider settling on the same version as IPFS. Currently, ipfs uses v1. There are plans to switch to v2: ipfs/kubo#6818
and there is a badgerv2 store: https://github.com/ipfs/go-ds-badger2

We could of course also write a v3 ds (if it does not already exist) and use it across the board. It is not entirely clear to me why we picked v3 tbh and if it is some kind of official release or rather a development version. The badger docs on how to choose a version do not even mention v3 (currrently): https://github.com/dgraph-io/badger#choosing-a-version

Either way, this does not have high priority right now but it's something to keep an eye on.

@liamsi liamsi mentioned this issue Jun 2, 2021
17 tasks
@tzdybal
Copy link
Member

tzdybal commented Jul 29, 2021

Out of curiosity, did some small research.
DGraph is using badger v3 in official releases (see go.mod in latest release).

go-ds-badger2 can be easily switched into v3 - only some options were removed from badger (see dgraph-io/badger#1574, dgraph-io/badger#1555). See tzdybal/go-ds-badger3#1

@Wondertan
Copy link
Member

Yeah, in our case migration to v3 should be easy. AFAIK, the badger changes major version only in case of on-disk data format change, so for existing users that would require some special migration. In our case, we don't have any so we are good to go.

@liamsi
Copy link
Member Author

liamsi commented Aug 13, 2021

we will move the ipfs storage story to a separate repo. So there is no need inside of this repo to deal with this. If anything we should make pruning after the unbonding period the default (if that is not the case already).

@liamsi liamsi closed this as completed Aug 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:store DB / store related
Projects
None yet
Development

No branches or pull requests

4 participants