database 与关系数据库相比,使用像 MongoDB 这样的无模式数据库有哪些优势?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/2117372/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are the advantages of using a schema-free database like MongoDB compared to a relational database?
提问by Guillaume Flandre
I'm used to using relational databases like MySQL or PostgreSQL, and combined with MVC frameworks such as Symfony, RoR or Django, and I think it works great.
我习惯使用 MySQL 或 PostgreSQL 等关系型数据库,并结合 Symfony、RoR 或 Django 等 MVC 框架,我认为它非常有效。
But lately I've heard a lot about MongoDB which is a non-relational database, or, to quote the official definition,
但是最近我听说了很多关于 MongoDB 的消息,它是一个非关系型数据库,或者,引用官方定义,
a scalable, high-performance, open source, schema-free, document-oriented database.
一个可扩展、高性能、开源、无模式、面向文档的数据库。
I'm really interested in being on edge and want to be aware of all the options I'll have for a next project and choose the best technologies out there.
我对处于边缘状态非常感兴趣,并希望了解下一个项目的所有选项,并选择最好的技术。
In which cases using MongoDB (or similar databases) is better than using a "classic" relational databases? And what are the advantages of MongoDB vs MySQL in general? Or at least, why is it so different?
在哪些情况下使用 MongoDB(或类似数据库)比使用“经典”关系数据库更好?MongoDB 与 MySQL 的总体优势是什么?或者至少,为什么会如此不同?
If you have pointers to documentation and/or examples, it would be of great help too.
如果您有指向文档和/或示例的指针,它也会有很大帮助。
采纳答案by Kyle Banker
Here are some of the advantages of MongoDB for building web applications:
以下是 MongoDB 在构建 Web 应用程序方面的一些优势:
- A document-based data model. The basic unit of storage is analogous to JSON, Python dictionaries, Ruby hashes, etc. This is a rich data structure capable of holding arrays and other documents. This means you can often represent in a single entity a construct that would require several tables to properly represent in a relational db. This is especially useful if your data is immutable.
- Deep query-ability. MongoDB supports dynamic queries on documents using a document-based query language that's nearly as powerful as SQL.
- No schema migrations. Since MongoDB is schema-free, your code defines your schema.
- A clear path to horizontal scalability.
- 基于文档的数据模型。存储的基本单位类似于 JSON、Python 字典、Ruby 哈希等。这是一种能够保存数组和其他文档的丰富数据结构。这意味着您通常可以在单个实体中表示需要多个表才能在关系数据库中正确表示的构造。如果您的数据不可变,这将特别有用。
- 深度查询能力。MongoDB 支持使用几乎与 SQL 一样强大的基于文档的查询语言对文档进行动态查询。
- 没有架构迁移。由于 MongoDB 是无模式的,您的代码定义了您的模式。
- 一条通往水平可扩展性的清晰途径。
You'll need to read more about it and play with it to get a better idea. Here's an online demo:
您需要阅读更多关于它的内容并尝试使用它以获得更好的主意。这是一个在线演示:
回答by marcgg
There are numerous advantages.
有很多优点。
For instance your database schema will be more scalable, you won't have to worry about migrations, the code will be more pleasant to write... For instance here's one of my model's code :
例如,您的数据库架构将更具可扩展性,您不必担心迁移,代码编写起来会更愉快……例如,这是我的模型代码之一:
class Setting
include MongoMapper::Document
key :news_search, String, :required => true
key :is_availaible_for_iphone, :required => true, :default => false
belongs_to :movie
end
Adding a key is just adding a line of code !
添加一个键只是添加一行代码!
There are also other advantages that will appear in the long run, like a better scallability and speed.
从长远来看,还有其他优势会出现,比如更好的可扩展性和速度。
... But keep in mind that a non-relational database is not betterthan a relational one. If your database has a lot of relations and normalization, it might make little sense to use something like MongoDB. It's all about finding the right tool for the job.
...但请记住,非关系数据库并不比关系数据库好。如果你的数据库有很多关系和规范化,那么使用像 MongoDB 这样的东西可能没什么意义。这一切都是为了找到适合工作的工具。
For more things to read I'd recommend taking a look at "Why I think Mongo is to Databases what Rails was to Frameworks" or this poston the mongodb website. To get excited and if you speak french, take a look at this articleexplaining how to set up MongoDB from scratch.
要阅读更多内容,我建议您查看“为什么我认为 Mongo 之于数据库,而 Rails 之于框架”或mongodb 网站上的这篇文章。如果您会说法语,请查看这篇文章,了解如何从头开始设置 MongoDB ,让您兴奋不已。
Edit: I almost forgot to tell you about this railscastby Ryan. It's very interesting and makes you want to start right away!
编辑:我差点忘了告诉你关于这个railscast由瑞安。这很有趣,让你想马上开始!
回答by Erwin Smout
The advantage of schema-free is that you can dump whatever your load is in it, and no one will ever have any ground for complaining about it, or for saying that it was wrong.
无模式的优点是您可以转储其中的任何负载,并且没有人有任何理由抱怨它,或者说它是错误的。
It also means that whatever you dump in it, remains totally void of meaning after you have done so.
这也意味着无论你往里面倾倒什么,在你这样做之后仍然完全没有意义。
Some would label that a gross disadvantage, some others won't.
有些人会认为这是一个严重的劣势,有些人则不会。
The fact that a relational database has a well-established schema, is a consequence of the fact that it has a well-established set of extensional predicates, which are what allows us to attach meaning to what is recorded in the database, and which are also a necessary prerequisite for us to do so.
关系数据库具有完善的模式这一事实是因为它具有一套完善的扩展谓词,这些扩展谓词使我们能够将意义附加到数据库中记录的内容上,哪些是也是我们这样做的必要前提。
Without a well-established schema, no extensional predicates, and without extensional precicates, no way for the user to make any meaning out of what was stuffed in it.
如果没有完善的模式、外延谓词和外延精确词,用户就无法从其中填充的内容中获得任何意义。
回答by Patrick
MongoDB was featured on FLOSS Weekly this week - http://twit.tv/floss105A database using a similar concept is CouchDB which was featured on another FLOSS Weekly: http://twit.tv/floss36
MongoDB 本周在 FLOSS Weekly 上有特色 - http://twit.tv/floss105使用类似概念的数据库是 CouchDB,它在另一家 FLOSS Weekly 上有特色:http: //twit.tv/floss36
I think it's worth listening to those in addition to the links provided by @marcgg
我认为除了@marcgg 提供的链接之外,还值得听听那些
回答by ProgrammerPanda
My experience with Postgres and Mongo after working with both the databases in my projects .
在我的项目中使用这两个数据库后,我对 Postgres 和 Mongo 的体验。
Postgres(RDBMS)
Postgres(RDBMS)
Postgres is recommended if your future applications have a complicated schema that needs lots of joins or all the data have relations or if we have heavy writing. Postgres is open source, faster, ACID compliant and uses less memory on disk, and is all around good performant for JSON storage also and includes full serializability of transactions with 3 levels of transaction isolation.
如果您未来的应用程序有一个复杂的模式,需要大量连接或所有数据都有关系,或者我们有大量的写作,那么推荐使用 Postgres。Postgres 是开源的、速度更快、符合 ACID 并且在磁盘上使用更少的内存,并且在 JSON 存储方面具有良好的性能,并且包括具有 3 个事务隔离级别的事务的完全序列化。
The biggest advantage of staying with Postgres is that we have best of both worlds. We can store data into JSONB with constraints, consistency and speed. On the other hand, we can use all SQL features for other types of data. The underlying engine is very stable and copes well with a good range of data volumes. It also runs on your choice of hardware and operating system. Postgres providing NoSQL capabilities along with full transaction support, storing JSON documents with constraints on the fields data.
留在 Postgres 的最大优势是我们拥有两全其美的优势。我们可以将数据存储到具有约束、一致性和速度的 JSONB 中。另一方面,我们可以将所有 SQL 特性用于其他类型的数据。底层引擎非常稳定,可以很好地应对各种数据量。它还可以在您选择的硬件和操作系统上运行。Postgres 提供 NoSQL 功能以及完整的事务支持,存储带有字段数据约束的 JSON 文档。
General Constraints for Postgres
Postgres 的一般约束
Scaling Postgres Horizontally is significantly harder, but doable.
水平缩放 Postgres 要困难得多,但可行。
Fast read operations cannot be fully achieved with Postgres.
Postgres 无法完全实现快速读取操作。
NO SQL Data Bases
没有 SQL 数据库
Mongo DB (Wired Tiger)
Mongo DB(有线老虎)
MongoDB may beat Postgres in dimension of “horizontal scale”. Storing JSON is what Mongo is optimized to do. Mongo stores its data in a binary format called BSONb which is (roughly) just a binary representation of a superset of JSON. MongoDB stores objects exactly as they were designed. According to MongoDB, for write-intensive applications, Mongo says the new engine(Wired Tiger) gives users an up to 10x increase in write performance(I should try this), with 80 percent reduction in storage utilization, helping to lower costs of storage, achieve greater utilization of hardware.
MongoDB 可能会在“横向规模”维度上击败 Postgres。存储 JSON 是 Mongo 的优化目标。Mongo 以称为 BSONb 的二进制格式存储其数据,它(大致)只是 JSON 超集的二进制表示。MongoDB 完全按照设计存储对象。根据MongoDB的说法,对于写密集型应用,Mongo表示新引擎(Wired Tiger)让用户的写性能提高了10倍(我应该试试这个),存储利用率降低80%,有助于降低存储成本,实现更大的硬件利用率。
General Constraints of MongoDb
MongoDb 的一般约束
The usage of a schema less storage engine leads to the problem of implicit schemas. These schemas aren't defined by our storage engine but instead are defined based on application behavior and expectations.
使用无模式存储引擎会导致隐式模式的问题。这些模式不是由我们的存储引擎定义的,而是基于应用程序行为和期望定义的。
Stand-alone NoSQL technologies do not meet ACID standards because they sacrifice critical data protections in favor of high throughput performance for unstructured applications. It's not hard to apply ACID on NoSQL databases but it would make database slow and inflexible up to some extent. “Most of the NoSQL limitations were optimized in the newer versions and releases which have overcome its previous limitations up to a great extent”.
独立的 NoSQL 技术不符合 ACID 标准,因为它们牺牲了关键数据保护来支持非结构化应用程序的高吞吐量性能。在 NoSQL 数据库上应用 ACID 并不难,但它会在一定程度上使数据库变慢和不灵活。“大多数 NoSQL 限制都在较新的版本和发行版中进行了优化,在很大程度上克服了以前的限制”。
回答by AABBCCDD
It's all about trade offs. MongoDB is fast but not ACID, it has no transactions. It is better than MySQL in some use cases and worse in others.
这都是权衡取舍。MongoDB 很快,但不是 ACID,它没有事务。它在某些用例中比 MySQL 更好,而在其他用例中则比 MySQL 更差。
回答by Nanhe Kumar
Bellow Lines Written in MongoDB: The Definitive Guide.
用 MongoDB 编写的波纹管:权威指南。
There are several good reasons:
- Keeping different kinds of documents in the same collection can be a nightmare for developers and admins. Developers need to make sure that each query is only returning documents of a certain kind or that the application code performing a query can handle documents of different shapes. If we're querying for blog posts, it's a hassle to weed out documents containing author data.
- It is much faster to get a list of collections than to extract a list of the types in a collection. For example, if we had a type key in the collection that said whether each document was a “skim,” “whole,” or “chunky monkey” document, it would be much slower to find those three values in a single collection than to have three separate collections and query for their names
- Grouping documents of the same kind together in the same collection allows for data locality. Getting several blog posts from a collection containing only posts will likely require fewer disk seeks than getting the same posts from a collection con- taining posts and author data.
- We begin to impose some structure on our documents when we create indexes. (This is especially true in the case of unique indexes.) These indexes are defined per collection. By putting only documents of a single type into the same collection, we can index our collections more efficiently
有几个很好的理由:
- 将不同类型的文档保存在同一个集合中对于开发人员和管理员来说可能是一场噩梦。开发人员需要确保每个查询只返回某种类型的文档,或者执行查询的应用程序代码可以处理不同形状的文档。如果我们要查询博客文章,则清除包含作者数据的文档会很麻烦。
- 获取集合列表比提取集合中的类型列表要快得多。例如,如果我们在集合中有一个类型键,表示每个文档是“脱脂”、“整个”还是“矮胖的猴子”文档,那么在单个集合中查找这三个值要比查找这三个值慢得多。有三个单独的集合并查询它们的名称
- 将相同类型的文档组合在同一个集合中可以实现数据局部性。从仅包含帖子的集合中获取多篇博客帖子可能比从包含帖子和作者数据的集合中获取相同帖子需要更少的磁盘搜索。
- 当我们创建索引时,我们开始在我们的文档上强加一些结构。(在唯一索引的情况下尤其如此。)这些索引是按集合定义的。通过只将单一类型的文档放入同一个集合中,我们可以更有效地索引我们的集合
回答by user2982063
- MongoDB supports search by fields, regular expression searches.Includes user defined java script functions.
- MongoDB can be used as a file system, taking advantage of load balancing and data replication features over multiple machines for storing files.
- MongoDB 支持按字段搜索、正则表达式搜索。包括用户定义的 java 脚本函数。
- MongoDB 可以用作文件系统,利用多台机器上的负载平衡和数据复制功能来存储文件。
回答by PhiLho
After a question of databases with textual storage), I glanced at MongoDB and similar systems.
If I understood correctly, they are supposed to be easier to use and setup, and much faster. Perhaps also more secure as the lack of SQL prevents SQL injection...
Apparently, MongoDB is used mostly for Web applications.
Basically, and they state that themselves, these databases aren't suited for complex queries, data-mining, etc. But they shine at retrieving quickly lot of flat data.
在一个关于文本存储数据库的问题之后),我看了一眼 MongoDB 和类似的系统。
如果我理解正确,它们应该更容易使用和设置,而且速度更快。也许更安全,因为缺少 SQL 可以防止 SQL 注入......
显然,MongoDB 主要用于 Web 应用程序。
基本上,他们自己声明,这些数据库不适合复杂的查询、数据挖掘等。但它们在快速检索大量平面数据方面表现出色。