Re:CERN’s use of MongoDB for Large Hadron Collider data
by ergo98 on Thursday June 03, 2010 @02:12PM
(#1402015)
They use it as a trivial caching system of pre-aggregated data.
[ Parent
| on HN ]
Re:CERN’s use of MongoDB for Large Hadron Collider data
by brown9-2 on Thursday June 03, 2010 @02:49PM
(#1402120)
Correct me if I'm wrong but couldn't any number of other caching solutions (such as memcached) be used in this situation?
In other words, are there any features specific to MongoDB that they are actually making use of?
Re:CERN’s use of MongoDB for Large Hadron Collider data
by ergo98 on Thursday June 03, 2010 @03:06PM
(#1402177)
They don't give much details, but it sounds like a very superficial need that could be accommodated by Redis, Memcached, AppFabric, and on and on. Kind of surprised that they chose MongaDB as it's far from the fastest competitor.
Re:CERN’s use of MongoDB for Large Hadron Collider data
by dschn on Thursday June 03, 2010 @03:35PM
(#1402268)
Just speculation, but the built-in map/reduce is probably quite useful.
Re:CERN’s use of MongoDB for Large Hadron Collider data
by ergo98 on Thursday June 03, 2010 @05:10PM
(#1402571)
Perhaps, but the description essentially said that there is a custom python layer that aggregates the data, and they punt it into MongoDB with some SQL extraction pattern simply to store it into that silo.
e.g. If I run a query for NAME LIKE 'BLAH%' it stores that resultset. If I run NAME LIKE 'BLAP%' it stores that resultset. If someone else comes and runs either of them, only a direct match will pull my prior results.
It's okay, but it's no big win or case study.
Re:CERN’s use of MongoDB for Large Hadron Collider data
by ehwizard on Thursday June 03, 2010 @09:11PM
(#1403186)
They needed to be able to do some queries on various indexes, so key/value stores wouldn't work. Also MongoDB tends to be only 10% slower then memcache, so not sure why you think its not fast...