VMware Tanzu Data Solutions Reviews

Asynchronous messaging; supporting data integrations between multiple applications on behalf of our many customers. RabbitMQ allows us to elegantly fan-out data to a variable number of subscribers, with almost zero effort.

We have been able to set up a messaging system that facilitates data integration between the software modules that we sell.

RabbitMQ allowed us to do this quickly so that we could focus on the business requirements, rather than divert our efforts to message broker implementations.

Once the architecture was proven, we were able to return to the RabbitMQ message layer in order to implement an HA cluster with a minimum of problems encountered.

Our business now has a fit-for-purpose information hub that we can apply across our systems. As the customer-base grows, we know that the hub can grow with it.

RabbitMQ is a solid, widely-used messaging system with a low cost-of-ownership. It is open, but with commercial support potentially available from Pivotal if required. (We have never needed it.) There is also a strong online user community.

One crucial feature was guaranteed messaging. We needed a solution that we could trust to not lose data.

Its built-in clustering capability allowed us to configure it as a highly available message broker, so that we can have confidence in the resilience of our architecture.

It can be scaled as well, although we have not tested this.

After almost two years' usage in our production environment, I am impressed by how stable the platform is - even when running on Windows Server 2012. Sure, we have had to tweak our set-up here and there as we have learned a few operational lessons along the way but overall it is very good.

RabbitMQ is clearly better supported on Linux than it is on Windows. There are idiosyncrasies in the Windows version that are not there on Linux.

The documentation for the Windows version is also less plentiful and less accurate.

The online community clearly provides better Linux support, but this naturally follows from the smaller Windows installed base.

There are also some potential concerns about how we maintain high-availability whilst also scaling out.

We have had no stability issues.

We have not used the scalability features yet.

We have not used technical support.

No previous solution was used.

The initial setup was straightforward. The online documentation was adequate and there is minimal initial configuration required to get up and running.

After that, it is simply a matter of experimentation with the various features and learning as you go.

This is an open source solution.

We looked at MSMQ, NServiceBus, Azure Service Bus, and Apache Kafka.

I would recommend that anyone who intends to deploy RabbitMQ on Windows should first consider whether a Linux implementation is a viable option for their situation.

We use it for data warehousing.

For complex queries, which would normally take a long time, and for reporting, it is very efficient. It doesn't take a long time for the execution of any report for the end-user.

• It's one of the fastest databases in the market.
• It's easy to use.
• From a maintenance perspective it's a good product.
• The segmentation, or architecture of the product is different than other databases such as Oracle. So even in 10 years, the data distribution for such segments will not affect other segments.
• The query performance of the product, for complex queries, is very good.
• It has good integration with Hadoop and Big Data.

The implementation of an upgrade takes a long time. But maybe it's different from one instance to another, I'm not sure.

Also, one of the disadvantages, not a disadvantage with the product itself, but overall, is the expertise in the marketplace. It's not easy to find a Greenplum administrator in the market, compared to other products such as Oracle. We used to work with such products, but for Greenplum, it's not easy to find resources with the knowledge of administration of the database.

If we face any issues they're normal and we open tickets.

It's scalable. I would rate scalability seven out of 10.

We hired one DB admin for Greenplum. If he faces any issues he opens tickets with the vendor, but most of the issues, 90% of them, he is able to solve without support.

We used to other products before, but when we worked with Greenplum, as compared to other products on the market, we found it's a good product.

Before Greenplum, we used Oracle but it was mostly obsolete. So we had to upgrade our tools. We needed to have a database with an API tool.

I'm not a professional in the setup but setup of the environment itself was managed by us. We managed between development, testing, and production servers. We are able to maintain it. I don't think it is complicated.

Most of the issues can be solved without referring back to support. A very small minority of issues required support from the vendor.

Pricing is good compared to other products. It's fine.

We did a comparison among some databases, one of them Greenplum. We assessed features, did a comparison in terms of the price, then we chose Greenplum. And we've retained it. We've found it's a good product, to date.

Oracle Exadata was part of the comparison, as was IBM Netazza. In terms of quality and the price, compared to the other products, we chose Greenplum. Also, to be honest, at that time we got a good offer: Use it for the first year with a minimal price. Then they opened a support contract with us, later. That was one of the advantages.

I give it an eight out of 10. To bring it up to a 10, they need to interact more with customers. They need to explain the features, especially when there are new releases of Greenplum. I know just from information I've found that it has other features, it can be used to for analytics, for integration with Big Data, Hadoop. They need to focus on this part with the customer. 

Also they need to enhance integration with other Big Data products. They need to adapt more, give more features, because customers are looking for these things in the market now. They have the product itself already, but they need to integrate with Big Data platforms and to open a bi-directional connection between Greenplum and Big Data. They need to focus on these features more.

But, from my perspective, for what I'm looking for, I can say it's a good product. Most of the features I'm looking for are available.

I am still comparing RabbitMQ and Kafka, but based upon the information I have gathered RabbitMQ is an awesome tool.

RabbitMQ will help to remove a lot of the complexities and create a loosely coupled codebase.

I like the high throughput of 20K messages/sec, and that it supports multiple protocols. The flexible routing is great as well.

The next release should include some of the flexibility and features that Kafka offers.

I have used IBM MQ software, but it was not applicable to this application.

I have evaluated and researched Axon, RabbitMQ, Kafka, and IBM MQ.

It is a very good appliance for data warehouse (DWH) usage.

• Very fast for query processing
• Parallel load
• Polymorphic storage

