我们提供视频和音频剪辑,照片和矢量图形平台.我们从MySQL开始作为数据库后端,最近包括MongoDB,用于存储文件的所有元信息,因为MongoDB更符合要求.例如:照片可能包含Exif信息,视频可能具有我们想要存储元信息的音轨.视频和矢量图形不共享任何常见的元信息,所以我知道,MongoDB非常适合存储这些非结构化数据并使其可以搜索.
但是,我们继续开发我们的平台并添加功能.现在,接下来的步骤之一将是为我们的用户提供一个论坛.现在出现的问题是:使用MySQL数据库,这是存储论坛和论坛帖子等的好选择,或者也可以使用MongoDB吗？
所以问题是:何时使用MongoDB以及何时使用RDBMS.你会选择什么,mongoDB或MySQL,如果你有选择,为什么要接受它？
在NoSQL中:如果只有那么容易,作者写了关于MongoDB:
MongoDB不是一个键/值存储,它是相当多的.它绝对不是RDBMS.我没有在生产中使用MongoDB,但是我已经使用它构建一个测试应用程序,它是一个非常酷的工具包.它似乎非常高效,并且具有或将很快具有容错和自动分片(也称为可扩展).我认为Mongo可能是迄今为止我见过的最接近RDBMS替代品的东西.它不适用于所有数据集和访问模式,但它是为典型的CRUD内容而构建的.存储什么本质上是一个巨大的哈希,并能够选择任何这些键,是大多数人使用关系数据库.如果您的数据库是3NF并且您没有进行任何连接(您只是选择了一堆表并将所有对象放在一起,AKA大多数人在Web应用程序中执行的操作),MongoDB可能会为您提供帮助.
然后,在结论中:
值得指出的是,如果你因为无法选择数据库而无法制作超级棒的东西,那么你做错了.如果您了解mysql,请使用它.在您确实需要时进行优化.像ak/v商店一样使用它,像rdbms一样使用它,但为了上帝的缘故,构建你的杀手级应用程序!这些对大多数应用程序都不重要.Facebook仍然使用MySQL,很多.维基百科使用MySQL,很多.FriendFeed使用MySQL,很多.NoSQL是一个很棒的工具,但它肯定不会成为你的竞争优势,它不会让你的应用程序变得热门,而且最重要的是,你的用户不会关心这些.
我打算如何构建我的下一个应用程序？可能是Postgres.我会使用NoSQL吗？也许.我也可以使用Hadoop和Hive.我可能会把所有内容保存在平面文件 也许我会开始攻击磁悬浮.我将使用最适合这份工作的东西. 如果我需要报告,我将不会使用任何NoSQL.如果我需要缓存,我可能会使用Tokyo Tyrant.如果我需要ACIDity,我不会使用NoSQL.如果我需要大量的计数器,我会使用Redis.如果我需要交易,我会使用Postgres. 如果我有一大堆单一类型的文件,我可能会使用Mongo.如果我每天需要写10亿件物品,我可能会使用Voldemort.如果我需要全文搜索,我可能会使用Solr.如果我需要对volatile数据进行全文搜索,我可能会使用Sphinx.
我喜欢这篇文章,我发现它非常有用,它很好地概述了NoSQL的风景和炒作.但是,这是最重要的部分,当在RDBMS和NoSQL之间进行选择时,问自己正确的问题确实很有帮助.值得一读恕我直言.
文章的替代链接
使用MongoDb作为社交应用程序两年后,我亲眼目睹了没有SQL RDBMS的真正意义.
你最终写作业来做一些事情,比如从不同的表/集合中加入数据,这是RDBMS自动为你做的事情.
您对NoSQL的查询功能严重受损.MongoDb可能是最接近SQL的东西,但它仍然远远落后于它.相信我.SQL查询非常直观,灵活且功能强大.MongoDb查询不是.
MongoDb查询只能从一个集合中检索数据,并且只能利用一个索引.MongoDb可能是最灵活的NoSQL数据库之一.在许多情况下,这意味着更多往返服务器以查找相关记录.然后你开始对数据进行去标准化 - 这意味着后台工作.
它不是关系数据库这一事实意味着您不会(通过某些人认为表现不佳)外键约束来确保您的数据是一致的.我向您保证,这最终会在您的数据库中创建数据不一致.做好准备.最有可能的是,您将开始编写进程或检查以保持数据库的一致性,这可能不会比让RDBMS为您执行更好.
忘记像hibernate这样的成熟框架.
我相信,使用典型的SQL RDBMS,98%的项目可能比使用NoSQL更好.
存储此非结构化数据
正如您所说,MongoDB最适合存储非结构化数据.这可以将您的数据组织成文档格式.这些称为NoSQL数据存储(MongoDB,CouchDB,Voldemort)的RDBMS替代对于大规模扩展并需要从这些大数据存储更快地访问数据的应用程序非常有用.
并且这些数据库的实现比常规RDBMS更简单.由于这些是简单的键值或文档样式二进制对象,直接序列化为磁盘.这些数据存储不强制执行ACID属性和任何模式.这不提供任何交易能力.所以这可以扩大规模,我们可以实现更快的访问(读取和写入).
但相比之下,RDBM在数据上强制执行ACID和模式.如果您想使用结构化数据,可以继续使用RDBM.
我会选择MySQL来为这种东西创建论坛.因为这不会扩大规模.这是一个非常简单(常见)的应用程序,它在数据之间建立了结构关系.
请注意,Mongo实际上存储了JSON.如果你的应用程序正在处理很多JS对象(使用嵌套)并且你想要持久保存这些对象,那么使用Mongo就会有一个非常强大的论据.它使您的DAL和MVC层超薄,因为它们不会解包所有JS对象属性,并试图将它们强制适应它们自然不适合的结构(模式).
我们有一个系统,它的核心有几个复杂的JS对象,我们喜欢Mongo,因为我们可以非常,非常容易地坚持所有内容.我们的对象也是非常无定形和非结构化的,而且Mongo在没有眨眼的情况下吸收并发症.我们有一个自定义报告层,可以破译人类消费的无定形数据,而且开发并不困难.
如果你需要复杂的交易,我会说使用RDBMS.否则我会使用MongoDB - 更灵活地使用它,你知道它可以在你需要时扩展.(虽然我有偏见 - 我在MongoDB项目上工作)
谁需要分布式,分片论坛？也许Facebook,但除非你正在创建一个Facebook竞争对手,只需使用Mysql,Postgres或任何你最熟悉的东西.如果你想尝试MongoDB,好吧,但不要指望它为你做魔术.就像其他一切一样,它会有它的怪癖和一般的肮脏,因为我确信你已经发现如果你真的已经在研究它了.
当然,MongoDB可能会被炒作并且表面看起来很容易,但是你会遇到更成熟的产品已经克服的问题.不要那么容易被诱惑,而是等到"nosql"成熟或死亡.
就个人而言,我认为"nosql"会因碎片而枯萎死亡,因为没有固定的标准(几乎按照定义).所以我不会为任何长期项目亲自打赌.
只有能够在我的书中保存"nosql"的东西,如果它可以无缝地集成到Ruby或类似的语言中,并使语言"持久",几乎没有编码和设计的任何开销.这可能会成真,但我会等到那时,而不是现在,当然它需要更加成熟.
顺便问一下,你为什么要从零开始创建一个论坛？有很多开源论坛可以调整以满足大多数要求,除非你真的在创建下一代论坛(我怀疑).
京公网安备 11010802040832号 | 京ICP备19059560号-6 