我想知道是否有人可以告诉我 MongoDB 或者 沙发数据库 准备好 生产 环境。

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

我想知道的是:

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

  2. 您如何使用 MongoDB/CouchDB?

  3. 当您采用这种新的存储机制时,您遇到了哪些问题(如果有)(以及您是如何克服这些问题的)?

  4. 您是如何处理必须处理的迁移问题的?

  5. 您对这些解决方案有什么好的/坏的经验可以分享吗?

有帮助吗?

解决方案

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

商业内幕 现在已经在生产中使用 mongo 一年多了。他们将它用于从用户和博客文章到网站上的每个图像的所有内容。

商店维基 将它用于一些事情,包括实时分析和缓存层。他们每秒对一个相当大的数据库执行超过 1000 次写入。

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

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

其他提示

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

主要挑战是了解如何组织文档并停止根据关系数据进行思考。

来源锻造 使用 MongoDB。看 这个演示文稿 或者 在这里读.

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

我们的目标是:

  1. 轻松从主数据库复制到具有不同文档的多个客户端。

  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 视图的强大功能和复制设置的简便性。

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

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

我承认,这是一个相当冒险的步骤。首先,因为它还不是 v1.0。其次,因为它需要驱动器空间。根据我的计算,CouchDB 文件(带索引)比具有相同行的 MySQL 数据库大约 30 倍。但我很确定它会很好地发挥作用。

CouchDB 0.11(三月底发布)是 1.0 的功能冻结版本。这意味着我们将保持与 1.0 的当前 API 的兼容性,因此,如果您有一段时间没有关注 CouchDB,现在是再次查看 CouchDB 的好时机。

CouchDB 0.11 源代码版本可在此处获取。二进制安装程序和其他好东西链接在这里。

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

CouchDB 准备好投入生产了吗?

是的,请参阅 在野外 使用 CouchDB 的部分项目列表。另一个很好的概述是 CouchDB 案例研究

另外,一些链接:

我们在生产中使用 couchdb,并且从该项目进入 Apache 保护伞之前就开始使用了。

我们用它来存储我们可能使用数据库管理系统的所有内容,以及各种非结构化数据。就我个人而言,我真的很喜欢如何将各种数据放入其中,并根据情况使用视图来剔除不需要的数据。

最困难的部分是摆脱 dbms 思维方式。为了安全起见,当存储格式发生更改时,我们编写了自己的迁移实用程序,因此这并不是真正的问题。

我们还没有任何负面的经历,但话又说回来,我们还没有在任何巨大的负载下进行设置。我 思考 事情会工作得很好,因为我们有两个从属类型服务器,它们从获取所有写入的单个主服务器进行复制。我很确定我们不必这样做才能使复制正常工作,但这就是我们一开始的设置方式,并且它卡住了。

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

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

我们目前使用 mongodb 作为文件存储服务,用于通过 LAN 进行协作。另外,像这样的项目 特雷洛 使用 mongodb 作为后端数据存储。我之前使用过couchdb,但没有用于生产能力。

我们在移动后端服务的生产中使用 MongoDB,即 内特梅拉。 我们用它来存储所有用户和内容数据。

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

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

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

我的 CouchDB 数据库并不像其他大公司那么疯狂。但到目前为止,我仍然做得很好。目前我有 24000 个文档,大小为 700MB。

我喜欢的 CouchDB 功能是“复制”、“存储文档的修订版本”。

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

我们在生产中使用 mongodb

www.beachfront.io-接近5K写请求,每秒www.beachfrontbuilder.com -500读/写请求,每秒,维护1000万用户数据和OLAP。

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

这个问题已经接受答案,但现在又过了一天 NoSQL数据库 因其许多出色的功能而流行。这是 Couchbase;其运行方式为 CouchbaseLite 在移动平台上和 Couchbase Server 在你的服务器端。

以下是 Couchbase Lite 的一些主要功能。

Couchbase Lite 是一种轻量级、面向文档 (NoSQL)、可同步的数据库引擎,适合嵌入到移动应用程序中。

轻量化意味着:

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

面向文档意味着:

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

可同步意味着:

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

您可以探索更多 沙发底座精简版

沙发基地服务器

这将是下一件大事。

就生产而言,无缝故障转移/恢复都需要保姆
1- Couchbase,没有无缝的故障转移/恢复,需要手动干预。
重新平衡需要太多时间,如果多个节点丢失,风险太大。

2-带有分片的 Mongo,从丢失配置服务器中恢复数据并不是一件容易的事

土坯 正在使用 MongoDB 为他们即将发布的 Adobe 体验经理 (以前 日CQ)作为核心数据库引擎。

我工作的机构的几个客户正在使用 沙发数据库 针对大客户的项目。

在我看来,两者都是伟大且可行的数据库。:)

以下是使用 mongoDB 的生产部署站点的列表

  • 纽约时报:在表单构建应用程序中使用它来提交照片。Mongo 缺乏架构,使生产者能够定义自定义表单字段的任意组合。
  • 来源锻造:用于所有项目的 SourceForge 首页、项目页面和下载页面上的后端存储。
  • 比特网
  • 埃特西
  • IGN:为 IGN 的实时流量分析和 RESTful 内容 API 提供支持。
  • 贾斯汀电视:为 Justin.tv 的内部分析工具提供支持,以实现病毒式传播、用户保留和一般使用统计数据,这是开箱即用的解决方案无法提供的。
  • 后壁
  • 财捷
  • 四方:foursquare 的大部分数据都使用分片 Mongo 数据库。
  • 商业内幕:从 2008 年初开始使用。网站的所有数据,包括帖子、评论,甚至图像,都存储在 MongoDB 中。
  • 吉图布:用于内部报告应用程序。
  • 考官:将他们的站点从 Cold Fusion 和 SQL Server 迁移到 Drupal 7 和 MongoDB。
  • 槽鲨:目前使用 Mongo 每天管理超过一百万个唯一用户会话。
  • 嗡嗡声
  • 铁饼
  • 埃维特:用于分析和快速报告。
  • 方空间
  • 快门:用于 Shutterfly 内的各种持久数据存储需求。MongoDB 帮助 Shutterfly 构建无与伦比的服务,使客户与他们生活中最重要的人之间建立更深入、更私人的关系。
  • 托普西
  • 分享这个
  • 蒙古人:为 MongoDB 提供托管平台,并使用 MongoDB 作为其服务的后端。我们的托管中心页面提供了有关 MongoHQ 和其他 MongoDB 托管选项的更多信息。

和更多...

摘自:http://lineofthought.com/tools/mongodb

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top