|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-12-14
AreYouOK? 写道 我在工作中也遇到很多问题，关系数据库确实有些力不从心了，但是不使用关系数据库，面对复杂的查询，没有好的解决方案。
从这篇文章的介绍看，我对MongoDB最感兴趣，期待后续。 我的需求和这里列出的Web2.0的网站需求还不太一样。我的场景是：
在某个项目里面，数据量大的时候大约每天40、50G，使用postgresql，居然也支撑了下来，但是查询非常慢。接下来的一些项目数据量会更大，可能会有这个量的100倍以上，目前没有好的办法，只能从数据源头先做过滤。 我在1年前，开始尝试进行一些探索，根据产品需求特点，使用自定义的数据格式存储。目前能够解决的问题有：
不幸的是，我只有很少的时间能投入到这上面，有时候几个星期都没空去弄，所以到现在还有很多要完善的地方，没有在项目里面实用。有时候我都怀疑这条路是不是走错了。 目前没有解决的问题是高性能的、对数据的复杂查询。数据可以分为2部分，原始数据和格式化后的数据，目前我这里只解决了原始数据的问题，对于格式化数据的复杂查询，还是需要类似关系数据库的功能才行。这也是我对MongoDB比较感兴趣的原因。 感觉上，你这就是一个日志统计系统，解决模型可以看现在大部分的日志统计程序 只保留必要的数据，并且汇总必要的数据，根据你可以开放的查询功能，设计你的数据结构。 |
| 返回顶楼 | |
|
发表时间：2010-01-06
非常好的文章。
我们目前使用的是TokyoCabinet。为了能更好的使用，我们也写了一个类似于ActiveRecord的gem包———— ActiveObject. 有兴趣参与开发的朋友可以和我们联系  http://github.com/totothink/active_object |
| 返回顶楼 | |
|
发表时间：2010-01-11
最后修改：2010-01-11
mongodb是目前高性能数据库中唯一可以在windows下使用的，它具备类似对象数据的高级查询功能，目前已具备高级查询功能，如：与、等于、大于、小与、正则表达式查询、分页等等（或逻辑目前还没有支持）。
正则表达式查询可以做出类似全文检索的功能。 但在windows下，mongodb作为服务启动，当直接关闭windows而非通过人工停止mongodb服务，会引起本次开机以来的所有数据丢失问题，不知道是否有人遇到过这个问题？ 不知道linux下是否也存在该问题，抽时间测试一下。 |
| 返回顶楼 | |
|
发表时间：2010-01-14
最近一直在利用空闲时间整mongodb，分别用vc2008编写了操作mysql和mongodb的测试工程
今天测试了一下同插入十万条数据 mongodb需10秒 mysql需20秒 而数据全部删除mongodb显示为0秒（为何是0还未研究mongodb的机制） mysql需要6秒 上面的测试环境都是我个人的PC，性能并不好，但用于对比倒也无妨。 |
| 返回顶楼 | |
|
发表时间：2010-01-15
itian 写道 准备做个社区类网站，在寻觅nosql数据库，最近简单测试了一下市面上的nosql数据库，MongoDB是我目前最想用的。
我用java连接另外一台机器上的虚拟机上的ubuntu服务器，插入1W条数据，速度基本上控制在1000ms以内，相比我在同样的坏境下用Hibernate写入mysql来说，mongo我已经觉得是神级的了，但是目前还有最后一个问题，Mongodb说它的默认引擎是使用“内存映射文件”的，这一点我一直搞不太明白，或者说，我不知道怎么控制它只占用指定的内存空间，不管我一次插入一百万，还是一千万条数据，它的内存始终在增长，直到内存占用90%以上，整个系统动不了为止，这点让我非常郁闷。 是啊，我也遇到这个内存一直增加的问题，现在是在生产环境下跑的。内存已经用到69%，还是一直在涨，不知道会不会当掉 |
| 返回顶楼 | |
|
发表时间：2010-01-15
我记得论坛里有一篇帖子 - 数据库水平切分的实现原理解析讲的很好，这个水平切分的模型有点类似Teradata，其核心思想就是将大数据打散，提高并发。
我们试想下：假如有1亿条数据，以某种算法（Teradata里是用的哈希算法）均匀分散到20个库里面（在Teradata里是20个AMP），那么每个库只需要处理500万条数据，压力大幅降低，在路由器的广播控制下（Teradata里是YNET）多个库并发协同工作（每个库有自己独立的磁盘，这样就大幅减少高并发下的I/O冲突）（在Teradata里是每个AMP对应一个或者多个磁盘），高并发下海量数据处理性能就得到了极大的提高！相比Teradata单个节点动辄上千万的天价，数据库水平切分真是个平民化的解决方案！ |
| 返回顶楼 | |
|
发表时间：2010-01-15
最后修改：2010-01-15
lenky0401 写道 最近一直在利用空闲时间整mongodb，分别用vc2008编写了操作mysql和mongodb的测试工程
今天测试了一下同插入十万条数据 mongodb需10秒 mysql需20秒 而数据全部删除mongodb显示为0秒（为何是0还未研究mongodb的机制） mysql需要6秒 上面的测试环境都是我个人的PC，性能并不好，但用于对比倒也无妨。 由我测试的结果表明，mongodb写入数据时并未写入磁盘，而是放在了内存当中，在重启系统数据全部丢失就能证明这一点，所以数据删除非常迅速，remove()方法就是删除了所有记录，不知道你删除是用了何种方法。 |
| 返回顶楼 | |
|
发表时间：2010-01-21
多谢分享，最近我也在研究voldemort以及hadoop，觉得目前单纯靠DB的partition和sharding已经很难满足高伸缩性的情况，尤其是对写入高伸缩性的情况，采用key-value存储使得切分和复制不用我们考虑，真的是一种非常棒的scale out解决方案.
|
| 返回顶楼 | |
|
发表时间：2010-01-24
最后修改：2010-01-25
我也做了一下MongoDB测试，结果如下：
（suse11-64bit、xeon3.6*2、4G DDR333、scsi73G*2无raid 的老机器） 1、insert 九百万条简单数据（3个字段）：平均值大约在24000/s（最高2.8W，最低2.1W）；同时，插入第一个一百万和第九个一百万效率没有明显差异，数据文件体积大概在3.8G，比较大； 2、select 一万条数据（有索引）：57~61ms，一千条大概在6ms左右，非常稳定； 在过程中也碰到了很棘手的问题，我原本想插入亿级别的数据，但没有成功，每次插入到一千万数据就崩溃了，提示：mmap failed with out of memory，google了一把，资料还是比较匮乏，有的说是bug，有的说是内存太小，我偏向后者，因为Mongo已经说过，mongodb采用内存文件映射机制，怀疑是否因为内存太低？但若真是这样麻烦又来了，有多少数据就要多大内存，这恐怕一般用户受不了吧？ 大家也碰到类似问题了嘛？ 另外还有一点，mongodb的数据文件挺有意思，千万条数据分为若干个文件，分别为：db1.0：64M ; db1.1：128M ; db1.2：256M ;db1.3：512M ; db1.4：1024M ; db1.5：2G ; db1.6：2G ...都没有超过两G，我以为是win32的问题，结果到suse64上一样 |
| 返回顶楼 | |
|
发表时间：2010-01-28
最后修改：2010-01-28
view = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if ( view == MAP_FAILED ) {
out() << " mmap() failed for " << filename << " len:" << length << " errno:" << errno << endl;
if ( errno == ENOMEM ){
out() << " mmap failed with out of memory, if you're using 32-bits, then you probably need to upgrade to 64" << endl;
}
return 0;
}
return view;
在64位linux下也会报“mmap failed with out of memory”错误？ |
| 返回顶楼 | |
