mysql – 何时使用MongoDB或其他面向文档的数据库系统？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了mysql – 何时使用MongoDB或其他面向文档的数据库系统？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3088字，纯文字阅读大概需要5分钟。

内容图文

我们提供视频和音频剪辑,照片和矢量图形平台.我们从MySQL开始作为数据库后端,最近包含MongoDB用于存储文件的所有元信息,因为MongoDB更符合要求.例如：照片可能有Exif信息,视频也可能有音频轨道,我们也想要存储元信息.视频和矢量图形不共享任何常见的元信息,所以我知道,MongoDB非常适合存储这些非结构化数据并使其可以搜索.

但是,我们继续开发我们的平台并添加功能.现在,接下来的步骤之一将是为我们的用户提供一个论坛.现在出现的问题是：使用MySQL数据库,这是存储论坛和论坛帖子等的好选择,或者也可以使用MongoDB吗？

所以问题是：何时使用MongoDB以及何时使用RDBMS.你会选择什么,mongoDB或MySQL,如果你有选择,为什么要接受它？

解决方法:

在NoSQL: If Only It Was That Easy,作者写了关于MongoDB的文章：

MongoDB is not a key/value store, it’s quite a bit more. It’s definitely not a RDBMS either. I haven’t used MongoDB in production, but I have used it a little building a test app and it is a very cool piece of kit. It seems to be very performant and either has, or will have soon, fault tolerance and auto-sharding (aka it will scale). I think Mongo might be the closest thing to a RDBMS replacement that I’ve seen so far. It won’t work for all data sets and access patterns, but it’s built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. 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. If you know mysql, just use it. Optimize when you actually need to. Use it like a k/v store, use it like a rdbms, but for god sake, build your killer app! None of this will matter to most apps. Facebook still uses MySQL, a lot. Wikipedia uses MySQL, a lot. FriendFeed uses MySQL, a lot. 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.

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use 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. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.

我喜欢这篇文章,我发现它非常有用,它很好地概述了NoSQL的风景和炒作.但是,这是最重要的部分,当在RDBMS和NoSQL之间进行选择时,问自己正确的问题确实很有帮助.值得一读恕我直言.

Alternate link to article

内容总结

以上是互联网集市为您收集整理的mysql – 何时使用MongoDB或其他面向文档的数据库系统？全部内容，希望文章能够帮你解决mysql – 何时使用MongoDB或其他面向文档的数据库系统？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端