OpenText Analytics Database (Vertica) Reviews

Vertica’s analytic capabilities are its key strength. It can aggregate and analyze data at massive scale and neatly bring the calculation logic to the data with external procedures in C, Java and R.

The Vertica architecture means it can process/ingest data in parallel to reporting and analyzing because of its in-memory Write-Optimized Storage sitting alongside the analytics optimized Read-Optimized Storage.

Which brings us to projections and the DB designer which intelligently structures how data is actually stored on disk to improve the queries you actually run against it. So tables are a logical construct which are operated on as per other DBMS systems, but there’s a whole next level of intelligence in optimization for querying that puts Vertica in another league.

Our consultancy has introduced Vertica to a number of clients, from small scale ones who benefit from the free tier and per TB pricing model to have a powerful analytics cluster fairly cheaply to large investment banks who have been able to handle data at a scale that wouldn’t otherwise be possible.

We’ve built a data ingestion tool to sit alongside Vertica for easy data loading, and I would personally like to see extended developer tooling suited to Vertica – think published PowerDesigner SQL dialect support, IDE with IntelliSense, and stored procedures which we’ve also had to build a work-around module for.

Personally, I've used it for three to four years (since v6), but a few others in Thorium Data Science have used it for longer.

We've had no issues. You do need to invest a little time to understand how to set things up and optimize for your workload, but it’s all well documented and there are consultancy firms who will happily help with that.

We've had no issues with the stability.

We've had no issues scaling it.

It's very good. HP have some technically smart guys and are willing to give access to them when you start using Vertica. We’ve had some great support from their engineering team with things like telling us about upcoming features (snapshotting, in this case), which were spot on for a need a client of ours had. We were looking into engineering a solution ourselves and HP happened to have just what we needed coming down the pipeline in the next version.

We previously used Exadata, which is typically very expensive by comparison. This is because Oracle throw top end hardware at the problem as opposed to
HP Vertica’s commodity hardware and smart software approach.

It takes some time to come to grips with the various considerations. I’d suggest bringing in a consultant if you don’t have the time or inclination to do it yourself as it takes going through and install and configuration one or two times to really understand the implications of the different options.

The implementation itself is excellent with fantastic features, speed and scalability. They lose a point only for the development experience which relies on third party tooling like squirrel, and not having SQL based stored procedures.

Go for it! Try the pre-installed VM which HP offers to have a play with it and get a feel for it. It can certainly scale better than any other RDBMS and pushes the envelope of SQL analysis so you can query/analyze/report “BIG-DATA” without having to resort to the complications associated with Hadoop & unstructured data analysis. If your data is structured and large Vertica is what you need.

Two of them:

• The core feature, meaning their highly efficient columnar file format and execution engine along with a great coverage of ANSI SQL, provides our analysts with a highly expressive and performing platform.
• The extensibility and efficiency provided by their C++ SDK.

