btree support

Kevin A. Burton burton at newsmonster.org
Sat Dec 11 12:37:22 PST 2004


Sorry for the delayed reply... just subscribed and was scanning the 
archives.

> delete search_page_*
>
> would be infinitely nicer and probably faster, actually, because it'd 
> save the client from making multiple requests.  Given that memcached 
> is nearly always RAM bound and not CPU bound, I'm wondering what 
> people (ie, Brad, Ava) would think in terms of moving/adding a tree 
> storage method.  Storage would still be managed by the slab/pool 
> allocator, but instead of using a hash to lookup keys, a tree could be 
> used instead, or in addition too (pending some kind of config).  
> Granted a tree is going to take a few more cycles when doing a lookup, 
> but in terms of price/performance for being able to do wild card 
> matching, I don't know that it'd be a hard tradeoff to justify adding, 
> esp if it's a CLI option that'd allow existing functionality to be used.
>
I've been thinking (blue sky) about the possibility of implementing 
Lucene on top of memcached.  This would support storing posts directly 
in memory and spanning the query across multiple machines.

With just a basic hashtable you can only do keyword query "Show me all 
posts with 'linux'" but not a full prefix query "Show me all posts with 
linux%".

With btree indexing this would be possible.  Also implementing btrees in 
memory is a lot easier than writing a disk based btree.  The hashcode 
would still be used to store content in the cache its just that there 
would be a secondary btree index per box.

BTW this is the same path that MySQL took with their memory tables.  
They initially were just hashtables but in MySQL 4.1.x they've added 
btree indexing for sorts, etc.

Just thinking out loud.

Kevin

-- 

Use Rojo (RSS/Atom aggregator).  Visit http://rojo.com. Ask me for an 
invite!  Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you 
should work for Rojo!  If you recommend someone and we hire them you'll 
get a free iPod!
    
Kevin A. Burton, Location - San Francisco, CA
       AIM/YIM - sfburtonator,  Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412



More information about the memcached mailing list