VMware Tanzu Data Solutions Reviews

Greenplum is an MPP architecture database. Data can be distributed across multiple nodes and strong distribution will allow queries to execute on all segments at once, which is very powerful. As long as we have good SQL knowledge, we can start playing in the platform. Greenplum uses Postgres and ANSI Standard SQL. Also, it supports many other procedural languages, such as Python, C++, and Pearl.

Greenplum is a high powered, multi-node database that was chosen for its capacity to ingest and query data at extremely high rates of speed, enabling in Database Analytics and Statistical output on granular levels of data that was otherwise inaccessible before its deployment. We were able to analyze and produce output on large volumes of data very quickly which saved us lots of time (we used to wait for hours to get the same output). The management was able to get insights very quickly so that they can make informed decisions.

I used Greenplum between Aug 2011 – Aug 2015. Almost all the members in the analytics team used Greenplum on a daily basis.

There were no issues, and it was doing what it was supposed to do.

There were no issues, and it was doing what it was supposed to do.

We had a pre-sales consultant who provided end-end solution about the product. Also, he was working with our data and clearly demonstrated the advantages of Greenplum. After we purchased the product, we were provided a full time consultant who had extensive knowledge about the product. He was primarily responsible for providing hands on experience on projects and also did excellent job of teaching everyone and bringing everyone up to the speed on the new platform. We also had a technical person offshore who was responsible for fixing things if something breaks up or any other issues.

We did use other products in the company but it wasn’t an MPP architecture database. Our data was getting bigger so we needed something with MPP architecture to tackle big data challenges so Greenplum was considered. It was a management decision to purchase this product (not sure whether other similar products were considered or not)

All the set up I believe was done by Greenplum team.

I didn't have any visibility on the pricing and licensing. But I can say that, we needed product like Greenplum to store, manage and analyze huge volumes of data which can be daunting task

Greenplum is a MPP (massively parallel processing) database which is extremely fast. If people are dealing with very high volume of data, it is definitely a product to consider seriously

The most valuable feature is it’s robustness. Message queues need to be extremely reliable as they are the glue between system components.

Also, the speed is important and its good scaling capabilities.

It allows developers to focus on application functionality without having to re-invent interprocess communication, which is difficult.

I also allows us to develop smaller, more efficient, and less complex subcomponents of a larger application.

I would like to see better documentation on how to set up complex webs of RabbitMQ servers — master/slave, multi-master, etc.

I have been using RabbitMQ for 7+ years.

We have not encountered any stability issues.

We have not encountered any scalability issues.

We were using IBM MQ, but it was too costly and not open source.

The initial setup was simple for my applications, but I have not used RabbitMQ on a complex project that would require clusters of servers.

My advice is to read the message boards and play with the API.

Strong integration with Greenplum Servers.

Loading data to Greenplum server after batch processing.

6 months

Yes, issues with HA and issues in syncing with the Greenplum.

You cannot expect a split second response.

On a scale of 10 I would rate it as 7

On a scale of 10 I would rate it as 8

This has just been used for POC period not for a regular use.

Initial setup works absolutely well. We were using with only Greenplum.

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.

Processing speed of queries used for ‘Reporting’ solutions is the most valuable feature.

Not Applicable for the area I was responsible for, as we ended up migrating away from Greenplum.

Stability and scalability for large number of concurrent applications & their users. The results we got were very inconsistent, depending on number of connections taken up by multiple applications and users.

When our application was first deployed using Greenplum, the number of users of the rrack on which Greenplum was deployed was very limited. We got excellent query performance results at that time. But as more applications started getting deployed, we started getting very inconsistent performance results. Sometimes the queries would run in sub-seconds, and sometimes same queries would run 10 times longer. The reason we found this was that Greenplum limits the number of active concurrent connections. Once all connections are being used, any new query gets queued, and thus response time suffers.

The impression we got was that the EMC Sales team that sold Greenplum to the organization did a great job. But later on the ball was dropped when it came to educating on which type of applications are suitable to Greenplum , and how to configure it to get optimal performance. When Pivotal took over support of Greenplum, their consultant visited us to go over the issues we were having. He advised us that Greenplum is not the best environment for our application needs. We ended up migrating our application out of Greenplum, along with a few other applications.

There was no issue with the deployment.

There were issues with the stability.

There were issues with the scalability.

Ensure that this is the right tool for your needs. For instance, Greenplum is not the best tool for cases where data has to be kept up to date in real time. Capacity planning is key to success, once you do decide it is the right tool for you.

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.

• Does SSL (security)
• Does clustering (stability)
• Integrates with LDAP (management)
• Automatically resends data when a consumer fails
• Automatically routes data
• Excellent spring boot integration
• Multiple programming languages provide excellent integration

With RabbitMQ cluster servicing micro-services, we don't have any downtime and we don't lose any data. We can update and/or upgrade the micro-services without downtime.

• You cannot edit shovels other than by recreating them.
• Routing of data could be more enhanced with a nice GUI. ("IF header.contains(this.thing) THEN data.goesTo(cluster_02)").
• In its current form, you have to recreate a shovel with the same parameters except for the one you want to change. You end up doing more or less a delete/create.
• There is no HTML form where you can click on a shovel and adjust the wrong parameter.
• If I click on a shovel, I get on a page that lists the shovel, but it is not editable. You have to create a shovel and then delete the old one with all the same parameters, except for the one you want to change.
• Temporarily stopping shovels is also not possible in the web interface. I do not know if the CLI version can do it, but if somebody wants to temporarily stop the incoming flow, he or she has to delete the shovel and then recreate it afterwards. This is annoying, to say the least.
• RabbitMQ has to be started before one can define exchanges, queues, and even users with rabbitmqctl. See https://www.rabbitmq.com/man/r...
• This is no problem if one lives in the monolithic server environment. However, if one wanted to make a RabbitMQ Docker-container with a pre-defined set of exchanges, queues, users, and shovels, you have to literally jump start the server. You would have to configure it in the Docker build phase. You would do it like this in the Dockerfile: RUN service start rabbitmq-server && wait 30 && rabbitmqctl add_user mike mikespassword.

I have used RabbitMQ for four years.

We did have stability issues in the past. After shutting it down, the cluster did not start until we deleted some corrupted file. This occurred more than a year ago.

It works as expected, i.e., flawless.

We have not needed any technical support as of yet.

We did not evaluate any previous solutions.

Just enter this command: $ apt-get install rabbitmq-server

It’s open source with paid support.

We looked at Kafka, but we needed the routing as well.

Start it in Docker and use Java Spring Boot or Node.JS with amqplib to connect to it. It has transformed how I think data should flow in an organization.

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.