NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。
专注于为中小企业提供成都网站设计、成都网站制作服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业九台免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了近1000家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
虽然NoSQL流行语火起来才短短一年的时间，但是不可否认，现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实：技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的工具，可以为大数据建立快速、可扩展的存储库。
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
对于NoSQL并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：
不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。
无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移。
分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。
异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。
BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。
NoSQL数据库并没有一个统一的架构，两种NoSQL数据库之间的不同，甚至远远超过两种关系型数据库的不同。可以说，NoSQL各有所长，成功的NoSQL必然特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其他的NoSQL。
关系数据库经过几十年的发展，已经非常成熟，但同时也存在不足：
表结构是强约束的，业务变更时扩充很麻烦。
如果对大数据量的表进行统计运算，I/O会很高，因为即使只针对某列进行运算，也需要将整行数据读入内存。
全文搜索只能使用 Like 进行整表扫描，性能非常低。
针对这些不足，产生了不同的 NoSQL 解决方案，在某些场景下比关系数据库更有优势，但同时也牺牲了某些特性，所以不能片面的迷信某种方案，应将其作为 SQL 的有利补充。
NoSQL != No SQL，而是：
NoSQL = Not Only SQL
典型的 NoSQL 方案分为4类：
Redis 是典型，其 value 是具体的数据结构，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被称为数据结构服务器。
以 list 为例：
LPOP key 是移除并返回队列左边的第一个元素。
如果用关系数据库就比较麻烦了，需要操作：
Redis 的缺点主要体现在不支持完成的ACID事务，只能保证隔离性和一致性，无法保证原子性和持久性。
最大的特点是 no-schema，无需在使用前定义字段，读取一个不存在的字段也不会导致语法错误。
特点：
以电商为例，不同商品的属性差异很大，如冰箱和电脑，这种差异性在关系数据库中会有很大的麻烦，而使用文档数据库则非常方便。
文档数据库的主要缺点：
关系数据库是按行来存储的，列式数据库是按照列来存储数据。
按行存储的优势：
在某些场景下，这些优势就成为劣势了，例如，计算超重人员的数据，只需要读取体重这一列进行统计即可，但行式存储会将整行数据读取到内存中，很浪费。
而列式存储中，只需要读取体重这列的数据即可，I/O 将大大减少。
除了节省I/O，列式存储还有更高的压缩比，可以节省存储空间。普通行式数据库的压缩比在 3:1 到 5:1 左右，列式数据库在 8:1 到 30:1，因为单个列的数据相似度更高。
列式存储的随机写效率远低于行式存储，因为行式存储时同一行多个列都存储在连续空间中，而列式存储将不同列存储在不连续的空间。
一般将列式存储应用在离线大数据分析统计场景，因为这时主要针对部分列进行操作，而且数据写入后无须更新。
关系数据库通过索引进行快速查询，但在全文搜索的情景下，索引就不够了，因为：
假设有一个交友网站，信息表如下：
需要匹配性别、地点、语言列。
需要匹配性别、地点、爱好列。
实际搜索中，各种排列组合非常多，关系数据库很难支持。
全文搜索引擎是使用 倒排索引 技术，建立单词到文档的索引，例如上面的表信息建立倒排索引：
所以特别适合根据关键词来查询文档内容。
上面介绍了几种典型的NoSQL方案，及各自的适用场景和特点，您可以根据实际需求进行选择。
Web1.0的时代，数据访问量很有限，用一夫当关的高性能的单点服务器可以解决大部分问题。
随着Web2.0的时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据。加上后来的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。
NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式数据库 列式数据库 Hbase Hbase
HBase是Hadoop项目中的数据库。它用于需要对大量的数据进行随机、实时的读写操作的场景中。
HBase的目标就是处理数据量非常庞大的表，可以用普通的计算机处理超过10亿行数据，还可处理有数百万列元素的数据表。
Cassandra Cassandra
Apache Cassandra是一款免费的开源NoSQL数据库，其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集(数据量通常达到PB级别)。在众多显著特性当中，Cassandra最为卓越的长处是对写入及读取操作进行规模调整，而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。
主要应用：社会关系，公共交通网络，地图及网络拓谱(n*(n-1)/2)
企业应用系统架构优化方法
系统优化是一个全面而复杂的工作，很难通过某一方面的提升而获得很好的效果，也很难在一朝一夕完成系统的全面优化，每个系统都有其特性，需要综合分析综合考虑才能获得比较好的效果。 我下面为大家整理了一些企业应用系统架构优化的方法，欢迎阅读参考：
1 实现动静分离
所谓“动静”分离，就是将静态资源如图片、CSS、Js等和动态资源如JSP、Servlet等进行分开的处理，通过使用不同的服务器，从而加快页面的响应速度，这是目前互联网应用最常用的方式之一，但是在企业应用端相对应用较少。
动静分离至少有两个方面的好处，一是提高了静态资源的处理速度，因为应用服务器处理静态资源的速度—般都不如专业的web服务器，第二个好处就是减少了应用服务器的负担，应用服务器专注于处理动态请求，这对系统的稳定运行是有很大的帮助的。
要实现动静分离，有两种方式，一种是在加载静态资源的HTML语言中，将地址指定到不同的IP/域名上，实现彻底的分离。这种方式需要在设计之初进行考虑，并不适合优化项目，因为这种修改会产生很大的工作量。第二种方式是通过分发器，拦截对静态资源的访问，将动态资源转发给后端的应用服务器，实现动静分离。这种方式的好处是不需要改动现有的代码，仅需要做部署方式故调整，增加web服务器进行静态资源的处理。示意图如下：
目前转发器比较多，既有老牌的Apache Web Server、有性能卓越的Zeus，也有目前如日中天的Nainx，不同的项目可以按照各自的需求进行选择。
2 使用缓存技术
缓存技术是巨型项目、超大型项目中最重要的技术，范围也比较广，从前端的页面、应用中的数据、数据库本身等均可以进行缓存，每个方面使用的技术也千差万别。使用缓存可以带来两个方面的好处，一是缓存的数据可以被高速加载，从内存中读取数据比通过数据库或磁盘读取具有更好的效率;二是最重要的，减少了数据库服务器的压力，有利于数据库的稳定，数据库可以使用更多的资源进行查询、统计等工作，有利于提高系统的整体运行速度。对于大中型应用而言，应用中的数据缓存和数据库端的缓存是应该被考虑的。数据库端的缓存在本文数据库章节中进行描述，本节描述应用中数据的缓存。
要使用缓存，首先需要明确缓存的'内容。一般优化项目不建议做全部数据缓存，或者使用内存数据库之类的技术，这种修改工作量巨大，由此带来的安全性、稳定性、数据的一致性都可能存在较大的隐患。所以，缓存的内容需要有所选择，一般的说，应该根据数据的数据量、被读取的次数、增加/更新频率进行选择。如果数据较少、增加/更新频率非常低，那么应该考虑直接缓存在应用服务器端，只有对于重要性较高、读取次数较多、增加/更新频率相对适中的数据，才适合使用独立缓存。 确定缓存的内容之后，就应该确定缓存的方式。对于缓存于应用服务器端的资源，一般选择KEY-ALUE(OBJECT)进行缓存。对于独立缓存，其内容也KEY-VALUE的格式进行存储(如果使用内存数据库实现缓存，那么存储的就是与数据库相同的信息)，VALUE可以选择SON或者Java Object，其中JSON占用空间较少，读取的网络流量较少，读取之后需要进行转换为Java对象;JavaXCN占用空间较大，读取的网络流量会较多，读取之后无需进行转化(前提是要求该对象已经系列化)，不同系统可以各自特点进行选择。
对于独立缓存，接下来的工作是选择缓存服务器，缓存服务器选择需要具有一定的原则：是否满足已经确定的缓存方式、对操作系统要求如何、稳定性如何、是否支持分布式、是否支持多节点热备、客户端(即JAVA调用接口)接口是否支持漂移(一个节点崩溃是否能转移到另外的节点)、客户端是否高效等等。从目前业界来看，memcached、redis都是应用比较广泛的缓存服务器。
选择完缓存服务器之后，就需要对系统的代码进行一定的改造。改造的内容就是将通过数据库读取的信息改为从缓存服务器获得，而对数据的保存、修改、删除操作，既要操作数据库上的数据，也需要对缓存服务器的信息进行更新，如下图所示：
由于是对系统的优化，那么系统中已经具有很多数据且并未进入缓存，因此还需要将缓存服务器中的数据进行初始化。有两种方式来进行，一种方式是直接将数据库中的数据一次性加载到缓存服务器，另外一种方式是在修改Load数据的方式，先从缓存服务器获取，如果没有，则从数据库获取，然后同步到缓存服务器上。对于优化项目，建议使用第二种方式。第二种方式一个额外的好处就是当缓存服务器全部不可用时，系统也能提供完整的服务。
3 使用异步日志记录
对于企业应用而言，对用户的操作的记录是很重要的，在系统出现某些问题的时候，可以通过日志进行数据恢复。一般系统要么没有进行记录，要么使用数据库进行同步记录。这部分数据会比较庞大，少则百万级，多则数亿，并且随着使用量的增加而逐渐增加。这些表属于使用率最高的表之一，在这些表上进行经常性数据插入，有可能会变成系统的噩梦。
为了解决这个问题，引入异步日志记录，是较为理想的选择。通过在web容器中增加过滤器，拦截用户的请求，然后将用户的请求和表单数据封装为JSON格式的数据，采用异步方式发送到NoSQL数据库，需要恢复的时候，通过对JSON数据进行还原。这种方式有如下好处：
1)不需要改动现有代码而进行了用户操作记录;
2)由于采用异步模式，几乎不会增加用户操作的时间;
3)采用NoSQL+JSON存储，不用为每一类操作特别设置特定的表结构，修改简单。
目前的NoSQL数据库也逐渐显露头角，根据DB Engines在今年10月发布的数据库排名中，MongoDB的NoSQL服务器已经跃居第七位，因此NoSQL服务器目前推荐使用MongoDB。
;
