you have related data, you need to join them. • Sometimes, indexing doesn't work very well. ◦ Introduce denormalization. ◦ Build extra tables. • Changes can lock data. ◦ Downtime ◦ Load on system • Code changes are not automatically coupled with schema changes. ◦ Coordination can be difficult.
Partition Tolerant • Tableless / Schemaless • Very Fast Example Whitehouse.gov direct engagement • 15k/day requests • 2M records in db • Replication issues since db was nearly 4gb. • Switch to MongoDB ◦ Relatively easy replication / sharding • Now over 180M collections in collection.
to format your query to it correctly. • Range query / sort must be based on last column in index. • Have a limit of 64 indexes. • Cannot join across entities (and thus filter on data from multiple entities). • No DBTNG Implementation.
modules • mongodb_block: Store blocks in mongo • mongodb_cache: Cache using mongo • mongodb_session: store sessions in mongo • mongodb_watchdog: Store watchdog in mongo • mongodb_queue: Store queues in mongodb • mongodb_field_storage: Store fields in mongodb
$conf['session_inc'] = 'sites/all/modules/mongodb/mongodb_session/mongodb_session.inc'; • Sessions will likely be helpful but cache...not sure what kind of difference is to be seen there. Better off placing efforts in using apc / memcache / something else.
$conf['field_storage_default'] = 'mongodb_field_storage'; • Biggest gains to site are from this. PROS • Faster saving, deletion, node retrieval. • Fully compatible with entityfieldquery. • No real limits on field lengths (*no image alt length issues) • Partial Views Integration through EntityFieldQueryViews (http://drupal.org/project/efq_views) - could use some help