The compute and processing engine returns the queries fast and let us use our analysis resources in a better utilization.
The concurrency got better in this version and we are able to run more queries and load concurrently.
The compute and processing engine returns the queries fast and let us use our analysis resources in a better utilization.
The concurrency got better in this version and we are able to run more queries and load concurrently.
We built an internal dashboard using the MicroStrategyto increase visibility to our management and our employees. Also, we built tool to expose the data to our selected partners and users to create better engagement with our platform.
We've been using Vertica for a year.
In case of one HD failure in the cluster, the entire cluster got slower. We feel that it should be able to handle such issues.
No.
The support was slow and didn’t provide a solution in most cases. The community proved to be the better source for knowledge and problem solving.
Pretty straightforward, the installation was simple and we added more nodes easily as we grew.
Vertica is pretty expensive, take into account the servers and network costs before committing.
We evaluated both AWS Redshift and Google BigQuery.
Redshift didn’t fulfill our expectations regarding query latency at high scale (over 60 TB). Regarding BigQuery, we found the pricing structure pretty complex (payment per query and data processed) and harder to control.
Don't plan a production usage on high-scale straight on Vertica, use caching or other buffers between the users and the DB. Get yourself familiar with the DB architecture before planing your model (specifically, make sure you know ROS/WOS and projections). Try to avoid LAP before your schema gets stabilized.
Columnar storage makes 'hot data' available much faster than a traditional RDBMS solution. Also, Vertica scales up quickly and maintains good performance.
Performance management of high-traffic sites - Vertica's ease of scaling has been invaluable for one of our main customers.
I'm concerned that HP Enterprise has sold their software business, and worry about future investment to enhance predictive/machine-learning capabilities.
3 years.
Not really.... Vertica shines on stability.
No, scalability is also a strength of the solution.
9 out of 10. HPE has some excellent engineers who are eager to help us make Vertica work well.
I've been a 'full stack' data expert for years, started on Oracle and SQL Server, moved to Hadoop, Mongo, etc, but Vertica was the right fit for large enterprises with high performance demands and ease of scalability.
Initial setup is a bit clunky, like most complex, tunable products can be.
Negotiate when their fiscal year is about to close :)
It's a solid product that keeps its promises. I do worry about HP Enterprise's sale of Vertica to Micro-Focus
Rating: 8/10 - it works very well, but some customers worry about 'Vendor lock-in'.
Speed in query in general and specifically in aggregate functions on multi-million rows tables.
Data Warehouse response times have decreased of one order of magnitude with respect to the previous solution (SQL Server + Oracle).
Sadly, it does not support stored procedures in the way we are used to thinking of them. There is the possibility to code plug-in in C++, but that's out of our reach. Correlated sub-queries are another point where we'd love to see enhancements, plus the overall choice of functions available. ETL with SSIS was not as easy as one we had expected (must remember to COMMIT and we had some issues with datetime + timezone, but that's was probably our fault).
OleDB and .NET providers need some touches; and another great improvement would be support for Entity Framework, which so far I haven't seen.
There is no serious graphical IDE for HPE Vertica, that's frustrating. One free option available is DbVisualizer for Vertica, but it's a bit basic.
One year.
We have a one node cluster on Red Hat and last week the DB went down. The setting to restart the database is not very intuitive and by default the DB does not restart alone.
After a reboot, which may be good in some environments, but leaves you with an insecurity feeling.
Our DB isin in the tens of Gigs, we did not need to scale yet.
N/A, not used.
We had SQL Server, switched for money reasons and space. But we're not sure yet, SQL Server is way more stable and predictable.
No, the documentation is scarce on non standard setups. We had to create a virtual machine locally, set it up and then upload it to AWS.
We use the free community license, plenty of space for our environment. If I had unlimited budget I'd buy a preinstalled instance on EC2, much faster, but costly.
Netezza, but I didn't like it. For no particular reason, but the feeling was not right. Redshift - I was not impressed by the performance. Google Big Query - we tried it.
Do COMMIT, and enable/enforce constraints because by default they ARE NOT!!!!
We're able to retrieve queries nearly instantaneous for our custom analytical tools we built on top of Vertica.
More frequent updates.
1 year
None.
None.
Very knowledgable team which has provided excellent documentation for every issue we've had to troubleshoot.
MonetDB -- unstable, frequent crashes.
Straightforward, was able to get the database up fairly quickly with minimal effort.
We're still using the Community Edition (CE).
MonetDB, Cassandra, Amazon RedShift.
Great product, very mature and robust. Vertica is able to scale to meet our demands as we scale our business 10x.
The fact that it is a columnar database is valuable. Columnar storage has its own benefit with a large amount of data. It's superior to most traditional relational DB when dealing with a large amount of data. We believe that Vertica is one of the best players in this realm.
Large-volume queries are executed in a relatively short amount of time, so that we could develop reports that consume data in Vertica.
Speed: It's already doing what it is supposed to do in terms of speed but still, as a user, I hope it gets even faster.
Specific to our company, we do store the data both in AWS S3 and Vertica. For some batch jobs, we decided to create a Spark job rather than Vertica operations for speed and/or scalability concerns. Maybe this is just due to the computation efficiency between SQL operations vs. a programmatic approach. Even with some optimization (adding projections for merge joins and grouped by pipelined), it's still taking a longer time than a Spark job in some cases.
I have personally used it for about 2.5 years.
I have not recently encountered any stability issues; we have good health checks/monitoring around Vertica now.
I have not encountered any scalability issues; I think it's scalable.
N/A; don't have much experience on this.
We do have some pipelines accessing raw data directly and process it as a batch Spark job. Why? I guess it's because the type of operations we do can be done easily in code vs. SQL.
I would recommend using Vertica for those people/teams having large denormalized fact tables that need to be processed efficiently. I worked around optimizing the query performance dealing with projections, merge joins and groupby pipelines. It paid off at the end.
Speed and performance: Vertica stands top among its peers in the MPP world, delivering unparalleled speed and performance in query response time. Its distributed architecture and use of projection (materialized version of data) beats most of its competitors.
This product is used for in-database analytics for reports and queries that require very fast response times. Complicated multi-table queries perform very well, and the company has improved on business operations looking at hot data from various dimensions.
Projections take up a lot of space and hence, compression can be improved. Installation can be more intuitive via a simple, lightweight web client instead of the command line.
I have used it for two years.
While Vertica is otherwise stable, sometimes there are issues with restores to the last checkpoint.
I have not encountered any scalability issues.
Technical support is very good and knowledgeable.
I previously used Postgres; switched as performance suffered due to data growth.
Initial setup was straightforward through the command line.
Negotiate; with HDFS, storage is cheap. Vertica charges per terabyte of compressed data. But the underlying architecture materializes data in a different order and hence space utilization is always heavy, even for a single table; add to that the replication factor.
Make sure the data and table structures are compact. Vertica will create many versions of the same data as a projection and isolated tables will increase size, increasing licensing cost.
We use it for analytics (marketing).
I have used it for three years. I worked with versions 4-7.x.
I occasionally encountered stability issues (more so in earlier versions).
I have not encountered any scalability issues.
Technical support is excellent.
Initially when I first started, the documentation, etc. available was scarce. However, this has improved substantially.
I was used to OLTP and DWH solutions based on technology such as Oracle, so some of the concepts are quite different.
Before choosing this product, other options were considered, e.g., Kognitio.
It’s still not mainstream (especially in the UK) and I would say to some extent still ‘improving’ at each release, but it is enterprise ready and a hugely cheaper option than some.
We did some like-for-like comparisons between HP Vertica and Oracle Exadata (work load / timings) and the two compared favourably, with Vertica being faster than Oracle in all but the biggest and most complex of queries.
The biggest, most valuable feature for us is the clustering aspect with a share-nothing mentality. Most clusters usually require their own shared storage, shared subnet, etc. and this becomes a pain and a nightmare to maintain.
The second most valuable feature is that it's very easy to maintain. It's a breeze once you know how to handle it with your scenario in mind.
Loading raw data and leveraging column store to quickly aggregate the values as well as run a general analysis were the biggest improvements we found. Before, we had to scrub the data or reformat, load it, possibly scrub it some more, and then run the first set of analysis, and so on.
With Vertica, we were able to combine some of these steps, such as loading gzip data directly into the table and leveraging R in Vertica to run all of the analysis.
Developer Tools - Vertica really needs some kind of IDE plugin for a system such as Eclipse or IntelliJ. Developing external functions in Vertica can kind of be like shooting in the dark sometimes. Also, an improved monitor or monitoring with alerting built-in that actually works would be a welcome addition.
They truly need a Python or some script that can handle all of the low-level system changes for you and find out how the customer has heavily modified their nodes before the install. Some automation here would help a lot.
The product overall is a great product, however management tools as well as monitoring tools are lacking. The product does, however, offer a lot of information in the form of system views and tables, but most of the data is hard to translate with out the help of their support team.
I have used HP Vertica in multiple companies over the last four years. We currently have it running on a three-node Centos cluster and a six-node Centos cluster.
There have been no issues with the deployment.
There have been no issues with the stability.
We have had no issues scaling it for our needs.
Like everything else HP has support for, the support is very poor. You normally have to threaten to leave, not buy support renewals, or call your sales rep to talk
to anyone who knows anything about the product. The community normally knows more than support and most of my questions or issues were resolved by searching the old community boards while I wait for overseas support to ask me to send them the logs again for the 50th time.
I have previously tried SQL PDW, Mongo, Cassandra for alternatives. Even though all of those products are in different landscapes, the Vertica column store ended up being the best thing that was needed.
It is straightforward if you read the documents and have mid to senior-level knowledge of Linux. Non-Linux admins will find the setup complex and cumbersome since most are Windows admin and they want point-and-click.
We implemented through our in-house team. You need to read the docs, then read them again, and then make yourself a cheat sheet. Once you have done the setup for a two-node cluster, do some Research and Development before taking the time to do a large production cluster or buy the license.
ROI is great compared to the previous solution, SQL Server.
TCO is much lower given the Linux OS and the fact that Vertica is licensed by data size and not node count. The best advice for licensing is to make sure you have a proper data retention policy in place and well-documented as well as some growth expectations before buying. Following this, it will make sure you don't over or under buy.
If you are not Linux savvy, find a person that is. Make a cheat sheet with the commands and/or steps for your environment. If you are in the cloud, make sure to understand the networking aspect is completely different in AWS from it will be in your local data center. Failure to plan is planning to fail with Vertica implementation, and try not to mess up the spread as it's a pain to fix. If you read the documents, you will see what I am talking about.