将 Vertica 数据库用于 OLTP 数据？答案

【问题标题】：Use Vertica Database for OLTP data?将 Vertica 数据库用于 OLTP 数据？
【发布时间】：2012-07-11 14:57:25
【问题描述】：

可以将 Vertica 数据库用于 OLTP 数据吗？
如果是这样，这样做的利弊是什么？
正在寻找 Vertica 与 Oracle 的较量 :)
既然 Oracle 许可证如此昂贵，那么 Vertica 会以更优惠的价格完成这项工作吗？谢谢大家

【问题讨论】：

标签： vertica

【解决方案1】：

将 Vertica 用作事务数据库是个坏主意。它被设计成一个数据仓库工具。本质上，它以优化的方式读取和写入数据。交易量大？这不是它的设计目的。

我建议您查看 VoltDB。 Vertica 的幕后推手 Michael Stonebreaker 也创立了这家公司。他的基本理念是 Oracle、SQL Server 等在高性能方面做得不好，因为它们旨在完成所有工作。未来将拥有专为特定任务设计的数据库。

因此，他对后来成为 Vertica 的数据仓库有了一些概念。对于事务数据库，有 VoltDB。不归惠普所有。

作为记录，我没有使用过 VoltDB。据我所知，它不像 Vertica 那样成熟，但它看起来很有希望。

【讨论】：

Thx Geoff，
真正的 Vertica 设计不适合 OLTP 使用，通过在 OLTP 中使用它，你会带走它的 WOS 和 ROS 额外功能，这会让它与其他产品不同。
部分是它仍然使一切都比 OLTP RDBMS 好得多，到目前为止速度非常好。
至于你说的 VoltDB 仍然不成熟，很难向客户展示。
但是是DB 让我密切关注 :)。
。我将尝试与其他 OLTP RDBMS 一起实施 Vertica，也许有一个 5 年的计划，我们可能会从中获得丰厚的回报！

【解决方案2】：

HP Vertica 是一个列存储数据库。列存储中数据组织方式的性质不适合快速写入。

HP Vertica 通过 WOS（写入优化存储）和 ROS（基于文件的读取优化存储）解决了这个问题。

数据从 WOS 很快转移到 ROS 中，并且 ROS 本身有一个“合并”过程，该过程可以获取小的 ROS 文件并将它们合并在一起以形成更大的文件，因此更容易扫描。

如果您尝试将 Vertica 用于 OLTP，那么您会收到大量 ROS 容器，并可能很快达到 1024 个 ROS 容器的默认限制。

如果您在商店前面使用某种形式的排队机制来批量传递记录，那么这将导致 ROS 文件越来越少。它会起作用，但如果您想让您的 OLTP 系统读取非常接近其写入活动，则它不适合用例。

WOS/ROS 机制很好地解决了列存储数据库中写入的基本性能损失，但从根本上说，Vertica 不是 OLTP 数据库，而是一种可以近乎实时地摄取数据的数据集市技术

【讨论】：

感谢您的回复，此时我已经达到 Vertica 的 Arquitect 级别！无论如何谢谢
这里更正，没有1024个容器的限制，有1024个分区的限制。我有包含 6500K+ ROS 容器的表，它们运行良好。在您考虑设计之前，容器的数量并不重要。我们有许多投影和许多分区，这会产生许多容器，但如果您有 1 个分区和 1 个投影，那么拥有很多容器会破坏您的性能。
@user1084563 不正确。 ROS 限制不在表格上，而是在每个节点的每个投影上。分区决定了这些 ROS 容器的粒度，因此如果您不小心可能会导致许多 ROS 容器，如果您超出限制，则会导致 ROS 回退。

【解决方案3】：

我认为有不同的方式来解读这个问题。

能否将 Vertica 用作 OLTP 数据库？

首先我会稍微定义一下这个问题。 OLTP 数据库意味着数据库本身负责事务处理，而不是简单地接收一些规范化的数据。

我的回答绝对不是，除非它可能是一个单用户数据库。几乎没有 RI，没有 RI 锁定，DELETE/UPDATE 上的表锁定，并且您可能会在正常的 OLTP 类型使用中积累一个删除向量。

您可以通过一些广泛的中间件编程（分布式锁、大量避免删除/更新等）来解决其中的一些问题。但为什么？有很多不是 Oracle 的选项，价格不高，但可以为您提供 OLTP 所需的一切。

