标签: olap

我有点困惑，因为我在质疑 OLTP 和 OLAP 中“在线”的定义。我曾经认为，这里的“在线”意味着我们希望在有限的时间内根据某个实例的可用数据获得答案。

但是 OLAP 查询可能需要几个小时来计算 - 这不是离线的吗？

快速搜索表明离线 OLAP 听起来相当混乱（离线在线分析处理）......？

究竟什么是“在线”？

在进行分析查询时，有人可以向我展示 MDX 优于常规 SQL 的一个很好的例子吗？我想将 MDX 查询与给出相似结果的 SQL 查询进行比较。

维基百科说：

虽然可以将其中的一些转换为传统 SQL，但即使对于非常简单的 MDX 表达式，它也经常需要合成笨拙的 SQL 表达式。

但是既没有引用也没有例子。我完全清楚底层数据必须以不同的方式组织，并且 OLAP 将需要每次插入进行更多的处理和存储。（我的建议是从 Oracle RDBMS 迁移到Apache Kylin + Hadoop）

上下文：我试图说服我的公司我们应该查询 OLAP 数据库而不是 OLTP 数据库。大多数 SIEM 查询大量使用分组依据、排序和聚合。除了性能提升之外，我认为 OLAP (MDX) 查询比等效的 OLTP SQL 更简洁、更易于读/写。一个具体的例子可以说明这一点，但我不是 SQL 专家，更不用说 MDX ...

如果有帮助，以下是针对过去一周发生的防火墙事件的与 SIEM 相关的 SQL 查询示例：

SELECT   'Seoul Average' AS term, 
         Substr(To_char(idate, 'HH24:MI'), 0, 4) 
                  || '0'        AS event_time , 
         Round(Avg(tot_accept)) AS cnt 
