SSAS(Analysis Services )白皮书_中文

SSAS(Analysis Services )白皮书_中文
SSAS(Analysis Services )白皮书_中文

Analysis Services 性能指南

SQL Server 技术文章

撰稿人:Richard Tkachuk 和 Thomas Kejser

参与者和审阅人:

T.K. Anand

Marius Dumitru

Greg Galloway

Siva Harinath

Denny Lee

Edward Melomed

Akshai Mirchandani

Mosha Pasumansky

Carl Rabeler

Elizabeth Vitt

Sedat Yogurtcuoglu

Anne Zorner

发布时间:2008 年 10 月

适用于:SQL Server 2008

摘要:本白皮书介绍了应用程序开发人员如何将查询和处理性能优化方法应用到 SQL Server 2008 Analysis Services OLAP 解决方案。

版权信息

本文档中包含的信息代表 Microsoft Corporation 在发布之日对所讨论问题的观点。由于Microsoft 必须应对不断变化的市场情况,这些信息并不应视为 Microsoft 的承诺,Microsoft 也不能保证任何信息在发布之日后的准确性。

本白皮书仅供参考。 MICROSOFT 对本文档中的信息不做任何明示、暗示或法定的担保。

用户有责任遵守所有适用的版权法/著作权法。在不限制版权法/著作权法管辖的权利的前提下,未经 Microsoft Corporation 的明确书面许可,本文档中的任何部分均不得复制、存储或引入检索系统,或者以任何形式或借助任何手段(电子、机械、影印、录制或其他手段)、出于任何目的进行传播。

Microsoft 可能拥有本文档所涵盖主题的专利、专利申请、商标、版权或其他知识产权。除非Microsoft 提供了明确的书面许可协议,否则提供本文档并不意味着赋予您这些专利、商标、版权或其他知识产权的任何许可。

? 2008 Microsoft Corporation。保留所有权利。

Microsoft、Excel、SQL Server、Visual Basic、Windows 和 Windows Server 是 Microsoft 所属各公司的商标。

所有其他商标归其各自拥有者所有。

目录

1简介 (6)

2了解查询处理器体系结构 (7)

2.1会话管理 (8)

2.2作业体系结构 (8)

2.3查询处理器 (9)

2.3.1查询处理器缓存 (10)

2.3.2查询处理器内核 (12)

2.4数据检索 (16)

3提高查询性能 (17)

3.1设置基准查询速度 (17)

3.2诊断查询性能问题 (19)

3.3优化维度 (21)

3.3.1标识属性关系 (21)

3.3.2高效使用层次结构 (22)

3.4充分发挥聚合的作用 (23)

3.4.1检测聚合命中 (24)

3.4.2如何解释聚合 (25)

3.4.3生成聚合 (25)

3.5使用分区提高查询性能 (28)

3.5.1简介 (28)

3.5.2分区切片 (29)

3.5.3多个分区的聚合注意事项 (29)

3.5.4非重复计数分区设计 (30)

3.5.5分区大小 (30)

3.6优化 MDX (30)

3.6.1诊断问题 (30)

3.6.2计算最佳实践 (31)

3.7缓存准备 (44)

3.8.1增大查询并行度 (45)

3.8.2内存堆类型 (46)

3.8.3阻止长时间运行的查询 (47)

3.8.4网络负载平衡和只读数据库 (47)

4了解和测量处理能力 (48)

4.1处理作业概述 (48)

4.2设置处理基准 (49)

4.2.1性能监视器跟踪 (49)

4.2.2事件探查器跟踪 (50)

4.3确定处理时间所花的地方 (50)

5提高维度处理性能 (51)

5.1了解维度处理体系结构 (51)

5.2维度处理命令 (53)

5.3维度处理优化流程图 (54)

5.4维度处理性能最佳实践 (55)

5.4.1使用 SQL 视图实现针对维度的查询绑定 (55)

5.4.2优化跨多个数据源的属性处理 (55)

5.4.3降低属性开销 (55)

5.4.4高效使用 KeyColumns、ValueColumn 和 NameColumn 属性 (56)

5.4.5删除位图索引 (56)

5.4.6禁用特性层次结构和使用成员属性 (57)

5.5优化关系维度处理查询 (57)

6增强分区处理性能 (58)

6.1了解分区处理体系结构 (58)

6.2分区处理命令 (59)

6.3分区处理优化流程图 (60)

6.4分区处理性能最佳实践s (62)

6.4.1优化数据插入、更新和删除 (62)

6.4.2从事实表中选取有效的数据类型 (63)

6.5.1清除联接 (64)

6.5.2彻底搞清关系分区 (64)

6.5.3彻底搞清关系索引 (65)

6.5.4使用索引 FILLFACTOR = 100 和数据压缩 (66)

6.6消除数据库锁定开销 (67)

6.7优化网络吞吐量 (68)

6.8改进 I/O 子系统 (69)

6.9通过添加更多分区增强并发性 (69)

6.10调整最大连接数 (70)

6.11调整 ThreadPool 和 CoordinatorExecutionMode (70)

6.12调整 BufferMemoryLimit (71)

6.13优化处理索引阶段 (71)

6.13.1避免将临时数据溢出到磁盘 (71)

6.13.2消除 I/O 瓶颈 (72)

6.13.3添加分区以便增加并行度 (72)

6.13.4优化线程和 AggregationMemorySettings (72)

7优化服务器资源 (74)

7.1使用 PreAllocate (74)

7.2禁用网络流量记录器 (75)

7.3监视和调整服务器内存 (75)

8结论 (76)

1 简介

由于 Microsoft? SQL Server? Analysis Services 查询和处理性能优化是涉及面很广的主题,本白皮书

将性能优化方法分为以下三个部分来加以说明。

提高查询性能 - 查询性能直接影响最终用户体验的质量。因此,它是用于评估联机分析处理(OLAP) 实现是否成功的主要标准。 Analysis Services 提供了各种机制来提高查询性能,包括聚合、

缓存和索引数据检索。此外,还可以通过优化您的维度属性、多维数据集以及多维表达式 (MDX)

查询的设计来提高查询性能。

提高处理性能 - 处理是在 Analysis Services 数据库中刷新数据的操作。处理性能越好,用户就能越

快地访问刷新的数据。 Analysis Services 提供可以提高处理性能的各种机制,包括高效的维度设计、高效的聚合、分区和开销小的处理策略(例如,增量刷新、完全刷新与主动缓存)。

优化服务器资源–有几个同时影响查询和处理性能的引擎设置可以进行优化。

2 了解查询处理器体系结构

为了使最终用户能更快地进行查询,Analysis Services 查询体系结构提供几个协同工作的组件以便高效地检索和计算数据。图 1 显示了在查询期间进行的三个主要操作:会话管理、MDX 查询执行和数据检索,还显示了参与每个操作的服务器组件。

图 1 Analysis Services 查询处理器体系结构

2.1 会话管理

客户端应用程序使用 TCP/IP 或 HTTP 上的 XML for Analysis (XMLA) 与 Analysis Services 进行通信。Analysis Services 提供一个 XMLA 侦听器组件,该组件处理 Analysis Services 与它的客户端之间的所有 XMLA 通信。 Analysis Services 会话管理器控制客户端如何连接到 Analysis Services 实例。经过Windows? 操作系统验证且至少可以访问一个数据库的用户可以连接到 Analysis Services。用户连接到 Analysis Services 后,安全管理器基于应用到用户的 Analysis Services 角色组合确定用户权限。根据连接的客户端应用程序体系结构和安全权限,客户端在应用程序启动时创建一个会话,然后对于所有用户请求重用该会话。该会话提供查询处理器执行客户端查询所用的上下文。在被客户端应用程序或服务器关闭前始终存在一个会话。

2.2 作业体系结构

Analysis Services 使用一个集中式作业体系结构来实现查询和处理操作。“作业”是处理或查询工作的通用单位。根据请求的复杂程度,一个作业可以有多个嵌套子作业级别。

例如,在处理操作期间,为您正在处理的对象(如维度)创建一个作业。维度作业然后可以创建处理维度中属性的多个子作业。在查询期间,使用作业从分区检索事实数据和聚合以满足查询请求。例如,如果您有访问多个分区的查询,将为该查询本身生成一个父作业或协调器作业,并为每个分区生成一个或多个子作业。

图 2 作业体系结构

一般来说,只要有足够的处理器资源可以高效处理并发操作以及有足够的内存和磁盘资源,并行

