VMware Tanzu Data Solutions Reviews

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.

We use it as our main microservices connection queue.

The product's reliability is the most valuable feature.

• The product has to improve the crisis management, especially in memory issues.
• Its clustering feature also needs improvement.
• I would simplify the configuration. I would add default configuration that prevents the queue system from filling out the server storage.
• I would also decouple the queue from the RabbitMQ Management, so that the queues won't get stuck.
• Clustering and clustering crisis management: When the cluster falls, there needs to be a simple way to recover it. It currently suffers from a recover problem.

In the regular state, there were no stability issues. When the queues are full, only complicated pre-configuration can help you so that you don't lose all of your crisis messages.

There were some scalability issues. There is no scalable queue. The cluster only supports redirections.

The documentation needs to be improved. We don't use any human technical support.

We have used DBus and ZeroMQ. We wanted something more reliable and simple, so we switched over to this tool.

The setup was okay, but there are some configurations that one needs to do by oneself. There are many dependencies as well.

It is an open source solution.

Do many stress tests.

My company runs on high availability. It is known for high accuracy in its items that are being shipped.

To do this, drivers/vendors who are shipping these items have to send their location details frequently to the server to update their current location. It all depends on accuracy.

Based on this, the end user can plan to receive shipping items on his end. We wanted a JMS tool that can create 'queues' on the fly and pass messages from one system to another.

• Queues and topics
• Native cloud app support
• Light-weight
• Easy maintenance
• Simple and straightforward admin portals: Made it easy for users and worked out excellently for our requirements

The solution needs improvement on performance.

It was stable enough to process our requests.

We were able to operate multiple nodes and we implemented a load balancer to meet our high traffic requirements.

We have never needed technical support. It was all there in the API documents provided by RabbitMQ and there are numerous blogs available on internet.

We analyzed our requirement thoroughly and were sure that RabbitMQ was the solution for us. We didn’t look at anything else.

It was bundled with PCF, so it was never a problem for us.

Again, it was part of PCF bundle, so that was never a worry for us.

This is a great product. It is lightweight, supports cloud native applications, is easy to implement, is easily manageable, and has excellent support. I would say, just go for it!

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

Guaranteed message delivery, queuing, and low latency delivery.

This allowed us to create a resilient network and independently scale various parts of the system dynamically as the business needs changed.

The biggest area we struggled with was operations troubleshooting. We were running a pretty big cluster and ended up with some random cluster failures that were difficult to troubleshoot. A good portion of these were self inflicted but occasionally the distributed database would end up corrupted.

I have been using RabbitMQ for six years, from prototype to production.

We had a bit of an issue with stability. The usual initial cause would be a hiccup in IOPS in EC2 but then this would cascade into more instability in our main clusters.

For the most part the product was very scalable. The only times we would have problems were usually related to Amazon hiccups that would cause the cluster to slow down.

We did not use their technical support much.

We evaluated a variety of message products and found that for the feature set RabbitMQ was the best.

Initial setup was relatively simple and then we were able to grow into the product by using more of the features.

We used the open source implementation and did not need to pay for support.

We looked at ZeroMQ, Kafka and Redis.

You really need to have or train Erlang expertise. The Erlang tools will become the best way to troubleshoot misbehaving clusters.

We're using this as our central messaging bus. It drives our micro-service architecture.

• Great management UI: The best in its class of messaging products
• Very sophisticated routing control and priority messaging capabilities

• The product should have much better scaling and scalability capabilities. Currently, they're really falling behind some of the competitors such as Kafka and NSQ.
• The installation of the HA version and clustering mechanism should be made much easier.
• The fact that a single queue can't be distributed across multiple instances/nodes is a major disadvantage.

We had multiple issues with stability. The product tends to be highly unstable when under heavy loads.

We had multiple issues with scalability. The product's scalability is rather problematic. It tends to be very complex to maintain with various sharding and high availability options.

I have never used technical support.

We tested some earlier version of Apache Kafka, but it wasn't stable enough at the time. At the moment, we're considering switching back to Apache Kafka.

The non-sharded/clustered setup is very easy and straightforward. The clustered solution setup is much more complicated.

We have only used the open source version.

We evaluated Apache Kafka, NSQ, and ActiveMQ.

Check the scaling issues. If scale is not an issue and you're just looking for a stable messaging queue, I would highly suggest it.

If scale is an issue, I would suggest using Apache Kafka.