我们为视频和音频剪辑、照片和矢量图提供了一个平台.我们从MySQL开始作为数据库后端，最近加入了MongoDB个，用于存储文件的所有元信息，因为MongoDB更符合要求.例如:照片可能有Exif个信息，视频可能有音频曲目，我们想在其中存储元数据信息.视频和矢量图形不共享任何公共元信息等.所以我知道，MongoDB非常适合存储这些非 struct 化数据并保持其可搜索性.
然而，我们仍在继续开发我们的平台并增加功能.现在，下一步将为我们的用户提供一个论坛.现在出现的问题是:使用MySQL数据库，这将是存储论坛和论坛帖子等的好 Select ，还是使用MongoDB呢？
所以问题是:何时使用MongoDB，何时使用RDBMS.如果你有 Select 的话，你会 Select mongoDB还是MySQL？为什么 Select ？
在NoSQL: If Only It Was That Easy年中，作者写到了MongoDB:
MongoDB不是一个键/值存储，它的功能远不止这些.它也绝对不是RDBMS.我还没有在生产中使用MongoDB，但我用它构建了一个测试应用程序，它是一个非常酷的工具包.它的性能似乎非常好，要么已经具备，要么很快就会具备容错和自动分片功能(也就是说，它可以扩展).我认为Mongo可能是迄今为止我见过的最接近RDBMS替代品.它不会适用于所有的数据集和访问模式，但它是为典型的CRUD构建的.存储本质上是一个巨大的散列，并能够 Select 其中任何一个键，这是大多数人使用关系数据库的目的.If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.
然后，在结论中:
The real thing to point out is that if you are being held back from making something super awesome because you can’t choose a database, you are doing it wrong.如果你知道mysql，就用它吧.在实际需要时进行优化.像k/vstore 一样使用它，像rdbms一样使用它，但看在god 的份上，构建你的杀手级应用！所有这些对大多数应用都无关紧要.Facebook仍然大量使用MySQL.维基百科经常使用MySQL.FriendFeed经常使用MySQL.NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t care about any of this.
我将在什么基础上构建我的下一个应用程序？可能是博士后.我会使用NoSQL吗？大概我也可以使用Hadoop和Hive.我可能会把所有东西都放在平面文件里.也许我会开始攻击磁悬浮列车.I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL.如果我需要缓存，我可能会使用Tokyo Tyrant.If I need ACIDity, I won’t use NoSQL.如果我需要大量计数器，我会使用Redis.If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo.如果我需要每天写10亿个物体，我可能会使用伏地魔.如果我需要全文搜索，我可能会使用Solr.如果我需要对易变数据进行全文搜索，我可能会使用Sphinx.
我喜欢这篇文章，我觉得它信息量很大，它很好地概述了NoSQL的前景和炒作.但是，这是最重要的部分，在 Select RDBMS和NoSQL时，问自己正确的问题真的很有帮助.值得一读.