执行多个作业可以提高性能。当前操作可以并行执行的最大作业数(包括处理和查询)由CoordinatorExecutionMode属性决定:

?负值指定每个内核每个操作可以启动的最大并行作业数。

?零值表示没有限制。

?正值指定每台服务器可以启动的绝对并行作业数。

CoordinatorExecutionMode的默认值为 -4,它表示每个内核可以并行启动 4 个作业。此值适用于

大多数服务器环境。如果要增大服务器的并行度,可以通过增大每个处理器的作业数或将此属性

设置为一个绝对值来增大此属性的值。

尽管它可以全局增大可并行执行的作业数,但是CoordinatorExecutionMode并不是影响并行操作

的唯一属性。还必须考虑其他全局设置的影响,如MaxThreads服务器属性,它确定可以并行执

行的最大查询或处理线程数(有关线程设置的详细信息,请参阅提高多用户性能)。此外,在更

细的粒度级别,对于给定的处理操作,可以使用MaxParallel命令指定可并行执行的最大处理任务数。将在接下来的章节中详细讨论这些设置。

2.3 查询处理器

查询处理器执行MDX 查询并生成单元集或行集。本节简要介绍了查询处理器是如何执行查询的。有关优化 MDX 的详细信息,请参阅优化 MDX。

为了检索查询请求的数据,查询处理器生成一个执行计划以生成从多维数据集数据和计算请求的

结果。主要有两种不同类型的查询执行计划,引擎选择哪种计划对性能有重大影响。有关详细信息,请参阅子空间计算。

为了与存储引擎通信,查询处理器使用执行计划将数据请求转换为存储引擎可以理解的一个或多

个子多维数据集请求。子多维数据集是查询、缓存和数据检索的逻辑单元–它是多维数据集数据

的子集,由每个属性层次结构单个级别的一个或多个成员的交叉联接定义。单个级别的一个或多

个成员有时也称为“单粒”或“单粒度”。根据涉及的属性粒度和计算复杂性,可以将一个 MDX 查询

分解为多个子多维数据集请求,例如,将涉及Country 属性层次结构(假定它不是父子层次结构)的每个成员的查询拆分为两个子多维数据集请求:一个请求用于 All 成员,另一个请求用于国家/

地区。

因为查询处理器计算单元的值,因此它使用查询处理器缓存来存储计算结果。使用这个缓存的主

要好处是可以优化计算并支持跨用户的计算结果重用(这些用户具有相同的安全角色)。为了优

化缓存重用,查询处理器管理确定缓存可重用性的级别的三个缓存层:全局、会话和查询。

2.3.1 查询处理器缓存

在执行 MDX 查询期间,查询处理器在查询处理器缓存中存储计算结果。使用这个缓存的主要好

处是可以优化计算并支持跨用户的计算结果重用。我们通过以下示例来说明在执行查询期间查询

处理器如何使用缓存。您有一个名为“利润率”的计算成员。 MDX 查询请求按销售区域划分的利润率时,查询处理器缓存每个销售区域的非 Null 利润率值。为了管理跨用户的缓存结果重用,查询

处理器在缓存中区分不同的上下文。

?查询上下文 - 包含在查询中使用 WITH 关键字创建的所有计算结果。查询上下文根据需要来创建并在查询完成时被终止。因此,不在会话的各个查询间共享查询上下文的缓存。

?会话上下文 - 包含在给定会话中使用 CREATE 语句创建的所有计算结果。在同一会话的各个请求间重用会话上下文的缓存,但是不在各个会话间共享它。

?全局上下文 - 包含在各个用户间共享的所有计算结果。如果会话共享同一安全角色,则可以在各个会话间共享全局上下文的缓存。

根据重用级别将上下文分层。在最顶层,只能在查询中重用查询上下文。在最底层,可以在多个会话和用户间最大限度地重用全局上下文。

图 3 缓存上下文层

在执行期间,每个 MDX 查询必须引用这三个上下文来识别可能影响查询计算的所有计算和安全条件。例如,为了解析包含查询计算成员的查询,查询处理器创建一个查询上下文来解析查询计算

成员,创建一个会话上下文来进行会话计算,创建一个全局上下文来计算 MDX 脚本并检索提交该查询的用户的安全权限。请注意仅在缺少这些上下文时才创建它们。创建后,将尽可能重用它们。

即使这三个上下文查询都引用了,它也只能使用其中一个上下文的缓存。这意味着对于每个查询,查询处理器必须选择要使用哪个缓存。查询处理器根据是否能在更窄的上下文检测到计算,始终

尝试使用适用面更广的缓存。

如果查询处理器遇到在查询时创建的计算,即使查询还引用全局上下文中的计算,它也始终使用

查询上下文,但是具有Aggregate(<集>) 形式的查询计算成员的查询除外,这些查询共享会话缓存。如果没有查询计算但是有会话计算,则查询处理器使用会话缓存。查询处理器基于作用域中存在

的计算选择缓存。此行为与使用 MDX 生成前端工具的用户尤为相关。如果前端工具创建任何会

话计算或查询计算,即使您未专门使用会话或查询计算,也不使用全局缓存。

还有其他影响查询处理器如何缓存计算的计算情形。当您从 MDX 计算调用存储过程时,引擎始

终使用查询缓存。这是因为存储过程是不确定的(即无法保证存储过程将返回的内容)。因此,没有要全局缓存的内容或需要存储在会话缓存中的内容。计算将存储在查询缓存中。此外,以下因素也影响查询处理器如何缓存计算结果:

?使用单元安全性。MDX 脚本、维度或单元安全定义中的任意UserName、StToSet或LookupCube函数将禁用全局缓存(这意味着只要有一个表达式使用了这些函数,整个多

维数据集就将禁用全局缓存)。

?如果通过将 Analysis Services 连接字符串中的默认“MDX 可视模式”属性设置为 1 来为会话启用可视合计,则查询处理器为该会话中发出的所有查询使用查询缓存。

?如果通过使用MDX VisualTotals函数来为查询启用可视合计,则查询处理器使用查询缓存。

?对于使用嵌套 select 语法 (SELECT FROM SELECT) 或基于会话子多维数据集 (CREATE SUBCUBE) 的查询,将相应使用查询或会话缓存。

?如果在嵌套 select、WHERE 子句或计算成员中使用任意形状,则这些形状只能使用查询缓存。任意形状为一种集,这些集无法表示为同一属性层次结构级别的成员的交叉联接。

例如,{(Food, USA), (Drink, Canada)} 就是任意集,{https://www.360docs.net/doc/311689749.html,A,

customer.geography.[British Columbia]} 也是。请注意,查询轴上的任意形状不限制任何缓

存的使用。

基于此行为,当跨用户重用数据有利于减小查询工作负荷时,最好在全局作用域定义计算。例如,在具有少量安全角色时结构化报表工作负荷就属于这种情况。相反,如果您有要求单独提供每个

用户的数据集的工作负荷(例如,在 HR 多维数据集中,此时您有很多安全角色或在使用动态安

全设置),跨用户重用计算结果的可能性就很小或基本没有。这样,重用查询处理器缓存并不能

显著提高性能。

不缓存部分表达式(即可以在表达式中多次使用的某个计算片段)和单元属性。在首次计算时请

考虑创建单独的计算成员来允许查询处理器缓存结果,以在后续引用中重用这些结果。有关详细

信息,请参阅缓存部分表达式和单元属性。

2.3.2 查询处理器内核

在 SQL Server 2008 Analysis Services 中对查询处理器内核进行了几处更改。在本节中,在介绍特定的优化方法前先讨论一下这些更改。

2.3.2.1 子空间计算

为了了解子空间计算的核心概念,我们将它与自然计算或逐个单元计算进行比较。以一个普通的计算 RollingSum 和一个查询为例,RollingSum 对上一年度和本年度的销售额求和,查询则请求获取所有产品 2005 年的 RollingSum。

RollingSum = (Year.PrevMember, Sales) + Sales

SELECT 2005 on columns, Product.Members on rows WHERE RollingSum

然后对此计算应用逐个单元计算,如图 4 中所示:

图 4 逐个单元计算

将依次计算 [2005, All Products] 的 10 个单元。对于每个单元,我们将导航到上一年度,获取销售值并将其加到本年度的销售额中。使用此方法存在两个严重的性能问题。

首先,如果数据是“稀疏的”(即稀疏填充),则即使将单元限制为返回 Null 值也要计算它们。在上面的示例中,计算产品 3 和产品 6 之外的产品单元都没有必要。这样的计算对性能影响很大,在稀疏填充的多维数据集中,计算的单元数可能相差几个数量级。

