c********l
发帖数: 8138 | 1 随便用了半天，还都是一些最基本操作，就发现一大堆bug |
|
|
|
N******7
发帖数: 1297 | 4 这个不会吧，现在很多公司都扔了MySQL，转向postgresql。如果这么容易找到这么多
bug，还有人敢用嘛。 |
|
|
|
N********n
发帖数: 8363 | 7
Don't be silly. SQL Server is growing at Oracle's expense as it
offers much better bang for the bucks and making a ton of money
for MSFT.
The top 2 dogs in the DB field are Oracle and Sql Server. DB2 is
lagging. The other MySql, PostGre and so on are negligible. |
|
d***q
发帖数: 1119 | 8 日本人对emacs/lisp，还有Postgres贡献不小。 |
|
s***o
发帖数: 2191 | 9 postgresql是python系的最爱吧。你们是继续用postgres还是别的？ |
|
c******o
发帖数: 1277 | 10 对，不一样的project 用不一样的datastore
我们就是 user/social data 是mongodb
payment 是 mysql
BI 是hadoop
postgres |
|
p*****2
发帖数: 21240 | 11
我也觉得数据量大了确实比较费机器。你觉得有什么好的选择？我觉得应该可以考虑
Redis做cache，postgres／mysql做persistence。因为其他NoSQL都没有Mongo这么强大
的query。当然主要看应用了。
Mongo的schemaless感觉还是比SQL要方便很多。用习惯了，想想SQL的alter table心里
就发怵。 |
|
|
|
p*****2
发帖数: 21240 | 14 1k什么？
需要join选mongo当时抉择有问题吧？ |
|
|
c****e
发帖数: 1453 | 16 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. |
|
d*******r
发帖数: 3299 | 17 没太懂这个的意思，我看文档说的是，被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，看着是比较合理的限制呀。 |
|
p*****2
发帖数: 21240 | 18 nosql都有着问题 需求变了可能需要migration 或者schema调整 好处是没有downtime
感觉你们当时没考虑好
you |
|
p*****2
发帖数: 21240 | 19 其实sql mugration更痛苦
downtime |
|
|
|
h****r
发帖数: 2056 | 22 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 | 24 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 |
|
p*****2
发帖数: 21240 | 25 如果sharding的话上cassandra吧
我们都是这么干的
product
it |
|
|
c******o
发帖数: 1277 | 27 vm是多，我们一个mongodb，为了sharding要弄13个vm minimum |
|
|
|
|
p*****2
发帖数: 21240 | 31
三个configuraiton server
一个shard至少两个machine |
|
|
|
c******o
发帖数: 1277 | 34 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 |
|
d*******r
发帖数: 3299 | 35 二爷回头打算只要多instance，就放弃mongo? |
|
|
c******o
发帖数: 1277 | 37 cassandra 是 eventually consistent, 不一样的req
mongo db 宁可lock,也不会out of sync |
|
w**z
发帖数: 8232 | 38 你read/write 都quorum 就基本consistent 了 |
|
g*****g
发帖数: 34805 | 39 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 | 40 ES 是 ElasticSearch?
NetFlix 有把 MySQL 换成 PostgreSQL 的需求吗 |
|
d*******r
发帖数: 3299 | 41 请大牛指点上面的问题呀，不知道是不是不方便透露 |
|
d*******r
发帖数: 3299 | 42 多谢。我也觉得 MySQL 用着也行。
brainer. |
|
|
|
c********1
发帖数: 421 | 45 为什么没有人问：PHP + Postgres? |
|
c********1
发帖数: 421 | 46 windows server / sql server 都是要钱的
linux / nonsql mysql postgres 都是免费的 |
|
p*****2
发帖数: 21240 | 47
我觉得是。我们公司很多A过来的，只用Java。
还有一个postgres大牛过来不让用mongo，cassandra。 |
|
y**********u
发帖数: 6366 | 48 性能还可以啊，比mysql多了一些复杂的数据类型,schema change也更容易
问题也有，sharding比较困难，caching用了kernel level的，比起innodb的user-
level要差一些 |
|
z****e
发帖数: 54598 | 49 这是你们组的其他人不懂postgresql造成的
至少至少会换成mariadb
但是如果对db依赖深的话，这种migration会有学习成本
which很多人不愿意投入的，这就是为啥我们会用hibernate
对于hibernate来说，管他什么db，都是一样的 |
|
z****e
发帖数: 54598 | 50 用hibernate吧，这样你就不在乎是什么db了
不要对单个产品产生依赖，那些consultants就靠这个骗钱了
开源的越做越好是大势所趋，我早就不用mysql了
虽然很多人会，但是oracle收购sun之后，这个东西我就抛弃了
商业公司产品都是骗钱的 |
|
