传统关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS （Social Network Site,社交网站）显得力不从心，暴露了很多难以克服的问题。
存在问题 | 说明 | |
1 | 对数据库高并发读写的需求 | 关系数据库硬盘I/O无法应付上万次SQL写数据请求 |
2 | 对海量数据的高效率存储和访问的需求 | 关系数据库在上亿条记录的表里进行SQL查询，效率极其低下乃至不可忍受 |
3 | 对数据库的高可扩展性和高可用性的需求 | 数据库难以横向扩展，无法像Web Server和App Server那样简单通过添加更多硬件和服务节点来扩展性能和负载能力 |
非关系数据库出现的背景
ID | 关系数据库 | 实际需求 |
1 | 事务一致性需求降低 | 很多Web2.0实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高 |
2 | 数据库的写实时性和读实时性需求 | 很多Web2.0应用来说，并不要求高实时性 |
3 | 复杂的SQL查询（特别是多表关联查询）减少 | Web2.0应用从需求以及产品设计角度，弱化了SQL功能，往往更多的只需要单表的主键查询 |
意义：
打破了长久以来关系型数据库与ACID理论大一统的局面。
数据存储不需要固定的表结构，通常也不存在连接操作。
在大数据存取上具备关系型数据库无法比拟的性能优势。
满足了当今应用体系结构需要数据存储在横向伸缩性上的需求。
典型案例：
Google的BigTable（商业）
Amazon的Dynamo（商业）
Facebook的Cassandra（开源）
Apache的HBase（开源）