MongoDB或CouchDB——适合生产环境吗?

我想知道是否有人能告诉我MongoDB或CouchDB是否为生产环境准备好了。

我现在正在研究这些存储解决方案(目前我更喜欢MongoDB)，但是这些项目还很年轻，所以我预见到我将不得不非常努力地说服我的经理，我们应该采用这种新技术。

我想知道的是:

  1. 现在谁在生产环境中使用MongoDB或CouchDB ?

  2. 你如何使用MongoDB/CouchDB?

  3. 当你采用这种新的存储机制时，你遇到了什么问题(如果有的话)(你是如何克服它们的)?

  4. 你是如何处理你不得不面对的移民问题的?

  5. 你有任何好的或坏的经验，这些解决方案，你想分享吗?

131649 次浏览
小开

我对MongoDB一无所知，但从CouchDB常见问题解答:

CouchDB准备好投入生产了吗?

是的，请参阅InTheWild以获得使用CouchDB的部分项目列表。另一个很好的概述是CouchDB案例研究

还有一些链接:

小开

我们在生产环境中使用couchdb，就在项目被纳入Apache保护伞之前。

我们用它来存储所有可能使用dbms的数据，以及各种非结构化数据。就我个人而言，我非常喜欢这样一种方式:您可以将各种数据放入其中，并使用视图根据情况剔除不需要的数据。

最难的部分是摆脱dbms的思维模式。为了安全起见，当存储格式改变时，我们编写了自己的迁移utils，所以这并不是真正的问题。

我们还没有任何负面的经历，但我们也没有在任何巨大的负载下进行设置。I 认为的东西会工作得很好，因为我们有两个从类型的服务器，从一个主服务器复制，得到所有的写。我很确定我们不需要这样做才能正确地进行复制，但这就是我们一开始设置的方式，它一直存在。

小开
最佳答案

我是10gen (MongoDB的开发者)的CTO，所以我有点偏见，但我也管理一些在生产中使用MongoDB的网站。

businessinsider已经在生产中使用mongo一年多了。从用户和博客文章，到网站上的每张图片，他们都在使用它。

shopwiki正在使用它做一些事情，包括实时分析和缓存层。它们每秒对一个相当大的数据库进行超过1000次的写入。

如果你去mongodb生产部署页面，你会看到一些人在生产中使用mongo。

如果您对生产部署的规模或范围有任何疑问，请在我们的用户列表中发帖，我们将非常乐意提供帮助。

小开

我们使用CouchDB存储移动入站和出站消息，并通过我编写的一些自定义视图报告此流量。前端是用Python编写的。我们没有任何真正的技术问题，它自12月底以来一直在运行。我遇到的唯一障碍是最初从MapReduce的角度思考，但一旦我学会了如何做到这一点，其他一切都很顺利。

小开

我在生产中使用CouchDB。目前它存储了所有不在原始DB模式中的“可选”字段。现在我正在考虑将所有数据转移到CouchDB。

我承认这是相当冒险的一步。首先，因为它还不是1.0版本。其次，因为它需要大量的驾驶空间。根据我的计算，CouchDB文件(带索引)比具有相同行的MySQL数据库大30倍。

.

.

.
小开

SourceForge使用MongoDB。参见这个演讲或在这里阅读。

小开
英国广播公司和meebo.com在生产中使用CouchDB，我的一个客户也是如此。 下面是其他使用Couch的人的列表:CouchDB在野外

主要的挑战是知道如何组织文档，并停止从关系数据的角度思考问题。

小开

CouchDB 0.11(发布于3月底)是1.0版本的特性冻结版。这意味着我们将保持与当前1.0版API的兼容性，所以现在是重新研究CouchDB的好时机(如果您很久没有研究过)。

CouchDB 0.11源代码发布在这里。有二进制安装程序和其他好东西链接在这里。

小开

我们目前在生产中使用MongoDB作为缓存层和存储引擎，用于产品导入和操作产品数据。我们是一家电子商务公司，管理着超过200万个产品(1亿多个属性)，横跨10多个分销商，如果没有MongoDB，这项任务几乎是不可能的。

