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

In-mem database backend #13140

Closed
wilsonwang371 opened this issue Jun 24, 2021 · 7 comments
Closed

In-mem database backend #13140

wilsonwang371 opened this issue Jun 24, 2021 · 7 comments
Labels

Comments

@wilsonwang371
Copy link
Contributor

Guys,

We have a case in our company to use in memory only database which do not need to persist kv onto disk but it need strong consistency.

Do you guys think it would be a good chance to make changes to boltdb interface to make it more general for other btree based in mem db alternatives?

@gyuho @ptabor

@gyuho
Copy link
Contributor

gyuho commented Jun 24, 2021

Interesting idea.

@wilsonwang371 Can we research more if there is any existing system that supports pluggable storage backends? I think this requires multiple phases, starting with more generic peer-to-peer snapshot contracts. Or making existing boltdb optionally bypass file system calls is another option.

c.f. #13123

/cc @xiang90

@MakDon
Copy link
Contributor

MakDon commented Jun 25, 2021

Is it a good idea that store the bbolt's data file in tmpfs?

@wilsonwang371
Copy link
Contributor Author

Is it a good idea that store the bbolt's data file in tmpfs?

I am still doing related research. Basically, bbolt using tmpfs won't help much because bbolt is already using memmap to access the data. Using tmpfs may help to improve the performance a little bit but still, bbolt was not designed for a in-mem database.

I am still thinking about this issue. I will update it when I have some new idea.

@wilsonwang371
Copy link
Contributor Author

Interesting idea.

@wilsonwang371 Can we research more if there is any existing system that supports pluggable storage backends? I think this requires multiple phases, starting with more generic peer-to-peer snapshot contracts. Or making existing boltdb optionally bypass file system calls is another option.

c.f. #13123

/cc @xiang90

Sorry for the late reply. Agreed. I think a generic peer-to-peer snapshot contracts would be more urgent for us on this topic. Maybe we can just firstly introduce a layer on top of bbolt at the very beginning?

@morigs
Copy link

morigs commented Jul 8, 2021

Somewhat similar idea are currently being discussed in TiKV
tikv/tikv#6402

@warmchang
Copy link

Run with --unsafe-no-fsync flag? #11946

@stale
Copy link

stale bot commented Oct 29, 2021

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

@stale stale bot added the stale label Oct 29, 2021
@stale stale bot closed this as completed Nov 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants