正如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 users
SET email_addresses = {‘jbe@gmail.com’,
‘jbe@datastax.com’}
WHERE user_id = ‘73844cd1-c16e-11e2-8bbd-
7cd1c3f676e3’
关于Cassandra数据模型的更多内容，包括自届满数据（self-expiring data ）以及分布式计数器，请参考在线文档，
误解：Cassandra的读取速度较慢
Cassandra采用的日志结构存储引擎意味着它不会在硬盘中寻找更新，也不会 造成固态硬盘的写入放大，而同时它的读取速度也很快。
以下图示是关于随机访问读取、随机访问及顺序扫描，以及混合读写情况下的 吞吐数据，它们来自于多伦多大学的NoSQL性能指标分析结果：
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索数据库
， 数据
， cassandra
， users
， 一个
方式
关于理想的错误观点是、亚里士多德的错误观点、错误观点、刘植荣的错误观点、亚里士多德错误观点，以便于您获取更多的相关知识。