我的系统中有一个大型分析模块，并计划使用 vertica。有人建议我们在应用程序的其余部分（标准的 crud 应用程序和我们域中的模型）中也使用 vertica，这样就不要管理多个数据库。
vertica 是否适合这种双重场景？
问问题
417 次
5 回答
4
高频更新可能是 Vertica 落后于最坏情况的地方。我会避免将它用于此类数据模型。
于 2012-08-12T21:32:38.523 回答
2
Alec - 我想恭敬地挑战您对 Vertica 的评论。在加载之前，您绝不需要对数据进行非规范化或排序。Vertica 还保持着所有数据库中数据加载速度最快的记录。
您还谈到 Vertica 无法像 RDBMS 那样进行复杂的分析。Vertica 是一种 RDBMS，可以比任何其他 RDBMS 更快地进行分析，并且他们一遍又一遍地证明了这一点。
至于您的数字，在我的用例中，我每秒将大约 500 万条记录加载到我的 Vertica 集群中，并且有 100 条数十亿条记录。
所以 Yaron - 我强烈建议您先查看 Vertica，然后再根据此信息排除它。
于 2012-08-24T20:34:09.870 回答
1
就像现在经常发生的情况一样，一个有意义的答案取决于你需要做什么。一般来说，“大数据”解决方案是从 RDBMS 系统中的大数据量缺陷发展而来的。没有任何“大数据”解决方案可以与 RDBMS 系统的核心功能（即复杂分析）相媲美，但 RDBMS 系统对于大数据量处理来说是较差（昂贵）的解决方案。目前的实际解决方案必须是混合解决方案。加载数据后，Vertica 可能会很好，但我相信（不是专家）它需要在加载之前对数据进行非规范化和预排序以达到最佳性能。对于大数据量，这可能会显着增加所需的资源。使用一个系统来满足您的所有需求肯定有好处，但保持您的选择开放也有好处。
我采用的方法是存储和索引新数据，然后根据需要向各种报告/分析引擎提供特定的提要。这将原始数据的收集和存储与复杂的分析处理分开。如果您有兴趣，我很乐意提供更多详细信息。这种分离解决了一直存在于数据库系统中的核心问题。过去常常听到“快存、慢报或慢存、快报，但不能两者兼得”。在过去几年中，对完整解决方案的搜索催生了许多 NoSQL 产品，这些产品通常用于解决“快速存储”任务。一些系统还通过将数据存储在内存或缓存中来提供令人印象深刻的查询性能，但这需要许多服务器来处理大量数据。我相信 NoSQL 和 SQL 解决方案可以而且将会是集成的，
为了给你一些背景信息，我处理每天至少加载 10 亿条记录的场景。如果您每天处理 1 亿条记录（大是相对的），那么您的 Vertica 方法可能就足够了，否则我认为您需要扩展您的选择。
于 2012-08-13T11:09:04.000 回答
1
测试一下。每个用例都是不同的。假设 Vertica 是适用于每个用例的解决方案，几乎与为每个用例都使用 MongoDB一样糟糕。
Vertica 是一个高性能分析数据库，面向列，旨在分析非常大的数据集并进行水平扩展。它也很昂贵，难以管理，并且文档参差不齐。显然，在正确的环境中获得的回报很容易值得付出努力
MySQL 是一个传统的 RDBMS，面向行，旨在对结构化数据之间的关系进行建模，并且在单节点规模上运行良好（尽管许多公司已经对其进行了改造，取得了巨大的成功，例如 Facebook）。它的文档非常完善，似乎可以在任何平台、语言或框架上运行，任何人都可以使用。
我的猜测是将 Vertica 用于员工通讯录数据库就像穿着 3000 美元的西装出现在蓝领工作中一样。当然可以，但它是适合这项工作的工具吗？也许如果您已经拥有 Vertica 许可证并且您的应用程序已经拥有必要的数据适配器/ORM/等...，请继续尝试。它仍然是一个 SQL 数据库，因此在这些情况下它应该可以正常工作。如果您的目标是最少的编程而不是最佳性能，那么为什么要使用 Vertica？听起来更简单的东西会更理想。Vertica 可能会或可能不会在常规 CRUD 应用程序环境中提供更好的性能，因为它没有为此进行优化，但您始终可以同时测试并查看。
于 2012-11-15T21:05:03.663 回答
1
Vertiy 有很多高并发问题（每分钟很多小事务） 在 MPP 系统中，数据是跨集群分段的，任何时候都需要获取集群级别的锁（主要是在提交时间），所以很多提交很多集群级别 X锁。高并发在 DWH 和报告中的用例较少，因此 vertica 非常适合。在大多数情况下，需要为此提供高并发性的 OLTP 解决方案（如 CRM 等）是非常糟糕的选择
谢谢
于 2016-03-01T20:53:11.497 回答