可以使用Excel，GSheet或大型ORM系统来实现数据库。 在业务分析的实践中，我遇到了不同的解决方案。 自从我从财务和审计部门进行业务分析以来，每次遇到新系统时，我都会问自己一个问题-它们之间的区别是什么以及它们要解决什么任务？ 找到了一些答案。 本文将介绍数据库的两个主要目的：
1-运营会计，
2-数据分析
第一种任务由OLTP系统解决：来自O的事务处理。 第二种是通过OLAP系统解决的：来自O n L ine A的分析处理
OLTP
可以将OLTP存储模型与电话簿条目进行比较。 表中的行显示为索引和相应的数据索引：（indexN，数据）。 因此，这样的表不能称为表。 这是一本普通的书，带有编号的行。 如果您需要对书籍进行新操作，请添加一行，分配一个索引，然后关闭书籍。 标签从书中伸出来，使您可以快速O（登录n），找到所需的行并执行CRUD。
对于运营会计，这是一个友好的显示。 但这并不敌视数据分析，因为我们对这些行本身不感兴趣，而是根据这些行的内容进行计算。 并且如果您基于行的内容进行分析查询，即 对于未建立索引的字段，则此类查询的运行会更加缓慢。
如您所知，对所有记录建立索引不是一种选择。 尽管这本书就像一张桌子，但随着属性可用于快速搜索，它也减慢了创建新行和更新现有行的速度。 因为这些操作将需要对整个数组进行重新排序。
OLAP和OLTP之间的权衡
在1C解决方案中，实现折衷方案如下。 写入数据库时的事件一次写入多个位置。 在一个地方，记录的索引很少，并且针对OLTP负载进行了优化；在另一个地方，记录被所有字段索引，并适合OLAP负载。 这样的表称为累积寄存器和信息寄存器。 由于写入多个位置会增加数倍的占用空间，因此为了保存，并非所有事务属性都落入寄存器中，而是仅保存那些对于此部分分析会计重要的属性。 这种折衷被称为ROLAP模型，即 关系分析映射。
OLAP
在SAP中，德国对手1C走得更远。 该软件中的关系OLTP模型可以复制到OLAP模型。 SAP HANA实现存储列结构。 这意味着“表”不是作为一组行而是作为一组列存储在此处。
在Google Bigquery，Microsoft SSAS Tabular，Amazon Redshift，Yandex ClickHouse等解决方案中实现了类似的存储方案。
列存储和行存储之间的区别
如果采用行结构，则数据以“水平”元组的形式存储，每个元组都是一个事务：
period, product, department (Q1, SKU1, 1) (Q1, SKU2, 1) (Q1, SKU1, 1) ... (Q2, SKU1, 1) (Q2, SKU1, 1) (Q3, SKU1, 1) (Q3, SKU1, 1) ...
然后，将这些数据“垂直”存储在列中：
(Q1, Q1, Q1, ... Q2, Q2, Q3, Q3, ...) (SKU1, SKU2, SKU1, ... SKU1, SKU1, SKU1, SKU1, ...) (1,1,1, ... 1,1,1,1, ...)
可以有条件地优化重复，如下所示：
period = (Q1, {start: 0, count: n}, Q2, {start: n+1; count: m}, ...) product = (SKU1, {start: 0, count: 1}, SKU2, {start: 1; count: 1}, SKU1, {start: 2; count: m}, ...) department = (1,{start:0, count:m}...)
如果有一列这样的优化不会减少初始数量，那么数据将以其原始形式存储。
列表的引擎本身会选择对列进行排序的顺序，但是如果您知道数据并手动对其进行排序，则通常会增加压缩率并减轻分析负担。 我对单个表的压缩超过300次。 实际上，这样的数据存储结构：
- 允许您将数据压缩到RAM中时的水平，即 使内存计算在速度上无法与关系数据库查询相提并论
- 设置自己的构建数据模型的规则，不再需要像OLTP中那样的标准化
- 定义用于构造解析表达式的语义。
表达式的细节详细描述：
这是针对Google BigQuery的。
这是针对Microsoft DAX的。
BI作为列基础架构
BI是服务于分析负载的解决方案。 如果建立在列数据库之上，它们将使工作变得更加轻松。 这可以是自制的ClickHouse-Grafana-Python束，也可以是Google堆栈束：Bigquery-Data Studio-Dataprep-Dataflow或整体式Power BI。
多维数据集是列存储的另一种OLAP替代方法。 但是对我而言，与BQ或DAX中的SQL相比，MDX表达式是多余且复杂的。