The "no migrations" claim is a lie. Migrations still exist, they just happen at the time of reading:<p><pre><code> def parseMongoRow(jsonBlob):
x = None
if jsonBlob['date'] < 2012/12/02:
x = jsonBlob['foo']['bar']
else if jsonBlob['date'] < 2013/06/01:
x = mergeFields(jsonBlob['bar'], jsonBlob['baz'])
else:
x = jsonBlob['x']
...
</code></pre>
For expiring fields in a redis database, this isn't a big deal. Your code stinks between [time of migration, time of migration + ttl]. For a permanent datastore, ouch.<p>I also do not understand why they are using MongoDB for this. They describe a schema involving shipments, shippoints and orders, and one of these things does not occur without the other (an attempt at justifying the document based data model?). I.e., something like this:<p><pre><code> CREATE TABLE orders (...)
CREATE TABLE shipments (
order_id BIGINT REFERENCES orders(id) NOT NULL,
ship_from_id BIGINT REFERENCES shippoints(id) NOT NULL,
ship_to_id BIGINT REFERENCES shippoints(id) NOT NULL
)
</code></pre>
You can't have a shipment without a shippoint. Black magic!<p>They have several hundred shipments/day, and lets be generous and assume there are 100 updates/notes to a shipment. We are talking maybe 50,000 inserts/day (omfg big data, invest in a 1TB hard disk!) and it sounds like data that's considerably more important than an ad impressions or pageviews. (Well actually <i>it fits in ram</i>, so maybe the 1TB hard disk on a dedicated server is overkill.)<p>Also, consider the daily aggregate generator in 3 lines of SQL rather than 236 lines of javascript:<p><pre><code> SELECT date, carrier, zone, COUNT(id), SUM(price)
FROM shipments
GROUP BY date, carrier, zone;
</code></pre>
I don't get it. How is mongodb even remotely the right tool for this job?