Is MongoDB Right For Your Project (or Organization)

Editor's Notes

• #2: This is about if MongoDB is best for your project. But we’ll try and lead you to other alternatives if needed.\n
• #3: - Aerospace\n- Ag\n- Marketing\n- Public Service\n- GForge\n\nLAMP but continuously dabbling in other stuff.\n
• #4: Diagram represents the rigidity of RDBMS in most organizations.\n\nRelated things broken out across multiple pages so either you need to create multiple logical models focusing on one part of business or be patient connecting all the dots and lines.\n\nAnd this is just the design aspect...we haven’t even touched SQL to access this crap.\n
• #5: It works, but you have to have a lot of it and even then you are left feeling bloated.\n\nShould be noted that “If it ain’t broke, don’t fix it”. F- dogma. Most of the best geeks I know find a way to dabble with new technologies in ways that allow for true evaluation. Strive for this. Startups may not be able to do this...innovation is, at times, about risk.\n
• #6: Get a lot more people drunk faster. \n
• #7: Four of these things are DB or DB related. WTF...\n\nIt’s expensive to find developers that can master all these\n\nWe haven’t even added the complication of the Cloud (e.g. AWS)\n
• #8: - Index verification\n- Page Size Optimizations (who does this anymore?)\n- Query caching\n- Denormalizing data (blow mind of classically trained DBAs)\n- Cluster (and insane sys admin’ing)\n- Sharding (use Digg example) Requires expensive DBMS or custom API for fluent access to shards.\n
• #9: This is where I get mad at PHP haters. Performance problems in all my apps have started at the database. PHP has seldom been the problem. Find a new reasons to hate PHP...performance ain’t it.\n\nSo despite APC, Memcache, denormalizing, query caching, etc the DB is still the biggest problem.\n
• #10: Started with a “hunch” things could be better.\n\nRSS feeds started filling up with NoSQL chatter.\n\nI admit I’m not working for FB, Twitter, etc but that’s the Web Scale “dream”\n\nFaster iteration over conventional RDBMS web development...particularly for proof of concepts/prototyping.\n
• #11: Are there others?\n\nHow may people are using NoSQL in production? Which flavor?\n\nAny quick plugs for those solutions?\n
• #12: Thrift - anybody here like thrift? \n\nThrift interface for Cassandra == fail. Might as well write assembler.\n\nWanted native PHP support if possible, not a PHP/Thrift wrapper.\n
• #13: In PHP Mongo is a quick PECL extension. Installs in one command on most sane Linux installs (and, happily, on OSX)\n\nMongo install is almost as easy. \n\nAPI is dead simple for an idiot like myself.\n\nAlmost everything I do is document based. In stark contrast to companies that do a lot of batch processing or high volume transaction processing. That’s a BigTable problem so you’ll want to explore other NoSQL solutions.\n\nI only mention the session thing because if you are using something that, at it’s very core, is distributed then first thing on todo list is session handling.\n
• #14: Admittedly, I haven’t used GridFS but it’s in production use on large scale system for storing things like audio and video.\n\nMapReduce is BigTable type stuff. It’s the only way to do real analytics (read: complicated queries) in NoSQL systems. I’ve avoided this to date but looks simple enough in MongoDB. HBase/Hadoop...not so much (but same basic concept).\n\nGeoSpatial support allows distance-based queries that are intuitive. Initial benchmarks show it performs much better than doing similar queries in MySQL.\n\nFluid schemas means each record in a document collection can have entirely different data. This can be good or bad. Good because it is managed in code bad because nothing but code can enforce schema changes. ORM still has a role here, IMHO.\n\nJSON is synonymous with API’s and having DB support it natively means no special work to get data into JSON\n
• #15: You can do full text search in Mongo using other tools like Lucene if required.\n\nWhile not ACID has atomic operators like push that allow you to, say, push multiple comments to a blog post without fear of collisions. In other words, no need to worry about programming around concurrency issues.\n\n\n
• #16: Cassandra was fine but Thrift interface sucked. Hard. Getting data in was fine but query interface was much lower level. Example query on email to get ID. Query on ID to get blog posts. This can be done with one call in MongoDB\n\nHBase/Hadoop is mind blowing. Store data in HBase, Hadoop for MapReduce, ZooKeeper...more moving parts, more complicated but meant to give high performant, non-relational solution for high volumn processing (talking trillions of records). In short I may not be smart enough for HBase.\n\nKey is to know what your organization needs, how the NoSQL databases differ and be sure to find up-to-date input on big organizations using it. NoSQL teams are iterating quickly so limitations are quickly resolved so be sure to stay current.\n
• #17: This is really true of all NoSQL implementations. Don’t do it and you’ll be blaming the tool, limping back to your boss.\n\nGreat example is there is a right and wrong way to shut MongoDB down. Wrong way can lead to data loss...only takes once and it’s easy to blame the tool\n\nMongoDB wants to work in RAM. You want it to work in RAM, too. Many times you’ll want to query an item before updating it to make sure updates is as fast as possible.\n\nShould know how they use the network. I admit I’m weak here but I’m aware of it so I know when to bounce things of network geeks.\n\nSchema design even in “schema-less” environments is still key. Takes some getting use to to\n\nOOID = timestamp + machine ID + process ID + counter\n
• #18: \n
• #19: \n
• #20: \n
• #21: \n