小开

我们将CouchDB作为MySQL的替代品运行在我们的商店(70.0000个商品/商店，所有商品的属性总数为400万个，商品之间的交叉连接)。

我们的目标是:

  1. 从master-db轻松复制到具有不同文档的多个客户端。

  2. 快速预计算数据，比如“这个属性和那个过滤器有多少部分符合这些条件”

事实:

  1. 我们的商店现在运行得比使用MySQL快得多(MySQL数据库需要额外的1-3天的预计算(因此每月更新两次)，使数据为产品计数和过滤做好准备，CouchDB需要5个小时，所以我们可以每晚更新产品数据)
  2. 设置(过滤)数据分布和放大器;备份到商店节点是快速和简单的

但也:

  1. 理解map/reduce和没有连接的限制是相当困难的
  2. 在没有外部程序的情况下，不能对数据进行“删除哪里”或“更新哪里”等操作
  3. 复制工作很好，除非出现问题;(对于初学者来说)真的很难找到原因
  4. 如果您不是Linux极客，那么没有二进制文件(是的，市面上有一些，但并不是每个操作系统/版本都适用)的CouchDB安装可能会很困难。但是CouchDB社区很有帮助(# CouchDB)，幸运的是有一些公司(cloudant, iriscouch)提供从免费到大企业的服务。
  5. CouchDB正在向前发展，因此有很多变化(改进)可能会改变您的工作方式。但基本情况保持稳定。
结果: MySQL作为数据创建和维护的数据库是可靠的，易于理解和处理。我认为我们不会改变这一点。 但我也不想错过CouchDB视图的强大功能和复制设置的便利性

在工作了几个月之后，生产沙发有时会因为错误配置和忘记日志(视图构建花费太长时间或挂起，复制停止)而造成麻烦，但从未丢失数据，并且总是可以轻松重置。

小开

我们在我们的移动后端服务中使用MongoDB，即Netmera。，我们使用它来存储所有用户和内容数据。

小开
我们目前正在使用mongodb作为局域网协作的文件存储服务。 同样，像trello这样的项目使用mongodb作为后端数据存储。 我以前使用过couchdb，但不是在生产能力下
小开

MongoDB在授权给企业方面存在一些问题，我不确定细节，但我们的法律部门不明确地告诉我们，我们不允许在我们的任何产品中使用MongoDB。

小开

我在生产中使用CouchDB已经快2年了。没有迁移工作，因为项目直接从CouchDB实现开始。它作为一个数据库，存储单个电子产品从开始到包装的数据。

由于我们销售的传感器对精度有很高的要求，我们在不同的阶段做了大量的测试，所有这些都将存储在CouchDB上的一个文档中。

我从我的经验中学到了一些学习曲线，那就是充分利用视图(也称为永久视图)。视图应该是数据库中经常被调用的部分的“小过滤器”。

我的CouchDB数据库不像其他大公司那样疯狂。但到目前为止，我做得还不错。目前我有24000个700MB的文档。

我喜欢CouchDB的特性是“复制”，“存储文档的修订”。

我读了很多关于MongoDB的好评，如果有机会，我想尝试一下。

小开

我们在生产中使用mongodb

www.beachfront.io -接近每秒5k写请求 www.beachfrontbuilder.com -每秒500个读写请求，维护1000万用户数据;olap . < / p >

我们通过实现自定义组件克服了数据归档面临的唯一挑战。

小开

这个问题已经有了答案，但现在又有了一个NoSQL数据库，它的许多伟大的功能是趋势。它是Couchbase;它在移动平台上运行为CouchbaseLite，在服务器端运行为Couchbase Server。

下面是Couchbase Lite的一些主要特性。

Couchbase Lite是一个轻量级、面向文档(NoSQL)的语法数据库引擎，适合嵌入到移动应用程序中。

轻量级的意思是:

embedded -数据库引擎是一个链接到应用程序的库，而不是一个单独的服务器进程。 小代码大小——对于移动应用程序来说很重要，因为移动应用程序通常是通过蜂窝网络下载的。 快速启动对时间非常重要，因为移动设备的cpu相对较慢。 低内存使用—典型的移动数据集相对较小，但一些文档可能具有较大的多媒体附件。 当然，良好的性能-确切的数字取决于您的数据和应用程序

面向文档的意思是:

以灵活的JSON格式存储记录，而不需要预定义的模式或规范化。 文档可以有任意大小的二进制附件，比如多媒体内容。 应用程序数据格式可以随着时间的推移而变化，而不需要显式的迁移。 MapReduce索引提供了快速查找，而不需要使用特殊的查询语言

Syncable的意思是:

数据库的任何两个副本都可以通过高效、可靠、经过验证的复制算法进行同步。 同步可以是按需的，也可以是连续的(延迟几秒钟)。 设备可以与远程服务器上大型数据库的一个子集同步。 同步引擎支持断续和不可靠的网络连接。 冲突可以检测和解决，应用程序逻辑完全控制合并。 修订树允许复杂的复制拓扑，包括服务器到服务器(用于多个数据中心)和点对点，而不会发生数据丢失或错误冲突。 Couchbase Lite为无缝的iOS (Objective-C)和Android (Java)开发提供了原生api。此外，它还包括PhoneGap的Couchbase Lite插件，它允许您通过使用熟悉的web应用程序编程技术和PhoneGap移动开发框架来构建iOS和Android应用程序

你可以在他Lite上探索更多

和他服务器

这将成为下一个大事件。

小开
就生产而言，无缝故障转移/恢复都需要一个保姆
1- Couchbase，没有无缝的故障转移/恢复，需要人工干预。
再平衡需要太多时间，如果多个节点丢失，风险也太大。< / p >

2- Mongo与shards，数据从松散的配置服务器恢复，不是一个简单的任务

小开

Adobe正在使用MongoDB作为他们即将发布的Adobe体验管理器(以前是天CQ)的核心DB引擎。

在我工作的机构中，有几个客户在大客户的项目中使用CouchDB。

在我看来，这两个都是伟大而可行的DBs。：）

小开

下面是mongoDB生产部署站点的列表

  • 《纽约时报》:在表单构建应用程序中使用它来提交照片。Mongo缺乏模式，这使得生产者能够定义自定义表单字段的任意组合。
  • SourceForge:用于SourceForge首页、项目页面和所有项目的下载页面上的后端存储。
  • bit . ly
  • Etsy
  • IGN:支持IGN的实时流量分析和RESTful Content api。
  • tv:权力贾斯汀。Tv的内部分析工具用于病毒式传播、用户留存和常规使用数据，这些都是常规解决方案无法提供的。
  • Posterous
  • 直觉
  • 四方: Sharded Mongo数据库用于foursquare的大多数数据。
  • 商业内幕:从2008年初开始使用它。该网站的所有数据，包括帖子、评论，甚至图像都存储在MongoDB上。
  • Github:用于内部报告应用程序。
  • 考官:将他们的站点从冷融合和SQL Server迁移到Drupal 7和MongoDB。
  • Grooveshark:目前使用Mongo每天管理超过一百万的独特用户会话。
  • Buzzfeed
  • 铁饼
  • 避开:用于分析和快速报告。
  • Squarespace
  • Shutterfly:用于Shutterfly中各种持久数据存储需求。MongoDB帮助Shutterfly建立无与伦比的服务，使客户和那些在他们生活中最重要的人之间建立更深入、更私人的关系。
  • Topsy
  • Sharethis
  • Mongohq中:为MongoDB提供托管平台，也使用MongoDB作为其服务的后端。我们的托管中心页面提供了关于MongoHQ和其他MongoDB托管选项的更多信息。

和更多的……

< p >提取: http://lineofthought.com/tools/mongodb < / p >

你也可以在那里查看其他数据库或工具。


提交答案