何时使用MongoDB [英] When to use MongoDB

问题描述

我在写一个不一定需要扩展能力的应用程序，因为它不会在开始时收集大量数据。

I'm writing an application that doesn't necessarily need scaling abilities as it won't be collecting large amounts data at the beginning. (However, if I'm lucky, I could down the road potentially.)

我将在同一个盒子上运行我的网络服务器和数据库（现在）。

I will be running my web server and database on the same box (for now).

话虽如此，我在寻找性能和效率。

That being said, I am looking for performance and efficiency.

我的应用程序的主要部分将加载博客文章。使用RDBMS（MySQL）我将做6个查询（2个查询是联接），只是加载一个博客文章页面。

The main part of my application will be loading blog articles. Using an RDBMS (MySQL) I will make 6 queries (2 of the queries being joins), just to load a single blog article page.

select blog
select blog_album
select blog_tags
select blog_notes
select blog_comments (join with users)
select blog_author_participants (join with users)

href =http://en.wikipedia.org/wiki/MongoDB =noreferrer> MongoDB 我可以反标准化和平展6表只有2个表/集合和最小化我的查询潜在地一个1查询，

However, with MongoDB I can de-normalize and flatten 6 tables into just 2 tables/collections and minimizes my queries to potentially just one 1 query,

users
blogs
    ->blog_album
    ->blog_tags        
    ->blog_notes
    ->blog_comments
    ->blog_author_participants

现在，使用MongoDB模式，会有一些数据冗余。但是，硬盘空间比CPU /服务器便宜。

Now, going with the MongoDB schema, there will be some data redundancy. However, hard drive space is cheaper than CPU/servers.

1。）这是使用MongoDB的好方案吗？

1.) Would this be a good scenario to use MongoDB?

2。）当您扩展到单个服务器之上时，您是否仅在使用MongoDB的性能上受益？

2.) Do you only benefit in performance using MongoDB when scaling beyond a single server?

3。 ）使用MongoDB有任何持久性风险吗？我听说在执行插入时可能会丢失数据 - 因为插入先写入内存，然后再写入数据库。

3.) Are there any durability risks using MongoDB? I hear that there is potential for loss of data while performing inserts - as insert are written to memory first, then to the database.

4。）这应该会阻止我

4.) Should this stop me from using MongoDB in production?

推荐答案

但是，使用MongoDB我可以反规格化和平展6个表只需2个表/集合，并将我的查询减少到可能只有一个查询

However, with MongoDB I can de-normalize and flatten 6 tables into just 2 tables/collections and minimizes my queries to potentially just one 1 query

但是硬盘驱动器空间比CPU /服务器更便宜。 p>

however hard drive space is cheaper than CPU/servers.

如果性能和扩展是一个优先级，那么你将关心有足够的RAM来适应一切到主内存和足够的CPU内核运行查询。企业级RAID 10阵列是一个要求，不要误会，但是一旦你的数据库软件（MongoDB或MySQL）需要扫描一个索引，无法适应主内存你会在一个世界的假设一个大型活动数据库。 ：）

If performance and scaling is a priority then you are going to be concerned with having enough RAM to fit everything into main memory and enough CPU cores to run queries. An enterprise grade RAID 10 array is a requirement, don't get me wrong, but as soon as your database software (MongoDB or MySQL) needs to scan an index that can't fit into main memory you'll be in for a world of pain assuming a large active database. :)

我喜欢MongoDB，但在我看来，它的强大之处在于map / reduce和它的文档方向。你不需要那些功能。 MySQL在大规模部署中经过时间测试，并支持分区（但我认为，您的数据库必须在50-100 GB的数量级，然后才能从分区与单个（加上被动备份）服务器实现实质性增益（64 GB +）的RAM。我也认为如果性能真的是一个关注，那么MySQL将是更可取的，因为你将对你的索引有最高的控制。

I like MongoDB, but it's big strength in my mind is map/reduce and its document-orientation. You require neither of those features. MySQL is time-tested in large scale deployments and supports partitioning (but I would argue that your database would have to be in the order of 50-100 GB before you can realize substantial gain from partitioning vs a single (plus passive backup) server with tons (64 GB+) of RAM. I would also argue that if performance is truly a concern then MySQL would be preferable as you would have supreme control over your indexes.

不是说MongoDB不是高性能，而是它的地方可能是不服务博客你对插入的关注也是有效的MongoDB不是一个 ACID 系统。在两个系统中进行Google交易并进行比较。

That's not to say that MongoDB isn't high performance, but its place probably isn't serving blogs. Your concern with inserts is valid as well. MongoDB is not an ACID system. Google transactions in both systems and compare.

这篇关于何时使用MongoDB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！