数据库中间件使用场景分析
数据库中间件使用场景分析数据库场景比较
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的服务，用来向客户端提供元数据服务。
Solr
Solr是一个开源的分布式搜索引擎，支持索引的分片和复制，可以根据需要来线性增加节点，扩展集群。Solr使用ZooKeeper主要实现如下功能：
?配置文件的管理：每个Collection都有对应的配置文件，多个分片共享配置文件（schema.xml、solrconfig.xml）
?Collection管理：一个Solr集群可以有多个逻辑上独立的Collection，每个Collection又包括多个分片和副本
?集群节点管理：Solr集群中有哪些活跃的节点可以使用，每个节点上都有Collection的分片（Shard）
?Leader分片选举：一个Collection的多个分片可以设置冗余的副本，一个分片的多个副本中只有一个Leader可以进提供服务，如果某个存储Leader分片的节点宕机，Solr基于
ZooKeeper来重新选出一个Leader分片，持续提供服务
HBase
HBase是一个基于Hadoop平台的开源NoSQL数据库，它使用ZooKeeper主要实现如下功能：
?Master选举：HBase基于Master-Slave模式架构，可以有多个HMaster，使用ZooKeeper 实现了SPOF下Master的选举
?租约管理：客户端与RegionServer交互时，会生成租约，该租约对象具有有效期
?表元数据管理：HBase中包括用户表及其两个特殊的表：-ROOT-表和.META.表（例如，管理-ROOT-表中location信息，一个-ROOT-表只有一个Region，它保存了RegionServer的地址信息。）
?协调RegionServer节点：数据变更会通过ZooKeeper同步复制到其他节点Lily
Lily是一个分布式数据管理平台，它基于Hadoop、HBase、Solr、ZooKeeper实现。使用ZooKeeper来注册Lily Node，从而管理集群节点的状态信息。
Dubbo
Dubbo是阿里巴巴开源的分布式服务框架，它可以选择使用ZooKeeper作为服务注册中心。
Dubbo服务基于Provider- Consumer模型，在服务发布的时候可以选择使用ZooKeeper作为注册中心来管理注册的服务，包括Provider发布的服务和 Consumer订阅的服务。
Katta
Katta实现了Lucene的分布式索引，能够提供数据的实时访问。Katta使用ZooKeeper实现了集群节点的管理，Master的选举，以及Lucene索引的管理。
Strom
Storm流式计算框架使用ZooKeeper来协调整个计算集群，Storm计算集群存在Nimbus和Supervisor两类节点。 Nimbus负责分配任务（Topology），将任务信息写入ZooKeeper存储，然后Supervisor从ZooKeeper中读取任务信息。另外，Nimbus也监控集群中的计算任务节点，Supervisor也会发送心跳信息（包括状态信息）到ZooKeeper中，使得Nimbus可以实现状态的监控，任何计算节点出现故障，只要重新启动之后，继续从ZooKeeper中获取数据即可继续执行计算任务。
BookKeeper
BookKeeper是Apache ZooKeeper项目的一个子项目。它是一个用来可靠地记录流数据的系统，主要用于存储WAL（Write Ahead Log）。
我们知道，Hadoop Namenode用来存储HDSF集群的元数据，其中存在一个用于写就花数据的EditLog文件，和一个存在于内存中的FsImage镜像，每当客户端与HDFS集群交互时，
对于集群中数据的变更都会记录在Namenode的EditLog文件中，然后再将该变更同步到内存的FsImage镜像上。
在BookKeeper中，服务节点（多个）称为Bookie，日志流（Log Stream）称为Ledger，每个日志单元（如一条记录）被称为Ledger条目。一组服务节点Bookie主要存储Ledger，Ledger的类型非常复杂多样，那么可能某一个Bookie节点可能发生故障，然而只要我们的BookKeeper系统的多个服务节点Bookie存储中存在正确可用的节点，整个系统就可以正常对外提供服务，BookKeeper的元数据存储在ZooKeeper中（使用ZooKeeper存储的只是元数据，实际日志流数据存储在Bookie中）。
Hadoop HDFS HA基于BookKeeper系统，可以实现HDFS Namenode的高可用性，这种方案称为BJM（BookKeeper Journal Manager），HDFS HA的另一种方案叫做QJM
（Quorum Journal Manager）。可以参考相关文档，在后面会给出参考连接。
HedWig
HedWig是基于ZooKeeper和BookKeeper的发布-订阅系统。在HedWig系统中，使用ZooKeeper来持久化系统的元数据，使用BookKeeper来存储实际的消息数据。
其他方案
还有其他一些开源方案，都使用了ZooKeeper，如下所示：
?Kafka
?Flume
?Accumulo
?Mesos
数据库索引
索引的是一种功能 索引是个既稳定又开放的信息结构，它有十一种功能。 1 分解功能 把文献中的资料单元(如篇名、机构、短语、概念、物名、地名、书名、人名、字词、符号等)一一分解，这就是索引的分解功能。它是索引工作的起跑线和索引编纂的基础，没有对文献内容的这种分解功能，就没有索引。 过去有些反对索引的人说，索引是把古人的著书“凌迟碎割”。他们对索引法的反对，实出于对流传已久的那种落后的皓首穷经的陋习的偏爱和对新的治学方法的无知，洪业曾鄙视他们为卧于涸辙的鲋鱼，以升斗之水济命，而不知西江水之可羡。虽然如此，但他们所谓的索引是把古人著书“凌迟碎割”的形象说法，却从反面十分正确地道破了索引的分解功能。 分解功能是索引作用于文献的特殊功能，是它和其他检索工作不同之处。 2 梳理功能 每种文献都包容着许多不同性质的资料单元，它们在文献中基本呈无序的状态。把这些无序状态的资料单元按外表特征或内容性质进行各归其类的整理，这就是索引的梳理功能。章学诚早就发现了这种功能，他在给《族孙守一论史表》信中要求其在治二十四史年表时一并把廿二史列传中的人名编成索引，两者互为经纬，这样便可使考古之士，于纷如乱丝之资料中，忽得梳通栉理。 梳理功能是索引分解的后继。如果只有分解功能而没有梳理的功能，那么分解功能就没有价值。 梳理是对资料单元的初分。如是字序，只要按笔划或音序归类即可；如是类序只要按大类归纳即可。就像小姑娘梳头，先把长发梳顺，而编什么辫子或梳什么发型则是下一步的要求了。 3 组合功能 把梳理后的资料单元按照分类的要求，严密地组织它们的类别层次以及类目下的专题和同类目下款目的序列关系；或按字序的要求，严密地把标目的结构正装或倒装、考虑限定词对标目的限定和修饰的级数、或考虑字序和类序相结合的可能。此外，不论是类序或字序都要考虑参照系统的建立方案，使相关款目形成网络，使用户检索的眼界得以拓宽。这些，都是索引的组合功能。 过去，国外的同行曾把圣经的页边索引以“串珠”命名；我国有人曾把本草的方剂编成索引，以“针线”命名，“串珠”和“针线”是索引组合功能很形象的描绘。它使文献资料单元成为一串串的明珠，成为被针线贯穿起来的资料单元的珍品。 4 结网功能 对某个领域的文献进行有计划的索引编纂，利用类型的结构从各种不同的角度和层次对这些文献的内容进行纵横交错和多维的揭示和组合，使之形成一个检索这些文献中的各种不同性质的资料单元的网络。这就是索引的结网功能。 由“主表”和“词族索引”、“范畴索引”、“英汉对照索引”等所组成的《汉语主题词表》是由几种不同性质的索引构建的一个主题词间的联系、辨析主题词词义和被标引的文献主题概念是否精确的一个隐含的语义网络，它对文献中的资料单元产生族性检索和扩大检索途径的作用。这个网络的结构和作用就是运用索引结网功能的一个范例。
平台数据库及中间件招标技术要求参考
平台数据库及中间件招标技术要求参考 1.总体要求 本次采购的数据库系统和中间件软件应具备如下基本特性： 1.1安全性：保证系统数据处理的一致性，保证数据不被非法盗用和修改伪造，保证数据不因意外情况丢失和损坏，提供多种安全检查审计手段。 1.2准确性：保证系统数据处理的准确性，提供多种核查、审计手段。 1.3可靠性：保证系统可靠连续运行。 1.4可伸缩性：系统应能适应不同规模的业务，系统硬件平台和数据库应具有良好的可扩充扩展性能。 1.5可扩展性：采用组件化设计原则，以使系统能够适应将来可能出现的一些变化，新增功能时不应需要改造原软件系统。 1.6开放性：系统应采用主流的、开放的技术，以保证系统对各种数据业务的服务，以及与相关系统的互连能力。 1.7可移植性：系统还应具有较强的可移植性、可重用性，保证在将来发展中迅速采用最新出现的技术、长期保持系统的先进。 1.8实时性：实时完成大容量数据处理，对业务提供并发处理支持。 1.9易用性：应具有良好的中文操作界面、详细的帮助信息，系统参数的维护与管理通过操作界面完成。 1.10可管理性：应具有良好的管理手段，可管理安全、网络、服务器、操作系统、数据库及应用等。 1.11系统必须能够7X24小时运行，支持基于集群的部署结构。 1.12系统应具备良好的备份/恢复机制。 1.13其他：为确保产品的合法来源及售后服务的技术保障，本次投标必须提供数据库和中间件软件的原厂授权书。 1.14供应商需提供现场安装、调试，并在原厂售后服务基础上提供一年的免费现场技术指导。 2.应用服务器中间件软件的详细技术要求如下 2.1支持多协议与服务管理。 2.2支持同步数据集成服务。
边界值分析法+场景法
黑盒测试-边界值分析法和场景法边界值分析法： 实验1：某选课系统中规定每门课程的选修人数在[20，60]之间，小于20人不开设该门选修课，大于60人不接受后面的选课要求。 结合黑盒测试方法中等价类划分和边界值方法设计测试案例，并给出相应测试用例。 参考答案 测试设计 ?输入变量：选课人数 ?测试输入 ?选择当选课人数分别为19，20，21, 59，60和61等几个边界点 ?再加上一个正常值点40 实验 2：编写一个程序，输入某雇员的工作时间（以小时计）和每小时的工资数，计算并输出他的工资。 具体如下： ?若雇员周工作小时小于40小时（0，40），则按原小时工资0.7来计算薪水。 ?若雇员周工作小时等于40小时，则按原小时工资计算薪水。 ?若雇员周工作小时介于40到50(（40，50）)小时的，超过40的部分按照原小时工资的1.5倍来计算薪水。 ?若雇员周工作小时超过50小时([50,60）)，则超过50的部分按原小时工资的3倍来计算薪水。 ?超出60小时或小于0小时，提示输入有误，重新输入。 结合黑盒测试方法中等价类划分和边界值方法设计测试案例，并
给出测试用例和相应的测试结果。参考答案
程序参考答案： #include
以百度地图为例,对地图产品的应用场景进行分析
一、地图标注 各种to B的产品中有很多展示地理位置的场景，而这些都需要在后台预先设置好。简而言之，该场景下的操作就是选择正确的位置并进行保存，核心操作包括搜索和标记。 搜索：输入关键词，点击suggest提供的内容或者直接输入关键词点击按钮进行搜索。 因为suggest的展示不够直观，只能在下拉列表中展示；输入关键词后搜索在地图上直观的看到分布情况无疑更为合适。是实际应用中一般是将两者结合使用。 标记：鼠标单击地图上的点或者拖拽预设置的当前城市中心点。 这两种操作其实是相互辅助的，有些时候地理位置错误或者不存在就需要拖拽中心点这种方式来修正。当然点击suggest提供的内容其实也算是一种标记，这个时候会覆盖掉之前选择的位置点。 二、周边配套 这种场景在房产行业的使用尤为突出，调用地图接口来显示周边配套信息，数据相对准确，体验上也更友好。该场景下涉及到地图的功能点也比较多，包含了诸如关键字检索、信息窗口显示、缩放
拖拽地图等功能点。 产品经理更多关注的是以下方面： 配套类型和排序； 右侧列表的排序规则、展现数量、默认和选中样式； 地图上POI和右侧列表联动的交互； 地图是否支持拖拽和缩放； 如何快速查找周边地理位置和规划出行路线等。 以上这些都需要产品经理对地图产品有深入的了解。 三、全景地图 全景地图是指把三维图片模拟成真实物体的三维效果的地图，浏览者可以拖拽地图从不同的角度浏览真实物体的效果。全景地图目前还存在一定的滞后性，很多地方也没有全景信息，相信这些也是地图厂商需要发力的地方。另外全景和VR结合也很具有发展潜力和想象空间，甚至有可能是一次全新的变革。 全景地图和普通地图的切换需要重点考虑，如何在选择一种类型后引导用户按照原路径返回对于体验非常重要。
数据库及中间件采购需求
数据库及中间件采购需求 中间件：ORACLE WebLogic Server Standard Edition应用服务器中间件标准版25用户数量：1套 数据库：ORACLE Database Enterprise Edition数据库企业版25用户数量：1套 其他要求： 一、合同价格 1.1本合同价格包括货物金额以及依约在交付后所需承担的售后服务价格的总和，且为完税后价格。乙方免费赠送两套最新版原厂光盘介质 二、支付和结算方式 2.1、双方因本合同发生的一切费用均以人民币结算及支付。 2.2、双方的帐户名称、开户银行及帐号以本合同提供的为准。 合同付款方式变更如下： （1）预付款：自合同签订起10个工作日内甲方向乙方预付合同总额的30%。 （2）到货款：全部货物到达合同指定现场并安装运行，甲方签字验收后10个工作日内甲方向乙方支付合同总额的30%。 （3）终验款：在完成相关集成工作并试运行/开发初验或者到货3个月后，双方签署终验证书后10个工作日内甲方向乙方支付合同总额的35%。 （4）尾款：免费保修期满一年后，对保修和维护工作进行验收，双方签署验收证书后10个工作日内甲方向乙方支付合同总额的5%。（保修期 为一年，自全部货物验收合格，双方签定最终验收报告之日起计算）. 2.3、如乙方根据本合同规定有责任向甲方支付违约金或其它赔偿时，甲方有权直接从上述付款中扣除该等款项并于事后通知乙方，该情形下应当视为甲方已经依约履行了合同义务，而所扣乙方的款项金额未达到乙方依照其责任所应当向甲方支付的金额时，乙方仍应向甲方补足。同时，若乙方对甲方的扣款有异议而不能协商解决时有权依照本合同关于解决争议的约定方式解决。但，存在或解决
数据库索引的优缺点及使用时的注意事项
本文介绍了数据库索引，及其优、缺点。针对MySQL索引的特点、应用进行了详细的描述。分析了如何避免MySQL无法使用，如何使用EXPLAIN分析查询语句，如何优化MySQL索引的应用。 索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它 们包含着对数据表里所有记录的引用指针。 注：[1]索引不是万能的！索引可以加快数据检索操作，但会使数据修改操作变慢。每修改数据记录，索引就必须刷新一次。为了在某种程序上弥补这一缺陷，许多SQL命令都有一个DELAY_KEY_WRITE项。这个选项的作用是暂时制止MySQL 在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行。在需要把许多新记录插入某个数据表的场合，DELAY_KEY_WRITE 选项的作用将非常明显。[2]另外，索引还会在硬盘上占用相当大的空间。因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。 从理论上讲，完全可以为数据表里的每个字段分别建一个索引，但MySQL把同一个数据表里的索引总数限制为16个。 1. InnoDB数据表的索引 与MyISAM数据表相比，索引对InnoDB数据的重要性要大得多。在InnoDB数据表上，索引对InnoDB数据表的重要性要在得多。在InnoDB数据表上，索引不仅会在搜索数据记录时发挥作用，还是数据行级锁定机制的苊、基础。"数据行级锁定"的意思是指在事务操作的执行过程中锁定正在被处理的个别记录，不让其他用户进行访问。这种锁定将影响到(但不限于)SELECT...LOCK IN SHARE MODE、SELECT...FOR UPDATE命令以及INSERT、UPDATE和DELETE命令。 出于效率方面的考虑，InnoDB数据表的数据行级锁定实际发生在它们的索引上，而不是数据表自身上。显然，数据行级锁定机制只有在有关的数据表有一个合适的索引可供锁定的时候才能发挥效力。 2. 限制 如果WEHERE子句的查询条件里有不等号(WHERE coloum != ...)，MySQL将无法使用索引。 类似地，如果WHERE子句的查询条件里使用了函数(WHERE DAY(column) = ...)，MySQL也将无法使用索引。 在JOIN操作中(需要从多个数据表提取数据时)，MySQL只有在主键和外键的数 据类型相同时才能使用索引。
情景分析法
情景分析法 概念一：情景分析法，又称前景描述法或脚本法，是在推测的基础上，对可能的未来情景加以描述，同时将一些有关联的单独预测集形成一个总体的综合预测。 概念二：情景分析就是就某一主体或某一主题所处的宏观环境进行分析的一种特殊研究方法。概括地说，情景分析的整个过程是通过对环境的研究，识别影响研究主体或主题发展的外部因素，模拟外部因素可能发生的多种交叉情景分析和预测各种可能前景。 2作用 情景分析法的作用： (1)分析环境和形成决策; (2)提高组织的战略适应能力; (3)提高团队的总体能力，实现资源的优化配置; 3特点 情景分析方法的特点：
(1)在了解内部环境的基础上; (2)定性分析加定量分析; (3)需要主观想象力; (4)承认结果的多样性; 4优点和局限性 1.主要优点：对于未来变化不大的情况能够给出比较精确的模拟结果。 2.局限性： (1)在存在较大不确定性的情况下，有些情景可能不够现实; (2)在运用情景分析时，主要的难点涉及数据的有效性以及分析师和决策者开发现实情境的能力，这些难点对结果的分析具有修正作用; (3)如果将情景分析作为一种决策工具，其危险在于所用情景可
能缺乏充分的基础，数据可能具有随机性，同时可能无法发现那些不切实际的结果。 5执行步骤 ◎方法一： （1）主题的确定； （2）主要影响因素的选择； （3）方案的描述与筛选：将关键影响因素的具体描述进行组合，形成多个初步的未来情景描述方案。――横纵坐标进行归类； （4）模拟演习：邀请公司的管理人员进入描述的情景中，面对情景中出现的状况或问题做出对应策略的过程； （5）制订战略； （6）早期预警系统的建立； ◎方法二：
数据库实验 索引的创建与使用
实验三：索引的创建与使用 一、实验目的： 1、理解索引的概念和索引的作用。 2、掌握创建索引的方法。 3、学会使用索引。 4、了解聚簇索引和非聚簇索引。 二、实验要求：（必做） 硬件：Intel Pentium 120或以上级别的CPU，大于16MB的内存。 软件：Windows 95/98/2000操作系统，关系数据库管理系统SQL SERVER 2000。 学时：2学时 三、实验内容： 1、用create index在学生表student的学号sno上建立聚簇索引。 2、在学生表student中，为姓名sname建立非聚簇索引。 3、在课程表的课程号Cno上建立唯一索引。 4、在选课表的学号sno、成绩Grade上建立复合索引，要求学号为升序，学号相同时 成绩为降序。 5、用drop删除学生表student的索引。 数据库设计与管理实验报告
实验名称评分 实验日期年月日指导教师 姓名专业班级学号 一、实验目的 二、实验步骤及结果 1、用create index在学生表student的学号sno上建立聚簇索引。 create clustered index stusno on student(sno); 2、在学生表student中，为姓名sname建立非聚簇索引。 create index stusname on student(sname); 3、在课程表的课程号Cno上建立唯一索引。 create unique index coucno on course(cno); 4、在选课表的学号sno、成绩Grade上建立复合索引，要求学号为升序，学号相同时成绩为降序。
数据库中间件使用场景分析
数据库中间件使用场景分析数据库场景比较 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.捕获监控参数
场景描述需求分析实例
场景描述 场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。用场景法来测试需指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。 下面来看具体的例子：假设你现在需要完成的是一套出租车预定系统(顾客进行出租车的预定,系统完成扣款以及出租车司机的任务分配等相关的任务: 顾客中的大部分都是在出租车租赁公司立有相关存款账户的用户，他们一般通过的方式进行预约，有些是要求立马预定的，也有一些是预定几周后的，我们需要使用计算机系统来确保这些存款账户到目前为止是有效的，系统需要知道什么时候顾客需要出租车，以及接送地址和他们的目的地。接送地址一般来说是顾客账户信息上填写的地址，根据我们车辆调度员的经验，我们可以告诉顾客最佳的接送时间。系统会根据订阅情况产生一个司机工作编号并记录预定过程中的详细信息，并会根据接送时间的顺序对这些信息按照接送的时间进行排序，然后会给顾客一个订阅的确认信息，同时包括司机的工作编号)。与这个预定出租车用例相关的，就是给出租车司机分配具体工作的用例。用场景法来对这个需求进行测试,应该如何进行呢? 首先我们来看一下正常用例场景的构建过程
a.识别商业事件流：发现需求的过程包括研究和调查特定需求相关的业务规则和策略，调查包括一系列的业务事件以及商业规则的边界点。业务事件包括事件名，输入数据（由这个事件引起的输入数据），输出数据（为了响应这个事件产生的输出数据） b.画一个非正式的商业场景草图 c.把这个场景草图形成场景的具体步骤 以顾客预定出租车为例，这个事件是在当顾客决定需要一个出租车时发生的，这个事件导致客户和出租车公司之间发生一个预定请求的交互动作，当出租车公司收到预定请求时，它触发了安排出租车登记事件用来响应这个需求，从分析得出其中有一个需出租车公司需要提供一个预定确认响应信息给顾客的过程，那么什么是预定确认，在什么情况下这个确认信息会产生，其他与之相关的需什么？下面我们就通过构建场景的方式来进行细节上的分析 a.事件源：顾客想预定出租车，发出出租车预定请求 事件结果：安排出租车预定行为（包括许多商业逻辑规则），发送一个出租车预定确认信息给顾客 事件名: 顾客想要预定出租车 输入数据：出租车预定请求 输出数据：出租车预定确认响应
数据库中间件高级技术支持服务说明
数据库中间件高级技术支持 服务说明 -标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
数据库和中间件技术支持 服务说明书 版本号：V2.0 赛尔网络 2010年4月28日
目录 第一章、公司简介 (5) 第二章、服务内容提要 (7) 第三章、数据库和中间件技术支持与服务详述 (9) 3.1、远程支持服务 (9) 3.1.1、中文电话支持服务（7*24小时） (9) 3.1.2、Email服务（7*24小时） (9) 3.2．现场服务 (10) 3.2.1.数据库、中间件安装调试服务 (10) 3.2.1.1、数据库安装调试服务 (10) 3.2.1.2、中间件安装调试服务 (11) 3.2.2定期系统健康检查服务 (12) 3.2.2.1、数据库方面的健康巡检 (12) 3.2.2.2、中间件方面的健康巡检 (13) 3.2.2.3、操作系统方面的检查 (15) 3.2.3．性能优化服务 (16) 3.2.4．数据库备份恢复策略的制定和测试服务 (18) 3.2.5．数据库和中间件升级及迁移服务 (20) 3.2.6．数据库和中间件应急服务 (20) 3.2.7．重大事件待命服务 (21) 3.2.8、制定数据库和中间件管理规范服务 (21) 3.2.9．其他现场服务 (22) 第四章服务质量保证及验收标准 (23) 4.1、服务项目的组织结构及人员安排 (23) 4.2、客户服务档案 (24) 4.3、服务效果的验收 (25) 第五章赛尔网络服务质量保障体系 (26)
5.1 技术支持总体流程 (26) 5.2 现场支持工作流程 (27) 5.3 健康巡检工作流程............................................................................ 错误!未定义书签。 5.4 重大紧急事件处理流程 (29)
场景分析法详解
场景分析法简介 用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流. 为什么引入场景分析法 现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。 这种在软件设计方面的思想也可引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。提出这种测试思想的是Rational公司. 基本流和备选流 图中经过用例的每条路径都用基本流和备选流来表示. 直黑线表示基本流,是经过用例的最简单的路径. 备选流用不同的彩色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如1和3);也可能起源于另一个备选流(如2),或者终止用例而不再重新加入到某个流(如2和4). 场景如下： ?场景1:基本流; ?场景2:基本流,备选流1; ?场景3:基本流,备选流1,备选流2; ?场景4:基本流,备选流3; ?场景5:基本流,备选流3,备选流1;
?场景6:基本流,备选流3,备选流1,备选流2; ?场景7:基本流,备选流4; ?场景8:基本流,备选流3,备选流4; 场景分析法测试设计方法 根据说明，描述出程序的基本流及各项备选流； 根据基本流和各项备选流生成不同的场景； 对每一个场景生成相应的测试用例； 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据。 场景分析法举例 用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用账号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。 第一步：确定基本流和备选流 基本流：登录在线网站→选择物品→登录账号→付款→生成订单； 备选流1：账户不存在； 备选流2：账户密码错误； 备选流3：用户账户余额不足； 备选流4：用户账户没钱。 第二步：根据基本流和备选流确定场景 场景1成功购物：备选流； 场景2账号不存在：基本流，备选流1； 场景3账号密码错误：基本流，备选流2； 场景4账户余额不足：基本流，备选流3； 场景5账户没钱：基本流，备选流4。 第三步：对每一个场景生成相应的测试用例
SQL Server 索引结构及其使用
一、深入浅出理解索引结构 实际上，您可以把索引理解为一种特殊的目录。微软的sql server提供了两种索引：聚集索引（c lustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别： 其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。 二、何时使用聚集索引或非聚集索引 下面的表总结了何时使用聚集索引或非聚集索引（很重要）：
数据库中间件及其几种技术比较
数据库中间件及其几种技术比较 摘要：本文阐述了数据库中间件的概念，功能，原理，介绍了现今数据库中间件的几种主要技术，并进行了比较。 关键字：数据库中间件 1、数据库中间件的基本概念 数据库中间件是处于底层数据库和用户应用系统之间的,主要用于屏蔽异构数据库的底层细节问题的中间件，是客户与后台的数据库之间进行通讯的桥梁。当客户向Web Server发出对某个数据库的SQL请求时,通过数据库中间件搜索匹配的数据库连接,并将SQL请求转发给对应的数据库服务器,通过其对数据库进行操作。 数据库中间件的主要功能:(1)支持常用大型数据库的各种操作。如ORACLE ,DB2, MYSQL等常用数据库。(2)提供统一接口, 屏蔽数据库之间的操作差异。(3)封装复杂烦琐的数据库应用接口和数据库操作过程,简化应用程序的数据库操作, 提高应用程序开发效率。(4)支持常用的操作系统。如Windows、UNIX、Linux 等，便于应用代码在各平台之间的移植。(5)支持多线程, 可以提供多线程与线程库, 满足各种场合应用。 数据库中间件(UniWeb Server)工作原理：让其作为前端的客户与后端的数据库之间进行通信的桥梁，当客户向数据库中间件发出对某个数据库的SQL请求时数据库中间件搜索当前可用的与该数据库的连接(UniTcl Server) 通过UniTcl Server将SQL请求转发给对应的数据库服务器，数据库服务器执行SQL语句后将结果通过UniTcl Server 返回给数据库中间件,再由它返回给客户整个数据库中间件的体系结构采用的是三层(Three-tier)客户机/服务器模型，中间件与各个客户的数据通信采用流套接字(Stream Socket)机制实现并
情景分析法
情景分析法： 情景分析法又称脚本法或者前景描述法，是假定某种现象或某种趋势将持续到未来的前提下，对预测对象可能出现的情况或引起的后果作出预测的方法。通常用来对预测对象的未来发展作出种种设想或预计，是一种直观的定性预测方法。 发展情况： “情景”一词最早出现于1967年Kahn和Wiener合著的《2000年》一书，是对事物所有可能的未来发展态势的描述，既包括对各种态势基本特征的定性和定量描述，同时还包括对各种态势发生可能性的描述。情景分析法是由荷兰皇家壳牌集团于60年代末首先使用基于脚本的战略规划，并或得成功，并由该公司的沃克于1971年正式提出，是根据发展趋势的多样性，通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系统发展态势作出自始至终的情景与画面的描述。 分析法的作用： 分析环境和形成决策 任何企业若想生存进而壮大,必须要尽可能做到“知己、知彼、知环境”。情景分析法就是企业从自身角度出发,通过综合分析整个行业环境甚至社会环境,评估和分析自身以及竞争对手的核心竞争力,进而制订相应决策。由于每一组对环境的描述都最终会产生一个相应的决策,因此情景分析主要应用于分析环境和形成决策两个方面。 提高组织的战略适应能力
由于情景分析法重点考虑的是将来的变化,因此能够帮助企业很好地处理未来的不确定性因素。尤其是在战略预警方面,能够很好地提高企业或组织的战略适应能力。同时,企业持续的情景分析还可以为企业情报部门提供大量的环境市场参数,而这些参数又可以对企业提供多方面的帮助,例如可以帮助企业发现自身的机会、威胁、优势和劣势等。 提高团队的总体能力，实现资源的优化配置 从企业内部出发,企业的核心是人,而人的思想是关键。由于情景分析法不仅仅属于高层管理人员的战略工具,而是需要企业各层级人员都参与其中,如此可激发每个人的责任感和成就感,从而提高团队的总体能力。企业通过情景分析法预测出未来可能出现的情景,决策人员以此为基础进行决策,确定未来的发展方向,而决策的实施需要资源的支持,因此，在进行情景分析及决策时，企业的资源也就相应地实现了重新配置。
9-应用场景分析 (假设)
应用场景分析---假设 在这段视频中，我将展示如何使用应用场景分析- 用于数据挖掘的“假设”表分析工具。这个工具只是用于Excel 的众多数据挖掘外接程序之一，并且我们为每个外接程序都制作了视频。 该应用场景分析工具使用逻辑回归算法，可用于对两种类型的应用场景进行建模，并且报告对输入数据中的单行或整个表的影响。 “假设”分析有助于您了解“如果我这样更改，将会有什么结果？”此工具将基于它从您的数据中分析出的成果来帮助您做出决策，例如，裁减营销人员将会对销售额产生的影响。在本教程中，我们将使用呼叫中心数据来了解如何减少“各问题平均所用时间”(Average Time Per Issue)。我所使用的Excel 数据来自https://www.wendangku.net/doc/5f11711230.html,。如果您使用自己的电子表格，只要记住为了找到有意义的模式，必须从有价值的少量数据开始，但数据至少要有50 行。 向导 我们对Level2Operators和“各问题平均所用时间”(Average time per issue) 很感兴趣，为了更好地进行演示，我要隐藏一些列，这样更容易看清结果。 1.开始时，选择“表分析工具示例”(Table Analysis Tools Sample) 选项卡，然后单击表 内的任何地方以激活表分析工具。 2.在“表工具”(Table Tools) 菜单下，选择“分析”(Analyze) 选项卡，从而打开“表 分析工具”(Table Analysis Tools) 功能区。 3.单击“应用场景分析”(Scenario Analysis)，然后单击“假设”(What-If) 以启动该向 导。 4.选择“各问题平均所用时间”(Average time per issue) 作为要更改的列。 5.选择“百分比”(Percentage)，然后键入80。这样做的意思是：平均而言，我们愿 意在每个问题上稍微多花一点时间。 6.如果“更改”(Change) 列包含连续数值，您也可以在值中指定所需的增减量。例如， 我可以选择“每个问题的平均服务时间”(Service Average time per issue) 并将更改指定为一个确切值。 7.在“影响目标”(What happens to) 框中，选择将会受“各问题平均所用时间”(Average time per issue) 变化影响的列。我要选择Level2Operators。如果我降低我的“各问题平均所用时间”预期值，将会需要多少2 级运营商呢？ 8.如果我现在单击“运行”(Run)，将对所有列执行分析。我不这样做，而是打开“选 择分析时要使用的列…”(Choose columns to be used for analysis…)，然后取消选中FactCallCenterID和TotalOperators。通过简化我的分析，可以改进性能和准确性。 但是要小心，不要取消选中将用于“目标”(Target) 或“更改”(Change) 的列。 9.我将对“整个表”(Entire table) 作出预测，并且单击“运行”(Run)。 10.我的结果将作为新列添加到原始数据表的右侧。这些列显示了由于更改“各问题平 均所用时间”(Average time per issue) 而对Level2Operators产生的影响。第一列显示了如果我们进行这样的更改，是需要增加还是减少 2 级运营商的数量。最后一列为各行显示了调查结果的置信度。 现在，我们来针对单行数据进行“假设”分析。 1.对于单行数据，该工具将在对话框的“结果”(Results) 窗格中报告结果。如果找到 了成功的解决方案，该工具将显示结果。例如，“假设”工具可能会告诉您：如果您
WEB数据库与中间件技术解决方案
Web数据库与中间件技术 随着Internet/Intrranet的兴起与发展，Web服务器与数据库服务器的连接显得越来越重要，许多厂家不断推出新技术、新产品，使得连接更加简洁、迅速和方便。Web与数据库连接技术已成为基于Web的信息管理系统的核心，为Internet上的电子商贸打下了基础。 一般来说，通过Web页实现对数据库访问，在整个系统中关键的技术是中间件的解决方案。 中间件负责管理Web服务器和数据库服务器之间的通信并提供应用程序服务。由于驻留在Web服务器上，因而中间件软件能够调用作为Web服务器和数据库服务器间"传输机制"的外部程序或"编码"，并将执行查询等以HTML页面或纯文本的形式将信息返回给最终用户。数据库服务器负责管理驻留在数据库服务器中的数据。 一、当前几种流行的中间件的解决方案 1．通用网关技术（CGI） CGI是一种Web站点上可以用来访问Web站点的用户交互的各种程序的标准，使用CGI脚本允许用户在浏览器中等服务器上的数据库交互，完成对数据库的各种操作。 几乎使用的服务器软件都支持CGI，开发者可以使用任何一种Web服务器内置语言编写CGI，包括Perl语言，C，C++，VB和Delphi等。 CGI的工作原理是浏览器通过Web页面的表单搜索参数，这些参数通过HTTP传递Web服务器，在服务器通过CGI脚本分析参数（命令行参数或环境变量），同时启动通路程序，把分析后的参数转化为SQL命令，交数据库服务器执行，然后CGI程序返回处理结果给Web服务器，最后向客户机返回HTML或纯文本格式的结果并断开连接。 CGI缺点是执行速度较慢，Web服务器每启动一个数据查询服务，就必须启动一个新的CGI 进程，相对服务器资源代价比较高。 2．ASP（Active Server Pages） ASP是一种开放的，可以将HTML脚本及可重用的Active Server组件结合在一起以建立高效的动态的基于Web的应用程序环境，利用ASP，可以增加运行在服务器端的脚本的新特性，
大数据的典型应用场景及展望
大数据的典型应用场景及展望 2015年1月24号，2015 China Hadoop Summit技术峰会在北京如期举行。本次大会作为国内大数据行业最具影响力的IT大会，吸引了众多从事Hadoop研究与推广的权威技术专家、Hadoop技术爱好者和IT厂商前往参加。 现任星环信息科技(上海)有限公司联合创始人兼首席技术官，曾任英特尔数据中心软件部亚太区CTO的孙元浩老师在本次大会上带来了主题为《2014年大数据的典型应用场景及展望》的分享，本文主要针对目前Hadoop主流应用场景，实时流数据的处理以及大数据技术给未来生活的设想等内容进行了整理。 四年前的硅谷，风投埃里森拿出一亿美金来投资大数据公司，他认为Hadoop技术在未来的若干年中会从底层的数据平台，从传统的关系型数据库进行迁移。数据的分析层会被全新的数据分析工具所替代，可视化层和应用分析会有更多的新工具出现，并认为这个市场将达到几百亿美金的规模。 过去几年，Hadoop的发展非常迅猛。我们常讲大数据的四V特征，Hadoop在大数据处理上表现出的处理量、性能、挖掘能力的提升和碎片化处理能力，使其得到越来越广泛的应用。 一、Hadoop的主流应用场景：数据仓库的主要组成部分 传统的企业有若干个主机，用于销售、运营管理等等，产生的数据首先经过ODS层，将数据从多个业务系统中集中起来，进行清洗、转
换等集成操作，然后将过加工的数据进入企业IT架构的核心——数据仓库进行统计、挖掘和分析。最后用可视化工具进行展现。这是传统的企业数据仓库的架构，经常采用主流的甲骨文等数据库技术来实现。 Hadoop作为数据仓库组成部分的四个驱动力 互联网公司早年的时候，是把Hadoop做在数据仓库的核心，比如Facebook早期的时候是从服务器采集是通过实时的日志的采集工具，经过Hadoop把Hadoop作为数据分析工具，呈现把结果放在甲骨文中做展现。 互联网公司之所以这么做，是因为互联网数据量大到在传统的数据库不能处理。现在传统的企业也面临同样的问题，将Hadoop作为数据仓库主要组成部分有四个驱动力： 效率：传统的数据仓库技术已经面临非常繁重的数据分析任务，处理的延迟从一天到了一周。 成本：传统的数据架构成本动辄几千万。Hadoop可以实现成本若干倍的降低。 数据来源多样：视频、音频等企业非结构化数据来源增多。MapReduce 对于非结构化或半结构化数据的读取非常有效。 数据分析需求的演进：数据分析不再只满足于统计。使用Hadoop 的技术，能够对数据进行深度的挖掘和分析，实现对未来的预测。Hadoop改变企业数据仓库架构的线路图 第一步：数据仓库的补充
情景分析法
1 情景分析的概念及其特点 “情景”(Scenario)最早出现于1967年HermanKahn和Wiener合著的《2000年》一书中。他们认为:未来是多样的,几种潜在的结果都有可能在未来实现;通向这种或那种未来结果的途径也不是唯一的,对可能出现的未来以及实现这种未来的途径的描述构成一个情景。“情景”就是对未来情形以及能使事态由初始状态向未来状态发展的一系列事实的描述。 基于“情景”的“情景分析法”(ScenarioAnalysis)是在对经济、产业或技术的重大演变提出各种关键假设的基础上,通过对未来详细地、严密地推理和描述来构想未来各种可能的方案。情景分析法的最大优势是使管理者能发现未来变化的某些趋势和避免两个最常见的决策错误:过高或过低估计未来的变化及其影响。情景分析法在西方已有好几十年的历史。该方法最早用在军事上,20世纪40年代末,美国兰德公司的国防分析员对核武器可能被敌对国家利用的各种情形加以描述,这是情景分析法的开始。到20世纪70年代,兰德公司在为美国国防部就导弹防御计划做咨询时进一步发展了该方法。今天,许多世界著名的跨国公司,如美国的壳牌石油公司、德国的BASF公司、戴母勒-奔驰公司、美国的波音公司等在制定战略规划时都使用该方法。一些国家政府也采用了该方法,如南非白人政府的种族隔离制度的和平变革,就是利用该方法推导了各种选择可能的结果之后做出的选择。 根据国外一些学者的研究,情景分析具有以下本质特点:a.承认未来的发展是多样化的,有多种可能发展的趋势,其预测结果也将是多维的。b.承认人在未来发展中的“能动作用”,把分析未来发展中决策者的群体意图和愿望作为情景分析中的一个重要方面,并在情景分析过程中与决策者之间保持畅通的信息交流。c.在情景分析中,特别注意对组织发展起重要作用的关键因素和协调一致性关系的分析。d.情景分析中的定量分析与传统趋势外推型的定量分析区别在于: 情景分析在定量分析中嵌入了大量的定性分析,以指导定量分析的进行,所以是一种融定性与定量分析于一体的新预测方法。e.情景分析是一种对未来研究的思维方法,它所使用的技术方法手段大都来源于其它相关学科,重点在于如何有效获取和处理专家的经验知识,这使得情景分析具有心理学、未来学和统计学等学科的特征。 2 “情景”理论体系的构成 国外的经济学家对“情景”理论体系的构成有不同的看法。Fahey认为一个情景应该包括结束状态(End-state)、策略(Plotorstory)、驱动力(Drivingforce)和逻辑(Logics)四个要素。他认为每个要素都可以多个方式发展,并且这些要素之间的相互关联导致了三种不同类型的竞争情景:第一种是即时情景(emergent scenarios)。这种类型由分析竞争者当前市场策略为起始,探讨如果竞争者改变他现在的策略将会出现什么变化。第二种是不受限制的“如果-那么”情景分析(Unconstrained“What-If”Scenarios)。这种类型来自开放式结局(open-ended)或者是不受限的“如果-那么”问题(unconstrained“what-if”questions),这些问题通常暗示着可能的结束状态,例如一个完全新的竞争策略。第三种是受限的“如果-那么”情景分析 (Constrained“What-If”Scenarios)。受限的“如果-那么”问题产生的情景需要构想出完全不同的计划,这些计划允许情景设计者深入地评估一些迥然不同的竞争者的行动和行动造成的结果。 Fink认为“情景管理”应建立在以下三个主要原则之上:a.系统思考(SystemThinking)。传统的管理方法侧重于对单一个体的分析,忽略了对系统整体的认识,因此常常导致失败。所以我们