VMware Tanzu Data Solutions Reviews

• Parallel processing
• Takes minutes to process millions of records

This has improved our daily load process reducing the run time at least by three to four hours which made other departments within the organization to look for data from the Enterprise Data Warehouse.

It acts like a mainstream product not a novice any more. There are a lot of areas that can be improved. The bug fixes come as many patches like a start up instead of having scheduled release with proper improvements.

I've used it for five years.

It took a while to fully take advantage of this as we had to come up with lots proprietary solutions when linking to other products.

There is no issue with its stability.

There is no issue scaling it.

8/10 we had a technician come out on a new year in 2012 to fix some hardware failure.

We were one of pioneers in adopting this solution. So we got the best deal when compared to the competitors in several areas.

The initial move was a bulk transfer from the old system to new Greenplum based solutions. It was all done by Greenplum contractors. But to get it working with other products was challenging.

Greenplum employees developed and supported the initial move. Later they became remote consultants with support through phone and in-person as needed.

They gave a really good deal and we have been with them for five years even though the product got bought over by couple of different companies.

You need strong DBAs and architects to support the initial transfer.

Asynchronous messaging; supporting data integrations between multiple applications on behalf of our many customers. RabbitMQ allows us to elegantly fan-out data to a variable number of subscribers, with almost zero effort.

We have been able to set up a messaging system that facilitates data integration between the software modules that we sell.

RabbitMQ allowed us to do this quickly so that we could focus on the business requirements, rather than divert our efforts to message broker implementations.

Once the architecture was proven, we were able to return to the RabbitMQ message layer in order to implement an HA cluster with a minimum of problems encountered.

Our business now has a fit-for-purpose information hub that we can apply across our systems. As the customer-base grows, we know that the hub can grow with it.

RabbitMQ is a solid, widely-used messaging system with a low cost-of-ownership. It is open, but with commercial support potentially available from Pivotal if required. (We have never needed it.) There is also a strong online user community.

One crucial feature was guaranteed messaging. We needed a solution that we could trust to not lose data.

Its built-in clustering capability allowed us to configure it as a highly available message broker, so that we can have confidence in the resilience of our architecture.

It can be scaled as well, although we have not tested this.

After almost two years' usage in our production environment, I am impressed by how stable the platform is - even when running on Windows Server 2012. Sure, we have had to tweak our set-up here and there as we have learned a few operational lessons along the way but overall it is very good.

RabbitMQ is clearly better supported on Linux than it is on Windows. There are idiosyncrasies in the Windows version that are not there on Linux.

The documentation for the Windows version is also less plentiful and less accurate.

The online community clearly provides better Linux support, but this naturally follows from the smaller Windows installed base.

There are also some potential concerns about how we maintain high-availability whilst also scaling out.

We have had no stability issues.

We have not used the scalability features yet.

We have not used technical support.

No previous solution was used.

The initial setup was straightforward. The online documentation was adequate and there is minimal initial configuration required to get up and running.

After that, it is simply a matter of experimentation with the various features and learning as you go.

This is an open source solution.

We looked at MSMQ, NServiceBus, Azure Service Bus, and Apache Kafka.

I would recommend that anyone who intends to deploy RabbitMQ on Windows should first consider whether a Linux implementation is a viable option for their situation.

We use this product for general purpose messaging in cloud-based environments and as an implementation to MTP spec. We are customers of VMware and I'm a senior technical consultant.

One of the key benefits for us has been the ability to use this solution for microservice architecture communications because it provides great flexibility. One of our clients was able to push messages from the source which were replicated and forwarded to all the other brokers nationwide. Everyone who needed it, received it, and it's very cost-effective. 

The high availability and not having to replicate is valuable as is the message consumer. It can be configured depending on the use case to be a very fast message broker. I like the stability, the built-in admin tools and the plugin architecture. One of the things that makes it unique is that all of the components for messaging can be created programmatically, meaning you can have services or applications that get spun up or have auto incrementing instances. If you're in an elastic environment, you don't have to pre-configure the messaging system and the keys don't have to be known ahead of time. 

One of the issues is that as soon as you go outside of a switch or not in IP address range, the clustering no longer has all the wonderful features so clustering outside of network boundaries is a problem. I'd like to see stream processing as an additional feature. Kafka has a streaming API and I'd like Rabbit to have that too.

I've been using this solution for nine years. 

This solution is very stable, no problems there. 

This solution is very scalable and the number of users really depends on the organization. 

Technical support is good, very good. But because the underlying implementation technology is Erlang, sometimes the technical problems are at that level, in which case there's one major technical solution provider called Erlang Solutions. They're okay but if the problem goes past the product level and into the technology level, then there can be a delay in getting support because you're dealing with two companies and two technical support services. 

