1
ritksm 2013-11-27 09:55:00 +08:00 5
因为他们不知道如何让MongoDB靠谱。problem solved
|
2
andyhuax 2013-11-27 10:04:07 +08:00 via iPhone
让靠谱的人用它,它就可靠,否则…
|
3
lichao 2013-11-27 10:08:38 +08:00
抛开业务场景谈这个话题没有意义
|
4
griffinqiu 2013-11-27 10:11:29 +08:00
因为他们不知道如何让MongoDB靠谱。problem solved
我顶。。。 |
5
merlin852 2013-11-27 10:11:55 +08:00
没有NOSQL的设计经验,真的不是很推荐,还不如mysql
|
6
plucury 2013-11-27 10:23:17 +08:00
当热数据超过内存的时候,痛苦就开始了
|
7
anheiyouxia 2013-11-27 10:24:56 +08:00
不了解,但是我想说,也很多人说,不要用MySQL,因为他不靠谱,但是FaceBook就是用MySQL的。
|
8
timothyye 2013-11-27 10:26:51 +08:00 via Android 1
除了不支持事物,还没看到有不靠谱的地方
|
9
breeswish 2013-11-27 10:32:24 +08:00
MongoDB是很好的,但不要在什么都不了解的情况下盲目使用MongoDB,那会很糟糕
大概是这个意思吧 |
10
ibaser 2013-11-27 10:38:26 +08:00
|
11
shiny 2013-11-27 10:39:07 +08:00
反对的是头脑发热就去用,你问出这种问题来说明你就不适合使用。
|
16
jk2r 2013-11-27 11:12:59 +08:00
@family,得看你的应用场景。新手的话,生成环境使用时,运维与学习成本还是较高的。根据业务指定性能指标,实际测试应该是比较好的方法。
@ibaser 库写不是特别大的话,可以考虑关闭预分配。http://docs.mongodb.org/manual/reference/configuration-options/,noprealloc参数。 |
19
halfelf 2013-11-27 11:36:52 +08:00
sf的回答毫无意义,这个逻辑可以推广到一切质疑
|
21
ritksm 2013-11-27 12:00:17 +08:00
@halfelf 我这么回答的意思就是,能够让楼主rest assured,去研究如何靠谱地用MongoDB而不是怀疑MongoDB到底可不可靠....我感觉没啥逻辑上的问题
|
22
wesley 2013-11-27 12:21:43 +08:00
我司JAVA部门的猪头们从来不管业务逻辑都坚定不移地用mongodb
|
23
xzl 2013-11-27 13:42:37 +08:00
让靠谱的人在靠谱的应用环境下靠谱的用。看哪些喷的不是没切片就是没做副本集,一不小心加个索引加没了。热数据大于内存?加内存啊,前端再换上redis哈,热数据大于内存你换mysql就能好使?
|
24
yuxing1171 2013-11-27 14:30:26 +08:00
要根据业务需求来决定, 单纯的为了mongodb而使用, 才是最不靠谱的。
|
25
seraphln 2013-11-27 18:34:47 +08:00
@ibaser 可以试试 compact.不过会锁库。
另外,直接remove数据mongodb不会直接释放文件。所以体积会越来越大。 |
26
willmouse 2013-11-27 19:32:42 +08:00
|
27
josephshen 2013-11-27 20:14:14 +08:00
水平不够,用什么都不靠谱。
|
29
est 2013-11-27 20:39:38 +08:00
我看过对mongodb的吐槽都是因为开发者2了。
|
30
txlty 2013-11-27 20:41:11 +08:00
用惯了mssql/mysql/oracle,会很难理解mangodb。
|
33
reorx 2013-11-27 21:39:52 +08:00
对未知事物的恐惧,以及维护自己所擅长事物权威性的本能。
|
34
ritksm 2013-11-27 21:43:25 +08:00
@timothyye 其实这个tokumx也解决掉了...虽然我没用到 http://www.tokutek.com/2013/04/mongodb-transactions-yes/
|
36
gihnius 2013-11-27 23:31:17 +08:00
|
37
ritksm 2013-11-27 23:43:42 +08:00 2
@gihnius
第一个Its volume on disk is growing 3-4 times faster than the real volume of data it store:设计就是这样的 参见 http://docs.mongodb.org/manual/faq/storage/ 第二个 it eats up all the memory without the possibility to limit this:MongoDB设计的时候的想法(我记得哪里看到)就是用系统的内存管理去控制而不是自己搞一套(参见 http://docs.mongodb.org/manual/faq/fundamentals/#does-mongodb-require-a-lot-of-ram ),但是Tokumx加了一个参数叫做cacheSize可以限制缓存大小,虽然如果你的数据超过了这个大小,会依赖磁盘性能。而且如果内存真的占用过大了一定是你的索引建的不科学,再大就参照第四个吧。 第三个it begins to slow down the application because of frequent disk access:什么db超过了缓存大小不会去读磁盘数据,我表示不知,求科普 第四个We don’t want to set a server with more than 100Gb of memory to Errbi:那他一定不知道有个东西叫做auto-sharding,这么强大的功能都不用=_= 第五个MongoDB require much more attention than we have time. Perhaps we just have more experience in working with postgresql:正如@reorx 所说,难以跳出自己的comfort zone 点个赞吧亲嘿嘿 |
38
winiex 2013-11-28 00:19:46 +08:00
@ritksm = =,爆爆更健康......。看上这个 use case 主要是因为 mongodb 的数据模型对于查询来说太方便了,确实挺适合于这个场景的。我听说,貌似为了提供这种强大的检索能力就不得不各种吃内存吃硬盘,此乃原因之一,这个确实是一只比较纠结的事情。
另外,mongodb 做读写分离、replication 什么的方便吗?要优化读写什么的,单单 scale up 肯定是不行的吧~。 |
39
winiex 2013-11-28 00:22:08 +08:00
@ritksm 我想你用 redis 应该也是做 mongodb 前端的 cache,并且利用 redis 的数据类型的可查询性来做 mongodb 的查询备胎吧。现在这种方式够用咩?
|
40
ritksm 2013-11-28 00:30:04 +08:00
@winiex MongoDB的replication其实挺方便的了 http://docs.mongodb.org/manual/replication/
Redis的set和sorted set太好用了- - |
42
ritksm 2013-11-28 00:38:34 +08:00
@winiex 还没具体用到,闲暇时候研究了下而已=-= 只是一些不咋重要的数据分析无所谓做不做Replication了的。。。坑到了也会有解决办法的撒
|
43
yutify 2014-01-13 22:20:46 +08:00 via iPhone
最近几个月对 mongodb 的好感度逐日下降。据说前段陌陌劲舞团的事故也是不正确使用 mongodb 导致的。后来陌陌的技术人员飞上海帮久游把数据库移到了 redis 上。
|
44
dingyaguang117 2014-05-14 22:39:28 +08:00 via iPhone
查不出原因的update失败算嘛
|
45
qw7692336 2016-01-04 09:55:13 +08:00
你是不是用 Google 搜了"mongodb"关键词
|