d*******r
发帖数: 3299 | 1 貌似 DynamoDB 只能在 create Table 时候建该 Table 的 indexes ？这么不方便的？
我看 Cassandra 也没这个限制吧。MongoDB 更不用说了。 |
w**z
发帖数: 8232 | 2 Cassandra的index 最好还是别用。
【在 d*******r 的大作中提到】
: 貌似 DynamoDB 只能在 create Table 时候建该 Table 的 indexes ？这么不方便的？
: 我看 Cassandra 也没这个限制吧。MongoDB 更不用说了。
|
d*******r
发帖数: 3299 | 3 大牛详细说说呢？
不能用的话。岂不是跟 DynamoDB 一样，只有 create tables 的时候把 key 设计好？
然后不改了？
【在 w**z 的大作中提到】
: Cassandra的index 最好还是别用。
|
w***g
发帖数: 5958 | 4 就是像你说的这样，create table的时候把key设计好。如果不行的话就重新create
table再把数据导过去。Cassandra这类分布式的key-value store和传统数据库设计理
念不一样，所以用法也是不一样的。传统的key-value store的index一般就是B+-tree
或者hash table。这两者都假设random disk access，一旦cache不够用了并行读写甚
至单线程读写也就完蛋了。重新导一遍几十G的数据库都很费时费力了。而Cassandra的数
据据我的理解是按log方式存储的，也就是说新的数据来了就往文件最后面添加。这种
情况下就增加了建index的难度和性能。好处则是数据写入非常有效，而且因为有多台
机器多个硬盘同时读写，重新导一遍数据就跟玩似的。而且因为用的廉价硬盘，空间极
大，不在乎多保存几个copy的数据。新兴的互联网公司有点前途的都是指数增长的，也
就是说一个时间段新增的数据量基本和之前所有积累的数据量相当，所以隔断时间重新
导一下可以作为一个常态。
MongoDB跟Cassandra很不一样，更接近传统数据库的设计，scalability极差。
我是纸上谈兵，二楼有实际经验也希望能展开说说。有什么错的也希望Goodbug大牛和
zhaoce大牛指正。
【在 d*******r 的大作中提到】
: 大牛详细说说呢？
: 不能用的话。岂不是跟 DynamoDB 一样，只有 create tables 的时候把 key 设计好？
: 然后不改了？
|
c******o
发帖数: 1277 | 5 mongodb的scalability不差，我们prod上用了一段了，挺好。
加shard很容易，lock也不是问题。
说起来，scalability还好，但是availability不如cassandra, 主要还是注重
consistency了。而且document db比column db， 小地方用起来方便多了。
mongo
sharding key选的不好没法改，而且对performance影响很大，最后也是重导入一遍，
我们刚刚对一个collection干了一次。 |
d*******r
发帖数: 3299 | 6 那看样子 Cassandra 跟 DynamoDB 在这方面比较像了
tree
的数
【在 w***g 的大作中提到】
: 就是像你说的这样，create table的时候把key设计好。如果不行的话就重新create
: table再把数据导过去。Cassandra这类分布式的key-value store和传统数据库设计理
: 念不一样，所以用法也是不一样的。传统的key-value store的index一般就是B+-tree
: 或者hash table。这两者都假设random disk access，一旦cache不够用了并行读写甚
: 至单线程读写也就完蛋了。重新导一遍几十G的数据库都很费时费力了。而Cassandra的数
: 据据我的理解是按log方式存储的，也就是说新的数据来了就往文件最后面添加。这种
: 情况下就增加了建index的难度和性能。好处则是数据写入非常有效，而且因为有多台
: 机器多个硬盘同时读写，重新导一遍数据就跟玩似的。而且因为用的廉价硬盘，空间极
: 大，不在乎多保存几个copy的数据。新兴的互联网公司有点前途的都是指数增长的，也
: 就是说一个时间段新增的数据量基本和之前所有积累的数据量相当，所以隔断时间重新
|
d*******r
发帖数: 3299 | 7 MongoDB 的易用性真是没的说
不知道 10Gen 啥时候能出个去掉 db-level lock 的新版本。
看他们 blog，貌似在开发这个。
【在 c******o 的大作中提到】
: mongodb的scalability不差，我们prod上用了一段了，挺好。
: 加shard很容易，lock也不是问题。
: 说起来，scalability还好，但是availability不如cassandra, 主要还是注重
: consistency了。而且document db比column db， 小地方用起来方便多了。
: mongo
: sharding key选的不好没法改，而且对performance影响很大，最后也是重导入一遍，
: 我们刚刚对一个collection干了一次。
|
g*****g
发帖数: 34805 | 8 This blog sums up the problem pretty well. You better know what you are
doing before using secondary index, particularly on big dataset.
http://www.wentnet.com/blog/?p=77
【在 d*******r 的大作中提到】
: 大牛详细说说呢？
: 不能用的话。岂不是跟 DynamoDB 一样，只有 create tables 的时候把 key 设计好？
: 然后不改了？
|
c***d
发帖数: 996 | 9 好文， 已收藏。
【在 g*****g 的大作中提到】
: This blog sums up the problem pretty well. You better know what you are
: doing before using secondary index, particularly on big dataset.
: http://www.wentnet.com/blog/?p=77
|
d*******r
发帖数: 3299 | 10 多谢，收藏了
【在 g*****g 的大作中提到】
: This blog sums up the problem pretty well. You better know what you are
: doing before using secondary index, particularly on big dataset.
: http://www.wentnet.com/blog/?p=77
|
h****r
发帖数: 2056 | 11 They started to work on it since 01/2013, guess it is a hard issue to them.
【在 d*******r 的大作中提到】
: MongoDB 的易用性真是没的说
: 不知道 10Gen 啥时候能出个去掉 db-level lock 的新版本。
: 看他们 blog，貌似在开发这个。
|
