推荐工具
› RoboMongo
推荐书目
› 50 Tips and Tricks for MongoDB Developers
Related Blogs
› Snail in a Turtleneck
这是一个创建于 4844 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
ri0day 2011-09-26 21:34:54 +08:00
我们有用 ，大概800G左右的图片 。还有一些日志。日志很小。
|
 |
2
adamsxu 2011-09-26 22:13:39 +08:00
我们在用，LS猛啊，这么多数据量，我们才80G...
|
 |
4
Livid MOD OP |
 |
5
ratazzi 2011-09-26 22:37:40 +08:00
我之前的公司在用，现在的公司只是辅助性的试用
|
|
6
Livid MOD OP 大家如果方便的话，不妨留一下公司的名字吧。
|
|
7
ratazzi 2011-09-26 22:44:05 +08:00
|
 |
8
summic 2011-09-26 22:49:53 +08:00  1
chinaui.com 在用
|
 |
9
linnchord 2011-09-26 22:54:21 +08:00
了解国内比较大的就是 chinavisual.com，有一个他们相关的技术演讲 http://www.infoq.com/cn/interviews/pf-mongodb-develop
|
 |
10
Just1n 2011-09-26 22:55:15 +08:00
麦库 note.sdo.com 貌似也是用的MongoDB。
|
 |
11
kongruxi 2011-09-26 23:04:35 +08:00
|
 |
13
Los 2011-09-26 23:42:54 +08:00
尝试使用过，但发觉在某个数量级的应用中还是mysql好用，而更大的数量级应用自身还没有，实在没必要为新技术而新技术，弃用。现在唯一用到它的项目是用于存储爬回来的数据，方便。
|
 |
14
zicjin 2011-09-26 23:52:51 +08:00
在公司已经大量使用了，具体多少G我都不清楚。主要是因为方便好用，性能方面我估计大家都没有过多深究，因为这公司奢侈惯了。
www.eastmoney.com |
 |
15
imonyse 2011-09-27 00:44:45 +08:00
Some quotes:
"Unless you're already running tens of thousands of dollars a month in servers and think MongoDB was a better fit for the nature of your data, you probably wasted a lot of time for negative benefit. " "MongoDB is fun to toy with, but it's almost never a better choice than Postgres/MySQL/SQL Server/etc. for production applications." "It's beta quality and the list of deployments( http://www.mongodb.org/display/DOCS/Production+Deployments ) is misleading. Most of those companies listed have used MongoDB for one side project, they aren't running their main services on it. Read the comments next to each company name -- one used it to track a single web form, another used it for an internal reporting application, etc. " "One of the few that actually uses MongoDB for their main service is Foursquare, and that came back to bite them with days of downtime which would not have occurred if they were using a RDBMS." |
 |
16
iandyh 2011-09-27 01:56:27 +08:00
MongoDB 不确定的地方还是很多。因为 Cache 使用 Memory-mapped 的原因，在进行 sharding 的时候，sharding key 选择要很小心，不然像出现 4sq 那样的问题，修都没法修，只能停掉整站重新做 sharding。
也因为 cache 的原因，一些随机 I/O 也很讨厌。 现在 MongoDB 的写入锁还是全局的，没法实现单一 collection 的写锁。这个有点要命。虽然写入内存的速度很快，但是谁也不知道大数据量的时候会怎样。 使用 replica set 之后网络间的通信也是一个问题。sourceforge 为此采用了读写都在 master 上进行这样的架构。 http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc 引用 Adam D'Angelo 的更新：a friend's startup that was going through explosive growth tried to switch to MongoDB and gave up after a month due to instability MongoDB 也是给有钱人用的，没有大内存的机子很难发挥优势。况且使用 BSON 后也十分消耗硬盘。有兴趣的人可以那这个和 MySQL 做比较。 所以我觉得 MongoDB 还需要再等等，可以用些小项目，但是做主力数据库，有点悬。 |
|
17
ri0day 2011-09-27 02:02:30 +08:00 via iPod 1
@kongruxi 是存在gridfs里 sharding+replication set .
总体来说: 1.mongodb 不是很稳定，曾经在读写频繁时把机器内存耗尽 疯狂使用swap 导致机器hang住 他内存管理不是很好 2.存图片的话gridfs对于使用文件系统没有任何性能上的优势。图片读写都需要使用程序读出来或者写进去 3.使用mongodb 要比使用文件系统占更多空间他是bson格式存储数据 4.如果使用mongodb集群架构 备份和容错需要双倍乃至多倍的物理硬件资源 5.管理复杂.需要care 集群中的每个节点。复杂度高 6.由于数据是分布式的出了问题很难还原出数据，比如shard节点中的数据文件损坏或者文件系统故障 7.在当前使用环境看来 唯一的收益就是无缝扩展存储容量了. 反正这东西虽然是趋势 但是还不成熟，放放日志，做做备份什么的还行，关键数据还是用自己最能把控的吧。 我折腾这个东西不少次了 也吸收到了些经验了。 |
|
18
ratazzi 2011-09-27 07:28:49 +08:00
@ri0day
有没有使用 https://github.com/mdirolf/nginx-gridfs 这一类的东西呢 或者象 chinavisual.com 那样使用 nginx 的 proxy_store |
 |
