VMware Tanzu Data Solutions Reviews

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.

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.

Complex message routing makes it very easy to replicate product data for user acceptance testing which was required in our user case.

Applying message queues in general has helped my company, BuzzNumber, to scale easily with the load.

The High Availability feature is not really reliable. It also took a really long time to restart the box when there were a lot of messages in the queue.

As mentioned on its document page, it cannot tolerate network partition well.
I suffered a network parturition with 3 nodes cluster and lost all data. So with our cloud provider, we can’t rely on pause_minority and seems like auto_heal is a better fit for us.

Apart from that, RabbitMQ doesn’t seem to be stable when it has high RAM usage. Especially when you have millions of queue items in a queue and a node crashes, adding a new node to such cluster will be a pain as the replication takes forever.

We have used the solution for two years.

We encountered an issue with stability. It didn't work very well with millions of messages in the queue when you add a new node to the cluster.

There were no specific issues with scalability except the issue of adding a new node to the cluster.

We used the open source version with community support, so we didn't contact technical support.

We previously used MSMQ. Apparently, it is not as good as RabbitMQ in terms of the features offered.

The setup is easy.

This is not applicable, as we were using the free version.

I am not aware of other evaluated options.

I would advise potential customers to make sure it works with your architecture, scale plan, and load. There are other alternatives.

One of our favorite features is the exchange. The queuing out-of-the-box is awesome. Also, due to the clustering, our system was highly available.

It made our system more scalable, resilient and easy to maintain.

Support for Windows systems needs to improve. This could move Microsoft shops away from it. We provisioned Linux servers specifically for our RabbitMQ servers.

RabbitMQ clusters run on two kinds of protocols: AMQP and HTTP. The one we were using was AMQP (this requires all your cluster nodes to be in the same network partition). With our Windows servers, every time we used to run Puppet, RabbitMQ used to think it got partitioned. This problem never occurred in our Linux cluster.

All this is subjective. Maybe we were doing something wrong. There are a few other things which they have listed here: https://www.rabbitmq.com/windows-quirks.html Overall, I don't think it's RabbitMQ's fault because Windows can be a problematic OS at times.

So, I would recommend using Linux servers instead of Windows servers for a RabbitMQ cluster.

We have used RabbitMQ for 1 year now.

Other than the fact that our Windows cluster would experience network partitions for no reason (could be due to Puppet), we had no other stability issues. We stress-tested the servers, as well, and they responded really well.

Its really easy to scale.

We never used technical support.

We had a monolith application. This was our solution to have more of a micro-service architecture

Initial setup was decently elaborate. The documentation is good but there are a few quirks in the case of Windows. The RabbitMQ processes would be running but the status would show that it is down. The solution was to stop and restart the process. This only happened on Windows.

We also evaluated ZeroMQ and EasyNetQ.

It is a really good solution if you require queuing with the competing consumer and multicast routing out of the box. It’s a bit too elaborate if you need just simple message queuing.

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.

It has solved issues such as queue processing, real-time data processing and decrease count of Cron jobs.

The management of Cron jobs is very hard for me. If you are using RabbitMQ, you may not need a Cron job since you can create a consumer for a queue and listen to the queue in real-time. For example, you need to send an email for your new members but you want to do this from your software. The reason being if you encounter an SMTP error, you should handle it or sending an email from your membership activity can take about 5-10 seconds. If you don't use RabbitMQ, you need to create a Cron job and check for new members to send an email to them. But, if you use RabbitMQ, you do not need a Cron job. You can send a message to your queue and consume it in real-time and then send the email.

I have used this solution for changing stock of products in an e-commerce project. We update the stock of products from RabbitMQ. Some of our clients can change the stock of a product, i.e., either increase or decrease it. They send the stock count to RabbitMQ as a message and our e-commerce platform changes the stock when it gets the message. Consequently, we update the database, cache, search engine service and so on.

There are too many advantages of using this solution. You can scale your processes and update your data in a nearly synchronous way.

RabbitMQ needs 2 additional features:

• It is lacking a good dashboard on the web interface; maybe they can develop a dashboard for monitoring.
• There is no alert mechanism. For example, sometimes consumers may be killed or the input messages in queues are greater than the consumed messages. Thus, I would like them to define a rule for alert; maybe they can develop an alert mechanism.

I have used this product for three or four years.

I have not encountered any stability issues.

I have not encountered any scalability issues either.

Since it is open source, you can resolve your problems either from forums or Stack Overflow in regards to RabbitMQ.

We have used different solutions before. We have tried MySQL as a queue and it was terrible.

It is not complex.

However, if you try sharding or cluster, it is just a little complex because of Erlang.

It is open source.

I did not look into other solutions.

I would recommend this product. It is great and resolves a lot of problems.

RabbitMQ is good in its real-time capability of delivering the sensor data in different topic abstractions. It is quite easy to setup in our sensor network system which involves data monitor agents across geographically distributed organizations.

This tool made our research process easier and allowed our administration (monitoring) process to happen at the same time. We created different queues for different use cases of the same streaming data.

The solution can be improved in terms of how to handle the rolled off data from the queue. Currently, if the consumer does not consume a queue, the data in the queue will eventually overflow and be discarded.

I have used this solution for about a year.

Stability-wise, the consumer needs to configure with caution to make sure the queues never overflow. I have experienced data loss in scenarios in which consumer cases were configured incorrectly.

It would be nice if it could produce automatic load balancing when the number of brokers scales up.

The technical support is generally good in terms of being a nice and active user forum that has good documentation.

The initial setup is not very complex. We just needed to set up several broker instances running on different physical nodes to prevent unavailability. When we needed to add more nodes for more data and queues at a later time, it created a bit of load imbalance issues.

I would suggest that the vendor keep it the same way that it is now.

We chose this solution around 2010, so there weren’t many options at the time. We evaluated the native JMS method and it didn't scale up well.

Keep in mind that the queue structure and the consumer configuration need to keep up with the queuing speed. I would suggest researching other options if you need bulk data publish/subscribe in persistent data storage, e.g., Apache Kafka.

Allowing for a fully asynchronous solution is crucial for this particular feature. The seamless nature of creating and connecting to a queue makes it really easy to code and understand. Pivotal Cloud Foundry allows us to easily scale the number of consumers (or receivers) as well. So far, no hiccups have been found with the PCF implementation.

RabbitMQ allows for asynchronous solutions where previously everything was synchronous.

The product works pretty well, but one small thing could be an improvement to the monitoring site. It could be a little bit more modern, instead of postback refreshing, etc.

We have been using Rabbit for a while and I started integrating it into the mobile project a few months ago.

Every so often, I need to clear out the queue during development. This could be a symptom of something else, but unpacked requests tend to get trapped in the queue at times.

PCF allows us to scale the consumers.

I haven't used any technical support yet.

To my knowledge, this is the only queuing system my company has used.

Thanks to Pivotal Cloud Foundry, initial setup was straightforward. We simply created a new RabbitMQ service, obtained credentials for the queue and started developing.

I personally have not explored other queuing solutions, but have used Akka HTTP, with is a fully asynchronous web server of sorts. It's not a queuing system, but I mention it because of the asynchronous behavior. RabbitMQ was perfect for our current solution, however.

The RabbitMQ documentation is pretty good. I'd only suggest making sure to read through it for the implementation language of your choice first.