数据库新技术考题

数据库新技术考题1、 云计算环境与分布式计算环境各提出了那些新的数据管理需求。云计算环境新的数据管理需求：与传统数据库系统相比，目前云数据管理系统提供的接口有很多限制，只提供简单的数据存取接口或者极小化的查询语言，这增加了用户使用的难度，也增加了开发人员的负担.同时，相比于传统的分布式关系数据库，云数据管理系统的查询性能也有很大的提升空间.如何在现有云计算平台的基础上，完善云数据管理系统的查询功能并提高其数据处理的性能，是目前备受关注的挑战性问题用户接口和查询性能是目前云数据管理系统亟待提高的两个方面。要求云数据管理系统中的查询处理及优化算法具备良好的扩展性，不仅能够扩展到庞大规模的云平台上，而且能够实现资源的可动态增长及其带来的性能提升.云数据管理系统需要将软硬件错误看成系统运行的常态，错误发生时既要保证数据不丢失，又要保证数据的读写操作能够正常进行。云数据管理系统应当针对云数据的特点设计数据分布策略和查询优化相关算法，从而提高其管理海量数据的能力。云数据管理系统要提供SQL接口，这样习惯于关系数据库查询语言的用户不必重新学习新的接口或者编程方法，云数据管理系统还要提供UDF（UserDefinedFunction）接口，用户可以根据业务需求自己定义数据查询操作。分布式计算环境新的数据管理需求在分布式环境下数据传输和数据倾斜等问题的出现使得在MapReduce实现连接成为一个非常具有挑战性的问题。分布式计算系统没有统一的控制手段，它的质量和可用性难以保证，网络是一个异构的环境，分布式计算技术需要解决异构环境的互操作问题。现有资源不可能以同一种方式描述，有没有自动识别资源的方法，所以分布式计算技术的使用具有范围性。2、 简要叙述大数据可用性的概念及目前主要研究内容答：一个正确的大数据集合至少以满足以下5个性质：1）一致性：数据集合中每个信息都不包含语义错误或相互矛盾的数据。2）精确性：数据集合中每个数据都能准确表述现实世界中的实体。3）完整性：数据集合中包含足够的数据来回答各种查询和支持各种计算。4）时效性：信息集合中每个信息都与时俱进，不陈旧过时。5）实体同一性：同一实体在各种数据源中的描述统一。一个数据集合满足上述5个性质的程度是该数据集合的可用性。研究内容：1） 高质量大数据获取与整合的理论和技术；2） 完整的大数据可用性理论体系；3） 数据错误自动检测与修复的理论和技术；4） 弱可用数据上近似技术的理论和技术；5） 弱可用数据上的知识发掘与演化的机理。3、 简述云存储系统的主要安全需求有哪些？答：数据安全是云存储系统中最重要的安全需求之一。云存储系统中数据的安全性可分为存储安全性和传输安全性两部分，每个部分又包含机密性、完整性和可用性。D数据的机密性云存储系统中的数据机密性是指无论存储还是传输过程中，只有数据拥有者和授权用户能够访问数据明文，其他任何用户或云存储服备提供商都大法得到数据明文，从理论上杜绝一切泄漏数据的可能性.2） 数据的完整性云存储系统中数据的完整性包含数据存储时和使用时的完整性两部分,数据存儒时的完整性是指云存储服务提供商是按照用户的要求将数据完整地保存在云端，不能有丝毫的遗失或损坏.数据使用时的完整性是指当用户使用某个数据时,此数据没有被任何人伪造或规改.3） 数据的可用性云存储的不可控制性滋生了云存储系统的可用性研究.与以往不同的是云存储中所有硬件均非用户所能控制.因此，如何在存储弁质不可控的情况下提高数据的可用性是云存储系统的安全需求之一.密钥管理分发机制，一直以来，数据加密存储都是保证数据机密性的主流方法。数据加密需要密钥，云存储系统需要提供安全高效的密钥管理分发机制保证数据在存储与共享过程中的机密性。其他功能的需求，由于相同密文在不同的密匙或加密机制下生成的密文并不相同，数据加密存储将会影响到云存储系统中的一些其他共能，例如数据搜索，重复数据删除等，云存储系统对这些因数据加密而被影响的功能有着新的需求。4、 云环境下分布式缓存技术主要面临的问题与解决方案1） 缓存服务的性能隔离。改进的全局缓存替换方法，两种方案。通过为租户动态加权的方式确保访问频率低的租户内容不会很快被替换出内存；根据租户当前占用的内存空间是否少于目标空间，动态选取该租户或其他租户数据替换出缓存。2） 虚拟环境下数据迁移的优化。基于反馈控制的方法，周期性的求解满足QoS约束下的最优迁移速率；采用控制理论解决数据迁移中的开销优化问题.基于多元回归法构建迁移时间与性能衰减度的预测函数，将二者线性加权得到迁移开销模型，最终实现以最小化开销为目标的迁移速率控制。3）缓存策略的自适应与自管理。使用跟踪驱动模拟（trace-drivensimulation）方法为每个Web文件选取最优一致性策略；基于规则的方法,策略选取规则由带宽、数据变化率以及用户一致性需求要素组成；根据统计结果及识别规则（detectionrule）对当前访问模式进行分类,根据分类结果采用相应的最优替换策略。5、 MongoDB的分片存储与分布式数据库有何不同？答：MongoDB提供了一种自动分片的机制来实现系统的水平扩展。虽然分片的概念源于关系型数据库的分区，但还是有一些差别。最大的差别是MongoDB自动地完成所有的工作而不需要人工的介入，并且当各个分片中的数据分布不均衡时，自动完成数据的重分布。MongoDB的自动分片（Auto.Sharding）机制在设计时主要实现以下三个目标：1） 使集群“不可见”，应用程序不必知道其所需要的数据存储于哪个服务器上，也不必了解整个集群的架构。2） 使集群可随时读写，MongoDB通过几种不同的方式来最大化系统的正常运行时问3） 使集群容易扩展，当一个系统需要更多的空f刚和资源时，必须能够简单并且容易地进行扩展。MongoDB自动分片机制的基本原理是将数据集合分成小块(chunk)，这些块使用系统的均衡策略分散到若干个片(shard)qb，每个片包含数据集的一部分。当各个片中的数据分布不均衡时，均衡策略会自动重新分布数据，维持各个片中数据的均匀分布，不需人工干预。在MongoDB分片集群中，数据是按一定的顺序组织在一起的，即片键相邻的数据倾向于存储在同一个服务器上。在MongoDB自动分片集群中采用的方式是一个片中可以包含多个范围的数据。这种方式有效地减少了需要迁移的数据总量，特别是当集群中添加了新的片时，每个片将自己的部分数据移动到新片中。这种方式将数据从包含数据最多的片直接移动到目标片中，而不必在其他的片中进行中转，均衡效果最为有效且移动的总数据量最小。MongoDB自动分片集群中，数据迁移以块为单位，当一个特定片中含有过多的数据时，这个片中的块就会迁移到其他的片中MongoDB自动分片机制引入了balancer负责数据迁移和负载均衡，balancer是一个后台运行的任务，被集成在mongos中。均衡的操作对于客户端是透明的，客户端的应用程序不必在意数据是否正在被移动。6、 H-Store与VoltDB采用怎样的技术方法解决大数据存储、易扩展及性能问题？答：H-Store是第一个实现的新型并行数据库管理系统，称为NewSQL。这种数据库系统提供了NoSQL系统所具有的高吞吐量和高可用性的，而且并没有放弃传统DBMS的事务处理的功能。这样的系统能够在多台计算机上进行并行计算，以提高吞吐量，而不是运行在一个超强大，超昂贵的单节点计算机上。VoltDB提供了NoSQL数据库的可伸缩性和传统关系数据库系统的ACID一致性，不同NoSQL的key-value储存，VoltDB能使用SQL存取，支持传统数据库的ACID模型。VoltDB通过SQL引擎把数据分发给集群服务器的每个CPU进行处理。每个单线程分区自主执行，消除锁定和闩锁的需求。VoltDB可以通过简单的在集群中增加附加节点的方式实现性能的线性增加。7、 简述元搜索技术、数据空间以及跨媒体检索的技术要点答：元搜索技术：元搜索功能一般由可三个子功能组成，即数据源连接、自动信息抽取、个性化与多样化.数据源连接通过分析数据源的查询接口，实现查询请求的自动提交.自动信息抽取对数据源的返回结果以不同的数据粒度提取其中包含的有效数据.个性化与多样化提供了用户对数据源的个性化选择并且借助多种类型的数据源为用户带来了多样化的数据结果.数据空间：数据空间是由各种数据及其关联共同组成的一个数据集合.与数据集成相比，数据空间更关注于数据间的相关性，即"先有数据，后有模式"，其数据关联更加灵活、松散、滞后.灵活体现在中间模式和模式映射不再固定不变数据空间功能主要由四个子功能共同构成，包括数据关联、数据建模、PAYGO数据查询以及索引技术.其中数据关联是发现Web数据、数据模式间存在的各种关联；数据建模将设计合适的数据模型使其有能力依据数据空间的原则描述Web数据及其各种联系;PAYGO数据查询则利用这种自增的数据关联在数据模型中进行自增的数据查询；索引技术根据PAYGO的查询模式，预先建立索引提高查询效率。跨媒体搜索：跨媒体检索功能通常由四个子功能构成：语义关联、语义建模、跨媒体检索以及索引技术.语义关联从多个层面发现媒体间语义上的相关性；借助语义建模描述媒体间语义距离；根据用户提交的检索对象，计算数据空间中数据与检索对象间的语义相似度，进行跨媒体检索；使用索引技术降低跨媒体检索计算的时空开销，提高检索效率。8、 TwitterStorm，Yahoo!S4及RTMR(实时MapReduce)三个实时流处理方式的主要实现技术及性能分析答：1、TwitterStorm：主要实现技术：在Storm中也有对于流stream的抽象，流是一个不问断的无界的连续tuple,注意Storm在建模事件流时，把流中的事件抽象为tuple即元组。Storm认为每个stream都有一个stream源，也就是原始元组的源头，所以它将这个源头抽象为spout，spout可能是连接twitterapi并不断发出tweets，也可能是从某个队列中不断读取队列元素并装配为tuple发射。有了源头即spout也就是有了stream，那么该如何处理stream内的tuple呢，同样的思想twitter将流的中间状态转换抽象为Bolt，bolt可以消费任意数量的输入流，只要将流方向导向该bolt，同时它也可以发送新的流给其他bolt使用，这样一来，只要打开特定的spout（管口）再将spout中流出的tuple导向特定的bolt，又bolt对导入的流做处理后再导向其他bolt或者目的地。性能：1） 使用场景广泛：storm可以用来处理消息和更新数据库（消息流处理），对一个数据量进行持续的查询并返回客户端（持续计算），对一个耗资源的查询作实时并行化的处理（分布式方法调用），storm的这些基础原语可以满足大量的场景。2） 可伸缩性高：：Storm的可伸缩性可以让storm每秒可以处理的消息量达到很高3） 保证无数据丢失；实时系统必须保证所有的数据被成功的处理。那些会丢失数据的系统的适用场景非常窄，而storm保证每一条消息都会被处理，这一点和s4相比有巨大的反差。4） 异常健壮：storm集群非常容易管理。5） 容错性好：如果在消息处理过程中出了一些异常，storm会重新安排这个出问题的处理逻辑。storm保证一个处理逻辑永远运行，除非你显式杀掉这个处理逻辑。6） 语音无关性：健壮性和可伸缩性不应该局限于一个平台。Storm的topology和消息处理组件可以用任何语言来定义，这一点使得任何人都可以使用storm。2、Yahoo！S4：主要实现技术：1） 为了能在普通机型构成的集群上进行分布式处理，并且集群内部不使用共享内存，S4架构采用了Actor模式，这种模式提供了封装和地址透明语义，因此在允许应用大规模并发的同时，也提供了简单的编程接口。S4系统通过处理单元（ProcessingElements，PEs）进行计算，消息在处理单元间以数据事件的形式传送，PE消费事件，发出一个或多个可能被其他PE处理的事件，或者直接发布结果。每个PE的状态对于其他PE不可见，PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。2） 除了遵循Actor模式，S4也参照了MapReduce模式。为了简化部署和运维，从而达到更好地稳定性和扩展性，S4采用了对等架构，集群中的所有处理节点都是等同的，没有中心控制。这种架构将使得集群的扩展性很好，处理节点的总数理论上无上限；同时，S4将没有单点容错的问题。3） S4系统使用Java开发，采用了极富层次的模块化编程，每个通用功能点都尽量抽象出来作为通用模块，而且尽可能让各模块实现可定制化。4） 基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储，否则节点故障时，节点上处理事件的状态会丢失。5） 节点间通信采用“PlainOldJavaObjeCPOJOs）模式，应用开发者不需要写Schemas或用哈希表来在节点间发送Tupleso性能：S4是面向流式数据和实时处理的，所以针对实时性较高的业务，可以很好地对数据做出高效的分析处理，而且系统一旦上线，很少需要人工干预，源源不断的数据流会被自动路由并分析。对于海量数据，它和MapReduce类似都可以应对，但它能比后者更快地处理数据。S4目前的缺点在于它的数据传输可靠性还不够，可能丢失数据，同时由于数据存放在内存中，一旦节点出现故障，就会丢失该节点的所有数据，这一点可以通过定期持久化来弥补（但是真的有必要吗？】同时我认为这和它面向的场景也有关系，实时数据分析通常都是针对一些非常离散、细小的数据，从统计的角度来看，损失掉一部分数据对最后的统计结果并没有很大影响，而这部分牺牲却可以换来吞吐率的大幅提升。所以就目前来看，S4还是更适合对那些不一定非得对每条数据都仔细分析的场景，只求最后一个统计的结果来对业务做出相应的预计和调整。此外S4系统要求输入的是事件流，这就涉及到事件的生成，所以在数据流入S4以前，必须有能将数据转化为事件的系统进行中间处理。从集群的扩展性来看，理论上可以通过增加节点应对更大的数据流，但是目前还无法在S4工作时动态增加或减少节点。所以对节点进行调整时很可能必须停下当前的工作，做不到无缝调整。而且由于S4由ZooKeeper进行集群管理，所以当集群增加到一定规模时，ZooKeeper的管理能力也有待考验。此外，仍然是因为S4无法保证数据100%的可靠传输，所以集群规模增长时，数据错误也会增长得很快。目前没有相关资料显示S4集群的规模究竟可以做到多大，但是相信未来随着数据传输可靠性的提升，会发挥很可观的作用。在业务耦合度方面，S4完全隔离了平台和业务逻辑，业务方只需要编写PE逻辑即可，这一点类似于MapReduce中只需编写map和reduce函数，业务和平台的耦合度是非常低的。3、RTMR：主要技术：MapReduce本身源自于函数式语言，主要通过Map（映射）和Reduce（化简）这两个步骤来并行处理大规模的数据集。首先，Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作，且原始列表不会被更改，会创建多个新的列表来保存Map的处理结果。也就意味着，Map操作是高度并行的。当Map工作完成之后，系统会接着对新生成的多个列表进行清理（Shuffle）和排序，之后，会这些新创建的列表进行Reduce操作，也就是对一个列表中的元素根据Key值进行适当的合并。性能：谈到MapReduce的优点，主要有两个方面：其一，通过MapReduce这个分布式处理框架，不仅能用于处理大规模数据，而且能将很多繁琐的细节隐藏起来，比如，自动并行化、负载均衡和灾备管理等，这样将极大地简化程序员的开发工作;其二，MapReduce的伸缩性非常好，也就是说，每增加一台服务器，其就能将差不多的计算能力接入到集群中，而过去的大多数分布式处理框架，在伸缩性方面都与MapReduce相差甚远。而MapReduce最大的不足则在于，其不适应实时应用的需求，所以在Google最新的实时性很强的Caffeine搜索引擎中，MapReduce的主导地位巳经被可用于实时处理Percolator系统所代替。9、 要实现知识（智能数据）管理需要在传统数据管理基础上扩展哪些功能？答：知识管理就是对组织的各种来源的知识内容进行处理，实现知识的生产、共享、应用以及创新，从而产生价值并形成知识优势。基于语义网的知识管理基本框架在该体系结构中，本体知识库是最核心的部分，它是实现知识的共享、重用（知识的访问）和对组织知识进行维护的基础。因此，构建基于本体的知识库将成为整个知识管理活动中最关键的任务。通常有两种途径来构建组织的本体知识库［6］：一是运用本体描述语言对来自组织内、外部的基于元数据的知识进行表示，然后存储在本体知识库中，一般通过这种途径来扩大组织本体知识库的容量；二是知识工作者直接通过本体编辑器实现对本体知识库的修改，该途径一般涉及到智能推理和维护等高级活动。一旦构建好了本体知识库，就可实现语义层上的知识访问。10、 普适数