p*****2
发帖数: 21240 | 1 Cassandra也表现异常良好
http://db-engines.com/en/blog_post/30
感觉MongoDB, Cassandra, Redis是最好的NoSQL |
c****e
发帖数: 1453 | 2 MongoDB cannot index over 1K and horrible if your system rely heavily on
JOIN. We switch from MongoDB to Postgres. Postgres has decent support for
JSON. We are quite happy. |
p*****2
发帖数: 21240 | 3 1k什么？
需要join选mongo当时抉择有问题吧？
【在 c****e 的大作中提到】
: MongoDB cannot index over 1K and horrible if your system rely heavily on
: JOIN. We switch from MongoDB to Postgres. Postgres has decent support for
: JSON. We are quite happy.
|
p*****2
发帖数: 21240 | 4 另外post的performance怎么样呀
【在 c****e 的大作中提到】
: MongoDB cannot index over 1K and horrible if your system rely heavily on
: JOIN. We switch from MongoDB to Postgres. Postgres has decent support for
: JSON. We are quite happy.
|
c****e
发帖数: 1453 | 5 google/bing mongodb index 1k limitation.
There is no black/white choice when you start the project. The features you
added on over iterations can be a major part you don't expect initially.
【在 p*****2 的大作中提到】
: 1k什么？
: 需要join选mongo当时抉择有问题吧？
|
d*******r
发帖数: 3299 | 6 没太懂这个的意思，我看文档说的是，被index的key value不能超过1k大小吧
http://docs.mongodb.org/manual/reference/limits/
Index Key
The total size of an indexed value must be less than 1024 bytes. MongoDB
will not add that value to an index if it is longer than 1024 bytes.
你说的好像是一个 index 的总长度不能超过1k? 你到底说的是“被index的key value
”还是“一个index总长度”？
index的key value大小不超过1k，看着是比较合理的限制呀。
【在 c****e 的大作中提到】
: MongoDB cannot index over 1K and horrible if your system rely heavily on
: JOIN. We switch from MongoDB to Postgres. Postgres has decent support for
: JSON. We are quite happy.
|
p*****2
发帖数: 21240 | 7 nosql都有着问题 需求变了可能需要migration 或者schema调整 好处是没有downtime
感觉你们当时没考虑好
you
【在 c****e 的大作中提到】
: google/bing mongodb index 1k limitation.
: There is no black/white choice when you start the project. The features you
: added on over iterations can be a major part you don't expect initially.
|
p*****2
发帖数: 21240 | 8 其实sql mugration更痛苦
downtime
【在 p*****2 的大作中提到】
: nosql都有着问题 需求变了可能需要migration 或者schema调整 好处是没有downtime
: 感觉你们当时没考虑好
:
: you
|
a*****g
发帖数: 19398 | 9 交友。
【在 p*****2 的大作中提到】
: Cassandra也表现异常良好
: http://db-engines.com/en/blog_post/30
: 感觉MongoDB, Cassandra, Redis是最好的NoSQL
|
n******t
发帖数: 4406 | 10 cow, postgres不是几十年前就有的东西吗？
【在 p*****2 的大作中提到】
: Cassandra也表现异常良好
: http://db-engines.com/en/blog_post/30
: 感觉MongoDB, Cassandra, Redis是最好的NoSQL
|
|
|
c*****a
发帖数: 808 | |
h****r
发帖数: 2056 | 12 If you need to use join, Mongo DB is not right for you. In fact, no sql dbs
are not right for you.
To me, the weakest link of Mongo DB so far is it still can not support table
level lock.
【在 c****e 的大作中提到】
: MongoDB cannot index over 1K and horrible if your system rely heavily on
: JOIN. We switch from MongoDB to Postgres. Postgres has decent support for
: JSON. We are quite happy.
|
g*******o
发帖数: 156 | 13 大牛明鉴啊～～～
dbs
table
【在 h****r 的大作中提到】
: If you need to use join, Mongo DB is not right for you. In fact, no sql dbs
: are not right for you.
: To me, the weakest link of Mongo DB so far is it still can not support table
: level lock.
|
c****e
发帖数: 1453 | 14 When you think you are ok with "no join", it might NOT be true when product
evolves. Collection level lock is on the list for very long time, they
should have support that from day 1. MongoDB is very easy to hook up but it
doesn't scale well. I haven't seen any big footprint installment around.
Once you go with multiple sharding, it costs too many VMs.
dbs
table
【在 h****r 的大作中提到】
: If you need to use join, Mongo DB is not right for you. In fact, no sql dbs
: are not right for you.
: To me, the weakest link of Mongo DB so far is it still can not support table
: level lock.
|
p*****2
发帖数: 21240 | 15 如果sharding的话上cassandra吧
我们都是这么干的
product
it
【在 c****e 的大作中提到】
: When you think you are ok with "no join", it might NOT be true when product
: evolves. Collection level lock is on the list for very long time, they
: should have support that from day 1. MongoDB is very easy to hook up but it
: doesn't scale well. I haven't seen any big footprint installment around.
: Once you go with multiple sharding, it costs too many VMs.
:
: dbs
: table
|
B*****g
发帖数: 34098 | 16 你这么快就搞上cassandra了？
【在 p*****2 的大作中提到】
: 如果sharding的话上cassandra吧
: 我们都是这么干的
:
: product
: it
|
c******o
发帖数: 1277 | 17 vm是多，我们一个mongodb，为了sharding要弄13个vm minimum |
p*****2
发帖数: 21240 | 18
算快吗？好虫，wwzz都搞了好久了。
【在 B*****g 的大作中提到】
: 你这么快就搞上cassandra了？
|
p*****2
发帖数: 21240 | 19
大牛没有考虑C＊？
【在 c******o 的大作中提到】
: vm是多，我们一个mongodb，为了sharding要弄13个vm minimum
|
B*****g
发帖数: 34098 | 20 怎么配的？谢谢
【在 c******o 的大作中提到】
: vm是多，我们一个mongodb，为了sharding要弄13个vm minimum
|
|
|
p*****2
发帖数: 21240 | 21
三个configuraiton server
一个shard至少两个machine
【在 B*****g 的大作中提到】
: 怎么配的？谢谢
|
B*****g
发帖数: 34098 | 22 一个shard不是3台吗？
【在 p*****2 的大作中提到】
:
: 三个configuraiton server
: 一个shard至少两个machine
|
p*****2
发帖数: 21240 | 23
所以说至少两台呀
【在 B*****g 的大作中提到】
: 一个shard不是3台吗？
|
c******o
发帖数: 1277 | 24 3个shards, 每个3个replica instance (每一个都是1/1的auto scaling group， 两个
working instance,一个专职take snapshot), 3个config server， （每个都是单独
的1/1的auto scaling group）。一个小的mongos node供查询，每个webhead上再加一
个mongos
【在 B*****g 的大作中提到】
: 怎么配的？谢谢
|
d*******r
发帖数: 3299 | 25 二爷回头打算只要多instance，就放弃mongo?
【在 p*****2 的大作中提到】
: 如果sharding的话上cassandra吧
: 我们都是这么干的
:
: product
: it
|
p*****2
发帖数: 21240 | 26
是。sharding太麻烦了。
【在 d*******r 的大作中提到】
: 二爷回头打算只要多instance，就放弃mongo?
|
c******o
发帖数: 1277 | 27 cassandra 是 eventually consistent, 不一样的req
mongo db 宁可lock,也不会out of sync
【在 p*****2 的大作中提到】
:
: 是。sharding太麻烦了。
|
w**z
发帖数: 8232 | 28 你read/write 都quorum 就基本consistent 了
【在 c******o 的大作中提到】
: cassandra 是 eventually consistent, 不一样的req
: mongo db 宁可lock,也不会out of sync
|
g*****g
发帖数: 34805 | 29 Only on row level, it may not be enough for many applications. We use a
combination of Mysql, C*, ES for storage.
【在 w**z 的大作中提到】
: 你read/write 都quorum 就基本consistent 了
|
d*******r
发帖数: 3299 | 30 ES 是 ElasticSearch?
NetFlix 有把 MySQL 换成 PostgreSQL 的需求吗
【在 g*****g 的大作中提到】
: Only on row level, it may not be enough for many applications. We use a
: combination of Mysql, C*, ES for storage.
|
|
|
d*******r
发帖数: 3299 | 31 请大牛指点上面的问题呀，不知道是不是不方便透露
【在 g*****g 的大作中提到】
: Only on row level, it may not be enough for many applications. We use a
: combination of Mysql, C*, ES for storage.
|
g*****g
发帖数: 34805 | 32 ES is elastic search. I don't think MySQL and PostGre is that different
today. But RDS for PostGre is still in beta today, the choice is no brainer.
【在 d*******r 的大作中提到】
: 请大牛指点上面的问题呀，不知道是不是不方便透露
|
d*******r
发帖数: 3299 | 33 多谢。我也觉得 MySQL 用着也行。
brainer.
【在 g*****g 的大作中提到】
: ES is elastic search. I don't think MySQL and PostGre is that different
: today. But RDS for PostGre is still in beta today, the choice is no brainer.
|
p*****w
发帖数: 429 | 34 你是公司这么配置的还是自己玩的配置。
【在 p*****2 的大作中提到】
:
: 是。sharding太麻烦了。
|
p*****2
发帖数: 21240 | 35
我们没有sharding。
【在 p*****w 的大作中提到】
: 你是公司这么配置的还是自己玩的配置。
|
