问题标签 [oltp]

我正在将一些表和存储过程迁移到内存优化表和本机编译的存储过程。我被困在字符串比较上。

本机编译的存储过程不支持对不使用 *_BIN2 排序规则的字符串进行比较、排序和操作。

是否有适用于先决条件的高度分布式 OLTP 情况的已知架构解决方案？例如，让我们以银行为例。A 想将 $N 转给 B。此操作成功的先决条件是 A 的账户中必须有超过 $N。

从人 A 的角度来看，他们登录到某个 Web 应用程序。他们以 $N 的价格创建了从自己到个人 B 的转账。请记住，在应用此转账和创建转账时，资金会在后台实时从个人 A 的账户中提取和存入。这笔钱可能在创建之前就存在，但一旦应用转移，它可能就不存在了。换句话说，这不可能是客户端验证。A 想知道这个传输是同步成功还是同步失败。A 不希望异步提交传输，然后稍后返回到队列或传输失败的某些通知。

是否有一种已知的架构可以大规模解决这个问题？如果所有帐户都在一个 RDBMS 中，那么您可以通过内置的事务功能执行类似的操作。但是，如果您使用的是最终一致的 NoSQL 风格的数据存储，或者像 Kafka 这样的基于日志/消息的基础架构，那么是否有解决此类问题的已知解决方案？

我正在寻找一种方法来扩展我工作场所的基础设施。目前只有一个大小约为 1.5TB 的数据库。大多数查询都是 OLTP 类型，例如插入、更新、删除。

我正在考虑使用 CitusDB、PostgresXL 或 MySQL 结构等对数据库进行分片，但我不知道哪一个以及这对我们来说是否是一个好的解决方案。

这些是这类查询的好解决方案吗？

我们有两个数据库，而数据库 A 是事务性的，数据库 B 是数据库 A 和其他系统编译数据（存在于数据库 B 中）的统一视图。

数据库 B 使用每日 ETL 从 A（Flush and Load）和其他系统编译数据（存在于数据库 B）中加载数据。

我们可以将这两个 db 合并为一个，即 A Only 吗？

换一种说法，我们可以直接从 A 报告报告，而不是每天早上在统一数据库 B 中进行 ETL。

如果是，在合并这两个 wrt 性能时我应该关注什么因素。

我正在尝试在我当前的应用程序中实现分布式事务，这些事务目前与 MSDTC 一起运行良好，唯一的问题是 MSDTC 仅在 Windows 中受支持。许多地方建议的替代方案是放弃 DTC 并实施消息队列，这将在单独的部分中破坏事务。但由于我的应用程序是一个流量大、性能敏感的事务应用程序，用户需要即时响应，消息队列是否是合适的替代方案？如果没有，还有什么其他方法可以实现完全 2pc 支持的分布式事务？

我们的 OLTP 系统使用多个代理键。现在我们要为我们的系统创建一个维度模型以进行分析。我们是否应该保留 OLTP 系统代理键和自然键，并且还要再创建一个数据集市代理键？还是我们应该忽略 OLTP 系统代理键，只保留 OLTP 和数据集市代理键的自然键？

我有几个 OLTP 数据库与 API 对话。我也有每隔几个小时将数据推送到 OLAP 数据库的 ETL 作业。

我的任务是构建一个自定义仪表板，显示来自 OLAP 数据库的高级数据。我想构建几个指向 OLAP 数据库的 API。我是不是该：

1. 添加到我现有的 API 并调用 OLAP 数据库并使用 CQRS 类型模式，因此读取来自 OLAP，而写入来自 OLTP。我在这里担心的是读取和写入之间的数据可能不匹配。数据的不匹配程度取决于您运行 ETL 作业的频率（在我的情况下为小时数）。
2. 添加到我现有的 API 并调用 OLAP 数据库，然后要求客户端选择是否需要 API 重叠的 OLAP 或 OLTP 数据。我在这里担心的是客户端不需要知道数据来自哪里的实现细节。
3. 编写仅指向 OLAP 数据库的新 API。这是很多额外的工作。

我正在使用 SQL Server 2016 来了解内存中 OLTP 表。

我创建了一个数据库mydatabase，然后在其上运行 alter 命令来创建一个文件组：

要在该组上创建容器：-

这些命令执行成功，然后我在这个数据库中创建了内存优化的持久表和非持久表；mytable_durable并mytable_non_durable成功创建。

现在我想在 SQL Server 2016 的对象资源管理器中查看这两个表。它们在我的mydatabase > Tables节点下的数据库中不可见。我怎么能看到他们？请参阅随附的屏幕截图。

但是如果我运行这个

我可以看到两张桌子。请看下面的截图。

有什么方法可以在对象资源管理器中看到它们吗？或者这是默认行为？

我们刚刚开始研究使用 Postgres 作为我们系统的后端，该系统将用于 OLTP 类型的工作负载：> 95%（可能 >99%）的事务会将 1 行插入 4 个单独的表中，或更新1 行。我们的测试机器在具有 4 核 i7 处理器和传统 7200 RPM 磁盘的适度云托管 Windows VM 上运行 9.5.6（使用开箱即用的配置选项）。这比我们的目标生产硬件要慢得多，但现在对于发现我们基本设计中的瓶颈非常有用。

我们最初的测试非常令人沮丧。尽管插入语句本身运行得相当快（合并执行时间约为 2 毫秒），但总事务时间约为 40 毫秒，因为提交语句需要 38 毫秒。此外，在一个简单的 3 分钟负载测试（5000 个事务）中，我们每秒只看到大约 30 个事务，pgbadger 报告在“提交”中花费了 3 分钟（平均 38 毫秒），接下来最高的语句是分别在 10 (2ms) 和 3 (0.6 ms) 处插入。在此测试期间，postgres 实例上的 cpu 固定为 100%

提交所花费的时间等于测试经过的时间这一事实告诉我，不仅提交是序列化的（不足为奇，考虑到该系统上的磁盘相对较慢），而且在此期间它正在消耗 CPU，这让我感到惊讶。我之前会假设如果我们是 i/o 绑定的，我们会看到非常低的 cpu 使用率，而不是高使用率。

通过阅读，似乎使用异步提交可以解决很多这些问题，但需要注意崩溃/立即关闭时数据丢失。同样，将事务组合到一个开始/提交块中，或者使用多行插入语法也可以提高吞吐量。

我们可以使用所有这些选项，但在传统的 OLTP 应用程序中，它们都不会（您需要快速、原子、同步的事务）。20 年前，在比这台测试机器慢得多的硬件上运行的其他 RDBM 上，每秒 35 个事务在 4 核机器上是不可接受的，这让我认为我们做错了，因为我确信 Postgres 能够处理更高的工作量。

我环顾四周，但找不到一些可以作为调整 Postgres 实例的起点的常识配置选项。有什么建议么？

在网上我可以找到很多关于OLAP和OLTP的详细信息和文档，但没有一个定义什么是Online in Online Transaction/Analytical Processing