Skip to content
This repository has been archived by the owner on Jul 11, 2019. It is now read-only.

Use medea (medeadown) instead of leveldb #116

Open
Ivshti opened this issue May 3, 2015 · 8 comments
Open

Use medea (medeadown) instead of leveldb #116

Ivshti opened this issue May 3, 2015 · 8 comments

Comments

@Ivshti
Copy link

Ivshti commented May 3, 2015

Medea is a leveldb-like key/value store in pure JS over node.js. It offers almost the same performance as leveldb, which would be perfectly sufficient for FRIENDS.

Most importantly, it eliminates the need for build-time compiling.

@beaugunderson
Copy link
Member

I'm in the process of moving from compiled mdns to pure-JS multicast-dns for the multicast branch so this is intriguing; curious how @mafintosh feels re: performance

is it compatible with the leveldb module ecosystem?

@Ivshti
Copy link
Author

Ivshti commented May 3, 2015

Its a drop-in for leveldb and also medeadown is a drop-in for leveldown, so it is.

@ungoldman
Copy link
Member

@Ivshti sounds interesting!

@mafintosh
Copy link
Contributor

@beaugunderson assuming it works with friends i think we should just switch to using medea. i think @maxogden tried using initially with friends and it quirked a bit but it might have been something else that was the issue. friends isn't really db performance intensive so the perf hit is probably fine.

@calvinmetcalf
Copy link
Member

might we have some problems when the database grows? from what I remember medea needs to keep all keys in memory

@Ivshti
Copy link
Author

Ivshti commented May 5, 2015

Maybe. I did not think about this.

I do not know how LevelDB deals with it, but it's hard to imagine it being very different - keeping the keys in memory is pretty essential for query performance.

What kind of scale would the DB for an average user grow? Are you planning to keep all the chat logs at all times?

@calvinmetcalf
Copy link
Member

leveldb has a least recently used cache which it uses to keep the most recent entries in memory and then stores keys in files which have an index at the very end to allow quick lookup of the key, so it can find a key fairly quickly by first reading the index and then seeking to the specific point in the file. But it can grow to contain an arbitrarily large amount of data.

@max-mapper
Copy link
Member

I tried using medeadown (6224ed0) but it didn't work. I can't remember why though (apologies, it was during a crazy long hacking session).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants