4

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

4

5 回答 5

5

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

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

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

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

于 2012-07-13T03:22:58.153 回答
3

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

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

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

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

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

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

于 2014-06-10T10:58:40.797 回答
3

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

  1. 可以将 Vertica 用作 OLTP 数据库吗？

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

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

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

  1. 您可以使用 Vertica 摄取和查询 OLTP 数据吗？

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

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

于 2015-05-22T01:58:11.987 回答
2

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

除非您非常仔细地考虑您的工作量，否则我不会建议将 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 亿行。

于 2015-05-22T22:23:39.087 回答
0

Up_one - considering the telecom use-case - are you doing CDR or something else?

To answer your original question yes Vertica may be a great fit but it depends on how you are loading the data, how you are doing updates, what your data size is and what your SLA is. I am really familiar in this space because I implemented Vertica at a telecom that I worked for at the time.

于 2012-07-12T16:06:54.120 回答