Vertica数据库可以用于OLTP数据吗？
如果可以，这样做的利弊是什么？
期待一场Vertica与Oracle的竞争 :) 由于Oracle许可证价格昂贵，是否使用Vertica能以更好的价格胜任其工作？
谢谢大家。
使用Vertica数据库处理OLTP数据？
4
- Up_One
5个回答
5
将Vertica用作事务性数据库是一个不好的想法。它的设计初衷是作为数据仓库工具。基本上，它会以优化的方式读写数据。大量的交易？这不是它的设计目的。
我建议您研究VoltDB。Michael Stonebreaker是Vertica背后的力量，他也创立了那家公司。他的基本哲学是Oracle、SQL Server等不适合高性能，因为它们被设计成可以处理所有任务。未来将拥有专门针对特定任务设计的数据库。
因此，他有一些概念用于数据仓库，这些概念最终演变成了Vertica。对于事务性数据库，有VoltDB。值得注意的是，该公司并非由HP拥有。
值得注意的是，我没有使用过VoltDB。从我所知道的情况来看，它作为解决方案不像Vertica那样成熟，但它似乎有很多潜力。
我建议您研究VoltDB。Michael Stonebreaker是Vertica背后的力量，他也创立了那家公司。他的基本哲学是Oracle、SQL Server等不适合高性能，因为它们被设计成可以处理所有任务。未来将拥有专门针对特定任务设计的数据库。
因此，他有一些概念用于数据仓库，这些概念最终演变成了Vertica。对于事务性数据库，有VoltDB。值得注意的是，该公司并非由HP拥有。
值得注意的是，我没有使用过VoltDB。从我所知道的情况来看，它作为解决方案不像Vertica那样成熟，但它似乎有很多潜力。
- geoffrobinson
1
谢谢Geoff，<br/>真正的Vertica设计不适用于OLTP，如果在OLTP中使用它，就会削弱它的WOS和ROS额外功能，这使它与其他数据库不同。<br/>奇怪的是，它仍然比OLTP RDBMS做得更好，到目前为止速度很快。<br/>至于VoltDB，像你说的，它还不成熟，这使得向客户展示变得困难。<br/>但这是一个值得关注的数据库 :).<br/>我将尝试将Vertica与其他OLTP RDBMS一起实现，也许在5年计划中，我们可以从中获得良好的回报！ - Up_One
3
HP Vertica是一种列式存储数据库。由于数据在列式存储中组织的方式并不适合快速写入，因此需要寻找解决方法。
HP Vertica通过拥有WOS（写优化存储）和ROS（基于文件的读优化存储）来解决这个问题。
数据被快速地从WOS移动到ROS中，ROS本身还有一个“合并”过程，将小的ROS文件合并成更大且更容易扫描的文件。
如果您尝试使用Vertica进行OLTP，则可能会很快就会遇到1024个ROS容器的默认限制，并导致大量ROS容器。
如果您使用某种排队机制将记录传递给存储，就可以减少ROS文件的数量并增加它们的大小。虽然它可以工作，但如果您想使OLTP系统在非常接近其写入活动的情况下读取数据，那么它就不适合该用例。
WOS / ROS机制是解决列式存储DB写入性能问题的简便方法，但从根本上讲，Vertica不是OLTP DB，而是一种数据集市技术，可以实现数据近乎实时地摄取。
- Dave Poole
3
谢谢回复，目前我已经在Vertica中达到了架构师级别！无论如何还是谢谢。 - Up_One
1更正一下，这里没有 1024 个容器的限制，而是有 1024 个分区的限制。我有一些拥有 6500K+ ROS 容器的表格，并且它们运行得非常好。容器的数量并不重要，直到你考虑设计为止。我们有许多投影和许多分区，这使得容器很多，但是如果你只有一个分区和一个投影，那么拥有大量容器将破坏你的性能。 - user1084563
@user1084563 错误。ROS限制不在表上，而是在每个节点的每个投影上。分区决定了这些ROS容器的粒度，因此如果不小心，可能会导致许多ROS容器，并且超过限制会引起ROS推回。 - woot
3
我认为这个问题有不同的解读方式。
- 你能把Vertica用作OLTP数据库吗？
首先，我需要对这个问题进行一些定义。OLTP数据库意味着数据库本身负责事务处理，而不仅仅是接收一些规范化的数据。
我的答案是绝对不能，除非它是一个单用户数据库。在普通的OLTP类型使用中，几乎没有引用完整性、没有引用完整性锁定、删除/更新时会出现表锁，而且你很可能会积累一个删除向量。
你可以通过一些广泛的中间件编程来解决其中的一些问题（分布式锁、避免删除/更新等）。但是为什么要这样做呢？有很多选项可供选择，它们不是Oracle，不带有巨大的价格标签，但可以为你提供OLTP所需的一切。
- 你能使用Vertica来导入和查询OLTP数据吗？
是的，绝对可以。最好利用Vertica的优势。在Vertica中，查询通常具有相当大的开销，即使是规范化的大量数据，也可以轻松地处理。我不会使用Vertica来主要运行点查询，抓取一些行。这并不是说你不能，但你不能像其他专门用于此目的的数据库那样进行并发操作。
简而言之，要使用正确的工具来处理正确的工作。我非常喜欢使用Vertica，但仅仅因为我喜欢挥舞锤子，并不意味着每个问题都是钉子。
- woot
1
非常好的表达！感谢您的精彩文章。 - Up_One
2
这个问题有点老了，但我会分享我的经验。
我不建议将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实时数据库。我们将负载批处理为5分钟间隔，这使得Vertica在插入数量/大小方面感到满意。这些批次使用COPY DIRECT插入，以完全避免WOS（仅在批量很大时才这样做，因为这会强制ROS容器的创建，并且如果您做得太频繁，则可能会产生不良影响）。我们尽可能拥有许多未分段的投影，以实现更好的扩展性，因为这使查询仅命中一个节点并在一个节点上分配内存。到目前为止，它对我们运行良好，我们每天加载约50亿行数据，并从UI实时查询。
我不建议将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实时数据库。我们将负载批处理为5分钟间隔，这使得Vertica在插入数量/大小方面感到满意。这些批次使用COPY DIRECT插入，以完全避免WOS（仅在批量很大时才这样做，因为这会强制ROS容器的创建，并且如果您做得太频繁，则可能会产生不良影响）。我们尽可能拥有许多未分段的投影，以实现更好的扩展性，因为这使查询仅命中一个节点并在一个节点上分配内存。到目前为止，它对我们运行良好，我们每天加载约50亿行数据，并从UI实时查询。
- user1084563
2
过了一段时间，但你的帖子仍然非常有用。随着时间的推移，我更深入地了解了Vertica，你所说的一切都是真实的，这都归功于“Write Once” - 这种权衡使得Vertica在某些方面表现出色。但正如你所做的那样：将MySQL（高事务）与这个超级快速的Vertica混合使用 :) 这是正确的方法。 - Up_One
你能否在我的网站http://www.aodba.com/en/about/上给我留言并告诉我你的联系方式呢？我对自动化方面有一些疑问。谢谢。 - Up_One
0
Up_one - 考虑电信用例 - 你是在做CDR还是其他什么？
回答你最初的问题，Vertica可能非常适合，但这取决于你如何加载数据，如何进行更新，你的数据大小和SLA是什么。我真的很熟悉这个领域，因为我曾经在一家电信公司实施了Vertica。
- Joe
1
1你使用什么工具来加载数据？ - Up_One
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接