[repost ]关于Cassandra的错误观点

original:http://www.infoq.com/cn/articles/cassandra-mythology 正如Apache Cassandra的名称是来自于著名的物洛伊女巫一样，在它身上确实存在着各种误解。和大多数误解一样，至少在一开始时它们确实是有那么一点道理的，但随着Cassandra不断地深化与改善，这些误解的内容已经不复存在了。在本文中，我将针对五个常见的疑惑作出解释，澄清人们的困惑。 误解：Cassandra就是一个嵌套的map 随着使用Cassandra的应用程序变得越来越复杂，以下观点正在逐渐变得清晰起来：与“任何东西都是一个数组缓冲”或者“任何东西都是一个字符串”这种设计方式相比，schema与数据类型会使大型应用的开发与维护更加简单， 现如今，理解Cassandra的数据模型的最好方式是将其想像为表与行的组合，并且与关系型数据相似的是，Cassandra的列也是强类型的，并且可以进行索引。 你也许还听到过其它这些说法： “Cassandra是一种列数据库。”列数据库会将某个列的全部数据一起保存在磁盘上，这种方式对于数据仓库的检索方式是比较适合的，但对于那些需要对特定的行进行快速访问的应用程序来说就不太适合了。 “Cassandra是一种宽行数据库。”这种说法有一定的道理，因为Cassandra的存储引擎是由Bigtable所启发而设计的，而后者可以说是宽行数据库的祖先了。但宽行数据库的数据模型与存储引擎结合得太过紧密，虽然实现起来比较容易，但针对它进行开发就增加了困难，而且它还使许多优化方式变得不可行了。 我们之所以在开始的部分选择避开“表与行”这种方法，原因之一是因为Cassandra的表与你所熟的关系型数据库的表的确存在着某些微妙的差别。首先，主键的首个元素是分区键，在同一个分区中的所有行都会存储在同一台服务器上，而分区是分布在整个集群中的。 其次，Cassandra不支持关联查询与子查询，这是因为在分布式系统中跨越硬件进行关联查询的性能很差。Cassandra的做法是鼓励你采用去正规化（denormalization）的方式，从一个单独的表中获取你所需的数据，同时提供集合等工具以简化操作。 举例来说，考虑一下以下代码所表示的users表： CREATE TABLE users ( user_id uuid PRIMARY KEY, name text, state text, birth_year int ); 目前多数主流服务都会考虑到一个用户可以拥有多个email地址的情况。在关系型数据库中，我们必需建立一个多对一的关系，随后使用关联查询将地址与用户关联起来，如以下所示： CREATE TABLE users_addresses ( user_id uuid REFERENCES users, email text ); SELECT * FROM users NATURAL JOIN users_addresses; 而在Cassandra中，我们会以去正规化的方式将所有email地址直接加入用户表中，使用一个set集合就可以完美地实现这一点： ALTER TABLE users ADD email_addresses set<text>; 随后我们可以以如下方式为用户添加多个地址： UPDATE [...]



via WordPress http://blog.newitfarmer.com/nosql/bigtable-store/cassandra/13868/repost-%e5%85%b3%e4%ba%8ecassandra%e7%9a%84%e9%94%99%e8%af%af%e8%a7%82%e7%82%b9#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e5%2585%25b3%25e4%25ba%258ecassandra%25e7%259a%2584%25e9%2594%2599%25e8%25af%25af%25e8%25a7%2582%25e7%2582%25b9