NoSQL案例分析怎么写,nosql实训总结

大数据时代的案例分析

个案一

你开心他就买你焦虑他就抛

华尔街“德温特资本市场”公司首席执行官保罗·霍廷每天的工作之一，就是利用电脑程序分析全球3.4亿微博账户的留言，进而判断民众情绪，再以“1”到“50”进行打分。根据打分结果，霍廷再决定如何处理手中数以百万美元计的股票。

霍廷的判断原则很简单：如果所有人似乎都高兴，那就买入；如果大家的焦虑情绪上升，那就抛售。

这一招收效显著——当年第一季度，霍廷的公司获得了7%的收益率。

个案二

国际商用机器公司（IBM）估测，这些“数据”值钱的地方主要在于时效。对于片刻便能定输赢的华尔街，这一时效至关重要。曾经，华尔街2%的企业搜集微博等平台的“非正式”数据；如今，接近半数企业采用了这种手段。

●“社会流动”创业公司在“大数据”行业生机勃勃，和微博推特是合作伙伴。它分析数据，告诉广告商什么是正确的时间，谁是正确的用户，什么是应该发表的正确内容，备受广告商热爱。

●通过乔希·詹姆斯的Omniture（著名的网页流量分析工具）公司，你可以知道有多少人访问你的网站，以及他们呆了多长时间——这些数据对于任何企业来说都至关重要。詹姆斯把公司卖掉，进账18亿美元。

●微软专家吉拉德喜欢把这些“大数据”结果可视化：他把客户请到办公室，将包含这些公司的数据图谱展现出来——有些是普通的时间轴，有些像蒲公英，有些则是铺满整个画面的泡泡，泡泡中显示这些客户的粉丝正在谈论什么话题。

●“脸谱”数据分析师杰弗逊的工作就是搭建数据分析模型，弄清楚用户点击广告的动机和方式。

处理和分析工具

用于分析大数据的工具主要有开源与商用两个生态圈。

开源大数据生态圈：

1、Hadoop HDFS、HadoopMapReduce, HBase、Hive 渐次诞生，早期Hadoop生态圈逐步形成。

2、. Hypertable是另类。它存在于Hadoop生态圈之外，但也曾经有一些用户。

3、NoSQL，membase、MongoDb

商用大数据生态圈：

1、一体机数据库/数据仓库：IBM PureData(Netezza), OracleExadata, SAP Hana等等。

2、数据仓库：TeradataAsterData, EMC GreenPlum, HPVertica 等等。

3、数据集市：QlikView、 Tableau 、 以及国内的Yonghong Data Mart 。

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数据库简介

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)

简述什么是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应用

而传统的关系数据库在应付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数据库非常适合某些数据类型，如：非关系数据源。同时，NoSQL被吹捧为最适合Web应用程序的优秀平台。然而他适合大多数数据，特别是web应用程序的数据是相关型。那么，这是否可以给你一个坚持使用RDMS的理由呢？也不一定，即使很困难，我们还是要做出选择。

评估NoSQL是一个很茅盾的理论，一些人认为，应该将所有文档数据存储在一个文档中，做链接代码就是亵渎神明。另外一部分人认为，存储应用文档，加入代码，才是合理选择。与此同时，不同的数据库，需要在文档中限制嵌套数据数量。有的人会鼓励文档引用。这是NoSQL数据模型的基本部分，也没有一个明确的共识。

曾经有一篇很热的帖子"Why you should never use XYZ"，我想，读到这里，一定会有人搜索这篇文章。当然，这种文章各式各样，太过于笼统的标题也没什么帮助。毫无疑问，会有人会搜索这个文章，然后再找

到这个文章，进一步深入，找到该文章的方法远比成功（理解问题）的故事多。很难知道谁提供了一个有效的技术问题，谁又误读了这个问题（或者缺少证据证明其观点）。

有大量选择，RDBMS的世界，选择就很容易。你有4或5个目标，大家工作方式差不多，来选择环境、预算支持的平台。对于成熟的产品，风险比较小。 NoSQL的世界，有很多数据库引擎功能选择。每一个有自己的独特优势，也有致命弱点。所以选择很难， NoSQL项目生命周期短，尝试新项目或者流行项目也会有风险。上次，我的的项目是在 CouchDB上，而现在似乎停摆了。

做出这个痛苦决定的原因是，这可能是一个案例：你需要做一大堆工作，才能知道，你做出的选择对与错。你可以实体化你的数据模型，了解他与系统的工作情况，但是，这只有你正真撞到南墙，才可以找到裂缝（答案）。以我为例，我建的应用程序是关系数据库，移动文件存储的主要因素是，需要一个无模式设计来达到我的目标。使用NoSQL 数据库存储关系型数据库并不是我们所常说的，虽然，这种事常常发生。

现在我在用 Couchbase 和 MongoDB，Mongo对我没多大吸引力，不过鉴于他非常流行，对于引起来说，很有好处。当然，很多都可以以同样的方式流行。PHP很流行，因为他的易用性，而不是因为他很好。