内存数据管理（第2版）：可取性、适用性、可行性：内存计算技术的影响
软件和硬件架构，最终降低总成本。
实时信息：随时随地获取任何信息
当今的Web搜索引擎向我们展现了实时分析大量数据的巨大潜能。用户输入查询问题，即可获得搜索结果。在这一方面，企业级应用力求达到相同的效果，但事实上几乎未能实现。例如，呼叫中心代理或经理需要在公司所有数据源内查找一些特定片段的信息，希望围绕客户制定更明智的产品计划，或者规划未来发展战略。与能够即时查询结果的Web 搜索相比，企业级应用的运行速度较慢，用户会感到响应时间过长。毫无疑问，如果业务环境中的信息访问速度就像在Web 搜索引擎环境下一样快速，那么业务用户的行为必定会改变。
Web 搜索和企业级应用的主要区别在于预期结果的完整性。在Web搜索中，尽管所有相关数据都会被扫描并在搜索结果中显示，但只有匹配度最高的那些搜索结果才是用户关注的。Web 搜索查询一组数据的索引，评估相关性并提取结果。相比之下，企业级应用必须执行其他数据处理，比如复杂的聚集。在许多应用场景（如分析或计划）中，数据必须在呈现给用户之前就已经准备妥当，特别是当数据来自于不同的源系统时。
为了分析企业数据，并且达到合适的查询响应时间，目前运营系统和分析系统是分开的。分析系统的数据预处理只能作用于整个企业数据集的一部分，这会限制相关报告的数据粒度。根据具体的准备步骤（例如：数据清理、格式设置或计算等），从数据进入运营系统到最终得到报告需要几个小时甚至数天。当应用程序需要同时进行运营处理和分析时，这种延迟将对性能产生严重影响。例如，第 2 章中介绍的可承诺量（ATP）、需求计划和催款应用程序需要同时进行运营处理和分析。在运营处理方面，它们必须在最新的数据上运行，并执行读写操作。在分析处理方面，它们需要处理大量数据，因为近期数据和历史数据都是分析所必须的。这些应用程序都将受益于交互式的假设情景分析能力。但目前市场上还没有一个系统能既支持亚秒级的响应时间，又灵活访问系统中的任意信息。
图中展示了信息“唾手可得”的场景。“信息唾手可得”，是比尔·盖茨1994 年提出的一个术语，他展望在未来可从任何位置提取任意数据 [58]。该图表明，在不同的地点，与会者都可实时浏览、查询并操作相同的信息。信息交换的时间会大为缩短，同时还能随时响应用户的即席查询。
现在，我们一起来深入探讨亚秒级响应时间、实时分析和快速计算等主题。这些主题对实现上述情景至关重要。
未来的管理层会议
思想速度般的响应
在Web搜索中，用户使用关键词搜索来查询数据。关键词的含义可能含糊不清，因此用户需要根据所获得的结果重新定义搜索词。只有亚秒级的响应时间才会支持这种反复试验的行为。如果企业分析中也能够实现亚秒级响应时间，则用户也能使用相同的方法查询业务数据。准备数据和创建新报告的速度会很快，因此用户就可以交互式的定义和重定义报告查询条件。
通常观察者对刺激作出简单响应的平均反应时间为220毫秒[101]。其中一部分时间用于发现刺激，其余时间用于作出响应。识别需要的响应时间更长，因为它还需要理解和领悟。识别的平均响应时间为384毫秒。此外，识别响应时间会随着环境复杂程度的增加而增加。在比较复杂的环境中，550 至 750毫秒时间内做出的响应可以被称为“思想速度般的响应”。经过专业培训、重复执行同一动作的用户的反应时间会更短。因此，较慢的系统响应时间对他们来说会显得更加漫长。
系统响应时间超过人反应时间的部分被视为等待时间。此时，用户会转移注意力。这是一个无法用意识控制的过程。等待的时间越长，用户放弃手头任务的可能性就越大。而亚秒级的响应时间有助于确保用户专注于一个主题，而不会转移注意力。任务切换很容易引起疲劳。即便是小任务，用户也必须找回原先的主题，并回忆其后续步骤。如果可以避免这种任务切换，那么用户可以集中注意力，专注于浏览和分析数据。如果用户可以根据历史查询结果自由地建立查询条件，而不因任务切换分心，他就能在更短的时间内挖掘出数据中更深层的信息。
亚秒级的响应时间意味着我们能够以全新的方式（如通过移动设备）使用企业级应用。移动设备用户已无法忍受长达几秒的设备响应时间。如果企业级应用实现亚秒级的响应时间，则移动终端的响应时间（包括传输时间）会在可接受的范围内。这样，经理们便可一边等待航班，一边用手机查看催款结果。然后，他们可以直接呼叫最差的债务人，快速解决问题。而与此相比，传统系统的一次催款操作可能需要几个小时。
实时分析和动态计算
实时分析的基础是，所有资源在调用分析时都已就位 [142]。当前，高效的分析报告依赖于专门的物化数据结构（称为“数据立方体”）。这些数据立方体以固定的数据维度为基础。根据这些维度，分析报告可定义其结果集。因此，一个数据立方体只适用于一组特定的报告。如需要其他维度，则必须创建新的数据立方体，或者扩展现有的数据立方体。在最糟糕的情况下，数据立方体维度的线性增长会导致存储需求的指数级增长。如果扩展数据立方体，会导致已经使用该数据立方体的报告性能会下降。因此，需慎重决定是扩展还是重新构建。无论做出何种决定，在系统的生命周期内可能有大量的数据立方体，从而增加存储需求和维护工作。
业务用户应当能够制定即席报表，而不拘泥于预定义报表。它们应当涉及公司拥有的整个数据集，还有可能涉及外部数据源中的数据。假设拥有一个快速的内存数据库，则无需预先计算好的物化数据结构。只要将数据的变更提交到数据库，这些更改便会在报表中体现。如果报表仍然需要执行数据准备和转换步骤，则这些步骤将在查询过程中完成，所有计算都相当快速。报告期间的高速计算以不存储数据、仅提供报表接口的数据立方体为基础，它不但能解决困扰至今的问题，并能优化所有这类分析报表的性能。
最新硬件趋势的影响
现代硬件的发展一直处于不断变革和创新之中，而其中的最新发展是多核架构以及容量大、价格低的主存 的出现。要跟上这些技术的发展潮流，最大程度地挖掘基础硬件的潜能，必须对现有软件系统（如数据库管理系统）进行调整。本节将介绍数据库管理系统和硬件的最新发展趋势。内存数据管理有助于企业级应用实现真正的实时分析，我们将阐述内存数据管理的关键驱动因素。
企业级应用的数据库管理系统
我们认为，数据库管理系统（DBMS）是一系列支持用户创建和维护数据库[48]的程序的统称。DBMS 是一个促进不同用户和应用之间定义、构建、操作和共享数据库流程的软件系统。它是企业级应用中所有操作的基础.从整体上来说，企业级应用的性能很大程度上取决于 DBMS 的性能。
要实现整合分析系统，支持实时访问企业系统任意数据，关键是提高数据库层的性能。在本节中，我们将介绍与企业级应用最密切相关的数据库概念，阐述数据库层的硬件限制因素如何迫使商务智能（BI）应用程序与事务系统分离。此外，我们还将介绍硬件的最新发展趋势，探究如何通过内存计算提高性能。
无论是在学术领域，还是在商业领域，市场对企业级应用的需求已成为 DBMS 发展的主要动力。事实上，最早的商业 DBMS 之一是由 IBM 公司于 1968 年开发的信息管理系统 (IMS) [119]，当时专门用于美国国家航空航天局的“阿波罗太空计划”的库存管理。IMS 是全球第一款针对特定应用而构建的典型商业数据库系统。 当时，开发复杂软件系统 [19] 意味着DBMS要能为尚未开发的应用程序层提供各种通用功能。很明显，通过创建全新的DBMS，解决每个新企业级应用的需求，是一项耗时且低效的工作。让DBMS支持各种企业级应用，这才是明智的选择。因此其发展已成为学术研究和工业生产领域中的共同目标。
企业级应用和关系模型
早期系统中使用的IMS等层次化数据模型可以很好地处理简单的事务，但涉及对数据库中的数据进行分析时（这是企业级应用的基本要求），这类模型便会暴露出很多缺点。尤其是在整合叶节点中存储的信息时，效率十分低下。在层次较多的大型结构中，这一操作需要占用大量时间。
1970 年，科德（Codd）率先提出了“关系数据模型”的概念，以及以代数算子为基础的一组关系型运算，可以灵活地表示几乎所有实体类型之间的依赖性和关系[27]。科德的模型在学术界迅速获得了认可，但直到 1974 年首次引入“结构化英语查询语言”（SEQUEL）[21] （它支持以相对用户友好的语言编制关系数据的查询公式）时，这种关系模型才得到普遍推广。随后，这种查询语言简称为“结构化查询语言”（SQL）。通过与关系模型结合使用，它可用于各种应用程序。在此模型基础之上建立的系统称为“关系数据库管理系统”（RDBMS）。
后来，随着“事务”概念的引入，RDBMS 的研发迎来了另一重大突破[61]。事务是指具有明确定义的开头和结尾、有固定执行顺序的一组操作。这一概念[73]催生了术语 ACID ，它可用来描述事务的属性。ACID 是原子性(Atomicity)、一致性 (Consistency)、隔离性 (Isolation) 和持久性 (Durability) 的首字母缩写。“原子性”是指将数据库中的一系列不同操作作为单一操作提供给用户，且所有不同操作均应全部执行，或者全部不执行。“一致性”旨在确保数据库在事务开始之前以及结束之后保持一致状态。系统通过隔离来确保并发事务间的一致性，因为这样才能满足以下要求：只有事务本身才能访问其临时数据，除非事务尚未完成。“原子性”、“一致性”和“隔离性”将影响DBMS 处理数据的方式。“持久性”是维持成功交易的保障，使其不受任何系统故障的影响。以上都是企业级应用的必要特性。
RDBMS 支持 ACID 事务，这为存储和检索企业数据提供了一种高效可靠的方式。20世纪 80 年代，基于这类系统的企业级应用可用于处理运营数据（即“联机事务处理”（OLTP）），并执行联机分析处理（OLAP） [170]。在本书的后续章节中，我们将交替使用术语OLTP 和“运营数据处理”以及术语OLAP 和“分析处理”。
事务处理与分析处理的分离
随着数据量的不断增加，RDBMS 无法再高效地满足所有各类企业级应用的需求，特别是DBMS 本身无法及时为整个事务数据库提供即席查询服务。
其中一个原因就是，这种数据库模式设计已成为大多数事务型企业级应用的基础。OLTP 模式高度规范化，旨在最大程度地减少数据输入量，加快插入、更新和删除的速度。但当涉及检索数据时，这种高度规范化就成为一个缺点，因为系统可能需要连接多个表才能找到全部所需信息。创建这些连接并从多个表中读取数据会严重影响性能，因为这需要多次读取磁盘的操作。与此同时，分析查询必须访问数据库中很大一部分数据，因此传统的解决方案运行时间过长。
在这种情况下，OLAP 系统应运而生，旨在解决大型企业即时分析数据的需求。这些系统以专用的数据结构 [170] 为基础，旨在优化读取性能，并快速处理复杂的分析查询。这样一来，数据必须从企业的事务系统传输至分析系统，并针对预定义报表作相应处理。
这种传输以周期性批量的方式执行，反复运行“提取、转换、加载”（ETL）流程 [181] 。所需报表可能包含许多来自不同源系统的数据。这些数据必须抽取并转换为一种适用于转换处理的格式。随后，数据在转换阶段必须遵循相应的规则，才能加载到目标 OLAP 系统中。这些规则分别承担各种不同的功能，例如，删除重复数据、排序和聚集。最后，将转换后的数据加载到一个优化的目标模式中，以便快速生成报表。
整个流程的最大局限性在于，由于分析查询的对象是 OLAP 系统中的数据副本，而OLAP系统中并不包含最新事务，所以无法执行实时分析。
结论
内存计算和多核技术不仅可以提升企业级应用的性能而且还可提升业务价值。在本文中，我们介绍了内存计算技术对企业级应用造成的潜在影响，并阐述为何应当从现在开始这一转变。
在性能提升之后，企业级应用程序可以增加的用户所需的新功能。其中，最主要的是能够直接对事务数据进行分析，而不必另行使用分离的BI系统。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26421423/viewspace-741558/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/26421423/viewspace-741558/