OLAP 与内存

Question

我正在处理大数据，我所有的后端逻辑都是用 php 编写的。因此，对于更快的输出，以下哪些技术对我的产品有效且有益。

1. OLAP。
2. 内存数据库。

Answer 1

好吧，当我们谈论大数据时，我会选择 OLAP 数据库。但让我们仔细看看这些技术：

OLAP（= 在线分析处理）

...具有在维度级别上预先聚合数据的基本技术思想。

假设您想查询一个销售订单表，其中每天、每月和每年都有数千个订单。 您可以定义订单日期、销售渠道、发货国家/地区等维度以及营业额、订单数量、发货时间等指标。

通常，您会使用 OLAP 数据库回答以下问题：

• 我们在 2016 年 6 月有多少销售订单？
• 2016 年销售渠道 SHOP 发往美国的营业额（销售订单总金额）是多少？
• 每周/每月平均运送销售订单需要多长时间？

...或更专业的：

您可以回答所有问题，其中 SELECT 子句中有一个聚合，而 where 子句中有一个维度：

SELECT
    SUM(amount) AS Turnover,
    AVG(shipping_time) AS avg_shipping_time
FROM sales_orders
WHERE DATEPART(year,order_date) = 2016 AND sales_channel = 'SHOP'

OLAP 系统可以聚合的越多，性能就越好。因此，使用销售订单号或邮寄地址作为维度是一种不好的方法。 OLAP 的想法是消除数据（或行）。这需要标准化的数据。

以下问题最好在关系型数据库（数据仓库）中得到解答：

• 2016 年 9 月的前 50 名销售订单有哪些？
• 告诉我2017年1月销售订单的客户地址 等

那么什么是内存？

内存中的想法是在 RAM 中查询数据比在磁盘上查询数据更快。但 RAM 也很昂贵。

关系数据库中的内存实际上是为 OLTP（在线事务处理）系统（用户进行事务和工作的系统）构建的，而不是用于分析。

实际上，今天的企业 OLAP 系统（如 SQL Server 分析服务）在聚合数据后也使用内存中技术（OLAP 技术）。你只是看不到它。

--

所以 OLAP 是正确的选择，还是...？

让我们再想一想其他事情：OLAP 数据库与关系数据库不同，有时它太大而无法使用 OLAP 数据库（例如，当您只有一个巨大的表时）。 需要处理 OLAP 数据库（聚合并准备好使用）。那就是 - 大多数时候 - 在没有人工作的晚上完成（好吧，如果你愿意，你可以每秒都这样做:-)）

如果您是大数据的新手，只想在您的应用程序中修复这件事 - 并且不了解 OLAP，我建议您：尝试在您的应用程序中修复它应用程序代码 - 除非你想用新术语挖掘一个新世界，像 MDX 这样的语言而不是 SQL 等。

复杂性取决于您选择的 OLAP 数据库。但实际上，您可以在应用程序中轻松开发自己的“OLAP”聚合级别……只是它可能不如 OLAP 数据库灵活。

您的应用程序中可能的解决方案可能是：

• 使用SQL Server indexed views - 或其他数据库中的类似函数
• 使用 SQL 表触发器
• 使用 cron 作业聚合数据并将其写入表中