p*****2
发帖数: 21240 | |
m******t
发帖数: 635 | 2 从里面摘了一段，比较经典
- what will I miss if i use Mongo?
no transactions
no joins (you can reference a record A in record B, but you join them
manually in your code)
This makes Mongo DB not ready to work with some critical tasks, but not our
case. social networking data aren’t that critical. if we will deal with
critical data in the future like money, I think we will need to implement
that part using an RDBMS like MySQL.
【在 p*****2 的大作中提到】
: http://engineering.eventtus.com/post/69485634651/how-we-decided
: 写的不错
|
p*****2
发帖数: 21240 | 3
our
是这样呀。如果需要join，transaction这些上mongo就有些病态了。
大牛你上次还没有好好说说你用mongo到底出啥问题了。
【在 m******t 的大作中提到】
: 从里面摘了一段，比较经典
: - what will I miss if i use Mongo?
: no transactions
: no joins (you can reference a record A in record B, but you join them
: manually in your code)
: This makes Mongo DB not ready to work with some critical tasks, but not our
: case. social networking data aren’t that critical. if we will deal with
: critical data in the future like money, I think we will need to implement
: that part using an RDBMS like MySQL.
|
s***o
发帖数: 2191 | 4 Using MySQL to deal with money? I don't know MySQL has become so good
our
【在 m******t 的大作中提到】
: 从里面摘了一段，比较经典
: - what will I miss if i use Mongo?
: no transactions
: no joins (you can reference a record A in record B, but you join them
: manually in your code)
: This makes Mongo DB not ready to work with some critical tasks, but not our
: case. social networking data aren’t that critical. if we will deal with
: critical data in the future like money, I think we will need to implement
: that part using an RDBMS like MySQL.
|
m******t
发帖数: 635 | 5 我用mongodb 没啥问题，那个storm的dashboard项目里面，用redis存实时的数据，用
mongodb存时间片段(snapshot)，后来信用卡收费的部分我没参加，应该是用postgres
了。
现在想想可能从头到尾redis+postgres也没问题，还一个db维护起来省事。我唱
mongodb和scala的反调主要是反感他们的hype，搞的大家一窝蜂的上，很多时候这样的
选择都不合适。
【在 p*****2 的大作中提到】
:
: our
: 是这样呀。如果需要join，transaction这些上mongo就有些病态了。
: 大牛你上次还没有好好说说你用mongo到底出啥问题了。
|
m******t
发帖数: 635 | 6 mysql的innodb很早就可以transaction了。
【在 s***o 的大作中提到】
: Using MySQL to deal with money? I don't know MySQL has become so good
:
: our
|
c******o
发帖数: 1277 | 7 对，不一样的project 用不一样的datastore
我们就是 user/social data 是mongodb
payment 是 mysql
BI 是hadoop
postgres
【在 m******t 的大作中提到】
: 我用mongodb 没啥问题，那个storm的dashboard项目里面，用redis存实时的数据，用
: mongodb存时间片段(snapshot)，后来信用卡收费的部分我没参加，应该是用postgres
: 了。
: 现在想想可能从头到尾redis+postgres也没问题，还一个db维护起来省事。我唱
: mongodb和scala的反调主要是反感他们的hype，搞的大家一窝蜂的上，很多时候这样的
: 选择都不合适。
|
p*****2
发帖数: 21240 | 8
mongo sharding之后对performance影响有多大？
【在 c******o 的大作中提到】
: 对，不一样的project 用不一样的datastore
: 我们就是 user/social data 是mongodb
: payment 是 mysql
: BI 是hadoop
:
: postgres
|
c******o
发帖数: 1277 | 9 这个问题太general
注意你的sharding key, sharding key 对的话，只会送query到应该的shard, 不然就
会送到所有的shard.
当然最好是能按你的use case把operation 分散到各个shard 上。
http://docs.mongodb.org/master/MongoDB-sharding-guide.pdf
【在 p*****2 的大作中提到】
:
: mongo sharding之后对performance影响有多大？
|
p*****2
发帖数: 21240 | 10
你们的mongo cluster有多少server呀？多少个shards?
【在 c******o 的大作中提到】
: 这个问题太general
: 注意你的sharding key, sharding key 对的话，只会送query到应该的shard, 不然就
: 会送到所有的shard.
: 当然最好是能按你的use case把operation 分散到各个shard 上。
: http://docs.mongodb.org/master/MongoDB-sharding-guide.pdf
|
|
|
b******0
发帖数: 101 | 11 no-sql本来就不应该是RDB的替代品吧。应该是补充。 |
t********e
发帖数: 880 | |
z****e
发帖数: 54598 | 13 mysql真正的终结者将会是postgresql
而不是mongodb
mongodb将会面对couchdb的有力挑战
couchdb是apache的东东，mongodb更像是以前mysql那一套
很多年以前就有人说，mysql是一只披着开源外衣的商业公司
其本质跟oracle没有太大差别
这个用来说mongodb其实也差不多 |
z****e
发帖数: 54598 | 14 另外一个可能是oracle会亲手掐死mysql
mariadb最近上升势头很是猛烈
不管怎样，mysql is doomed
这个在sun被oracle吞并的时候
很多人就说了，mysql现在主要是一堆legacy code还不能替换掉
新增系统已经不再把mysql当成一个option来考虑了 |
c******o
发帖数: 1277 | 15 3 shards, each shard is a replica set contain 3 machines (there maybe other
utility machines in the set also)
and 3 config servers and some number of mongos server.
All on AWS
It is a total waste at beginning, do not know why they need so many.
【在 p*****2 的大作中提到】
:
: 你们的mongo cluster有多少server呀？多少个shards?
|
p*****2
发帖数: 21240 | 16
other
每个shard多少data呀？你们app server到mongo还需要cache吗？
【在 c******o 的大作中提到】
: 3 shards, each shard is a replica set contain 3 machines (there maybe other
: utility machines in the set also)
: and 3 config servers and some number of mongos server.
: All on AWS
: It is a total waste at beginning, do not know why they need so many.
|
c******o
发帖数: 1277 | 17 shard are auto balancing, data size does not matter much, you can throw in
shards as needed
no general cache, has some cache in play app
【在 p*****2 的大作中提到】
:
: other
: 每个shard多少data呀？你们app server到mongo还需要cache吗？
|
h*****a
发帖数: 1718 | 18 Mongo的主要问题还是scale吧，data超过了mem size之后performance比较差。这一点
上来说mysql通过sharding解决scale的问题比较成熟。
our
【在 m******t 的大作中提到】
: 从里面摘了一段，比较经典
: - what will I miss if i use Mongo?
: no transactions
: no joins (you can reference a record A in record B, but you join them
: manually in your code)
: This makes Mongo DB not ready to work with some critical tasks, but not our
: case. social networking data aren’t that critical. if we will deal with
: critical data in the future like money, I think we will need to implement
: that part using an RDBMS like MySQL.
|
c******o
发帖数: 1277 | 19 with sharding, this is not a problem.
in theory, mongodb scale better than mysql (less coupling)
【在 h*****a 的大作中提到】
: Mongo的主要问题还是scale吧，data超过了mem size之后performance比较差。这一点
: 上来说mysql通过sharding解决scale的问题比较成熟。
:
: our
|
c*********e
发帖数: 16335 | 20 en,支持acid
【在 m******t 的大作中提到】
: mysql的innodb很早就可以transaction了。
|
|
|
h*****a
发帖数: 1718 | 21 如果说每个Mongo instance能hold的data的上限是memory的size的话，它的
scalability当然比mysql要差。
现在很多公司用mysql根本不用任何join，就是当NoSql来用，所以没什么coupling的
问题。
【在 c******o 的大作中提到】
: with sharding, this is not a problem.
: in theory, mongodb scale better than mysql (less coupling)
|
c******o
发帖数: 1277 | 22 depends on your working set, worst case your working set of 100% of your
data
you can just add shard, it auto balancing, so never have the problem of 上限
it is far easier sharding and horizontal scaling for MongoDB still,
simply as it is all automatic and less coupling from the beginning.
In your case (mysql with no join), it is in fact better use mongodb (mongodb
has single document ACID), and it will be faster and more flexible.
【在 h*****a 的大作中提到】
: 如果说每个Mongo instance能hold的data的上限是memory的size的话，它的
: scalability当然比mysql要差。
: 现在很多公司用mysql根本不用任何join，就是当NoSql来用，所以没什么coupling的
: 问题。
|
h*****a
发帖数: 1718 | 23 你没理解我说的上限的意思。现在比较好的机器一个mongo instance 64G memory。这
样一个大规模网站10T的data可能需要100-200个shard，而对应的mysql就不需要这么多
。实际上很多网站的data要大于10T，所以这样的use case下mysql更scalable.
如果scale比较小，mongo确实不是太大的问题。但这种情况下elastic search也是不错
的选择。
mongodb
【在 c******o 的大作中提到】
: depends on your working set, worst case your working set of 100% of your
: data
: you can just add shard, it auto balancing, so never have the problem of 上限
: it is far easier sharding and horizontal scaling for MongoDB still,
: simply as it is all automatic and less coupling from the beginning.
: In your case (mysql with no join), it is in fact better use mongodb (mongodb
: has single document ACID), and it will be faster and more flexible.
|
c******o
发帖数: 1277 | 24 mysql is not magically saving memory, in this case (and in may other cases),
it will be slower than corresponding mongodb.
mongodb strength compare to relational db is always those 3:
1. flexible schema
2. easier to scale (technically and also development wise)
3. document db (if you use json it is a big plus)
【在 h*****a 的大作中提到】
: 你没理解我说的上限的意思。现在比较好的机器一个mongo instance 64G memory。这
: 样一个大规模网站10T的data可能需要100-200个shard，而对应的mysql就不需要这么多
: 。实际上很多网站的data要大于10T，所以这样的use case下mysql更scalable.
: 如果scale比较小，mongo确实不是太大的问题。但这种情况下elastic search也是不错
: 的选择。
:
: mongodb
|
h*****a
发帖数: 1718 | 25 In the use case I mentioned, mysql does save money and is easier to maintain.
I used mongo for data ranged from 10GB to 400GB, and the experience was not
good when data was 400GB. We then switched to using Elastic Search, which
shows to be much better.
For our current architecture, for the largest data set, mysql is working
totally fine with about 100 shards. It is not easy to handle such a big data
size with mongo.
Certainly, I agree, mongo has its own use case, but scalability is not its
advantage.
),
【在 c******o 的大作中提到】
: mysql is not magically saving memory, in this case (and in may other cases),
: it will be slower than corresponding mongodb.
: mongodb strength compare to relational db is always those 3:
: 1. flexible schema
: 2. easier to scale (technically and also development wise)
: 3. document db (if you use json it is a big plus)
|
p*****2
发帖数: 21240 | 26
maintain.
not
data
400G有做sharding吗？mongo data 超过memory之后performance下降到什么程度？
Elastic Search好在哪里？更容易scale吗？
【在 h*****a 的大作中提到】
: In the use case I mentioned, mysql does save money and is easier to maintain.
: I used mongo for data ranged from 10GB to 400GB, and the experience was not
: good when data was 400GB. We then switched to using Elastic Search, which
: shows to be much better.
: For our current architecture, for the largest data set, mysql is working
: totally fine with about 100 shards. It is not easy to handle such a big data
: size with mongo.
: Certainly, I agree, mongo has its own use case, but scalability is not its
: advantage.
:
|
p*****2
发帖数: 21240 | 27
),
你们的数据都是在memory里吗？
【在 c******o 的大作中提到】
: mysql is not magically saving memory, in this case (and in may other cases),
: it will be slower than corresponding mongodb.
: mongodb strength compare to relational db is always those 3:
: 1. flexible schema
: 2. easier to scale (technically and also development wise)
: 3. document db (if you use json it is a big plus)
|
p*****2
发帖数: 21240 | 28
我主要想知道的就是办海说的，数据memory乘不下了，perf是啥情况。
【在 c******o 的大作中提到】
: shard are auto balancing, data size does not matter much, you can throw in
: shards as needed
: no general cache, has some cache in play app
|
c******o
发帖数: 1277 | 29 我们没有那么大data,新项目，没发说。
但是在很多我知道的use case里，都是用mongodb上很多TB data的。
我说的scalability, 是指容易做，花的server多，但是做起来简单的多。app开发也简
单的多（本来就没有join)
我不知道你说的 easier to maintain什么意思，我们这儿两个人1个月就全部自动化了
，完全fail safe, 现在唯一的担心就是config server不好检测是不是down. 我觉得
mysql从techops到developer很难作到这么容易。
maintain.
not
data
【在 h*****a 的大作中提到】
: In the use case I mentioned, mysql does save money and is easier to maintain.
: I used mongo for data ranged from 10GB to 400GB, and the experience was not
: good when data was 400GB. We then switched to using Elastic Search, which
: shows to be much better.
: For our current architecture, for the largest data set, mysql is working
: totally fine with about 100 shards. It is not easy to handle such a big data
: size with mongo.
: Certainly, I agree, mongo has its own use case, but scalability is not its
: advantage.
:
|
c******o
发帖数: 1277 | 30 会慢很多，但是很简单的检测就可以自动加shard,无限scale
是会浪费一点，但是比人工便宜多了。
【在 p*****2 的大作中提到】
:
: 我主要想知道的就是办海说的，数据memory乘不下了，perf是啥情况。
|
|
|
p*****2
发帖数: 21240 | 31
我也觉得要fit memory的搞才行。主要的好处就是fit memory的情况下performance巨
好，不然mysql上边一般还要建一层cache。所以你说的对，mongo就是很容易用。
【在 c******o 的大作中提到】
: 会慢很多，但是很简单的检测就可以自动加shard,无限scale
: 是会浪费一点，但是比人工便宜多了。
|
p*****2
发帖数: 21240 | 32 其实我还真找了找，还没找到能替换mongo的东西。貌似Riak还行，但是好像
replication cross data center要交钱。 |
c******o
发帖数: 1277 | 33 mongodb的auto balancing有点tricky,你要小心用。 |
p*****2
发帖数: 21240 | 34
ZKSS？
【在 c******o 的大作中提到】
: mongodb的auto balancing有点tricky,你要小心用。
|
c******o
发帖数: 1277 | 35 move data across shard is very expansive, if it happens at the wrong time,
you have trouble.
add shard early to prevent too much data moving around, and disable auto
balancing at peak hours.
【在 p*****2 的大作中提到】
:
: ZKSS？
|
p*****2
发帖数: 21240 | 36
多谢大牛。另外问一下你们的server 多大内存？你们用了arbitor了吗？
【在 c******o 的大作中提到】
: move data across shard is very expansive, if it happens at the wrong time,
: you have trouble.
: add shard early to prevent too much data moving around, and disable auto
: balancing at peak hours.
|
h*****a
发帖数: 1718 | 37 我们没做sharding。当时的情况是server每run两个小时就出很多socket error。后来很
快switch到ES就算了。
【在 p*****2 的大作中提到】
:
: 多谢大牛。另外问一下你们的server 多大内存？你们用了arbitor了吗？
|
h*****a
发帖数: 1718 | 38 机器多了当然maintanence的work更多，至少要有failover的工作。Mysql的failover和
maintain和mongo比更加成熟，毕竟是20年的技术积淀，而且市场人招到熟悉mysql的
engineer或者DBA非常容易。
当然，或说回来，mongo的maintainence并不是问题。主要的问题还是cost.
【在 c******o 的大作中提到】
: 我们没有那么大data,新项目，没发说。
: 但是在很多我知道的use case里，都是用mongodb上很多TB data的。
: 我说的scalability, 是指容易做，花的server多，但是做起来简单的多。app开发也简
: 单的多（本来就没有join)
: 我不知道你说的 easier to maintain什么意思，我们这儿两个人1个月就全部自动化了
: ，完全fail safe, 现在唯一的担心就是config server不好检测是不是down. 我觉得
: mysql从techops到developer很难作到这么容易。
:
: maintain.
: not
|
p*****2
发帖数: 21240 | 39
来很
interesting. 你们主要是什么scenario呢？需要full text search吗？
我上次简单测了一下，发现ES的perf比mongo慢十倍。当然是数据能fit memory的情况
。感觉如果需要full text search，并且perf要求不高，尤其是没有concurrent write
的时候用ES还是很合适的。
【在 h*****a 的大作中提到】
: 我们没做sharding。当时的情况是server每run两个小时就出很多socket error。后来很
: 快switch到ES就算了。
|
h*****a
发帖数: 1718 | 40 我们需要full text search。mongo全在memory里面，快是正常的。所以适用与否主要
看performance的要求和data的scale.
write
【在 p*****2 的大作中提到】
:
: 来很
: interesting. 你们主要是什么scenario呢？需要full text search吗？
: 我上次简单测了一下，发现ES的perf比mongo慢十倍。当然是数据能fit memory的情况
: 。感觉如果需要full text search，并且perf要求不高，尤其是没有concurrent write
: 的时候用ES还是很合适的。
|
|
|
p*****2
发帖数: 21240 | 41
我也觉得数据量大了确实比较费机器。你觉得有什么好的选择？我觉得应该可以考虑
Redis做cache，postgres／mysql做persistence。因为其他NoSQL都没有Mongo这么强大
的query。当然主要看应用了。
Mongo的schemaless感觉还是比SQL要方便很多。用习惯了，想想SQL的alter table心里
就发怵。
【在 h*****a 的大作中提到】
: 机器多了当然maintanence的work更多，至少要有failover的工作。Mysql的failover和
: maintain和mongo比更加成熟，毕竟是20年的技术积淀，而且市场人招到熟悉mysql的
: engineer或者DBA非常容易。
: 当然，或说回来，mongo的maintainence并不是问题。主要的问题还是cost.
|
h*****a
发帖数: 1718 | 42 我们用mysql + redis。
如果大的data需要full text search，要么ES，要么只能自己搞了，呵呵。
【在 p*****2 的大作中提到】
:
: 我也觉得数据量大了确实比较费机器。你觉得有什么好的选择？我觉得应该可以考虑
: Redis做cache，postgres／mysql做persistence。因为其他NoSQL都没有Mongo这么强大
: 的query。当然主要看应用了。
: Mongo的schemaless感觉还是比SQL要方便很多。用习惯了，想想SQL的alter table心里
: 就发怵。
|
p*****2
发帖数: 21240 | 43
是。那你们当时用mongo是用mongo的regular expression的query吗？for text search
？
【在 h*****a 的大作中提到】
: 我们需要full text search。mongo全在memory里面，快是正常的。所以适用与否主要
: 看performance的要求和data的scale.
:
: write
|
p*****2
发帖数: 21240 | 44
我们公司内部也是强烈建议mysql。看来回头有时间也应该好好看一下。多谢大牛。
【在 h*****a 的大作中提到】
: 我们用mysql + redis。
: 如果大的data需要full text search，要么ES，要么只能自己搞了，呵呵。
|
