11–20 of 21 posts
Okay, semi-related: Why is the speed of the Go compiler so important? Why not just use an incremental compiler? Why the hell would you want to recompile a 100k+ line program when there are known better alternatives? Just doesn't make sense to me.
What are people using this 'cdb' for, irl? Sounds interesting but this is the first i've heard of it.
This is the perfect case for a cdb file: the list of local domains changes very rarely, but lookups happen 100s of times per second.
Granted though, it's a very special case. Aside of this mail case, I've yet to find another real world application.
What are people using this 'cdb' for, irl? Sounds interesting but this is the first i've heard of it.
What are people using this 'cdb' for, irl? Sounds interesting but this is the first i've heard of it.
I'm curious to know how it compares to LevelDB ( http://code.google.com/p/leveldb/ ). I'd love to see a detailed comparison between the two. LevelDB is mutable, but is built on top of an immutable key/value map: http://code.google.com/p/leveldb/source/browse/include/level...
Okay, semi-related: Why is the speed of the Go compiler so important? Why not just use an incremental compiler? Why the hell would you want to recompile a 100k+ line program when there are known better alternatives? Just doesn't make sense to me.
go seems to be nice, but compilation speed is no real argument!
Okay, semi-related: Why is the speed of the Go compiler so important? Why not just use an incremental compiler? Why the hell would you want to recompile a 100k+ line program when there are known better alternatives? Just doesn't make sense to me.
It turns out that way more than the C++ set were interested in Go. Naturally, people familiar with environments where compilation speed is a non-issue were mystified by our enthusiasm for Go's low compilation times.
What are people using this 'cdb' for, irl? Sounds interesting but this is the first i've heard of it.
It's useful if you have data that is easy to cache (i.e., rebuilt every 6 hours) but very commonly accessed. Because the lookups are so quick (two seeks) it's almost raw disk speed. But yeah, rebuilding the files is an offline process (build new file and swap it in using a rename), so your data has to be cache-friendly. It's a good alternative to memcache if your data is larger than what memcached can support in RAM.…
Unless you are running memcached on an ec2 large instance (8gb) or bigger:
"No random limits: cdb can handle any database up to 4 gigabytes."
Earlier quoted context omitted.
It's useful if you have data that is easy to cache (i.e., rebuilt every 6 hours) but very commonly accessed. Because the lookups are so quick (two seeks) it's almost raw disk speed. But yeah, rebuilding the files is an offline process (build new file and swap it in using a rename), so your data has to be cache-friendly. It's a good alternative to memcache if your data is larger than what memcached can support in RAM.…
It's a good alternative to memcache if your data is larger than what memcached can support in RAM. Unless you are running memcached on an ec2 large instance (8gb) or bigger: "No random limits: cdb can handle any database up to 4 gigabytes."
Anyways, it's useful for stuff where you want to ship out a big dictionary once a day or so and you need fast lookup but it doesn't have to be updated transactionally.
What are people using this 'cdb' for, irl? Sounds interesting but this is the first i've heard of it.
I didn't have the RAM for holding it all in memory and I was only ever going to do read lookups on it.
It made it very easy to query things like: Given my favorite set of movies, which actors appearing in them have also appeared in the Doctor Who television series?
Just for fun / learning :)