将Vertica数据库用于OLTP数据？

Question

可以将Vertica数据库用于OLTP数据吗？
如果有的话，这样做有什么优点和缺点？
寻找一个Vertica与甲骨文的战斗:)
由于Oracle许可证如此昂贵，Vertica会以更好的价格工作吗？ thx全部

Answer 1

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

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

Answer 2

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

我建议你看看VoltDB。 Vertica背后的力量Michael Stonebreaker也创建了该公司。他的基本理念是，Oracle，SQL Server等在高性能方面表现不佳，因为它们都是为了完成任何事情而设计的。未来是为特定任务设计数据库。

因此，他对于成为Vertica的数据仓库有一些概念。对于事务数据库，有VoltDB。不属于惠普，备案。

为了记录，我没有使用过VoltDB。据我所知，它不像Vertica那样成熟，只是看起来有很多承诺。

Answer 3

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

HP Vertica通过拥有WOS（写入优化存储）和ROS（基于文件的读取优化存储）来解决此问题。

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

如果您尝试将Vertica用于OLTP，那么将会发生的情况是您将获得大量ROS容器，并可能非常快速地达到1024个ROS容器的默认限制。

如果你用某种形式的排队机制向商店前进，以较大的批次通过记录，那么这将导致更少和更大的ROS文件。它可以工作，但如果你想让你的OLTP系统阅读与其写作活动非常接近，那么它就不适合用例。

的WOS/ROS机制是一个整洁的工作围绕在列存储数据库写入的基本性能损失，但是从根本上Vertica的是不是一个OLTP数据库，而是一个数据集市技术，可以近乎实时地提取数据

Answer 4

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

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

首先我要定义这个问题。OLTP数据库意味着数据库本身负责事务处理，而不仅仅是接收一些标准化的数据。

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

您可以解决其中的一些与一些广泛的中间件编程（分布式锁，避免重删除/更新的，等等）。但为什么？这里有很多不是Oracle的选项，不会带有巨大的价格标签，但可以为您提供OLTP所需的一切。

你可以使用Vertica的摄取和查询OLTP数据？

是的，当然。尽管如此，最好使用Vertica来发挥它的优势。 Vertica中的查询往往会有相当多的开销，并且您可以轻松浏览大量数据，甚至可以规范化。我不会将Vertica用于主要的运行点查询，在这里和那里抓取几行。这并不是你无法做到的，但你不能与其他数据库具有相同的并发性。

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

Answer 5

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

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

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

ROS是很多更可靠，提供更好的读取性能，但你永远都能够处理超过一定数量的查询更没有精心的设计。虽然vertica是可水平扩展的，但实际上大表在所有节点上都是分段的，因此查询必须在所有节点上运行。因此添加更多的节点并不意味着处理更多的并发查询，这意味着每个查询的工作量减少。如果你的桌子足够小以至于不可分割，那么这对你来说可能不是问题。

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

此外，Vertica的是坏与删除和更新（这决心删除，并在后台的插件），所以如果这些都是你的工作量的常规部分，然后Vertica的可能是一个不错的选择。我们个人使用MySQL作为需要删除/更新的维度表，然后将这些数据定期同步到Vertica中用于连接。

我个人使用Vertica作为OLTP-ish realtime-ish数据库。我们将我们的负载分成5分钟的时间间隔，这使得Vertica在插入物的数量/大小方面感到高兴。这些批次是使用COPY DIRECT插入的，因此它们完全避免了WOS（如果它们是大批量的，那么这会强制执行ROS容器的创建，如果您经常这样做可能会很糟糕）。由于许多预测都是不分段的，因此可以实现更好的扩展性，因为这使得查询仅击中1个节点并仅在1个节点上分配内存。到目前为止，它对我们运行良好，我们每天加载大约50亿行，并通过我们的用户界面实时查询。