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.

• 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!

The MPP element is crucial, so far as it allows us to query millions of rows at a time, at speed.

The previous data warehouse was built in Oracle. One of the things which has improved in GreenPlum is that we can query millions of rows at speed, without creating lags. We’ve also built far more views; slowly changing dimensions can instantaneously update without creating the issue of having to rebuild tables to reflect new hierarchies, for example.

We found some issues with larger tables that have daily data appended, where after a while this seems to create lag in the query speed. This might just have to do with local knowledge rather than the product itself.

We have a table which is currently contains 27.6m rows and has a daily delta added to it of roughly 16.5k rows per day. While this isn’t particularly large, we have noticed the table begins to perform poorly when queried, in spite of having set up a VACUUM process to be performed weekly. It may be that the VACUUM process needs to be performed more frequently (like daily), but we’ve not yet found the optimal way of maintaining this particular table.

It’s worth saying that this is one table out of over 400 perfectly well performant tables and views in the same database. Hope that helps,

I have used for approximately 30 months.

I have not encountered any deployment, stability or scalability issues.

I have not raised any service issues/tech queries, so I can’t really say.

We used Oracle previously. We based our choice on expertise in our US operation, where we have a GreenPlum expert who provided some amazing use case examples to help us in our selection process.

Implementation was done in-house.

Not within my area I’m afraid, but I understand that this was a very good fit from an ROI point of view

Investigate whether this solution works for you. It is worth creating a rating matrix to compare other similar products, and it is very useful to look deeply at whether the third-generation MPP software might be a good fit.