其次,即使数据总体上是“稠密的”,这意味着每个单元具有值,不存在访问空单元的问题,但是仍存在重复操作的问题。对于每个产品重复执行了相同的操作(例如,获取上一年度成员、设置上一年度单元的新上下文以及检查递归)。如果在计算每个单元的内部循环中剔除这些操作,将可以提高效率。

现在考虑将子空间计算应用于同一示例。首先,我们根据执行树确定需要填充的空间。给定查询后,我们需要计算空间

[Product.*, 2005, RollingSum]

(其中 * 表示属性层次结构的每个成员)。给定计算后,我们必须首先计算空间

[Product.*, 2004, Sales]

接着计算空间

[Product.*, 2005, Sales]

然后将 + 运算符应用到这两个空间。

如果计算涵盖 Sales 本身,将确定计算 Sales 所需的空间并且展开执行树。在这种情况下 Sales 是基本度量值,因此我们只需要获取存储引擎数据来填充叶上的两个空间,然后沿着树向上执行,应用该运算符以填充根部的空间。因此检索了一行 (Product3, 2004, 3) 和两行 { (Product3, 2005, 20), (Product6, 2005, 5)},并将 + 运算符应用到它们以生成图 5 中的结果。

图 5 执行计划

+ 运算符对“空间”执行运算而不是仅对“标量”值执行运算。它负责合并两个给定的空间来生成一

个空间,该空间包含在具有加和值的空间中显示的每个产品。这就是“查询执行计划”。请注意我

们只对可能影响结果的数据进行运算。不存在我们必须在其中执行计算的理论空间的概念。

查询执行计划不是子空间计算也不是逐个单元计算,但是可以包含子空间和逐个单元节点。一些

函数在子空间模式下不受支持,引擎会回退到逐个单元模式。甚至在逐个单元模式下计算表达式时,引擎也可以返回到子空间模式。

2.3.2.2 开销大与开销小的查询计划

生成查询计划的开销可能很大。事实上,生成执行计划的开销可能超过执行查询的开销。Analysis Services 引擎有一个粗略的分类方案:开销大与开销小。如果使用逐个单元模式或必须读

取多维数据集来生成计划,则认为该计划“开销大”;否则认为执行计划“开销小”。

在几种情况下在查询计划中使用多维数据集数据。由于有 MDX 函数(如PrevMember和Parent),一些查询计划导致将一个成员映射到另一个成员。在构建查询计划期间,从多维数据

集数据和具体化数据生成这些映射。如果IIf、CASE 和 IF 函数需要读取多维数据集数据来对多维

数据集空间进行分区以便计算某个分支,则这些函数也可能生成开销大的查询计划。有关详细信息,请参阅SQL Server 2008 Analysis Services 中的 IIf 函数。

2.3.2.3 表达式稀疏度

表达式的“稀疏度”是指具有非 Null 值的单元数占总单元数的比例。如果非 Null 值相对很少,则表

达式为稀疏的;如果很多,则表达式为稠密的。在后面的章节中我们将看到,表达式是稀疏的还是稠密的可以影响查询计划。

但是您如何知道表达式是稀疏的还是稠密的呢?以一个简单的非计算度量值为例–它是稀疏的还

是稠密的呢?在 OLAP 中,基本事实度量值都是稀疏的。这意味着典型度量值不是对于每个属性

成员都具有值。例如,客户在大多数时间里不购买大多数商店的大多数产品。实际上也如此。

一个典型客户在几天内从少数商店购买少量的产品。对于以下常用表达式有其他一些简单的规则。

2.3.2.4 默认值

每个表达式都具有默认值,即表达式大多数情况下采用的值。查询处理器计算表达式的默认值并在它的大多数空间重用。大多数情况下默认值为 Null(Microsoft Excel? 电子表格软件中为空白或空),因为具有 Null 输入值的表达式结果通常(不总是)为 Null。引擎然后可以计算一次 Null 结果并只需要为大大简化后的非 Null 空间计算值。

使用默认值的另一个重要地方是IIf函数的条件中。了解经常计算哪个分支将驱动执行计划。下表列出一些常用表达式的默认值:

2.3.2.5 可变属性

单元值主要依赖于属性坐标。但是一些计算不依赖于每个属性。例如,表达式

[Customer].[Customer Geography].properties("Postal Code")

只依赖于客户维度中的 Customer 属性。当在涉及其他属性的子空间中计算此表达式时,可以去掉表达式不依赖的所有属性,表达式解析并投影回原始子空间。表达式依赖的属性称为其可变属性。例如,请看以下查询:

with member measures.Zip as

[Customer].[Customer Geography].currentmember.properties("Postal Code")

select measures.zip on 0,

[Product].[Category].members on 1

from [Adventure Works]

where [Customer].[Customer Geography].[Customer].&[25818]

表达式依赖于 customer 属性而非 category 属性,因此 customer 是可变属性而 category 不是。在这种情况下,表达式只需要对客户计算一次,而不像产品类别那样要计算多次。

2.3.2.6 查询处理器内部概念

查询计划、表达式稀疏度、默认值和可变属性是影响查询处理器行为的核心内部概念,我们在讨论优化查询性能时也将围绕这些概念进行讨论。

2.4 数据检索

查询多维数据集时,查询处理器将查询分解为存储引擎的子多维数据集请求。 对于每个子多维数据集请求,存储引擎首先尝试从存储引擎缓存中检索数据。 如果存储中没有数据可用,则它尝试从聚合中检索数据。 如果不存在聚合,它必须从度量值组的分区中检索事实数据。

每个分区被分为称作段的几组 64K 记录。

为每个子多维数据集请求创建协调器作业。 它创建与分区数相同的作业数。 (查询请求获取分区切片中的数据时就是这样的。 有关详细信息,请参阅分区切片)。 每个作业:

? 将用于下一数据段的作业放入队列(如果当前段不是最后一个段)。

? 使用位图索引确定段中是否有数据与子多维数据集请求对应。

? 如果有这样的数据,则扫描该段。

对于单个分区,每个段作业排好队后,作业结构类似于下图:

一个段作业进入队列后,系统立即开始对其他段作业进行排队,作业数与段数相同。 如果索引表明段中不包含与子多维数据集对应的数据,则作业结束。

6 描作业结构

图分区扫

3 提高查询性能

为了提高查询性能,开发人员必须首先了解当前情况、找出瓶颈,然后采用某种方法,包括优化维度设计、设计和生成聚合、进行分区以及采用最佳实践。

很多时间可能浪费在做无用功上,因此首先要了解问题的性质,之后再应用相应的方法。

3.1 设置基准查询速度

在开始优化前,您需要一个可重现的基准。在以下情况下测量速度:一个“冷”(即未填充的)存储引擎和查询处理器缓存以及一个“热”操作系统缓存。为此,通过执行不返回和缓存任何内容的查询来执行该查询,清空公式和存储引擎缓存,然后初始化 calc 脚本,如下所示:

select {} on 0 from [Adventure Works]

第二次执行该查询。第二次执行该查询时,使用 SQL Server Profiler 进行跟踪,并启用其他事件:

?Query Processing\Query Subcube Verbose

?Query Processing\Get Data From Aggregation

该跟踪包含重要信息。

图 6 示例跟踪

“query subcube verbose”事件的文本需要进行解释。它包含每个维度中每个属性的信息:

?0:指示属性不包含在查询中(命中 All 成员)。

?*:指示已请求属性的每个成员。

?+:指示已请求属性的两个或更多成员。

?<整数值>:指示已命中属性的单个成员。该整数表示成员的数据 ID(引擎生成的内部标识符)。

保存跟踪–它包含重要的计时信息,并指示后面所述的事件。

要清空存储和查询处理器缓存,请使用 ClearCache 命令。

Adventure Works DW

操作系统文件缓存受硬件上其他所有因素的影响,因此请尽量减少或消除其他活动。如果多维数据集存储在其他应用程序使用的存储区域网络 (SAN) 中,这可能特别困难。

SQL Server Management Studio 显示查询时间,但是要注意,此时间是检索和显示单元集所需的时间。对于大型结果,呈现单元集的时间可能超过服务器生成它的时间。 SQL Server Profiler 跟踪不仅提供时间花在哪些地方的详情,还提供精确的引擎持续时间。

3.2 诊断查询性能问题

