将Vertica数据库用于OLTP数据?

时间:2012-07-11 14:57:25

标签: vertica

Vertica数据库可以用于OLTP数据吗? 如果是这样,这样做的利弊是什么?
 寻找Vertica与Oracle斗争:)由于Oracle许可证价格昂贵,Vertica会以更优惠的价格完成工作吗?  全部

5 个答案:

答案 0 :(得分:5)

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

我建议您查看VoltDB。作为Vertica背后的力量的Michael Stonebreaker也创立了该公司。他的基本理念是Oracle,SQL Server等不能很好地实现高性能,因为它们旨在完成所有工作。未来是为特定任务设计数据库。

所以他有一些数据仓库的概念,它们变成了Vertica。对于事务数据库,有VoltDB。不属于惠普公司的记录。

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

答案 1 :(得分:3)

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

HP Vertica通过使用WOS(写入优化存储)和ROS(基于文件的读取优化存储)来解决这个问题。

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

如果您尝试使用Vertica for OLTP,那么您将获得大量ROS容器并可能非常快地达到1024个ROS容器的默认限制。

如果您使用某种形式的存储机制来向商店提供大批量传递记录,那么这将导致更少和更大的ROS文件。它会工作,但如果你想让你的OLTP系统阅读非常接近它的写作活动,它将不适合用例。

WOS / ROS机制是针对列存储数据库中写入的基本性能损失的一种巧妙解决方案,但从根本上说,Vertica不是OLTP数据库,而是可以近乎实时地接收数据的数据集市技术

答案 2 :(得分:3)

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

  1. 您可以将Vertica用作OLTP数据库吗?
  2. 首先,我会稍微定义一下这个问题。 OLTP数据库意味着数据库本身负责事务处理,而不仅仅是接收一些规范化的数据。

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

    您可以使用一些广泛的中间件编程(分布式锁,大量避免DELETE / UPDATE等)来解决其中一些问题。但为什么?有很多选项不是Oracle,没有巨大的价格标签,但为您提供OLTP所需的一切。

    1. 您可以使用Vertica来摄取和查询OLTP数据吗?
    2. 是的,当然。但最好将Vertica用于其优势。 Vertica中的查询往往会产生相当大的开销,您可以轻松地浏览大量数据,甚至可以标准化。我不会将Vertica用于主要运行点查询,在这里和那里抓取几行。这不是你不能,但你不能与其他用于此目的的数据库具有相同的并发性。

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

答案 3 :(得分:2)

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

除非您仔细考虑您的工作量,否则我不建议将Vertica作为OLTP。

如其他答案所述,Vertica有两种类型的存储空间。 ROS是读优化存储,WOS是写优化存储。 WOS纯粹是在内存中,因此它对插入执行得更好,但查询速度较慢,因为需要查询和联合所有小更新。 Vertica理论上可以处理小负载,但实际上对于我们的性能而言,它并没有很好地解决。 WOS还有一个缺点,即当数据库出现故障时,当WOS回滚到上一个好时期时,WOS不一定得到保留。 (ROS不是,但实际上你从ROS中失去了很多)。

ROS更可靠,并且提供更好的读取性能,但如果不仔细设计,您将永远无法处理超过一定数量的查询。虽然vertica是可水平扩展的,但实际上大型表在所有节点上都是分段的,因此查询必须在所有节点上运行。因此,添加更多节点并不意味着处理更多并发查询,这意味着每个查询的工作量更少。如果您的表格足够小而不会被分段,那么这对您来说可能不是问题。

另外值得注意的是,OLTP通常意味着很多并发事务,因此您需要非常仔细地规划资源池。默认情况下,vertica具有针对每个服务器的最小核心数或RAM / 2GB的常规资源池的计划并发性。本值基本上是确定分段查询的默认内存分配PER NODE。因此,默认情况下,vertica不允许您运行比核心更多的查询。您可以调整此值但是一旦达到内存上限,就无法做到,因为内存是按节点分配的,因此添加更多节点甚至无法提供帮助。如果你遇到资源池内存分配的任何错误,那就是你应该看的第一个配置。

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

我个人使用Vertica作为OLTP-ish实时数据库。我们将我们的载荷分成5分钟的间隔,这使得vertica在插入的数量/大数方面都很满意。使用COPY DIRECT插入这些批次,以便它们完全避免使用WOS(仅当它们是大批量时才这样做,因为这会强制创建ROS容器,如果经常这样做可能会很糟糕)。我们可以拥有的许多预测都是未分段的,以便更好地扩展,因为这会使查询只触及1个节点并仅在1个节点上分配内存。到目前为止,它对我们来说效果很好,我们每天加载大约50亿行,并通过UI实时查询。

答案 4 :(得分:0)

Up_one - 考虑电信用例 - 你在做CDR还是别的什么?

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