数据库中间件使用场景分析数据库场景比较PS:涉及到金钱方面的事务处理，建议使用Oracle。

数据库优点缺点场景Oracle 基本适合所有业务维护成本和License成本高电信，电力、银行、支付以及涉及到金钱方面等综合性企业。

(事务型)MySQL 结构简单，部署方便，社区成熟，稳定性非常好，良好的事务和SQL支持扩展性差，软件本身性能瓶颈大，没有成熟的集群方案。

Schema复制。

百亿以内的数据存储，对数据安全性和事务支持有要求。

主要存储对数据状态有要求和更新频繁的数据。

(事务型)MongoDB Schema--free，快速开发，本身支持集群如sharding，支持空间索引等；锁的粒度大，并发性能差，性能受限于内存，解决方案有待考验。

1.LBS(基于位置服务;地理坐标，或大地坐标),缓存，小文件存储。

2.CMS内容管理系统；3.社交网络图数据库设计.4.MongoDB主要用于存储计费数据、日志数据和流水数据Hbase 基于Hadoop生态系统，良好的扩展性，高写入能力。

数据自动分片。

架构复杂，维护成本高。

搜索，数据写入非常高，监控数据。

1.典型互联网搜索问题2.捕获增量数据3.内容服务4.信息交换HBase主要用来做数据分析和存储大数据内容。

Redis 高性能，部署简单，非常的数据类型支持，支持数据持久化，集群方案支持。

性能受限于内存，单进程问题。

适合小数据高读写场景。

缓存服务。

1.保存点击数据(计数器)2.在哈希表中保存用户信息3.用集合保存社交网站圈子数据MySQL还是PostgreSQL?1、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。

例如是一个论坛和社区，你应该使用MySQL。

2、你的应用是一个严肃的商业应用，对数据完整性要求很高。

而且你希望对一些商业数据逻辑进行很好的封装，例如是一个网上银行，你应该使用PostgreSQL。

3、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。

4、等等从Oracle转向MySQL主要是出于三个方面的原因：第一，降低运维成本。

Oracle数据库自动化运维实现难度和成本较高，而MySQL运维自动化难度和成本相对较低，当数据库实例不断成倍增长的时候，使用MySQL可以在有限人力的情况下维护更多的数据库实例。

第二，降低软件成本。

Oracle License成本较高，MySQL及其分支目前是免费的。

第三，提高可扩展性。

MySQL是开源数据库，便于有技术能力的公司根据业务发展情况自己开发定制一些数据库周边服务，使数据库使用的扩展性提高，而Oracle对这方面的支持比较一般。

Hbase场景说明捕获增量数据数据通常是细水长流，累加到已有数据库以备将来使用，例如分析，处理和服务。

许多HBase使用场景属于这个类别——使用HBase作为数据存储，捕获来自于各种数据源的增量数据。

例如，这种数据源可能是网页爬虫，可能是记录用户看了什么广告和多长时间的广告效果数据，也可能是记录各种参数的时间序列数据。

我们讨论几个成功的使用场景和公司。

1.捕获监控参数服务于数百万用户的WEB产品的后台基础架构一般都有数百或数千台服务器。

这些服务器承担了各种功能——服务流量，捕获日志，存储数据，处理数据等等。

为了保持产品正常运行，监控服务器和上面运行软件的健康状态是至关重要的（从OS到用户交互应用）。

大规模监控整个环境需要能够采集和存储来自于不同数据源的各种参数的监控系统。

每个公司有自己的办法。

一些公司使用商业工具来收集和展示参数；而其他一些公司采用开源框架。

2.捕获用户交互数据捕获监控数据是一种使用方式。

还有一种是捕获用户交互数据。

如何跟踪数百万用户在网站上的活动？怎么知道哪一个网站功能是最受欢迎的？怎样使得这一次的网页浏览直接影响到下一次？例如，谁看了什么？某个按钮被点击了多少次？还记得Facebook和Stumble 里的Like按钮和StumbleUpon 里的+1 按钮吗？是不是听起来像是一个计数问题？每次用户Like 一个特定主题计数器增加一次。

3. 广告效果和点击流过去的十年，在线广告成为互联网产品的一个主要收入来源。

提供免费服务给用户，在用户使用服务的时侯投放广告给目标用户。

这种精准投放需要针对用户交互数据做详细的捕获和分析，以便于理解用户的特征。

基于这种特征，选择并投放广告。

精细的用户交互数据带来更好的模型，进而导致更好的广告投放效果和更多的收入。

但这类数据有两个特点：它以连续流的形式出现，它很容易按用户划分。

理想情况下，这种数据一旦产生就能够马上使用，用户特征模型可以没有延迟地持续优化——也就是说，以在线方式使用。

4.在线 VS 离线系统在线和离线的术语多次出现。

在线系统需要低延迟。

某些情况下，系统哪怕给出没有答案的响应，也要比花了很长时间给出正确答案的响应好。

你可以把在线系统想象为一个跳着脚的没有耐心的用户。

离线系统不需要低延迟，用户可以等待答案，不期待马上给出响应。

当实现应用系统时在线或者离线的目标影响着许多技术决策。

HBase是一个在线系统。

和Hadoop MapReduce的紧密结合又赋予它离线访问的能力。

HBase非常适合收集这种用户交互数据，HBase已经成功地应用在这种场合，它可以增量捕获第一手点击流和用户交互数据，然后用不同处理方式（MapReduce是其中一种）来处理数据（清理、装饰、使用数据）。