如果性能不像您预期的那样高,原因可能有很多。图 8 说明如何找到问题所在。

图 7 查询性能优化流程图

第一步是确定问题是否是查询处理器或存储引擎造成的。要确定引擎扫描数据所花的时间,请使

图 8 确定扫描分区所花的时间

用 SQL Server Profiler 创建跟踪。通过只选择“query subcube verbose”事件并筛选事件子类为 22 的事件,将事件限制为非缓存的存储引擎检索。结果将类似于图 9。

如果大多数时间花在具有长时间运行的查询子多维数据集事件的存储引擎中,则问题很可能与存储引擎有关。请考虑优化维度设计、设计聚合或使用分区来提高查询性能。如果大多数时间未花在存储引擎而是花在查询处理器中,请主要优化 MDX。

问题可能同时涉及公式和存储引擎。可以使用生成很多查询子多维数据集事件的事件探查器来识别含有碎片的查询空间。每个请求所花的时间可能不长,但是这些时间相加后会很长。如果是这样,请考虑填充缓存以减少可能造成的 I/O 抖动。

一些多用户性能问题可以通过优化单用户查询来解决,但是这不总是有效。在提高多用户性能一节中介绍了一些针对多用户环境的配置设置。

如果优化多维数据集,则可以优化 CPU 和内存资源使用率。在增大查询并行度一节中介绍了如何增大单用户和多用户方案的线程数。同一方法可以用于预留内存来提高查询和处理性能,请参阅与处理有关的使用预分配一节。

通过扩展 CPU、内存或 I/O 一般可以提高性能。这类建议已超过本文档讨论的范围。对于群集或只读数据库,还有其他方法可以扩展。我们将在后面的章节中简要介绍,以确定这样的方法是否可行。

监视内存使用情况将在单独的一节监视和调整服务器内存中介绍。

【中文版】以太坊白皮书

【中文版】以太坊白皮书 翻译:少平、Seven 当中本聪在2009 年1 月启动比特币区块链时,他同时向世界引入了两种未经测试的革命性的新概念。第一种就是比特币(bitcoin),一种去中心化的点对点的网上货币,在没有任何资产担保、内在价值或者中心发行者的情况下维持着价值。到目前为止,比特币已经吸引了大量的公众注意力,就政治方面而言它是一种没有中央银行的货币并且有着剧烈 的价格波动。然而,中本聪的伟大试验还有与比特币同等重要的一部分:基于工作量证明的区块链概念使得人们可以就交易顺序达成共识。作为应用的比特币可以被描述为一个先申请(first-to-file)系统:如果某人有50BTC 并且同时向A 和B 发送这50BTC,只有被首先被确认的交易才会生效。没有固有方法可以决定两笔交易哪一笔先到,这个问题阻碍了去中心化数字货币的发展许多年。中本聪的区块链是第一个可靠的去中心化解决办法。现在,开发者们的注意力开始迅速地转向比特币技术的第二部分,区块链怎样应用于货币以外的领域。 常被提及的应用包括使用链上数字资产来代表定制货币和

金融工具(彩色币),某种基础物理设备的所有权(智能资产),如域名一样的没有可替代性的资产(域名币)以及如去中心化交易所,金融衍生品,点到点赌博和链上身份和信誉系统等更高级的应用。另一个常被问询的重要领域是“智能合约”- 根据事先任意制订的规则来自动转移数字资产的 系统。例如,一个人可能有一个存储合约,形式为“A 可以每天最多提现X 个币,B 每天最多Y 个,A 和B 一起可以随意提取,A 可以停掉B 的提现权”。这种合约的符合逻辑的扩展就是去中心化自治组织(DAOs)- 长期的包含一个组织的资产并把组织的规则编码的智能合约。以太坊的目标就是提供一个带有内置的成熟的图灵完备语言的区块链,用这种语言可以创建合约来编码任意状态转换功能,用户只要简单地用几行代码来实现逻辑,就能够创建以上提及的所有系统以及许多我们还想象不到的的其它系统。 总之,我们相信这样的设计是迈向“加密货币2.0”的坚实一步;我们希望以太坊的出现之于加密货币生态系统的标志性意义,正如1995 年前后Web2.0 之于互联网。 历史 去中心化的数字货币概念,正如财产登记这样的替代应用一样,早在几十年以前就被提出来了。1980 和1990 年代的匿名电子现金协议,大部分是以乔姆盲签技术(Chaumian blinding)为基础的。这些电子现金协议提供具有高度隐私性

中文版白皮书H.264MPEG4 Part 10 White Paper

H.264概览 1. 引言 数字电视和DVD-video的出现使得广播电视和家庭娱乐发生了彻底的变革.越来越多的这些应用成为可能随着视频压缩技术的标准化.MPGE系列的下一个标准,MPEG4,正使得新一代的基于因特网的视频应用成为可能.而现在视频压缩的ITU-T H.263标准被广泛的应用于视频会议系统. MPEG4(视频)和H.263都是基于视频压缩(视频编码)技术的标准(大约从1995年开始).运动图像专家组和视频编码专家组(MPEG和VCEG)致力于开发一个比MPEG4和H.263有更好性能的新标准,有着高品质,低比特视频流的特性一个更好的视频图像压缩方法.新标准"高级视频编码"(A VC)的历史可追溯到7年前. 1995年,为了通过电话线传输视频信号而制定的H.263标准定稿以后.ITU-T视频编码专家组(VCEG)就开始工作在两个更深入的发展领域:一个是"短期"的努力去增加H.263的额外特性(制定出标准的版本2),还有一个"长期"的努力,去开发一个适用于低比低率下可视通信的新标准,提供比之前的ITU-T标准更有效,明显更好的视频压缩方法.2001年,ISO运动图像专家组(MPEG)意识到H.26L的潜在优点,就组成了视频联合工作组(JVT),包括MPEG和VCEG的的专家.JVT的主要任务就是将H.26L"模式"草案发展成为一个完全的国际标准.实际上,结果产生了两个标准:ISO MPEG4第10部分和ITU-T H.264. 新标准的官方命名是"高级视频编码"(A VC);然而,旧的命名H.26L和以ITU文档号命名的IH.264[1]更广为人知. 2. H.264 编解码器 和之前的标准一样(如MPEG1,MPEG2和MPEG4),H.264标准草案并没有明确定义一个编解码器.在一定程度上,标准定义了视频比特流编码和与之相对应的解码方法的语法.然而实际上,一个符合的编码和解码器一般包括如图Figure 2-1 和Figure 2-2中所示的功能模块.同时这些图中所示功能通常是必须的,但编解码器还是可以有相当多的变种.基本的功能模块(预测,传输,量化,熵编码)与之前的标准(MPEG1,MPEG2,MPEG4,H.261,H.263)差不多.H.264的最重要的变化是在这些功能模块的实现细节上. 编码器包括两个数据流路径.一个"前向"路径(从左到右,以蓝色表示)和一个"重构"路径(从右到左,以洋红色表示).解码器的数据流路径以从右到左的方式表示,以此来说明编码器和解码器之间的相同点. 2.1 编码器(前向路径) 当一个输入帧Fn被提交编码。该帧以宏块(相当于16X16像素的原始图像)为单位来进行处理。每个宏块被编码成帧内模式或帧间模式。在这两种情况下,会产生一个基于重建帧的预测宏块P。在帧内模式下,P根据之前已经编码,解码,重建的当前帧n中的采样产生(图中以uF’n表示。注意是未经过滤的采样用来产生P)。在帧间模式下,P根据采用一个或多个参考帧的运动补偿预测来产生。在图中,参考帧表示为之前已经编码的帧F’n-1;然而,每个宏块的预测可能根据过去或将来(以时间为序)的一或多个已经编码并重构的帧来产生。

(白皮书中文版)FIDIC业主咨询工程师标准服务协议书条件

FIDIC业主/咨询工程师标准服务协议书条件 (白皮书) 业主/咨询工程师标准服务协议书(协议书) 业主/咨询工程师标准服务协议书条件(第一部分标准条件) 业主/咨询工程师标准服务协议书条件(第二部分特殊应用条件) 业主/咨询工程师标准服务协议书条件(第二部分附注)