FROM     ( 
                SELECT                     * 
                FROM   st_event_100_#yyyymm-1m# 
                WHERE  idate BETWEEN trunc(sysdate, 'iw')-7 …

我的任务是为一家大型零售连锁店设计一个解决方案。他们希望允许其 120 万客户中的每一个都登录到一个网站，查看大约 50 个类别的最近购买（当月、上月、年初至今）的分布情况。数据将每天更新一次。

我正在考虑建立一个基于 SQL Server 2012 的 OLAP 多维数据集，并让网站直接查询这个多维数据集，利用主动缓存等功能。但是，作为一名开发人员，我几乎没有使用 SQL Server 的分析服务部分的经验，因此我非常关心此解决方案的性能。

将网站直接连接到 OLAP 多维数据集听起来像一个可行的解决方案吗？这些系统是否像 SQL Server 一样对来自多个用户的负载做出反应，使其成为一个合理的解决方案，或者它们的行为是否完全不同？

我不希望用户经常检查他们的状态，我当然会在网络服务器等上使用缓存。

我是新手，试图围绕 OLAP 进行思考，我有几个问题。

• 问题 1： OLAP 多维数据集可以存储中位数、众数、百分位数吗？
• 问题 2：用户编写的 MDX 查询能否返回行级数据的摘要？（例如：交易百分比 > 100 美元）。或者多维数据集设计者必须将它添加到多维数据集中？
• 问题 3：现在是否有任何 OLAP 产品提供访问行级数据的机制？哪一个？

我们的 IT 部门正在寻求有关特定 MS Analsis Services ROLAP 多维数据集出现的问题类型的反馈。我们无权访问其背后的关系数据库，需要执行当前无法作为多维数据集中度量的计算。

让我看看我是否有这个权利。

1. 立方体可以提供计数、均值、比例、标准偏差的统计数据。
2. 如果多维数据集设计器提供的度量未满足特定统计数据，我们是否可以编写 MDX 查询来获取它？或者他们是否需要更改多维数据集以便从行级数据预先计算它？
3. 多维数据集无法提供中位数、众数或百分位数等统计数据，因为这些统计数据不能正确聚合。

我正在阅读 Leland Wilkinson 的The Grammar of Graphics以及他关于数据挖掘和 OLAP 的章节，他说

这些 [立方体操作] 可以很好地处理诸如计数、均值、比例和标准差之类的统计数据。子类上的简单聚合可以通过对和、平方和和其他组合在线性函数中的项进行运算来计算，以生成基本的汇总统计。

它们不能与中位数、众数和百分位数等统计数据一起正常工作，因为这些统计数据的汇总不是它们汇总的统计数据。例如，中位数的中位数不是合计的中位数。

他接着补充说：

然而，最近出现了一种更复杂的 ROLAP 模型。通过多种技术，可以让统计算法通过关系模型实时访问原始数据。这种方法比数据立方体等结构提供的刚性聚合更有前途。

在这种架构的最优雅的形式中，应用程序可以请求远程连接以提供有关其数据处理方法的信息，并根据返回的信息采取适当的行动。在这种形式下，组件架构可以实现分布式计算的真正承诺：独立于站点、操作系统或语言的设计和执行。

那是大约 2005 年写的。有人知道使用这种方法来允许行级数据访问的产品吗？

内存中的 OLAP 引擎是否比传统的 OLAP 引擎有优势，并有足够的 RAM 支持以包含整个多维数据集？

例如，如果我使用 MOLAP 引擎 (SSAS) 和 GB/TB 的 RAM，其中整个多维数据集（甚至星型模式）都驻留在 RAM 中，那么与 TM1/SAP HANA 之类的东西相比有什么区别？

我有四台相同的服务器 2 用于生产，另外两台是演示机器/紧急故障切换盒。更强大的机器是一个 16 核 127 gig 的 Ram 托管我们的数据仓库和我们的 OLTP 数据库。功能较弱的盒子是我们用于 ETL 和数据存储的 8 核 98 gig ram 盒子。我遇到的问题是在生产服务器上集成服务需要大量时间来执行包验证。对于在 6 秒内返回的查询，完成包验证需要 40 秒。如您所见，这是一个相当简单的包。

请记住，这只是我用作示例的包，我的所有包都有相同的问题，尽管有些程度较低。当我运行它时，验证部分平均需要 40 秒。

为了更好地测试这一点，我在姊妹机器上运行了完全相同的包，它运行所有与该机器相同的 SQL 作业。只有执行前验证需要 0 秒，查询需要 4 到 6 秒。

为了进一步测试这一点，我对两个 SQL 服务器实例运行了查询。

SELECT '{' + CAST(Store_Id AS CHAR(36)) + '}' AS Store_Id
      ,'{' + CAST(ItemGroupDetail_Id AS CHAR(36)) + '}' AS ItemGroupDetail_Id
      ,ItemGroupType_Id
      ,'{' + CAST(Concept_Id AS CHAR(36)) + '}' AS Concept_Id
      ,'{' + CAST(Company_Id AS CHAR(36)) + '}' AS Company_Id
      ,'{' + CAST(ItemGroup_Id …

显然，此功能在以前的版本中可用，但现在已被删除。

有哪些替代方案？

我对数据库设计和开发相当陌生。我的要求是基于时间和单词语言（特定日期的语言）进行简单的钻取/切片。但是，我的数据库是 mysql。但到目前为止，我还没有运行这些查询的运气，所以我手动计算这些数据并存储在表中。

为了更具体地说明我的应用程序，我需要在 iPhone 上显示图表/图形。因此，用户每天/每周/每月使用每种语言的单词。我不需要实时，但用户使用一个月的行数约为 5000。

我想了解 mysql 是否有可能拥有仓库模式并在没有性能问题的情况下执行此类查询。我的选择是什么。

• 邮政？
• MySQL 企业版？
• 立方体

我真的无法支付企业解决方案的费用，我准备在我的应用程序（我有）中为这种处理编写代码，但想迁移到正确的方式。

我想对我来说最理想的情况是不使用任何工具就可以在我当前的数据库中创建事实和维度，然后转移我的 api 来运行这些 olap 查询。从我收集的信息来看，这对于 mysql 是不可能的。Postgres 显示出一些希望，但仍在阅读。

我正在使用 SQL Server 2014 设置一个 OLAP 数据库。核心事实表有大约 40,000,000 行、225 列，平均行大小为 181 字节。我一直在玩聚簇列存储索引，但运气不佳。一般来说，我发现使用新技术时查询性能要慢 4 倍以上。

一个特殊的例子 - 使用 int32 主键选择单行现在需要 12 秒......这是对行存储表的亚秒操作（当然它在 PK 上有一个唯一索引，这不允许与聚集列存储索引）。

我试图找出我做错了什么 - 从 MS 文档中听起来这是完成这项任务的理想技术；也许我错过了一些东西。

我正在 Windows 8.1 64 位上运行 SQL 2014 Enterprise，具有 128GB RAM 和 SSD 用于数据存储。此应用程序的数据是只读的。

我有一个字段，它是一个字母数字字段，理想情况下是非唯一标识符的加密字段。它用于以多对多关系关联其他相当大的事实表。我没有此字段的相关维度，因为此 FK 没有其他属性。

示例：Abcdefgh12345

该字段位于一个相当大且不断增长的数据仓库中，其中 Fact 表按时间集群，而不是像这样的键集群。

该列是VARCHAR(50)并且仅在 45 和 50 之间变化。必须检查，但我认为排序规则是SQL_Latin1_General_CP1_CI_AS. 出于优化原因，我不使用 FK。全部由 ETL 控制。

碎片化

由于键的类型，很难索引。它的碎片是由我最近进行的一系列测试管理的，这些测试表明 75% 的填充因子至少是可以管理的，减少每日增量负载的碎片至少一周，直到可能需要完全重建，每周一次就可以了。

表现

随着填充因子从 100% 降低到 75%，插入和读取变得更慢。正如预期的那样，这些记录也越来越大。任何包含包含的索引都在很大程度上推动了插入的性能，但当然可以帮助需要它们的查询提高 10 倍。

题

有没有人有在数据仓库环境中使用字母数字的良好经验？它的处理方式和索引现在很好，但我认为它可能会更好。我正在尝试在 ETL 过程中删除密钥、形成新维度并添加更易于管理的密钥的想法。