[chord] my plans to change merkle

[Frank Dabek]

Benjie,

	We talked about this at Chord meeting today and are all a bit confused.
Isn't the bottom level of the Merkle tree already an in-memory cache of
all of the keys in the system? 

	Why don't you present these changes at a meeting next week before you
start hacking the code?

--Frank

On Fri, 2003-08-01 at 09:16, Benjie Chen wrote:
> yes, i was planning to insert into the db, but not into the
> merkle tree, on every block insert. when inserting keys into
> the tree, we will end up traversing the db to keep the tree
> fresh.
> 
> benjie
> 
> 
> On Fri, Aug 01, 2003 at 07:32:41AM -0400, Frans Kaashoek wrote:
> > wouldn't it be better to do the insert in the database, but
> > don't iteratate throught the whole database on each insert?
> > 
> > perhaps i don't understand the plan, but this sounds like a
> > bad hack.
> > 
> > On Fri, 01 August 2003 at 00:21 (-0400), Benjie Chen wrote:
> > > 
> > > so i mentioned earlier that there is a slight efficiency issue with
> > > the Merkle implementation, namely that it tries to iterate thru the
> > > database on every db insert, and that this could be quite expensive.
> > > 
> > > my plan to fix/change this is to keep a fixed sized array of
> > > inserted keys in memory, and periodically inserts them into the
> > > merkle tree, instead of insert into the merkle tree on every store.
> > > in the worst case, i will insert keys into the merkle tree once
> > > every time the synchronization protocol runs.
> > > 
> > > with only 200K, i can keep 10,000 keys. so this should be okay
> > > memory-wise.
> > > 
> > > anyone has a problem with this?
> > > 
> > > benjie
> > > 
> > > 
> > > -- 
> > > benjie chen
> > > benjie at lcs.mit.edu
> > > _______________________________________________
> > > chord mailing list
> > > chord at amsterdam.lcs.mit.edu
> > > https://amsterdam.lcs.mit.edu/mailman/listinfo/chord