业主/咨询工程师标准服务协议书(协议书) 兹就以下事项达成本协议: 1.本协议书中的措词和用语应与下文提及的“业主/咨询工程师标准服务协议书条件”中分别赋予它们的含义相同。 2.下列文件应被认为是组成本协议书的一部分,并应被作为其一部分进行阅读和理解,即: (1)中标函; (2)业主/咨询工程师标准服务协议书条件(第1部分——标准条件和第2部分——特殊应用条件); (3)附件,即 附件A——服务范围 附件B——业主提供的职员、设备、设施和其他人员的服务 附件C——报酬和支付 3.考虑到下文提及的业主对咨询工程师的支付,咨询工程师在此答应业主遵照本协议书的规定履行服务。 4.业主在此同意按本协议书注明的期限和方式,向咨询工程师支付根据协议书规定应付的款项似此作为履行服务的报酬。 本协议书谨于前文所载明之年月日,由立约双方根据其有关的法律签署并开始执行。 特此证明。

业主/咨询工程师标准服务协议书条件(第一部分标准条件) 定义及解释 1.定义 下列名词和用语,除上下文另有要求者外,应具有所赋予它们的涵义: (1)“项目”是指第二部分中指定的并为之建造工程的项目。 (2)“服务”是指咨询工程师根据协议书所履行的服务,含正常的服务、附加的服务和额外的服务。 (3)“工程”是指为完成项目所实施的永久工程(包括提供给业主的物品和设备)。 (4)“业主”是指本协议书所指的雇用咨询工程师的一方以及业主的合法继承人和允许的受让人。 (5)“咨询工程师”是指本协议书中所指的,作为一个独立的专业公司接受业主雇用履行服务的一方以及咨询工程师的合法继承人和允许的受让人。 (6)“一方”和“各方”是指业主和咨询工程师。“第三方”是指上下文要求的任何其他当事人或实体。 (7)“协议书”是指包括业主/咨询工程师标准服务协议书第一、二部分的条件以及附件A(服务范围),附件B(业主提供的职员、设备、设施和其他人员的服务),附件C(报酬和支付),中标函和正式协议书(如果已签订),或第二部分中的其他规定。 (8)“日”是指任何一个午夜至下一个午夜间的时间段。 (9)“月”是指根据阳历从一个月份中任何一天开始的一个月的时间段。 (10)“当地货币”(LC)是指项目所在国的货币,“外币”(FC)是指任何其他的货币。 (11)“商定的补偿”是指第二部分中规定的根据协议书应支付的额外款项。 2.解释 (1)本协议书中的标题不应在其解释中使用。 (2)单数包含复数含义,阳性包含阴性含义。视上下文需要而定,反之亦然。 (3)如果协议书中的规定之间产生矛盾,按年月顺序以最后编写的为准。 咨询工程师的义务 3.服务范围 咨询工程师应履行与项目有关的服务。服务的范围在附件A中规定。 4.正常的、附加的和额外的服务 (1)正常的服务是指附件A中所述的那类服务。 (2)附加的服务是指附件A中所述的那类或通过双方的书面协议另外附加于正常服务的那类服务。 (3)额外的服务是指那些既不是正常的也不是附加的,但根据第28条咨询工程师必须履行的那类服务。 5.认真地尽职和行使职权 (1)咨询工程师在根据本协议书履行其义务时,应运用合理的技能、谨慎而勤奋地工作。 (2)当服务包括行使权力或履行授权的职责或当业主与任何第三方签订的合同条款需要时,咨询工程师应: ①根据合同进行工作,如果未在附件A中对该权力和职责的详细规定加以说明,则这些详细规定必须是他可以接受的。 ②在业主和第三方之间公正地证明、决定或行使自己的处理权,如有此授权的话。但不作为仲裁人而是根据自己的职能和判断,作为一名独立的专业人员进行工作。 ③可变更任何第三方的义务,如有此授权的话。但对于可能对费用或质量或时间产生重大影响的任何变更,须从业主处得到事先批准(除非发生任何紧急情况,此时咨询工程师应尽快通知业主)。 6.业主的财产 任何由业主提供或支付费用的供咨询工程师使用的物品都属于业主的财产,并在实际可行时应如此标明。当服务完成或终止时,咨询工程师应将履行服务中未使用的物品的库存清单提交给业主,并按业主的指示移交此类物品。此类移交应被视为附加的服务。 业主的义务 7.资料

SDN白皮书中文版(全)

软件定义网络:网络新规范 内容表 2摘要 3新的网络架构的需求 4当前网络技术的局限性 7引入软件定义网络 8 OpenFlow内部 10基于OpenFlow的软件定义网络的好处 12结论 摘要 传统的网络体系结构已经不适应当今企业、运营商和终端用户的需求。由于行业的广泛努力,开放网络基金会(ONF)带头,软件网络(SDN)正在改变网络架构。在SDN架构中,控制平面和数据平面解耦,网络智能和状态逻辑上集中,底层网络基础设施从应用中抽象出来。因此,企业和运营商获得前所未有的可编程性,自动化和网络控制,使他们能够建立高度可扩展的、灵活的网络,迅速适应不断变化的业务需求。 ONF是一个非营利性的行业协会,引领SDN的发展和规范SDN架构的关键要素如OpenFlow?协议,它支持的网络设备的控制和数据层之间结构通信。OpenFlow是专为SDN 设计的第一标准接口,提供高性能、颗粒流量控制通过多个厂商的网络设备。 基于OpenFlow的SDN目前正在推出各种网络设备和软件,为企业和运营商提供大量的好处,包括: ●集中管理和控制多个供应商的网络设备; ●改进的自动化和管理,通过使用通用的API,从业务流程和配置系统和应用程序中抽象 基本网络细节; ●通过提供新的网络功能和服务,而不需要配置单个设备或等待供应商发布的能力快速创 新; ●可编程性通过运营商、企业,独立软件供应商,和用户(不只是设备制造商)使用常见 的编程环境,为各方提供推动收入和分化的新机会; ●由于网络设备的集中和自动化管理,统一的政策执行,以及较少的配置错误,增加了网 络的可靠性和安全性; ●在会话、用户、设备和应用程序级别上应用全面和广泛的政策的能力实现更细粒度的网 络控制; ●有更好的终端用户体验,作为应用程序利用集中的网络状态信息无缝地适应网络行为满 足用户需求。 SDN是一个动态的、灵活的网络结构,保护现有投资,未来的网络。使用SDN,今天的静态网络可以演变成一个能够快速响应不断变化的业务,最终用户,与市场需求的可扩展的服务交付平台。 一个新的网络体系结构的必要性 移动设备和内容的爆炸,服务器虚拟化,云服务出现的趋势推动了网络产业重新审视传统的网络架构中。许多传统的网络是分层的,以太网交换机以树结构布置。这种设计是有意义的,当客户端-服务器计算是占主导地位,但这样的静态架构是不适合今天的企业数据中心,校园,和运营商的环境的动态计算和存储需求的。一些关键的计算趋势推动了对一个新的网络模式的需要,包括:

STP技术白皮书中文版

STP技术白皮书

目录 1 概述 (2) 1.1 STP技术回顾 (2) 1.1.1 IEEE 802.1D STP (2) 1.1.2 IEEE 802.1w RSTP (3) 1.1.3 PVST+ (4) 1.1.4 IEEE 802.1s MSTP (5) 1.2 华为3COM支持的STP类型 (5) 2 华为3COM STP特性及相关技术 (5) 2.1 RSTP模块到MSTP模块的平滑升级 (5) 2.2 MSTP模块的RSTP模式 (6) 2.3 PATH COST缺省值的计算 (6) 2.4 指定根桥和根桥备份 (8) 2.5 BPDU PROTECTION (9) 2.6 ROOT PROTECTION (9) 2.7 LOOP PROTECTION (10) 2.8 TC PROTECTION (10) 2.9 设置交换机的超时时间因子 (10) 2.10 CONFIGURA TION DIGEST SNOOPING (11) 2.11 NO AGREEMENT CHECK (13) 2.12支持802.1s MSTP标准报文格式 (14) 2.13 BPDU TUNNEL (1) 3 互通情况 (1) 3.1 STP、RSTP和MSTP的互通 (1) 3.2 STP/RSTP/MSTP和PVST+的互通 (2) 3.3 华为3COM MSTP和CISCO MSTP的域内互通 (3) 4 附录 (3) 4.1 RSTP模块缺省配置 (3) 4.2 MSTP模块缺省配置 (4)