Before Vertica, we used a combination of sharded RDBMSs and Hive: the typical runtime for a query was in the hours. It's now in the seconds, with way
more data than then (we're talking hundreds of terabytes).

Whatever's out, the core is not always as great as the engine, especially their first version. That's true, for example, for the Kafka or Hadoop integration.
But they're getting better release after release.

Four years.

Vertica's code, being designed to use the hardware at its maximum, is very sensitive to low level changes such as kernel bumps or GLibC upgrades. It's also important to do tests on the storage layer (RAID controller + disks).

The default layout (all nodes running spread) introduces latencies in query planning when you reach about 60 nodes, in our experience. Switching to a large cluster (one control node per rack) would be advised, way before reaching the 128 nodes hard limit.

It's really great. One of the best I had to deal with. They also assisted us during the development phase of the custom components we've designed.

Not really in the same area (MPP databases). However, we ran benchmarks back then against a bunch of competitors and Vertica was one of the fastest, while
being relatively cheap and able to accommodate our hardware.

The setup per se was pretty straightforward. However, it took us some time to design the most efficient loading pattern from Hadoop.

Nothing to advise really; try it out first, it's free up to three nodes and 1TB, and then get in contact with their sales guys.

We did evaluate mostly SAP HANA and SQL Server PDW back in 2013, along with a bunch of OSS solutions.

If you plan to use Vertica for different workloads (in term of IO patterns, query frequency, dataset structure) plan to split your clusters: the mother of all cluster patterns becomes quite difficult to manage at some point. We today have around 20 clusters for different usages.

• Quick retrieval of data
• Fast upload of data

Vertica was a key component in a billing systems analytic engine. Among other functionalities, the engine is constantly analysing offline usage and sending customers alerts when they exceed certain limits.

It would be hugely beneficial if HP Vertica offered stored procedures.

I have used it for five years.

As a green field solution, the features of the application were not clear and the system integrator was not up to the mark.

We did not encounter hardly any stability issues.

We did not encounter hardly any scalability issues.

It was a green field solution, and getting quick customer service was a challenge.

Technical support is scarce in Australia.

We did not previously use a different solution.

Initial setup is straightforward.

We implemented it through a vendor. The team was good, but they were not experts.

Vertica is an excellent data warehouse platform. Its column-oriented architecture makes it a powerful database specialized for data warehouses. Data should be designed around a star schema.

Data is accessed via SQL, which most developers are already familiar with.

Vertica is "catching on" in the software market, so its user knowledge base is gradually increasing.

The price seems reasonable, the product is reliable, and it uses SQL, so developers don't need to learn a new language.

It provides very fast results for analysts running reports. These reports are crucial to help our clients strategize their targeted marketing.

Vertica is relatively new and needs some polish and refinement, but its core functionality is excellent.

Documentation overall is fair to good; but lacks continuity or cohesiveness in places.

Although its knowledge base is increasing, it is still relatively small, making some issues difficult to diagnose without consulting Vertica Tech Support.

Vertica does not have native stored procedures or a native scripting language. Instead, external functions (which can be called from within Vertica) using Java, C++, Linux shell scripting, etc., are supported. This is an unpleasant surprise for many developers, but I feel this has not been a big hindrance in my experience. Complex business logic probably does not belong in a high-performance data warehouse platform. Rather, this should be taken care of during ETL.

I have 3+ years of experience with Vertica.

Deployment had only a few minor issues that one finds with most software.

It has been very stable.

I would give technical support 8 out of 10. They have been responsive, professional and knowledgeable.

• I have used traditional, row-oriented relational databases like SQL Server, Oracle and PostgreSQL for data warehousing. They are optimized for handling transactions, not data warehousing. Vertica is optimized for data warehousing and that was very clearly demonstrated in its ability to scan large amounts of data at high speed. It is also very fast at loading data.
• Vertica uses a distributed, shared-nothing architecture which allows for nodes to be added (or removed) according to need. This is a very scalable architecture which is very difficult to achieve with traditional row-oriented databases.
• Compared to Hadoop, Hive, and Spark, Vertica is much more adept at handling concurrent users.

Installation is recommended for someone familiar with Linux (the only OS available for Vertica). For developers with a Linux background, the issues are very manageable. Documentation is good for the installation, so follow it carefully, step-by-step.

Implementation was in-house. No significant issues were encountered.

ROI is good because Vertica, while not cheap, is a better performer than traditional databases.

• Understand that its strengths depend on a good data warehouse design using a star schema. It was never intended for high volumes of small, randomly distributed inserts, updates and deletes that are typically found in transactional databases.
• It uses column-oriented architecture. It is important to study aspects of this architecture and to implement them and modify them as the database grows in size and more users access the system. This is especially true for projections, run-length encoding, sorting and column ordering. It is important to understand these aspects in order to truly maximize Vertica's performance.

It has a very good design with high query performance. It provides the scale out capability by adding additional servers instead of scaling up the servers.

It has provided much better performance than SQL Server for big data analytics.

I would like to see integration with the latest Hadoop ecosystem.

We have used this solution for three years.

It is usually very stable, but we occasionally see some nodes going down.

There have not been any scalability issues. We are able to support trillions of data elements by adding more servers.

The technical support is pretty good. I would give it a rating of 9/10.

We used to use MS SQL Server. It is good for data transactions, but it is not good for big data analytics.

It is pretty expensive, but it is worth it if you need the production capability that it can support.

We evaluated SQL Server and Teradata.

It is worth a try if you are looking to provide a high-performance, big data analytics database.

The most valuable feature in the solution is ad hoc data analysis. It improved the SLAs for our end clients.

There are some predictive analytics features that we might be using which we thought were part of IDOL, but it seems some are also already part of Vertica.

The stability is super good, especially when you scale out.

Before using Vertica, we used to have problems scaling out because we increase our customer base significantly each year. We have more than 20.000 clients now. Since we implemented the Vertica solution, it is much less effort to maintain scalability.

I haven’t used technical support, but the IT colleagues definitely have. I think they are rather happy with it. I haven't heard any complaints. It could be quicker sometimes, but that's always the case with big processes.

Previously, we were basically using an old school setup based on a relational database. I’m not sure which database management system it was.

The performance of the previous solution was no longer adequate to support the growth we were seeing in our business. Response times were up to 10-15 seconds on different queries. We needed to get that down to under a second.

Now we’ve moved to a real big data analytics solution.

I wasn’t involved with that, but I think that those who did it were happy with the support.

When we chose a solution, we were looking at scalability, maintenance, and ease of use. With Vertica, we can access big data using regular SQL queries.

We are evaluating storage and database solutions for an OLAP application with following requirements:

• Extract, transform and load high velocity and volume of a numerical data stream on a distributed system.
• Interactive (less than 20 sec latency) query performance for critical group-bys.

Vertica is superior to other solutions in query performance.

We have not yet integrated the solution.

Vertica’s resource demands for RAM and I/O during load and storage were challenging for our platform. They recommend reserving 40% of storage for Vertica’s internal usage. Lower I/O usage during load is also highly desirable.

The solution is not integrated into our product. We engaged in a PoC for 2-3 months in 2015 and put the evaluation on hold due to other project priorities.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

The level of technical support by the sales engineers during our PoC was excellent.

Well-organized, online documentation made the initial setup fairly straightforward.

Our in-house team worked on the PoC.

We evaluated a number of open-source and proprietary databases, as well as an in-house solution. Our PoC has been put on hold and we have not made final decision on a solution.

The auto-distribution to all nodes for fault tolerance and query performance was pretty amazing.

Our data warehouse at the time was a multi-terabyte PostgreSQL cluster. It worked really well, but we wanted to increase the size to many TB's and our due to our query and loading patterns we found greater performance from Vertica's multi-node warehouse.

In the versions I worked with, if a majority of the nodes were being loaded under heavy, sustained rates the nodes would see some dramatic decreases in performance due to the data shuffling that needed to occur between all the nodes. To work around that we ended up doing most of the loading in one or two nodes and that helped significantly.

The synchronizations problems occurred when loading about 10 billion events, at a rate of about 100k tuples/second/node across 5 nodes. One of the suggestions from Vertica engineering was to increase the number of nodes to offset how much data was being sync'd per node.

Extensive use of Vertica 5 as a production datawarehouse, and a POC for a client.

In earlier versions Vertica, it could sometimes be a pain to install on multiple nodes. In the most recent versions most of that pain has been fixed. Stability in earlier versions was compromised at times when the majority of the nodes were under heavy write loads.

The service and support from Vertica was excellent. Every tech and sales rep I dealt with was very responsive, pleasant, and helped me solve any engineering issues we ran into in very short order.

I have used Greenplum and Postgres extensively. The latter is an excellent general-purpose database and is entirely suitable for most data needs, however Vertica works really well in cases where you are storing and querying a lot of data that can be compressed and stored in columnar format, and you need your data auto-balanced across many nodes.

The installation procedure was reasonably straightforward, but earlier versions of Vertica were a bit more tricky due to libraries and dependencies. The docs were unclear in a few places during the installation, particularly with OS' that were not fully compatible with the required libraries. I expect those issues have been resolved in the newest version (8 at this time).

Implementation was done in-house, with excellent support from the Vertica engineers.

My advice is to clearly define your expectations, and benchmark performance in real-world-like environments. If you expect to be executing 100 queries per second and loading 10 million tuples per minute, then test that, and test several times that so you collect measurements about where the system is liable to break down.