Before we had Oracle Exadata, some queries would take more than 20 hours of execution. With Greenplum, it take a few minutes.

It will be very useful if we could communicate with other database types from Greenplum (using a database link).

Four years.

No issues.

No issues.

Good. I would give their technical support a seven out of 10.

Yes, Oracle Exadata. Performance was the main criteria for switching to Greenplum.

It was a simple setup.

It is the best product with best fit for price/performance customer objectives.

We evaluated Oracle technology that we used before.

I encourage other customer to try Greenplum, specifically for DWH use. It is a very useful product.

• High performance
• Integration with Spring Framework
• Easy installation and configuration

We have been using GemFire for a Telco project, which we need process network data in real time and meanwhile access some reference data. GemFire has done a great job, as we have managed to process over 200,000 messages per second.

In build monitoring, the interface could be improved.

18 months.

With version 8.1, we had some issues while we were querying data from memory, but it has been fixed in version 8.2, and after that we have never had problems.

No, even when we had serious network problems, GemFire managed to recover.

A nine out of 10.

No, GemFire was always good enough for us.

Initial setup was easy. In older versions, the user interface was not helpful, but it's improved lately.

As a developer, I was never a part of this pricing decision. That's why I have no advice.

No, because we've started to use GemFire as part of a real-time intelligence platform.

Trust GemFire and use the benefits of their strong documentation.

Of particular value to our environment and applications are the following Greenplum capabilities:

1. Scalable (Massive) Parallel Processing (MPP) – The ability to bring to bear large amounts of compute against large data sets with Greenplum and the EMC DCA has proven itself to be very effective.
2. Fast load of data into Greenplum – We experience performance of approximately 1TB per hour loading data to Greenplum without the use of specialized hardware.
3. MADlib (madlib.net) – There are a number of statistical and analytical functions available within MADlib upon which we rely. Among these are linear regression, logistic regression, apriori, k-means, principle component analysis, etc.
4. User Defined Functions in Python (UDFs in PL/Python) – Where MADlib does not provide a direct solution to an application problem, the ability to quickly prototype and deploy user defined functions with Python has been effective.

We would like to see Greenplum maintain a closer relationship with and parity to features implemented in PostgreSQL. The current version of Greenplum is based on a fork of PostgreSQL v8.2.15. This edition of PostgreSQL was EOL by the PostgreSQL project on Dec 2011. The current version of PostgreSQL is v9.5.

We began production use in November, 2011. Alongside Greenplum, we're also using EMC Data Computing Appliance v2.3.3 (8/10), of which we have two and a half racks in production, and one and a quarter racks in dev/tests.

We had no issues with the deployment.

The only issues with stability we’ve experience have been the sporadic fail over of primary to mirror segments. The environment continues to operate in this instance with the failure of queries that were in flight at the time of the fail-over.

We have had no issues with scalability whatsoever.

The service and support we’ve received from both Pivotal and EMC has been exemplary. The exceptions to this would be:

1. The EMC Request for Product Qualification (RPQ) process – EMC DCA support is contingent upon EMC approval of all third party software installed onto a DCA. There have been times that this approval has taken as long as 60 days to process.
2. Root Cause Analysis of Greenplum Database Incidents – When Greenplum Database incidents have occurred (e.g. primary database segments failing over to their backup), and Pivotal has been called for support, the response has been near immediate (30 minutes or less). Additionally, the incident resolution provided has been equally expedient. Where this has caused some disappointment is the response to our request for a root cause of the incident. These requests tend to queue up and we don’t seem to get answers beyond the typical vendor response of “that’s been fixed in the next release”.

The purchase of Greenplum was our first interaction with Pivotal. We have been a customer of EMC for a very long time.

My primary reason for reducing points on this rating is due to the fact that Greenplum is based on a fork of PostgreSQL v8.2.15 (EOL by the PostgreSQL project on Dec 2011). The current version of PostgreSQL is v9.5. There are a number of current PostgreSQL features of which we would like to take advantage (JSON support, materialized views, full text search, XML support, column-based permissions, row-based permissions, etc.).

Legacy queuing systems have been replaced by RabbitMQ. The performance has been increased to a great extent.

The message routing is the most valuable feature. It is effective and flexible.

The debugging capabilities and testing flexibilities need to be improved.

The stability was fine.

There were no scalability issues as such. The scalability was fine.

I would give technical support a rating of 5/10.

Initially, we were using different queuing technologies. Due to the message routing feature and flexibility that RabbitMQ provided, we made the switch to this tool.

The setup was easy enough, once we had done proper research before the implementation.

The pricing is okay.

This product needs to be understood completely before implementing it. One should not be mistaken that it will replace the whole messaging system as such.

It allows for asynchronous development and horizontal scalability.

The queuing system is the most valuable feature. It meets our requirements.

After creating a RabbitMQ service, they provide you with a sort of web management dashboard.

The dashboard allows you see things on your queues, purge/delete queues, etc. The dashboard is pseudo-real time, refreshing every N secs/mins, specified with a drop down.

I’d like this dashboard to use web sockets, so it would actually be in real time. It would slightly increase debugging, etc.

We have not had stability issues.

We have not had scalability issues.

We never used technical support.

We did not have a previous solution.

The setup was straightforward. We are implementing using Node.js and the module we are using was easy to use.

I am not the one in charge of licenses and pricing, so I do not know anything about this.

We didn’t have any alternatives. Our company has a contract with PCF, so it was our only option.

For Node.js development, use amqplib. It’s a really good library for RabbitMQ.