These days the initial setup is moderately complex because it uses a technology that is worldwide, Erlang, which is obscure. You have to install Erlang first and that is moderately difficult. Deployment takes about a day. 

They use a credit based system for licensingwhere you purchase credits. People don't like it.

My advice would be to have the messaging topology mapped out before you deploy to make the process from installation to a functioning solution more efficient. If you start looking at the topology from the revenue perspective, it usually ends up with more iterations to implement the correct topology, whereas if you start off mapping and then install, it's a more efficient way to go about it. 

I rate this solution an eight out of 10. 

We install this solution for our clients. At the moment we are in the middle of an installation for a data warehouse that will be used by a telecommunications company that is based in Lesotho. We have not gone into production yet, but we have used it in a test environment and it works very well.

We are a technology company, so we handle software development, software implementation, data warehousing, and business intelligence.

We are using the on-premise deployment model. In Africa, there isn't much adoption of cloud services, so most of our clients are expecting on-premise implementation.

We chose Greenplum because of the architecture in terms of clustering databases and being able to have, or at least utilize the resources that are sitting on a database.

The installation is difficult and should be made easier. Maybe if the process was simpler it would have a quicker adoption by other developers. This could also be accomplished by providing training aids, such as videos to help with installation or using certain features. There are resources currently available on their website, but you have to search through a lot of documentation.

Our expectation is that the scalability will be good, as it is one of the main reasons that we have invested in this solution.

To this point, I have referenced the material on the website but have not really interacted with technical support.

The initial setup of this solution is not very simple. You need to properly follow the steps in terms of getting the whole architecture put together. We have a team of five people who are working on different aspects of the implementation.

Currently, we are focusing on the data layer. Next will be the ETL layer.

We are using our in-house team to implement this solution for our client.

We have used Oracle and Microsoft SQL, but we haven't had much success. We found that Oracle was not as scalable and we were having some performance bottlenecks. Also, from a licensing perspective, Greenplum was a better choice. For all of these reasons, we have chosen to invest heavily in Greenplum.

I would recommend this solution specifically for the scalability. This solution has a more futuristic technology, as opposed to the old school kind of data warehousing. If people are interested in getting something that is more future-proof, then I would recommend this solution.

So far, we're comfortable with what we've seen. What we have configured is addressing our needs at the moment.

I would rate this solution an eight out of ten.

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.

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.

Message queue, because it is easy to use, reliable, not a big load.

We are using it to distribute pieces of some large jobs to multiple machines, which improves performance several times.

Improve the ability to handle the large message load.

People usually use RabbitMQ as the lightweight messenger, if they have a large message load people are inclined to use Kafka. But at the beginning stage of most projects, the data is small, people do not need to use a Kafka type of messenger, they are more likely to use RabbitMQ. If RabbitMQ can handle the large message load and support ordered delivery, with the project growing, data bigger, people can still use RabbitMQ and wouldn't need to find another tool to use like Kafka which is much more convenient.

Half a year.

Didn’t have issues.

Didn’t have issues.

Very good. 8/10.

Simple. We followed the tutorial about RabbitMQ with Python.

We are using it internally with a very small data load in the developing period, which is free right now.

Yes, I evaluated Kafka.

Kafka is more suitable to large amount events in order. RabbitMQ is more suitable to the related small amount of messages, which is my situation and I don’t care about the message order.

RabbitMQ is a very easy to use and reliable message broker. If the work has a relatively small message load, RabbitMQ is the most robust and reliable choice.

Processing speed – especially loading and transformation of large data sets.

Before we implemented Greenplum, our weekly data loads (for third party marketing data sets) were taking over three days. (We also had some monthly data that could take up to 3 days to load and transform via Informatica.) After we implemented Greenplum, the loads were reduced to less than nine hours. Previously, we were receiving data early Wed a.m. and not getting out to the salesforce (if we were lucky) until noon on the following Monday. Now we get the data to the field early Friday mornings before they wake up.

The Greenplum appliance itself has had some reliability issues, so it would be great if that could be improved in the next version. More critical, though, is that the latest devices are not backward compatible. i.e., We have to replace our entire environment to upgrade. That’s quite an expense. I would hope they could improve the upgrade roadmap in the future.

We have used EMC Consulting for some projects, and we have lots of EMC storage.

If you can, do a benchmark with other MPP options including cloud alternatives. Although our Greenplum implementation was very successful (going on 4 years ago), I wish we had benchmarked against Teradata and Netezza (now IBM) at least. Today, I would consider not even buying hardware… just doing it all in the cloud.