19
blogcool 2011-09-27 09:06:37 +08:00
我们目前在用它存储冷数据,一家有五百多万会员的网站。
|
|
20
ri0day 2011-09-27 09:08:43 +08:00 1
@ratazzi
使用过这个模块。不过当初我们也不是一开始就用mongodb的。有些url不能变。由于这个模块只能传入filename或者id 才能展示出图片。反正是由于开发上对于url处理不够方便后来开发了自己的接口做的存和取。 其实后端的压力很小。我们前面有squid缓存的。基本上访问到mongodb的数据不多了 |
|
21
ratazzi 2011-09-27 09:35:24 +08:00
@ri0day
多谢分享，我们曾经在 1.4.5 的时候就把图片存在 GridFS 里的，后来因为读取性能放弃了，那时候没有足够的能力与时间去优化，放弃了，后来又想过用 Tornado 写个程序负责读取，前面加个 Varnish 之类的，现在看来还是基本可行的 还有个想法就是用 php 写程序读取，用 Hip-Hop 编译下 |
 |
22
fsw90628 2011-09-27 09:41:30 +08:00
JSON 的格式用起来很方便，配合Tornado使用更舒服，bit.ly还专门写了个asyncmongo，
可以看这个slides， http://www.slideshare.net/ikailan/rapid-web-development-using-tornado-web-and-mongodb 这里有一些视频，从原理上讲MongoDB。 http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-SeeAlso |
|
23
fsw90628 2011-09-27 09:42:28 +08:00
不过reddis也很好，比较一下吧
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis |
 |
24
liruqi 2011-09-27 09:44:50 +08:00
http://www.magnetjoy.com/ 我们的新游戏在用~ 之前的项目中也做过尝试.
|
 |
25
titan 2011-09-27 10:30:14 +08:00
www.tazai.com 也在用。
|
 |
26
leeiio 2011-09-27 10:35:32 +08:00
http://doit.im 在用。
|
 |
27
kuno 2011-09-27 14:19:37 +08:00
公司的新项目准备使用mongodb， 不过听说mongodb在处理关系型数据时很糟糕，而我们的项目非常注重用户之间的关系，不知道在这里使用mongodb是不是一个好的选择？
|
 |
28
chuangbo 2011-09-27 14:39:49 +08:00
DNSPod 也有一些非重要的部分在尝试 Mongodb，不过反映出来的情况是并没有 10gen 描述的的那么美好。
|
 |
29
avatasia 2011-09-27 14:41:25 +08:00
#kuno， 绝对非常糟糕，如果有好的方法，麻烦分享一下。 目前我是用sql server 2008 + mongodb,
关系型数据放到sql server 2008上，权宜之计，长久是不行的。 |
 |
30
Platinum 2011-09-27 15:19:48 +08:00
手机之家应该在用
|
 |
39
kafka0102 2011-09-27 20:41:09 +08:00
http://www.tuicool.com/ 创业产品，存储都在mongodb，数据量在拼命控制中。。。全局锁和复制是个问题。。。
|
 |
40
ZoomQuiet 2011-09-27 20:42:04 +08:00
金山网络,内部云安全用MongoDB 作任务分发,每日2千万以上的task...
|
|
41
kuno 2011-09-27 21:21:24 +08:00
@chloerei:
想象一个网站融合目前所有流行的网站类型， 微博， 轻薄客，博客，甚至还带有某些门户的色彩。不仅用户之间有单项/双向的关注/被专注/朋友之间的关系，而且用户还会和不同的内容实体之间建立联系，喜欢/转载/关注/回复，对回复的回复等等等等。。。 |
 |
42
chloerei 2011-09-27 21:57:36 +08:00
|
|
43
avatasia 2011-09-27 22:24:03 +08:00
@chloerei 把关联ID作为list存在某个实体的文档那端就行了,例如某条数据里包含一个用户组list如果同样的list，有1000万条数据，每次更新一下组，就要同时更新1000万条记录。这个开销的问题怎么解决？
|
|
45
avatasia 2011-09-27 23:06:30 +08:00
@chloerei 例如一条交易信息 ，10几个字段， 好吧，他属于某个用户的交易，弄个object放用户的信息，
如果交易信息有1000万条，每次更新用户信息，要更新1000万条的交易记录，反过来做，一条用户信息，有1000万条list，这个性能如何？ 不敢想。 如果这个用户属于某个组， 10几个组呢？用户里加个字段，存放10几个组名，假如1000个用户属于同样的组，同样的信息 1000次， 如果不同的用户有什么的数据操作权限，有的可增加，有的可删除，有的只读，又要分别加上不同的权限字段，是这么设计的么？ |
 |