************************************************内容服务一方面是用户使用内容 User Consuming Content，对应另一面是用户生成内容 User GenerateContent。

Tweete、Facebook帖子、Instagram 图片和微博等都是这样的例子。

他们相同的地方是使用和生成了许多内容。

大量用户通过应用系统来使用和生成内容，而这些应用系统需要Hbase作为基础。

集中的内容系统系统 CMS可以存储内容和提供服务。

但是当用户越来越多，生成内容越来越多的时候，就需要一个更具扩展性的CMS解决方案。

这种可扩展的CMS往往使用Hbase作为基础，再加上其他的开源框架，例如Solr，构成一个完整的功能组合。

(1)URL短链最近一段时间URL短链非常流行，许多类似产品破土而出。

StumbleUpon使用名字为su.pr.的短链产品，这个产品以HBase为基础。

这个产品用来缩短URL，存储大量的短链以及和原始长链接的映射关系，HBase帮助产品实现扩展能力。

(2)用户模型服务经过HBase处理过的内容往往并不直接提交给用户使用，而是用来决定应该提交给用户什么内容。

这种中间处理数据用来丰富用户的交互。

还记得前面提到的广告服务场景里的用户模式吗？用户模式（或者说模型）就是来自于HBase。

这种模型多种多样，可以用于多种不同场景，例如，针对特定用户投放什么广告的决定，用户在电商门户购物时实时报价的决定，用户在搜索引擎检索时增加背景信息和关联内容，等等。

很多这种使用案例可能不便于公开讨论，说多了我们就麻烦了。

当用户在电商网站上发生交易时，用户模型服务可以用来实时报价。

这种模型需要基于不断产生的新用户数据持续优化。

***********************************************************信息交换各种社交网络破土而出，世界变得越来越小。

社叫网站的一个重要作用就是帮助人们进行交互。

有时交互在群组内发生（小规模和大规模）；有时交互在两个个人之见发生。

想想看，数亿人通过社交网络进行对话的场面。

只是和远处的人通话是不够的，人们还想看看和其他人通话的历史记录。

社交网络公司感到幸运的是，存储很廉价，大数据领域的创新可以帮助他们充分利用廉价的存储。

Facebook短信系统经常被公开讨论，他也可能极大地驱动了HBase的发展。

当你使用Facebook时，某个时候你可能会收到或者发送短信给你的朋友。

Facebook的这个特性完全依赖于HBase。

用户读写的所有短信都存储在HBase里。

支持Facebook短信的系统需要具备：高的写吞吐量，极大的表，数据中心内的强一致性。

除了短信系统之外，使用HBase的其他应用系统另外要求：高的读吞吐量，计数器吞吐量，自动分库。

工程师们发现HBase是个理想的解决方案，因为他支持所有这些要求，他拥有一个活跃的用户社区，Facebook运营团队在Hadoop部署上有丰富经验，等等。

在“Hadoop goes realtime at Facebook”这篇文章里，Facebook工程师解释了这个决定背后的逻辑和显示了他们使用Hadoop和HBase建设在线系统的经验。

ZooKeeper实现的案例HDFS HA(QJM)Hadoop 2.x之前的版本，HDFS集群中Namenode是整个集群的中央元数据存储和服务节点，它存在SPOF的问题。

在2.x版本中，提出了各种HA方案，避免Namenode的SPOF问题，其中基于QJM（Quorum Journal Manager）的方案可以解决这个问题：使用QJM的方案中，HDFS集群中存在两类节点，一类是Namenode节点（包括Active状态的 Namenode，和Standby状态的Namenode），另一类是JournalNode，进行容错。

当Active状态的Namenode元数据发生改变时，通过JournalNode进程（ZooKeeper集群中）来监视这种变化，然后同步到Standby状态的Namenode节点（实际上同步的是EditLog镜像文件内容的变更）。

当Active状态的节点发生故障后，Standby节点的Namenode自动切换，并接管HDFS集群中Active状态Namenode的服务，用来向客户端提供元数据服务。

SolrSolr是一个开源的分布式搜索引擎，支持索引的分片和复制，可以根据需要来线性增加节点，扩展集群。

Solr使用ZooKeeper主要实现如下功能：∙配置文件的管理：每个Collection都有对应的配置文件，多个分片共享配置文件（schema.xml、solrconfig.xml）∙Collection管理：一个Solr集群可以有多个逻辑上独立的Collection，每个Collection又包括多个分片和副本∙集群节点管理：Solr集群中有哪些活跃的节点可以使用，每个节点上都有Collection的分片（Shard）∙Leader分片选举：一个Collection的多个分片可以设置冗余的副本，一个分片的多个副本中只有一个Leader可以进提供服务，如果某个存储Leader分片的节点宕机，Solr基于ZooKeeper来重新选出一个Leader分片，持续提供服务HBaseHBase是一个基于Hadoop平台的开源NoSQL数据库，它使用ZooKeeper主要实现如下功能：∙Master选举：HBase基于Master-Slave模式架构，可以有多个HMaster，使用ZooKeeper 实现了SPOF下Master的选举∙租约管理：客户端与RegionServer交互时，会生成租约，该租约对象具有有效期∙表元数据管理：HBase中包括用户表及其两个特殊的表：-ROOT-表和.META.表（例如，管理-ROOT-表中location信息，一个-ROOT-表只有一个Region，它保存了RegionServer的地址信息。