VMware Tanzu Data Solutions Reviews

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.

Some valuable features of this product are:

• Message queuing
• Good support
• Provided scalability and a distributed environment
• Easy usability with NodeJS
• Could easily withstand and pass stress/load testing with more than 10K API calls
• Helped achieve a distributed environment and implement a 3-tier structure
• Helped to develop a highly scalable system by decoupling front end and back end

We had a project where we had huge responses to APIs from the front-end and had to handle such large responses/requests without losing any of them. RabbitMQ efficiently handled this problem by providing message queuing and decoupling our front end and back end.

I would love to see better documentation/demo for few technologies. There is need for better stability in the Windows environment.

I have used this product for around six months.

We encountered a few problems with Windows while clustering and hence we used Linux.

We did not encounter any scalability issues.

I would give the technical support a 7/10 rating.

It involved more of research as how to use RabbitMQ. For clustering, it was little bit complex but I was able to follow the documentation provided.

We did not evaluate any other solution prior to this one.

It gives product support with your technology.

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.

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.

We find authentication, performance, and durable messaging the most valuable features. Due to the nature of my use case, performance and security were of the highest priority and were the main reason I chose RabbitMQ messaging frameworks.

Over time, the most useful feature became the ability to create durable queues, which increased reliability and also boosted performance.

I would like to see improvements in fluent configuration. I'd also like to see more support for code-first environment configuration. We do a lot of this stuff as part of our deployment process via command line scripts, but I'd rather have a specific API to target rabbitmq.config and rabbitmq-env.config so that configuration could scale with my environments more easily. If more of that was baked into the RabbitMQ management HTTP API, it would help.

We have been using RabbitMQ for about 2 years.

We did not have any issues with stability.

We had no issues with stability. Exactly the opposite! It actually blew me away how flexible a framework it is. It’s a very elegant solution.

I never used technical support.

I've had the most success using NServiceBus over MassTransit. Look there for .NET Devs.

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.

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.