1 概述 1.1 STP技术回顾 在二层交换网络中,交换机并不能像路由器那样知道报文可以经过多少次转发,一旦网络存在环路就会造成报文在环路内不断循环和增生,产生广播风暴。在广播风暴的情况下,所有的有效带宽都被广播风暴占用,网络将变得不可用。 在这种环境下STP协议应运而生,STP(Spanning Tree Protocol)是生成树协议的英文缩写。它是一种二层管理协议,它通过有选择性地阻塞网络冗余链路来达到消除网络二层环路的目的,同时具备链路的备份功能。 STP协议和其他协议一样,是随着网络的不断发展而不断更新换代的。在STP的发展过程中,老的缺陷不断被克服,新的特性不断被开发出来。最初被广泛应用的是IEEE 802.1D STP,随后以它为基础产生了IEEE 802.1w RSTP、PVST+、IEEE 802.1s MSTP,下面将分别讨论。 另外,STP包含了两个含义,狭义的STP是指IEEE 802.1D中定义的STP协议,广义的STP是指包括IEEE 802.1D STP以及各种在它基础上经过改进了的生成树协议。 1.1.1 IEEE 80 2.1D STP STP协议的基本思想十分简单。自然界中生长的树是不会出现环路的,如果网络也能够像一棵树一样生长就不会出现环路。于是,STP协议中定义了根桥(Root Bridge)、根端口(Root Port)、指定端口(Designated Port)、路径开销(Path Cost)等概念,目的就在于通过构造一棵树的方法达到裁剪冗余环路的目的,同时实现链路备份和路径最优化。用于构造这棵树的算法称为生成树算法SPA(Spanning Tree Algorithm)。 要实现这些功能,网桥之间必须要进行一些信息的交互,这些信息交互单元就称为配置消息BPDU(Bridge Protocol Data Unit)。STP BPDU是一种二层报文,目的MAC是多播地址01-80-C2-00-00-00,所有支持STP协议的网桥都会接收并处理收到的BPDU报文。该报文的数据区里携带了用于生成树计算的所有有用信息。 STP的工作过程是:首先进行根桥的选举。选举的依据是网桥优先级和网桥MAC地址组合成的桥ID,桥ID最小的网桥将成为网络中的根桥,它的所有端口都连接到下游桥,所以端口角色都成为指定端口。接下来,连接根桥的下游网桥将各自选择一条“最粗壮”的树枝作为到根桥的路径,相应端口的角色就成为根端口。循环这个过程到网络的边缘,指定端口和根端口确定之后一棵树就生成了。生成树经过一段时间(默认值是30秒左右)稳定

Sakai3白皮书(中文版)

Sakai3白皮书 【摘要】此文档陈述了下一代Sakai合作学习环境的目标。试图表达在Sakai社区中的大多数人关于Sakai将去向何方的思想。 介绍:Sakai3的由来 Sakai的重要变化时刻即将来到,正如投资大学和Mellon基金会所预想的那样,目前的系统已经成功的使世界各地的高校在社区资源合作中受益,但从Sakai 成立以来,变化一直不断。越来越熟悉Web2.0的Sakai的终端用户,正要求着一个更加自由并且给予他们更多的控制权的环境。社交网络目前已经得到广泛推广。实践证明利用Sakai进行研究、合作学习和行政合作是极其有价值的。Sakai 可以运用和整合的新的标准和开放资源项目相继出现,新的网络开发模型已经出现,这种模型充分利用了客户端的技术,极大的改善了效率,面向服务的框架已经作为公共机构一项设计和部署的优先选择而出现。最重要的是,传统的课程管理系统和电子学档的角色正迅速的变化,而且,有一个广泛的共识,那就是目前的平台要经历巨大的演变从而达到用户和公共机构的长远需求。 Sakai团队也已经学会很多。逐渐做出的越来越多的适应性调整,已经揭示了用例的范围和复杂程度,而且越来越明确的是,一部分代码将会在众多人的重写中被优化,从而降低维护开销,同时又能保持满足本地化需要的自由度。随着公共机构多年来在更多领域运用Sakai,将“网站”作为Sakai的原则的局限性越来越明显。代码和数据库的运转压力已经被确认到,并且经历了显著的改善。但是,运用目前的架构我们到达了受益递减点。Sakai实施的SOA (Service-Oriented Architecture)在实践中被证实是十分的有价值的,可以将其改进到符合现行标准,并且使它最大化的与像Kuali等新项目相融。最后,校园里的Java开发者的相对弱点使Sakai编程的简单化势在必行,进而将Sakai面向一个更加宽广的开发群体,并增加我们作为一个团队的创新能力。 概括的说,我们的目标不仅仅是Sakai的改善,更不是抄袭Google。我们的目标不简单的是创造另一个更好更便宜的Blackboard新版本。是时候明确这一点了:Sakai应利用已经建立的开放资源集中力量发展专门针对教育的需求。总之,我们应该努力创建一个不同的学术合作系统。我们将选择运用Sakai3的公共机构来运行一个本质上不同的系统。这是我们应该向教育领域提供的善举。并不只是在开放资源和私有资源之间做出选择。 基于以上原因,一个由剑桥,Georgia Tech 、 UC Davis 并且包括Indiana, Michigan, Toronto, Berkeley 和the Sakai基金会率领的公共机构团队,已经开始为下一代Sakai的开发拟定设想与初步技术方案。下一代Sakai将会基于一系列新的Sakai内核,该种内核充分利用开放资源(例如 Jackrabbit 和 Shindig),来使资源开发专注于真正关于学术合作。下一代Sakai将会呈现一个新的、以用户为中心的界面,这种界面使用起来既简单又舒适。而且它将包括新的功能,例如包括当今的用户所期待的社交网络和自由内容创作。 这个核心小组已经有了成绩了。新内核的概貌已经显现。设计工作已经开始了新的用户体验。关于Sakai诸多方面新概念正在被讨论和分析。虽仍存在一些有待从概念和技术上进一步斟酌之处,但是前进的方向却越来越清晰。下文提供

5G总体白皮书2.0 中文版 v1

摘要 5G致力于应对2020后多样化差异化业务的巨大挑战,满足超高速率、超低时延、高速移动、高能效和超高流量与连接数密度等多维能力指标。FuTURE论坛5G 特别兴趣组(SIG)围绕着“柔性、绿色、极速”的5G愿景,以“5+2”技术理念,重新思考5G网络的设计原则: 1)香农理论再思考(Rethink Shannon):为无线通信系统开启绿色之旅 2)蜂窝再思考(Rethink Ring & Young):蜂窝不再(no more cell) 3)信令控制再思考(Rethink signaling & control):让网络更智能 4)天线再思考(Rethink antennas):通过SmarTIle让基站隐形 5)频谱空口再思考(Rethink spectrum & air interface):让无线信号“量体裁衣”,以及 6)前传再思考(Rethinking fronthaul):通过下一代前传接口(NGFI)实现柔性无线接入网(RAN) 7)协议栈再思考(Rethinking the protocol stack):实现差异化接入点灵活配置以及BBU和远端无 线系统功能优化 围绕上述理念,FuTURE论坛5G SIG 在5G网络架构、RAN和空口研发方面的取得了显著进展,本白皮书对相关成果做出总结,特别介绍了用户中心网络(UCN)和软件定义空口(SDAI)两个核心概念。UCN架构有如下四个特征: ?RAN重构:为充分利用多样化的接入技术组合、提升组网效率,传统的蜂窝边界将允许动态重构调整、传统的协议栈以及基带功能将被切分并以最优的方式分布在重构的RAN网络节点和相关子系统上; ?边缘提升:以支持超低的端到终端延迟(低至1ms),高效的数据分流、分发、本地移动性、各种边缘业务(包括RAN上下文开放使能的跨层优化),以及移动边缘云; ?CN-RAN再划分:以支持融合多制式技术、低的端到端延迟(不超过10ms),并充分利用控制转发分离(SDN)和软硬件解耦(NFV)的优点; ?网络切片即服务:支持通过SDN/ NFV实现多个垂直子平台,并能够通过一种更强大的水平平台实现多个垂直子平台的融合;对于有效地满足“互联网+”的挑战和机遇,具有重要意义。 SDN, NFV, C-RAN, NGFI, UDN, Multi-RAT/RIT, D2D和灵活网络切片是UCN核心技术。大数据分析也是UCN动态特性不可缺少的部分。

Filecoin 白皮书 中文版

