VMware Tanzu Data Solutions Reviews

The most valuable feature of Greenplum is the Massively Parallel Processing (MPP).

With this solution, we've reduced load on the OLTP systems.

The fact GreenPlum is using an older version of Postgres means developers coming from other products will find many missing features in PostgreSQL, features which you would assume are standard.

Greenplum is based on Postgres 8.2.15 which was released in 2009. While the SQL syntax and functionality has continued to evolve in other platforms in the ensuing years it appears to have stagnated in Greenplum.

We haven't had any issues with deployment.

It's been stable for us.

It's scaled for our needs.

The community around GreenPlum is very small, making it difficult to learn from others experience via forums or blog posts.

With VMware Tanzu Greenplum, one can make a huge database table and analyze the queries by adding in the SQL command. Some hint or command for the query goes over the multi-parallel execution. Also, queries can be sent quickly to other database systems.

VMware Tanzu Greenplum needs improvement in the memory area and improved methods for quick access to the disc. So, one of the quick goals of Greenplum must work on enhancing access to the disc by adding hints in the database.

I have been using VMware Tanzu Greenplum since 2017. I have installed the ring through the Dell Dell Platform, the EMC platform, and the DX100.

We use the VMware Tanzu Greenplum support directly, the community for open source Greenplum database. I rate it a seven out of ten.

Neutral

The initial setup was complex because of the architecture we used. Ten people are needed to maintain the product, of which eight are DBAs, and two support the operating system as the administrator.

For the support network of the product, overall installation, use of the database, and improved database and support, I rate the solution an eight out of ten.

The use case involves the transferring of messages between services. It includes asynchronous messaging and I also need messages flowing to multiple microservices. In this case, it's basically a fan-out mechanism.

RabbitMQ is configurable and quite flexible.

The performance is fast and reliable.

It is easy to use. The addition of more queues and more services can be managed very easily.

There are some security concerns that have been raised with this product.

The configuration works with a config file, where all of the controls, including that of the administrator and user access, are stored there. The security isn't very stringent or very elaborate.

RabbitMQ is a stable solution.

This is a scalable product. There are six or seven services that are connected and using it.

I have not been involved with anything that necessitated contacting the support team.

Previously, we were using MSMQ, which is the Microsoft Message Queuing service. However, with the new version of .NET 4, support for MSMQ was no longer available. We could no longer get the libraries. As a result, we had to switch to a different queue mechanism. 

I have also used Azure Queue.

The initial deployment was quite easy. It took less than half an hour to get it up and running.

I deployed it myself.

The pricing for RabbitMQ is reasonable. It is worth the cost.

We researched ZeroMQ, RabbitMQ, and Kafka. We found that Kafka was a bit of an overkill because our requirements were quite simple. RabbitMQ was pretty easy to set up, which is why we chose it.

My advice for anybody who is implementing this product is to establish your users and exchanges properly.

In general, I'm quite comfortable with RabbitMQ. It satisfies my requirements and the main complaint I have is about the security.

I would rate this solution a seven out of ten.

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.

We can integrate the Hadoop with DCA V2. This will be huge development in the big data technologies.

It increased the read/write process because of it MPP architecture.

EMC already developed DCA V3, But if the hardware is little stable, I prefer DCA V2.

I am from a support background, and have used this on multiple accounts, for the last four years.

There have been no issues with the deployment.

Hardware failure is a concern.

We have had no issues scaling it for our needs.

Technical support is excellent.

I know many customers are migrating from Oracle to Greenplum due to its faster processing.

It is straightforward,open source system.

Better chose EMC to perform the implementation. More over, it is not complex and we can do it easily in our environment with a little knowledge.

Greenplum is an opensource system, but they do charge for support.

Installation is very simple, make sure to set the configuration values based on the requirement.

Our primary use case is as a messaging broker between enterprise applications. It makes for reliable and secure communication.

The most valuable feature for me is that it is open source. The licensing costs are really low and they are transparent. You know how much you are going to pay if you want the commercial version. If you want the open-source version, you do not have to pay anything and that is just as reliable as the commercial one.

I would like to see the performance of the administration portal improved and additional messaging protocols.

I have been working with VMware RabbitMQ for the past eight years.

It is highly stable, reliable, and persistent.

VMware RabbitMQ is definitely scalable.

Technical support is excellent.

Positive

The initial setup was very easy and takes about five minutes to install.

If you want to pay for the licensing it costs eight hundred dollars per CPU core annually with the support.

I would give the following advice prepare a demo, with the vendor and check if it really applies to their needs. I would rate VMware RabbitMQ a nine out of ten.

• Transaction processing between microservices
• Message queue integration with Spring and RPC over Rabbit.

• Quick and simple to implement

• Easy to build proof-of-concept modules based on working examples from Pivotal.

• Out-of-the-box setup and configuration
• Great documentation and support from Pivotal
• Very useful management console

• Difficult to integrate with automated test and CICD 
• Moving beyond basic configurations can be challenging
• Not clear how to implement durable subscriber connections
• Not clear how a Rabbit service restart allows subscriber auto re-connect
• Service cluster failover depends on shared disk infrastructure.

• The publisher and consumer ACK
• High availability
• Queue mirroring
• Exchanges and topics
• Supported programming languages with well-tested libraries

It provides us with a much better scale. We have never lost a single message with RabbitMQ.

The shared RabbitMQ Cluster has improved stability and maintainability of each application. We only have one message bus now.

I want it to reorder messages in a queue, if possible. If you could reorder messages in a queue directly, then you would not need a sequencer to reorder messages outside of RabbitMQ.

I have used this solution for seven years.

There were no stability issues.

There were no scalability issues.

We haven’t needed to use any support yet.

Initially, we were using the BizTalk and Redis solutions. The reason why we switched over was because we were looking for better support in Celery task management and other programming languages. We were looking for a much more stable and secure solution.

It is very simple to set up for basic usage. Clustering is a bit more complex, but it is also easy to do.

The RabbitMQ open source version works fine for almost all the use cases that I came across.

We looked at the Redis solution, but it was not a good fit for our needs.

Read the documentation and follow best practices. Make sure Erlang is up to date!