46
yqingp 2011-09-27 23:20:29 +08:00
我们公司在用 http://www.5yi.com 近期会把大量的东西迁移到mongodb上。。
|
|
47
chloerei 2011-09-27 23:22:35 +08:00
@avatasia 我不明白为什么要更新1000万条list。
user 有个 _id，交易记录方面记录 user_id 就行了。更新 user 或者 更新交易记录都不涉及更新另一个数据集合。 或者说你需要一次用join查询查出交易记录和用户信息，那么Mongodb做不到，需要多一次查询，先查交易，再查用户（或者反之）。 组那里大致就这样设计，不过存放最好用id不用组名。不要觉得在user里存组id是重复，因为少了一个关联表，其实就是把关联表拆散到文档里。 |
 |
48
halfamonk 2011-09-28 00:02:30 +08:00
clan.garena.com 有在用
|
 |
49
mathgl 2011-09-28 00:09:33 +08:00
mongodb 真正可用的是1.8.x系列或以后的版本.没有 -journal 的机制，Mongodb总是有些危险.
|
|
50
avatasia 2011-09-28 00:19:56 +08:00
@chloerei 因为在实际的应用中，用用户信息的某个字段去查所有类似该关键字的用户，可能有上万条用户记录，再通过这个用户ID去查交易记录， 两次查询，mongo不支持那么长的查询参数。
|
 |
55
mckelvin 2012-05-17 11:02:19 +08:00
淘宝网 数据平台，node +mongodb
|
 |
56
btw0 2012-05-21 01:16:41 +08:00
我们厂也在用，用gridfs存图片，也存log
|
 |
59
weihuilee 2012-05-26 22:03:42 +08:00
上次去参加了MongoDB北京的大会，用MongoDB的公司还是很多的，淘宝，盛大等很多公司都有用
|
 |
61
cy527300280 2012-05-28 13:40:56 +08:00
我发现好多公司都是用mongodb存图片
|
 |
62
tuoxie007 2012-05-28 13:57:23 +08:00
自己的博客在用:)
|
 |
63
Zjinys 2012-05-28 14:00:36 +08:00
@cy527300280 存图片用riak怎么样 ？
|
|
64
cy527300280 2012-05-29 15:06:37 +08:00
@Zjinys riak不知道，反正我之前的公司都是用mongodb存的，查询速度什么都还行
|
 |
67
aveline 2012-08-12 19:56:07 +08:00
用mongodb + redis做广告效果分析的路过...
|
 |
68
yoyicue 2012-08-22 23:42:10 +08:00
@livid 站内搜索 mongodb
发觉 Google 已经部分识别/支持 V2EX 的 Node 结构 URL 显示 www.v2ex.com › MongoDB http://www.google.com/search?q=site:v2ex.com/t%20mongodb |
 |
70
pppcat 2012-09-16 11:08:33 +08:00
mongodb和mysql都弱爆了。建议去看看es,全文索引 nosql 存储 分布式 HA 妹子你想要的全部集于一身
|
 |
71
Xandy 2012-09-16 12:05:38 +08:00
MongoDB开发的话市面上人不多的，还要精通NoSQL原理，然后再有NodeJS开发经验的就更少
|
|
73
aveline 2012-09-17 12:37:18 +08:00
其实觉着 MongoDB 有的时候并不适合我 ...
囧掉 |
 |
74
stxh 2012-09-17 13:09:13 +08:00
用过一下，php, c++
|
|
76
pppcat 2012-09-17 13:19:02 +08:00
@lxkaka elasticsearch,查询速度不用说了,人家专门干这个的.
重点是分布式做的不错。 还有就是可以用来当文档数据库使用。 还有就是在你用mysql或mongo的时候你既要在mysqll和mongo里面保存一份数据，这个时候你要添加搜索又要在全文索引里面保存一份数据，浪费么？有了ES，可以保存在一个地方了。而且可以设置数据保存的备份数，也不用担心数据的安全了。等等特性~~~官网上慢慢看...... |
 |
77
xiaojingyu 2014-09-25 10:46:01 +08:00
我们公司用了一段时间了,还不错,如果有这方面的人才,可以加入我们一起探讨!!!!!
也用顺便看看我们的微信框架 weixinjs.org |
 |
78
xianlin 2016-06-27 12:26:42 +08:00
都 5 年过去了， mongoDB 现在应该更强大了吧。
|
 |
79
zhuce1234578888 2017-01-26 10:50:23 +08:00
都 6 年过去了， mongoDB 现在应该更强大了吧。
|
 |
80
qq12345454 2017-07-20 22:39:35 +08:00
都 7 年过去了，mongoDB 现在应该更强大了吧。
|
 |
81
Axierty 2018-01-29 14:38:50 +08:00
都 8 年过去了，mongoDB 现在应该更强大了吧。
|
 |
82
herozzm 2019-05-18 23:13:05 +08:00
都 9 年过去了，mongoDB 现在应该更强大了吧。
|
 |
83
13482034233 2021-10-12 10:15:47 +08:00
都 10 年过去了，mongoDB 现在应该更强大了吧。
|
 |
84
danhahaha 362 天前
都 13 年过去了，mongoDB 看起来好像死透了
|
Select Language