当今的互联网正处于一股浪潮之中:中心专有式服务正逐渐被去中心式服务所取代;中心式信任方逐渐被可验证式分布计算取代;脆弱的位置寻址逐渐被弹性的内容寻址取代;低效的整体服务逐渐被点对点算法市场取代。比特币、以太坊及其他区块链产品已经证明了去中心化交易分账的有效性。这些公共账本可以处理精密而智能的合同,以加密的方式交易价值数百亿美金的资产。这些系统是开放式互联网最早的实体,去中心化网络的参与者们在没有中心管理或 中心式信任方的情况下,提供了很有用处的支付服务。IPFS通过对全球性点对 点网络所使用的数十亿文件提供服务,证明了去中心化网络中内容寻址的效用。 Filecoin是一个去中心化的存储网络,它可以将云存储转变为算法市场。这个市场运作在一个拥有本地协议记号(也叫做“Filecoin”)的区块链上,在这个市场上,矿工们通过对客户提供存储服务赚取Filecoin。相对地,客户可以使用Filecoin来雇佣矿工存储或分发数据。同比特币相似,Filecoin矿工们会为了追求回报而竞相开采区块,但Filecoin的开采能力与存储积极性正相关,这可以 为客户提供更有效用的服务(而不像比特币,为了维持区块链的一致性而限制其效用)。如此就激励了矿工们尽可能多地积累存储空间并租借给客户。本协议可以将积累起来的资源组织成任何人都可信赖的、有自愈功能的存储网络。这个网络通过复制和分发内容建立自身的鲁棒性,同时还可以自动侦测和修复复制错误。客户可以通过选择复制参数防范不同的风险类型。由于协议在客户方对内容进行了端对端加密,存储空间的提供者无法得到密匙,所以这种云存 储网络可以提供足够的安全性。Filecoin作为IPFS顶端的激励层,可以为任意 数据提供存储架构,在保存去中心化数据、构建和运行分发应用以及执行智能合约的情况下格外有用。 本文包含以下内容: ?介绍Filecoin网络,概述协议并详细介绍几个重要组件。 ?概述去中心化网络(DSN)的方案和特点,然后通过Filecoin构建一个 DSN。 ?基于存储证明方案,介绍一个名为“复制证明”的新方案,该方案可以使任意的复制数据储存在独立的物理空间中。

TEE 白皮书-中文版

TEE 白皮书 The Trusted Execution Environment: Delivering Enhanced Security at a Lower Cost to the Mobile Market 2010年2月 翻译:min.zhao@https://www.360docs.net/doc/311689749.html, W A T C H D A T A

目录 目录 .................................................................................................................................................. 2 概述 .................................................................................................................................................. 3 第一章:移动设备的安全需求. (3) 1.1安全需求的演化 ............................................................................................................... 3 1.2参与者的安全视角............................................................................................................ 5 第二章:TEE 介绍 ........................................................................................................................... 6 第三章:TEE 的位置 ....................................................................................................................... 7 第四章:使用场景 .. (9) 4.1企业应用 ........................................................................................................................... 9 4.2内容管理 ......................................................................................................................... 10 4.3移动支付 ......................................................................................................................... 10 4.4.服务发布 (11) 4.4.1. 服务发布........................................................................................................... 11 4.4.2. 服务管理........................................................................................................... 11 4.4.3. 举例:企业应用的服务发布 (12) 第五章:为什么将TEE 标准化..................................................................................................... 12 第六章:TEE 修订规划 ................................................................................................................. 12 第七章:总结 ................................................................................................................................ 13 附录A :术语与缩写 ..................................................................................................................... 14 附录B :名词定义 ......................................................................................................................... 14 附录C :Rich OS, TEE 和SE 的比较 . (15) W A T C H D A T A

Sakai3白皮书(中文版)

Sakai3白皮书(中文版) 【摘要】此文档陈述了下一代Sakai互助学习环境的方针试图抒发在Sakai社区中的大多数人关于Sakai将去的方向何方的思惟 介绍:Sakai3的由来 Sakai的重要变化时刻即将来到,正如投资大学和Mellon基金会所预想的那样,目前的系统已经成功的使世界各地的高校在社区资源合作中受益,但从Sakai成立以来,变化一直不断。越来越熟悉Web2.0的Sakai的终端用户,正要求着一个更加自由并且给予他们更多的控制权的环境。社交网络目前已经得到广泛推广。实践证明利用Sakai进行研究、合作学习和行政合作是极其有价值的。Sakai可以运用和整合的新的标准和开放资源项目相继出现,新的网络开发模型已经出现,这种模型充分利用了客户端的技术,极大的改善了效率,面向服务的框架已经作为公共机构一项设计和部署的优先选择而出现。最重要的是,传统的课程管理系统和电子学档的角色正迅速的变化,而且,有一个广泛的共识,那就是目前的平台要经历巨大的演变从而达到用户和公共机构的长远需求。 Sakai团队也已经学会很多。逐渐做出的越来越多的适应性调整,已经揭示了用例的范围和复杂程度,而且越来越明确的是,一部分代码将会在众多人的重写中被优化,从而降低维护开销,同时又能保持满足本地化需要的自由度。随着公共机构多年来在更多领域运用Sakai,将“网站”作为Sakai的原则的局限性越来越明显。代码和数据库的运转压力已经被确认到,并且经历了显著的改善。但是,运用目前的架构我们到达了受益递减点。Sakai实施的 SOA(Service-Oriented Architecture)在实践中被证实是十分的有价值的,可以将其改进到符合现行标准,并且使它最大化的与像Kuali等新项目相融。最后,校园里的 Java开发者的相对弱点使Sakai编程的简单化势在必行,进而将Sakai面向一个更加宽广的开发群体,并增加我们作为一个团队的创新能力。 概括的说,我们的目标不仅仅是Sakai的改善,更不是抄袭Google。我们的目标不简单的是创造另一个更好更便宜的Blackboard新版本。是时候明确这一点了: Sakai应利用已经建立的开放资源集中力量发展专门针对教育的需求。总之,我们应该努力创建一个不同的学术合作系统。我们将选择运用Sakai3的公共机构来运行一个本质上不同的系统。这是我们应该向教育领域提供的善举。并不只是在开放资源和私有资源之间做出选择。 基于以上原因,一个由剑桥,Georgia Tech 、 UC Davis 并且包括 Indiana, Michigan, Toronto, Berkeley 和the Sakai基金会率领的公共机构团队,已经开始为下一代 Sakai的开发拟定设想与初步技术方案。下一代Sakai将会基于一系列新的Sakai内核,该种内核充分利用开放资源(例如 Jackrabbit 和 Shindig),来使资源开发专注于真正关于学术合作。下一代Sakai将会呈现一个新的、以用户为中心的界面,这种界面使用起来既简单又舒适。而且它将包括新的功能,例如包括当今的用户所期待的社交网络和自由内容创作。 这个核心小组已经有了成绩了。新内核的概貌已经显现。设计工作已经开始了新的用户体验。关于Sakai诸多方面新概念正在被讨论和分析。虽仍存在一些有待从概念和技术上进一步斟酌之处,但是前进的方向却越来越清晰。下文提供了更多细节,包括:对您的大学的益处,怎样了解更多、如何加入这项努力。

knime白皮书(中文版)

技术报告(Knime: The Konstanz Information Miner) 摘要---knime是一个能用来很简单的虚拟装配和交互执行数据管道的标准的环境 Knime被设计成为一个教学,研究以及合作的平台,在这里你可以很容易的集成新的算法,数据操纵或者是可视化的方法比如一个新的模块或是节点。在这本白皮书我们将介绍有关设计方面的基础构架以及怎样将新节点插入的简单过程。 第一概述 在过去的几年里,人们对标准的数据分析环境的迫切需求已经达到前所未有的程度。 为了充分利用大量不同种类的数据分析方法,这样一个环境是必须的—--能够简单而直观的 使用,允许对分析进行快速和交互式的变换,用户可以可视化的搜索结果。 为了应付这些挑战,数据流水线操作环境是再合适不过一种模型。 它允许用户通过标准的组建模块可视化地组装和修改数据分析流,同时提供一种直观,图示的方法来记载操作日记。 Knime就能提供这样的一个环境。 图1展示的是一个例子的数据分析流截图 在中间,一个数据流正从三个源节点读入同时在多处进行处理,也跟分析流相平行,包括预处理,建模,以及可视化节点。在这种类繁多的节点中,你可以选择数据源,数据处理步骤,模型搭建算法,可视化技术甚至是输入输出模型工具,然后将它拖到工作区,可以让它和其他节点连接起来。让所有操作实现图形交互的能力创建了检索你手中的数据集功能强大的环境Knime是用Java编写的而他的图形作业编辑区是一个类似Eclipse插件程序的工具。 扩充是很容易的,通过打开API和数据抽象框架,把正确定义的新节点快速加入就可以了。在这本白皮书里我们会描述一些有关Knime内核的细节。更多信息你可以登陆网站查询。 第二部分构架 Knime的构架在设计之初就有三个主要的原则: ?可视化,交互式构架:数据流应该通过简单的拖放各种处理单元来组合。标准的应用程序能被设计通过单个的数据管道。 ?模块化:处理单元和数据容器不应该相互依靠,以便分布式计算和不同算法的独立开发的实现更简单。数据类型被封装,也就是说没有数据类型被重定义,新的数据类型能够伴随着