能否使用 Vertica 摄取和查询 OLTP 数据？

是的，当然。不过，最好使用 Vertica 来发挥其优势。 Vertica 中的查询往往有相当多的开销，您可以轻松地处理大量数据，甚至是标准化的。我不会使用 Vertica 来进行主要的运行点查询，在这里和那里抓取几行。并不是您不能，而是您不能使用与其他为此目的的数据库相同的并发性。

TL;DR 为正确的工作使用正确的工具。我真的很喜欢使用 Vertica，但仅仅因为我喜欢挥动锤子并不意味着所有问题都是钉子。

【讨论】：

说得好！谢谢你的好帖子。

【解决方案4】：

这个问题现在有点老了，但我会分享我的经验。

除非您非常仔细地考虑您的工作量，否则我不会建议将 vertica 作为 OLTP。

正如其他答案中提到的，Vertica 有两种类型的存储。 ROS是读优化存储，WOS是写优化存储。 WOS 纯粹在内存中，因此它在插入时性能更好，但查询速度较慢，因为所有小的更新都需要查询和联合。 Vertica 理论上可以处理小负载，但在实践中它对我们的性能表现并不好。 WOS 也有缺点，即当数据库发生故障时，WOS 在回滚到上一个好时代时不一定会保留。（ROS 也不是，但实际上你从 ROS 中损失得更少）。

ROS 更可靠，读取性能更好，但如果没有精心设计，您将永远无法处理超过一定数量的查询。尽管 vertica 是水平可扩展的，但实际上大型表会跨所有节点进行分段，因此查询必须在所有节点上运行。因此，添加更多节点并不意味着处理更多并发查询，它只是意味着每个查询的工作量更少。如果您的表足够小，可以不分段，那么这对您来说可能不是问题。

另外值得注意的是 OLTP 通常意味着大量并发事务，因此您需要非常仔细地规划资源池。默认情况下，vertica 为每个服务器或 RAM/2GB 的最小内核数的一般资源池计划并发。本质上，该值的作用是确定分段查询的每个节点的默认内存分配。因此，默认情况下，vertica 不会让您运行比核心更多的查询。您可以调整此值，但是一旦达到内存上限，您就无能为力了，因为内存是按节点分配的，因此添加更多节点甚至没有帮助。如果您在资源池内存分配方面遇到任何错误，这是您应该查看的第一个配置。

此外，Vertica 在删除和更新方面很糟糕（这会在后台解析为删除和插入），因此如果这些是您工作负载的常规部分，那么 Vertica 可能是一个糟糕的选择。就个人而言，我们将 MySQL 用于需要删除/更新的维度表，然后定期将该数据同步到 vertica 以用于连接。

我个人使用 Vertica 作为 OLTP 式实时数据库。我们将负载分批成 5 分钟的间隔，这让 vertica 对插入的数量/大小感到满意。这些批次是使用 COPY DIRECT 插入的，这样它们就可以完全避免 WOS（只有在它们是大批次时才这样做，因为这会强制创建 ROS 容器，如果你经常这样做可能会很糟糕）。我们可以拥有的尽可能多的预测都是未分段的，以允许更好的横向扩展，因为这使得查询仅命中 1 个节点并仅在 1 个节点上分配内存。到目前为止，它对我们来说效果很好，我们每天通过 UI 实时查询加载大约 50 亿行。

【讨论】：

它过去了一段时间，但您的帖子仍然有用，时间过去了，我对 Vertica 有了更多的了解，你所说的都是真的，这一切都归结为“只写一次”——这种权衡使 Vertica 表现出色在某些地方。但是当你这样做时：- 将 MySQL（高反式）与这个 Vertica 愚蠢的快速加载混合 :) 它是要走的路。
有没有办法可以在我的网站aodba.com/en/about 上给我发消息，我对自动化有疑问。谢谢

【解决方案5】：

Up_one - 考虑到电信用例 - 您是在做 CDR 还是其他？

要回答您最初的问题，是的，Vertica 可能非常适合，但这取决于您如何加载数据、如何进行更新、您的数据大小以及您的 SLA 是什么。我对这个领域非常熟悉，因为我在当时工作的一家电信公司实施了 Vertica。

【讨论】：

你使用什么工具来加载数据？