Why we chose Mongo + Hypertable
brownbag.springmetrics.com
Why we chose Mongo + Hypertable
1–7 of 7 posts
Re: Why we chose Mongo + Hypertable
#2What do they use for hosting?
As Jay Kreps (works at LinkedIn, created Voldemort DB) would wonder, they went from a service managed by Amazon to what?
http://blog.empathybox.com/post/19574936361/getting-real-abo...
Re: Why we chose Mongo + Hypertable
#3"Map/reduce operations aren’t exactly blazing fast, and are single-threaded (though they will parallelize over shards)."
This sounds extremely pointless with it being single-threaded, but whatever.
Re: Why we chose Mongo + Hypertable
#4This is very offtopic, but what is the deal with the header pictures in this blog? It's just random photos of office couches.
Re: Why we chose Mongo + Hypertable
#5"Map/reduce operations aren’t exactly blazing fast, and are single-threaded (though they will parallelize over shards)." This sounds extremely pointless with it being single-threaded, but whatever.
Its single-threaded nature for map/reduce is its biggest liability in my opintion. It will apparently be fixed in the next version (https://jira.mongodb.org/browse/SERVER-4258)
Right now, large map/reduce operations just bring the thing to its knees. So we just don't map/reduce with it. The query features are really quite nice, and we do the rest in hypertable.
Re: Why we chose Mongo + Hypertable
#6What do they use for hosting? As Jay Kreps (works at LinkedIn, created Voldemort DB) would wonder, they went from a service managed by Amazon to what? http://blog.empathybox.com/post/19574936361/getting-real-abo...
We're still on EC2, though we've learned to distribute servers across availability zones.
Re: Why we chose Mongo + Hypertable
#7This is very offtopic, but what is the deal with the header pictures in this blog? It's just random photos of office couches.
They're pictures of our office in Durham, NC.