要么共同存在，要么不存在
--Bertrand Russell
关系型数据库管理系统(RDBMS)自从70年代以来已经很普遍了。已经很难发现有哪个组织没有在他们的解决方案中不使用任何关系型数据库了。为了RDBMS的规范化做了大量的努力。正因为如此，如果你熟悉一种关系型数据库，切换到另外一种不是一个大的问题。你将保持在同一种范式而不会有大的转变。几乎所有数据库厂商提供了一套核心的标准特性接口在上面，包括他们自己的增值功能。有一个与关系型数据库通信的标准语言叫做结构化查询语言(SQL)。在一种关系型数据库上面的查询语言不需要重大的修改就能在另一种关系型数据库上运行。从技能设置角度看，这是一个很大的优势，因为你不用因为新产品的发展而去重新学习这些查询语言的新方言了。这就使从一种关系型数据库移植到另一种关系型数据库成为可能了。很多应用程序设计人员在用一种RDBMS无关的方法设计应用程序。换句话说，应用程序可以运行在多种关系型数据库上。只需要修改应用程序的某些配置文件的属性，就可以开始运行在不同的但是支持关系型数据库上面。很多软件产品被设计成支持多种关系型数据库，通过它们的配置文件的设置，来满足倾向于关系型数据库定制化的需求。
在大部分的关系型数据库里，一个数据库的schema组织一些objects到一个逻辑组里，例如表，视图，索引，存储过程，顺序等等。结构化和关联性的数据作为行和列，存储在表里。一个表里的主键唯一标识一行。表中的数据存储的方式有一个很强大的理论背景。
一个表由行和列组成。列包含了字段，行包含了数据的值。行也称为记录或者元组。元组演算，这是由Edgar F. Codd作为一种关系模型引进的，作为这一类型的结构化查询语言的基础。
尽量避免冗余。*定义数据库规范化如下：
数据库规范化是将关系型数据库的属性和表以最小化数据冗余组织起来的过程。
因为强调的是避免冗余，相关数据跨多个表，它们在不同的应用环境和SQL数据连接在一起。可以在表中的各个列上定义的多个索引.帮助数据检索、分类需求和维护数据完整性。
在最近这些年，各种应用程序产生的数据量变得非常大，传统的关系型数据库开始显示出它们的限制。大部分关系型数据库无法获取不同的数据类型到它们自己的模式里。当数据开始快速增长，传统关系型数据库经常成为瓶颈。当写入关系型数据库的数据存储速度非常快的时候，在短时间内，添加更多节点到集群中变得很有必要。SQL的性能在分布式的RDBMS上也会变差。换句话说，当我们进入了大数据时代，RDBMS无法处理数据的三个V: Volume(海量), Variety(多样性), 和Velocity(速度)。
很多RDBMS供应商提出了很多处理数据3V的解决方案，但是都带来了大量的代价。代价包括软件许可，复杂的硬件需求，建立容错解决方案栈的相关生态系统，开始很大的影响了底线。新一代互联网公司开始考虑解决这个问题的不同方法，而且，基于一些流行的研究论文基础上，从一些组织和开源社区里出现了很多专业的数据存储。这些数据存储通常称为NOSQL数据存储，然后它们开始解决非常具体的数据存储和检索的需求。Cassandra是其中的一种非常成功的NOSQL数据存储之一，有着和传统RDBMS很好的相似性。这种优势是在Cassandra被企业采用的时候尤其方便。传统的RDBMS和Cassandra在抽象上有一些相似之处。正因为如此，新用户可以将RDBMS和Cassandra联系起来。从逻辑角度来看，Cassandra的表和RDBMS的表在用户看来很相似，虽然这些表的底层是完全不一样的。正因为如此，Cassandra非常适合部署传统RDBMS的，解决了RDBMS无法解决的一些问题。
这里有警告是因为，在最终用户的视角中，RDBMS的表和Cassandra的列族(也称为表)的相似性，导致很多用户和数据建模者试图像使用RDBMS schema完全一样的方法来使用Cassandra，导致了很严重的部署问题。如何避免这些陷阱？在一开始，Cassandra可能看起来像传统的关系型数据库。然而事实是，它并不是一样的。这里的关键是要了解从理论角度的差异以及在一个实际的角度出发，遵循由Cassandra的创造者规定的最佳实践。
在Cassandra里，术语“列族”和“表”是同义词。Cassandra的查询语言(CQL)命令语法使用的是“表”
为什么Cassandra可以和其他的RDBMS一同使用？答案就在于RDBMS的局限性。其中一些比较明显的有，节省开销，规模的需要，处理海量流量，复杂查询降低响应时间，数据类型变得复杂，列表越来越多等等。最重要的需要和遗留的RDBMS共存的一个方面是，你要确保已经花掉的精力没有白费，而且当前应用程序工作没有任何问题。因此，你应该守护已花费的精力，确保你将来的调研花在一个聪明的NOSQL上面，例如Cassandra，采用一步一个脚印的方法。