IT牛人博客聚合

某人发了一篇Don’t use MongoDB的血泪控诉，我把原文翻译如下，你可以看看。不过，我想我们还要去看看10gen CTO的对此事的回复，我们还要去在Reddit上看看大家的说法，10gen CTO的对此事的回复后面也有一堆人在讨论这个事，还有一些程序员开始去读MongoDB的源码了，呵呵。看样子，说MongoDB的这些事并不是真的。

10gen CTO 对此事的并不完全知道，其在回复，对些文中的每一条都做了回复。我把其回复的大体意思也放在原文中。不过，很有意思的是那些程序员的讨论。建议大家看看。

正文

因为各种政治原因，我这段时间没有说什么，但是现在我觉得因为要对社会负责，所以我要阻止大家不要把你们的业务

查看全文: http://www.udpwork.com/item/6256.html

但凡初次接触MongoDB的人，无不惊讶于它对内存的贪得无厌，至于个中缘由，我先讲讲Linux是如何管理内存的，再说说MongoDB是如何使用内存的，答案自然就清楚了。

据说带着问题学习更有效，那就先看一个MongoDB服务器的top命令结果：

shell> top -p $(pidof mongod)
Mem: 32872124k total, 30065320k used, 2806804k free, 245020k buffers
Swap: 2097144k total, 100k used, 2097044k free, 26482048k cached

VIRT RES SHR

查看全文: http://www.udpwork.com/item/5668.html

最近忙着把一个项目从MySQL迁移到MongoDB，在导入旧数据的过程中，遇到了些许波折，犯了不少错误，但同时也学到了不少知识，遂记录下来。

公司为这个项目专门配备了几台高性能务器，清一色的双路四核超线程CPU，外加32G内存，运维人员安装好MongoDB后，就交我手里了，我习惯于在使用新服务器前先看看相关日志，了解一下基本情况，当我浏览MongoDB日志时，发现一些警告信息：

WARNING: You are running on a NUMA machine. We suggest launching mongod like this to avoid performance problems: numactl –

查看全文: http://www.udpwork.com/item/5623.html

MySQL是关系型数据库中的明星，MongoDB是文档型数据库中的翘楚。下面通过一个设计实例对比一下二者：假设我们正在维护一个手机产品库，里面除了包含手机的名称，品牌等基本信息，还包含了待机时间，外观设计等参数信息，应该如何存取数据呢？

如果使用MySQL的话，应该如何存取数据呢？

如果使用MySQL话，手机的基本信息单独是一个表，另外由于不同手机的参数信息差异很大，所以还需要一个参数表来单独保存。

