哈Ha！
这个小笔记是在讨论
“ Distributed Monoliths ...”一文时诞生的，并且由于需要进一步思考该主题，因此我决定将其发布在我的博客上。 本文的作者实际上描述了一个分布式数据库，证明了事件日志是其中唯一正确的存储结构。 参数大致如下：
- 由于事件始终以空间/时间进行本地化，因此它可以自身存储所有数据（有时以指向较早事件的链接的形式），从而使事件可序列化，增加位置性，减少连接性等。
- 事件一旦发生，便不再更改（其他事件记录了所有改进），从而减少了复制流量。
- 事件存储格式或多或少可以统一，并且与特定主题区域无关。
- 事件日志可以相对容易地拆分/合并，您可以将不同类型的事件存储在不同的节点上，也就是说，实质上，我们所说的是分布式数据库。
- 事件是按时间排序的，并且此序列也反映了因果关系（当前事件无法在以后引用）。
- 记录事件时，无需交易更新其他数据（实际上是必需的，但是在少数情况下，例如，计费系统中的订户余额必须立即相关，必须更新链接计数器等）。
- 可以直接从事件日志中构建报告，而无需将数据转换为规范化形式。
关于最后一点，大量的性能测试（包括在我的博客上）显示，在现代硬件上，使用具有短时记忆的单遍算法处理十亿个事件（事实）需要几分钟，这对于报告来说是可以接受的。 而且由于不通过链接连接的各种类型的事件的处理很容易并行化-报告时间可以减少到数十秒，而没有规范化数据/索引/收集统计数据/调试和提示查询的开销-就像常规RDBMS那样。 因此，基于此类数据构建报告并不会吓到我。 但是，请更广泛地考虑该问题。
典型的业务应用程序可以表示为数据转换链：
“输入=>模型=>输出”。 任何存储方案都是三个极端之间的折衷：
- 我们以输出格式存储数据。 这就是各种店面和OLAP的工作方式，其中响应时间很重要。 缺点是已知的-过多的内存需求和较低的更新速率（通常是批处理）。
- 我们以领域模型的格式存储数据，从而简化了计算算法。 有很多缺点-需要双重数据转换（从输入到模型，从模型到输出），交易成本增加，难以提供分布式存储，更改方案昂贵等。 但是，这是最受欢迎的选项。
- 我们以输入格式存储数据（实际上，文章的作者提供了一个事件日志）。 在这种情况下，交易成本最小，数据易于分割和合并，这是一种简单，清晰和稳定的存储方案。 赢利！ 没错，您必须再次学习编程。
关于我感兴趣的领域（企业信息系统），事件是主要文档，而参考书可以认为是较早的事件。 我已经在文章
“ NoERP或新外观...”中描述了典型西方ERP的表结构，在该文章中，我建议废除过度标准化的数据（即时余额寄存器除外），并以单遍循环重写大部分计算/报告，在该过程中，直接处理主要计算/报告。文件。 我不会重复这些论点，所有内容都在本文中进行了阐述，但是我提出的方案实际上与第一篇文章的作者的观点相吻合，即事件日志就是数据。 当其他人朝这个方向思考时，这很好。
显然，与现代智能DBMS相比，该方法似乎落后了一步，但是在高倍数的世界中，您有时不得不放弃流行的/抽象的/通用的工具-而是使用残酷而有效的命令式编程，此外，不需要昂贵的节点许可费/内核/用户。
关于事件日志中组织关系的方法，我想单独说一说-它必须是双向的，即每个事件必须存储一个指向其自身的引用计数器。 这对于实现单遍算法是必要的-我们从旧事件转到新事件，同时将每个事件的传入链接的数量非零地缓存在内存中，并仅在处理所有引用链接之后才将其从缓存中删除。 引用计数器的存在令人不愉快地降低了交易性能-例如，如果在每个文档中使用交易对手目录，则每次添加文档时（有时在不同节点上），交易对手中的参考计数器都必须更新。 但是，可以对该位置进行通用优化，在所有其他情况下都避免了分布式事务。
实际上，就目前的想法而言，我仍然希望有一个特定的项目（例如，基于现金收入或发票），如果有这个机会，我将报告结果。