VMware Tanzu Data Solutions Reviews

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

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.

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.

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.

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