CREATE TABLE IF NOT EXISTS `mobiles` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` VARCHAR(100) N

查看全文: http://www.udpwork.com/item/5214.html

前面如何优化/监控MongoDB的部分介绍很实用..

这是针对MongoDB本身设计来做的优化,,主要是Json格式内置的弊端,,如何取长补短.

Optimizing MongoDB: Lessons Learned at Localytics
View more presentations from andrew311

No related posts.

查看全文: http://www.udpwork.com/item/5212.html

通过源代码编译安装好MongoDB之后，接下来需要配置运行。在MongoDB的安装目录，有几个子目录，bin下面是可执行文件，包括

mongod：数据库服务端，类似mysqld，每个实例启动一个进程，可以fork为Daemon运行

mongo：客户端命令行工具，类似sqlplus/mysql，其实也是一个js解释器，支持js语法

mongodump/mongorestore：将数据导入为bson格式的文件/将bson文件恢复为数据库，类似xtracbackup

mongoexport/mongoimport：将collection导出为json/csv格式数据/将数据导入数据库，类似mysqldump/mysqlimport

查看全文: http://www.udpwork.com/item/4780.html

前面扯了一堆，要了解一个东西，最好的办法，还是让他跑起来，然后结合文档和测试，来验证其实现，并且了解其不足和优点。

MongoDB提供了部分系统的编译版本，但从研究学习以及线上不同依赖包的稳定性的目标，个人还是比较推荐从源代码编译安装的方式。MongoDB的源代码依赖了一些基础组件，如js引擎Spider Monkey，正则表达式引擎PCRE，安装构建工具Scons，以及C++的boost库等，因此编译还是有些麻烦的，realzyy的这篇文章已经比较详细的说明了编译的步骤，主要基于Redhat系统。在ubuntu上安装，还有几个注意点：

1. PCRE最好在编译的时候显式指明对UTF-8的支持

$ configure --en

查看全文: http://www.udpwork.com/item/4700.html

按照官方的说法，MongoDB是一种可扩展的高性能的开源的面向文档（document-oriented ）的数据库，采用C++开发。注意mongo不是mango（芒果），这个词是从humongous中截取出来的，其野心不言而明，直指海量数据存储。和其他很多NoSQL不太一样，MongoDB背后有一个专门的商业公司在提供支持和推广，有点类似MySQL AB的模式。这一系列文章，是为入门者写的，已经对NoSQL和MongoDB有一定研究和经验的，可以略过，或者看看如有疏漏，请留言指出。

面向文档，那么什么是文档呢？很明显这不是我们常见的word文档。这里说的文档，是一种可以嵌套的数据集合。从关系数据库的范式的概念来说，嵌套是明显的反范

查看全文: http://www.udpwork.com/item/4691.html

本文所说的整数问题，其实并不是MongoDB的问题，而是PHP驱动的问题：MongoDB本身有两种整数类型，分别是：32位整数和64位整数，但旧版的PHP驱动不管操作系统是32位还是64位，把所有整数都当做32位整数处理，结果导致64位整数被截断。为了在尽可能保持兼容性的前提下解决这个问题，新版PHP驱动加入了mongo.native-long选项，以期在64位操作系统中把整数都当做64位来处理，有兴趣的可参考：64-bit integers in MongoDB。

那么PHP驱动真的完全解决了整数问题么？NO！在处理group操作的时候还有BUG：

为了说明问题，我们先来生成一些测试数据：

<?php

ini_set

查看全文: http://www.udpwork.com/item/4674.html

mongodb支持的数据类型中，ObjectId是其自有产物，本文对其做些简单的介绍。

存储在mongodb集合中的每个文档（document）都有一个默认的主键_id，这个主键名称是固定的，它可以是mongodb支持的任何数据类型，默认是ObjectId。在关系数据库schema设计中，主键大多是数值型的，比如常用的int和long，并且更通常的，主键的取值由数据库自增获得，这种主键数值的有序性有时也表明了某种逻辑。反观mongodb，它在设计之初就定位于分布式存储系统，所以它原生的不支持自增主键。而现实的世界是，大量应用在可预见的时空里并不需要分布式的mongodb，所以网上就出现了大量的实现mongodb自增主键方法的文章

查看全文: http://www.udpwork.com/item/4463.html

赋闲以后很长没有更新博客了，说忙完全是借口，多半因为没有兴致所致。今天凌晨比赛多多，趁着比赛的前奏和间隙，遂浏览些技术文章。发现了 highscalability.com整理出了wordnik使用mongodb和scala的使用经 验：http://highscalability.com/blog/2011/2/15/wordnik-10-million-api- requests-a-day-on-mongodb-and-scala.html。这个wordnik也算是mongodb的先驱应用者之一，并贡献了一些管理工具给社区，去年的mongoSF大会也有它的参与：http://www.slideshare.net/fehguy /

查看全文: http://www.udpwork.com/item/4297.html

MySQL用户多半都有Auto Increment情结，不过MongoDB缺省并没有实现，所以需要模拟一下，编程语言以PHP为例，代码大致如下所示：

<?php

function generate_auto_increment_id($namespace, array $option = array())
{
$option += array(
'init' => 1,
'step' => 1,
);

$instance = new Mongo();

$instance = $instance->selectCollection('_se

查看全文: http://www.udpwork.com/item/4677.html

由于项目需要，最近简单研究了一下 mongodb。作为一款数据库产品，mongodb 确实有很多吸引人的地方：性能优异，模式自由，支持复制和故障恢复等等。但是我认为，mongodb 要在数据库领域占领一席之地，恐怕没那么简单。

每个公司都有成熟、稳定的数据存储解决方案，从 DBA 到程序员，都熟悉这些正在使用的数据库，如果没有很大的必要，为何要冒险迁移到新的数据库呢？mongodb 性能优异，但是只要部署了缓存服务，mongodb 的优异性能就不明显了，事实上，我相信没有多少公司直接使用数据库扛所有的读写请求。如果业务逻辑改了，需要增加新的数据字段，那老的数据总是要修复的，否则就要在代码里判断，所以模式自由这个优势也打了折扣。据我

查看全文: http://www.udpwork.com/item/4077.html

Redis作者antirez是一个非常勤奋的开发者，在Redis性能已经非常惊人的情况下持续不断开发新的特性，比如从新的cluster源代码看到，作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化，在Web 2.0时代，Memcached已经非常不够用，技术人员需要考虑做很多额外工作才能让Memcached适应新的变化和需求。

antirez在1月5日Google Groups发表了一篇Redis diskstore文章，对Redis VM方式进行了反省，思考是否有更好的方式来大数据的Redis访问。

a few months after VM st

查看全文: http://www.udpwork.com/item/3999.html

商品图片，平均200－500K，说大不大，说小不小，但量大且细碎，最早通过页面上传，全部保存在文件里，且不分目录，管理和索引都很慢，几乎无法备份，读取也很慢。

改进方案由大鱼设计，图片是保存在MySQL表里，每10万张图就换一张新表，操作语言是PHP，它解决了图片备份和缓存的问题。

经过一段运行时间后，我对效果并不满意，主要是速度还是有些慢，尤其是第一次加载的过程。这期间又负责主体商品数据迁移到MongoDB，大致研究了一下GridFS，并做了些测试，感觉这个比MySQL要靠谱，且MongoDB还有Sharding和Replica Set支持，帮我解决了分布存储的问题，很是诱人，决定一试。

设计思路和需求整理：

决不允许重复

查看全文: http://www.udpwork.com/item/3947.html

最近在做搜索的查询日志的统计分析，对每一条查询统计日志，我将其解析出来后以特定字段格式存在mongodb中，定时调度做些统计分析。其中有个需求是，统计某个时间段（每天、每周、每月）各个query的查询次数，展示上就是热门查询query了。考虑到处理的数据量不会很大，解决方法也可以简单来之。我现在使用的方法就是mongodb的MapReduce功能，其实这个需求也可以认为是个group操作，而mongodb的group功能就是基于MapReduce的，但group对结果集的大小是有限制的。本文就针对一个示例介绍一下mongodb MapReduce功能。

语法介绍

MapReduce是mongodb中的一个Command，它的语

查看全文: http://www.udpwork.com/item/2745.html