两种nosql的常用操作,NoSQL的三大基石?

NoSQL如何实现数据的增删改查？

package basic;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

public class JDBC {

public void findAll() {

try {

// 获得数据库驱动

//由于长时间不写，驱动名和URL都忘记了，不知道对不对，你应该知道的，自己改一下的哈

String url = "jdbc:oracle:thin:@localhost:1521:XE";

String userName = "system";

String password = "system";

Class.forName("oracle.jdbc.driver.OracleDriver");

// 创建连接

Connection conn = DriverManager.getConnection(url, userName,

password);

// 新建发送sql语句的对象

Statement st = conn.createStatement();

// 执行sql

String sql = "select * from users";

ResultSet rs = st.executeQuery(sql);

// 处理结果

while(rs.next()){

//这个地方就是给你的封装类属性赋值

System.out.println("UserName："+rs.getString(0));

}

// 关闭连接

rs.close();

st.close();

conn.close();

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (SQLException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

public void delete(){

try {

//步骤还是那六个步骤，前边的两步是一样的

String url = "jdbc:oracle:thin:@localhost:1521:XE";

String userName = "system";

String password = "system";

Class.forName("oracle.jdbc.driver.OracleDriver");

Connection conn = DriverManager.getConnection(url,userName,password);

//这里的发送sql语句的对象是PreparedStatement,成为预处理sql对象，因为按条件删除是需要不定值的

String sql = "delete from users where id = ?";

PreparedStatement ps = conn.prepareStatement(sql);

ps.setInt(0, 1);

int row = ps.executeUpdate();

if(row!=0){

System.out.println("删除成功！");

}

// 关闭连接

rs.close();

st.close();

conn.close();

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (SQLException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

}

简述什么是nosql数据库，并列举两种常见的nosql数据库名称及其特点

NoSQL太火，冒出太多产品了，保守估计也成百上千了。

互联网公司常用的基本集中在以下几种，每种只举一个比较常见或者应用比较成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代memcached，通过checkpoint和commit log提供了快速的宕机恢复，同时支持replication提供读可扩展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盘的key-value storage, 模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google的几位大神出品的精品，LSM模型天然写优化，顺序写盘的方式对于新硬件ssd再适合不过了，不足是仅提供了一个库，需要自己封装server端。

3. Document Store: Mongodb

分布式nosql，具备了区别mysql的最大亮点：可扩展性。mongodb 最新引人的莫过于提供了sql接口，是目前nosql里最像mysql的，只是没有ACID的特性，发展很快，支持了索引等特性，上手容易，对于数据量远超内存限制的场景来说，还需要慎重。

4. Column Table Store: HBase

这个富二代似乎不用赘述了，最大的优势是开源，对于普通的scan和基于行的get等基本查询，性能完全不是问题，只是只提供裸的api,易用性上是短板，可扩展性方面是最强的，其次坐上了Hadoop的快车，社区发展很快，各种基于其上的开源产品不少，来解决诸如join、聚集运算等复杂查询。

几种nosql的浅谈

1、性能

都比较高，性能对我们来说应该都不是瓶颈。

总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。

2、操作的便利性

memcache 数据结构单一。（key-value）

redis 丰富一些，数据操作方面，redis 更好一些，较少的网络 IO 次数，同时还提供 list，set，

hash 等数据结构的存储。

mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。

3、内存空间的大小和数据量的大小

redis 在 2.0 版本后增加了自己的 VM 特性，突破物理内存的限制；可以对 key value 设置过

期时间（类似 memcache）

memcache 可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent，比如建立

10 台 4G 的 Memcache 集群，就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b

10.1.2.3:14000 mongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务

不要和别的服务在一起。

4、可用性（单点问题）

对于单点问题，

redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整

个快照,无增量复制，因性能和效率问题，

所以单点问题比较复杂；不支持自动 sharding,需要依赖程序设定一致 hash 机制。

一种替代方案是，不用 redis 本身的复制机制，采用自己做主动复制（多份存储），或者改成

增量复制的方式（需要自己实现），一致性问题和性能的权衡

Memcache 本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的 hash 或者环

状的算法，解决单点故障引起的抖动问题。

mongoDB 支持 master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，对客户端屏蔽了故障转移和切分机制。

5、可靠性（持久化）

对于数据持久化和数据恢复，

redis 支持（快照、AOF）：依赖快照进行持久化，aof 增强了可靠性的同时，对性能有所影

响

memcache 不支持，通常用在做缓存,提升性能；

MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性

6、数据一致性（事务支持）

Memcache 在并发场景下，用 cas 保证一致性redis 事务支持比较弱，只能保证事务中的每个操作连续执行

mongoDB 不支持事务

7、数据分析

mongoDB 内置了数据分析的功能(mapreduce),其他不支持

8、应用场景

redis：数据量较小的更性能操作和运算上

memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写

少，对于数据量比较大，可以采用 sharding）

MongoDB:主要解决海量数据的访问效率问题。

表格比较：

memcache redis 类型 内存数据库 内存数据库

数据类型 在定义 value 时就要固定数据类型 不需要

有字符串，链表，集 合和有序集合

虚拟内存 不支持 支持

过期策略 支持 支持

分布式 magent master-slave，一主一从或一主多从

存储数据安全 不支持 使用 save 存储到 dump.rdb 中

灾难恢复 不支持 append only file(aof)用于数据恢复

性能

1、类型——memcache 和 redis 都是将数据存放在内存，所以是内存数据库。当然，memcache 也可用于缓存其他东西，例如图片等等。

2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。

3、 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。

4、 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。Redis 可以通

过例如 expire 设定，例如 expire name 10。

5、 分布式——设定 memcache 集群，利用 magent 做一主多从;redis 可以做一主多从。都可

以一主一从。

6、 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。

7、 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。

Memecache 端口 11211

yum -y install memcached

yum -y install php-pecl-memcache

/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid

-d 启动一个守护进程

-p 端口

-m 分配的内存是 M

-c 最大运行并发数-P memcache 的 pid

//0 压缩（是否 MEMCACHE_COMPRESSED） 30 秒失效时间

//delete 5 是 timeout

常见NoSQL数据库的应用场景是怎么样的

文档数据库

源起：受Lotus Notes启发。

数据模型：包含了key-value的文档集合

例子：CouchDB, MongoDB

优点：数据模型自然，编程友好，快速开发，web友好，CRUD。

图数据库

源起： 欧拉和图理论。

数据模型：节点和关系，也可处理键值对。

例子：AllegroGraph, InfoGrid, Neo4j

优点：解决复杂的图问题。

关系数据库

源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的

数据模型：各种关系

例子：VoltDB, Clustrix, MySQL

优点：高性能、可扩展的OLTP，支持SQL，物化视图，支持事务，编程友好。

对象数据库

源起：图数据库研究

数据模型：对象

例子：Objectivity, Gemstone

优点：复杂对象模型，快速键值访问，键功能访问，以及图数据库的优点。

Key-Value数据库

源起：Amazon的论文 Dynamo 和 Distributed HashTables。

数据模型：键值对

例子：Membase, Riak

优点：处理大量数据，快速处理大量读写请求。编程友好。

BigTable类型数据库

源起：Google的论文 BigTable。

数据模型：列簇，每一行在理论上都是不同的

例子：HBase, Hypertable, Cassandra

优点：处理大量数据，应对极高写负载，高可用，支持跨数据中心， MapReduce。

数据结构服务

源起： ?

数据模型：字典操作，lists, sets和字符串值

例子：Redis

优点：不同于以前的任何数据库

网格数据库

源起：数据网格和元组空间研究。

数据模型：基于空间的架构

例子：GigaSpaces, Coherence

优点：适于事务处理的高性能和高扩展性

NoSQL应用

而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance - 对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。

2、Huge Storage - 对海量数据的高效率存储和访问的需求

对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability High Availability- 对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1、数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。

3、对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。

NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。

当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。

nosql是什么

NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

虽然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。