Nosql，全称是”Not Only sql”,指的是非关系型的数据库。这类数据库主要有这些特点：非关系型的、分布式的、开源的、水平可扩展的。原始的目的是为了大规模web 应用。Nosql 的拥护者们提倡运用非关系型的数据存储，通常的应用如：模式自由、支持简易复制、简单的API、最终的一致性（非ACID）、大容量数据等。Nosql 被我们用得最多的当数key-value 存储，当然还有其他的文档型的、列存储、图型数据库、xml 数据库等。
二、Why Nosql?
随着互联网web2.0 网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速，而传统的关系型数据库在应付web2.0 网站，特别是超大规模和高并发的SNS 类型的web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
- High performance - 对数据库高并发读写的需求web2.0 网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系型数据库应付上万次sql 查询还勉强顶得住，但是应付上万次sql 写数据请求，硬盘IO 就已经无法承受了，其实对于普通的BBS 网站，往往也存在对高并发写请求的需求。
- Huge Storage - 对海量数据的高效率存储和访问的需求对于大型的SNS 网站，每天用户产生海量的用户动态信息，对于关系数据库来说，在一张上亿条记录的表里面进行sql 查询，效率是极其低下乃至不可忍受的。
- High Scalability && High Availability - 对数据库的高可扩展性和高可用性的需求在基于web 的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server 和app server 那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24 小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，可是停机维护随之带来的就是公司收入的减少。
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0 网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
- 数据库事务一致性需求很多web 实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
- 数据库的写实时性和读实时性需求对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web 应用来说，并不要求这么高的实时性。
- 复杂的SQL查询，特别是多表关联查询的需求任何大数据量的web 系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂sql 报表查询，特别是SNS 类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，sql 的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的Nosql 数据库应运而生。
三、Nosql Features
- 它可以处理超大量的数据
- 它运行在便宜的PC服务器集群上PC 集群扩充起来非常方便并且成本很低，避免了传统商业数据库“sharding”操作的复杂性和成本。
- 它击碎了性能瓶颈Nosql 的支持者称，通过Nosql 架构可以省去将Web 或Java 应用和数据转换成sql 格式的时间，执行速度变得更快。“sql 并非适用于所有的程序代码”，对于那些繁重的重复操作的数据，sql 值得花钱。但是当数据库结构非常简单时，sql 可能没有太大用处。
- 它没有过多的操作虽然Nosql 的支持者也承认关系型数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么复杂。
- 它的支持者源于社区因为Nosql 项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。