SDN白皮书中文版

解码SDN 在过去的一年中,软件定义网络SDN一直是网络界的讨论重点。但从很多方面来说,网络一直被软件定义着。软件渗透在所有影响我们生活的技术中,而网络也没有什么不同。然而,网络受软件配置、交付和管理方式的限制——从字面上来说,就是需要通过在1980年代微型计算机和DOS时期使用的命令行进行整体更新和管理。 网络软件的挑战 在行业中,网络软件一直是创新的累赘。因为每一个网络设备必须单独配置——通常是手工完成,就是指通过键盘——网络无法跟上现代云系统所需的快速变化。亚马逊或谷歌等互网络公司投入数百名工程师建立自己的云系统,以作为应对网络配置的解决方案。但对于大多数企业来说 建立自己的私有云不是一个合理的方法。随着虚拟化和云计算彻底改变了计算与存储方式,网络已经远远落后。 在服务供应商的环境中,配置和管理自己的网络往往使运营商焦头烂额。就像谷歌,他们也为配置自己的网络建立了运营支持系统,但这些系统就像用了20多年之久,常常因网络软件带来的负担而崩溃。对于服务供应商来说,网络是他们的业务。 为了实现新的业务机会,他们必须向网络供应商推出新的功能。于是,网络软件再一次使网络行业败象毕露——被开发为一个整体式嵌入系统,而不具备应用程序的概念。每一个新功能都需要软件堆栈的整体更新。想象一下,这就像每一次加载新应用都需要更新智能手机上的操作系统。而这就是网络行业强加给其客户的。更糟糕的是,每一次更新往往带有很多其它的变化——这些变化有时候会产生新的问题。因此,在引进到网络之前服务供应商必须认真、彻底地测试每一个更新。 什么是SDN 企业和服务供应商都在寻求应对网络挑战的解决方案。他们希望网络能根据自己的业务政策进行动态的调整和响应。他们希望这些政策能实现自动化,从而减少

币一(交易所)白皮书-中文版

BTCEX全球区块链资产交易平台 -----交易投资挖矿,分红收益永不停息Copyright ? 2017 btcex.one. All rights reserved.

目录 1.背景 (3) 1.1.区块链资产交易平台现状 (3) 1.2.现存区块链资产交易平台存在的问题 (4) 2.交易平台介绍 (5) 2.1精选区块链资产 (5) 2.2用户投票上线资产 (5) 2.3顺应币币兑换新潮流 (5) 2.4提供C2C交易专区 (5) 2.5安全稳定 (5) 2.6流畅的交易体验 (6) 2.7国际化的平台 (6) 2.8丰富多彩的优惠活动吸引更多用户 (6) 2.9创新的盈利模式 (6) 2.10平台贡献者持续奖励 (7) 3.技术架构 (8) 4.平台发展路线图 (9) 5.Token Sale细则 (10) 5.1Token介绍 (10) 5.2Token应用 (10) 5.3BEB的经济价值 (10) 5.4BEB售卖计划 (11) 5.5资金用途 (12) 6.风险提示 (13)

1.背景 1.1. 区块链资产交易平台现状 2009年中本聪提出区块链概念并创造比特币(BTC),开启了区块链世界的大门,2015年以太坊(ETH)横空出世,基于智能合约的区块链应用将区块链生态的演化再次向前推进。随着区块链技术的不断更新,各国政府及企业均注意到了区块链在价值传递、信息传输等领域存在的巨大潜力及价值。日本、澳大利亚等国家相继确?立比特币(BTC)的合法地位;微软、摩根大通等企业巨头成立EEA(企业以太坊联盟),开展基于以太坊的技术研究。区块链行业正在从初始的爆发当中走向成熟,优质区块链资产层出不穷。由此,区块链资产的兑换需求将呈爆发式的增长。据不不完全统计,2016年年1?月区块链资产总市值只有70亿美金,而2017年12?月已上升至4000亿美金,全球区块链资产日交易额也从4000万美金增长至80亿美金,并且仍处于上升趋势。 可以预见,区块链资产投资领域的参与者及参与资金都将持续增长,而好的交易平台又都处于强势地位,大力压榨区块链行业基金,使得好多优势区块链项目不能体现出真实价值,不利于行业发展,因此我们慎重决定,联合俄罗斯,中国几大私人矿场,在日本成立基金会,招揽全球顶级开发人才,利用最新互联网技术,将交易所,矿场资源整合,顺应时势,开发一款面向全球的交易平台&算力平台(比特币目前的价值主要由挖矿成本决定),让区块链红利惠及早期参与者。

Sphinx4白皮书中文版

Sphinx4

Sphinx4 FRAMEWORK 高度的灵活性和模块化 每个标记元素在图中代表一个模块,可以很容 易地更换,从而让研究人员尝试不同的模块实现, 同时不需要修改系统的其他部分 3个模块:前端处理模块、解码器、语言专家 Sphinx4API的注释和翻译: https://www.360docs.net/doc/311689749.html,/taiyb/article/category/24567 57

一、前端 前端包括一个或多个平行的称为数据处理器的通信信号处理模块。支持多个链同时从相同或不同的输入信号中计算不同类型的参数。每一个数据处理器相当于是一个特定的信号处理函数。例如:一个处理器对输入数据执行FFT(快速傅里叶变化)。另一个处理器执行的是高通滤波对输入数据。 在处理器链中的每一个数据处理器都实现了DataProcessor接口。实现了Data接口的对象进行前端,从前端出来,在前端的处理器中通过。输入前端的数据一般是音频数据,但是前端是允许任意类型的输入的。类似的,输出的数据一般是特征,但是允许输出任意的输出类型。你能够配置前端接收任意类型的输入,返回任意类型的输出。 前端是一个Pull模型,采用的是pull的设计模式。为了获得前端的输出,你需调用frontend.getData();。在前端调用getData()方法会依次调用上(前)一个数据处理器在数据处理器链中的,直到第一个数据处理器的getData()方法被调用,这个处理器是从输入中读取Data对象。前端的输入实际上是另一个数据处理器,通常是前端的一部分。

二、语言专家 在sphinx – 4中,语言专家是一个可插入模块,允许人们用不同的语言专家实现动态配置系统。它是为解码器(decoder)创建和管理搜索空间的,此类为是一个提供了语言模型服务的一般接口。 任何语言专家的主要作用是为解码器呈现搜索空间(构建搜索空间)。通过调用getSearchGraph 方法,搜索管理类对象能够获得搜索空间。此方法返回的是一个搜索图类对象。在搜索图中的初始状态能够通过调用getInitialState方法获得,后续状态能够通过调用SearchState.getSuccessors()方法获得。 一个语言专家有大量关于它在哪里返回搜索状态的顺序的维度。例如在一个flat语言专家也许会在一个字的开始处返回一个字状态,然而tree语言专家也许会在一个字的结尾处返回一个字的状态。同样的一个语言专家也许会在彻底的省略掉一些状态类型(如一个单元状态)。一些搜索管理器也许会想知道由语言专家产生的不同状态类型的先验顺序。SearchGraph.get N u m StateOrder()方法用来获得状态类型的数量,此状态类型将会被语言专家返回即由其创造。 被语言专家所表示的搜索空间依赖于词汇的长度(尺寸)和其拓扑,搜索空间也有会包含大量的状态。一些语言专家会动态的产生搜索状态,也就是说,在搜索空间中代表一个搜索状态的对象直到搜索管理器需要的时候才被创建。搜索管理器在比较状态之前需要决定一个特定的状态是否被加入。因为搜索状态有可能被动态的产生。被语言专家返回的状态通常能够提供e q uals 和hash C ode 方法的非常有效率的实现。这允许搜索管理器高效的维护在H ashMaps中的状态。 本身包含三个可插拔的组件:语言模型、字典、声学模型

相关主题
相关文档
最新文档