Amazon Redshift Reviews

Column store and distributed processing is optimized for read access. We grew to 3000+ users with no impact.

Column store is a data compression technique for relational data. I’m using it now in SQL Server 2016. We configured a 16-core VM for handling requests on the DB. The recommendation was to separate inbound data packets into related chunks, which were 1/16th of the size.

This way, the import process could make full use of parallelization, and it worked. We imported 20 million rows of sales facts in less than 15 seconds, and the content was query-able immediately. I’ve never seen that before. This was impressive. This meant that we could completely rebuild the data warehouse to “current” from "scratch" within minutes, assuming that the data was in S3 already.

Tables that would typically be 2GB in size are now about 250MB. This means more data in memory. You can also configure the tables to live in the memory of all of the available cores. This is good for small dimension tables. You can also fragment them across all cores, for the larger fact tables. This allows for distributed query processing. Once you set it up, it just worked. It was all specified in the PG-SQL table statements.

There were two data centers in Sydney that were guaranteeing us a distributed solution. We really didn’t notice this. It was more of a check box situation. At one point, there was an outage at AWS, but it didn’t impact our operations directly.

This has given us the ability to provide metrics to the large number of company staff on their performance without impacting core systems.

I’d like to see these RedShift features arrive in other languages, such as SQL's ColumnStore index.

.

I have used this solution for three years.

There have been no stability issues.

Technical support always met my expectations.

I was on a team that was using AWS tools for Dick Smith Electronics (now liquidated). The tools ceased use in February of 2016.

Prior to that, we were using them fully for about 3 years. We loaded data to Redshift according to the best practices included in the online docs and through consultation with the AWS staff. The combination of S3 and Redshift for this purpose was very high in performance. Redshift was used to provide the data model to an instance of MicroStrategy for BI reporting.

We were using MicroStrategy, which generated all the SQL that our reporting services needed.

As such, I could only comment on the data engineering phase. Technically, this was so impressive that I don’t know what to add. I don’t recall feeling that it missed anything. If anything, I was not using all the available features. AWS documentation is great in this regard. You can tell they have put a lot of thought into it.

A lot of the future direction in database technology has to do with memory optimization and concurrency (VoltDB). This is more targeted towards transactional processing, and not data warehousing.

Memory-only data warehousing solves a lot of access issues without having to think too hard about the problem from the consumers' point of view. I am sure that you can already configure this.

Columnar storage technology is the most valuable feature of this solution.

We can get the SLS/SLAs in our daily processes.

Some improvements can be brought about in:

Restore table:

I would like to use this option to move data across different clusters. Right now, you can only restore a table from the same cluster.

Right now, the feature only permits bringing the table back in the same cluster, based on the snapshot taken. I would like to have a similar option to move data across different clusters, right now I have to UNLOAD from cluster A and then COPY in cluster B. I would like to use the snapshots taken to bring the data in the cluster I need.
Maybe current design cannot be used, because it is based on nodes and data distribution.

But, our real scenario is: if we lose the data and we need to recover it in other cluster, we have to do:

1) Restore table in current table with a different name

2) Unload data to s3

3) Copy data to a new cluster. When we are talking about billions of records is complex to do.

Vacuum process: The vacuum needs to be segmented. For example, after 24 hours of execution, I had to cancel the process and 0% was sorted (big table).

Vacuum process:

The vacuum needs to be segmented, example after 24 hr of execution, I had to cancel the process and 0 % was sorted (big table)"

For big tables (billions of records). if the table is 100% unsorted, the vacuum can take more than 24hrs. If we don't have this timeframe, we have to work around taking out the data to additional tables and run vacuum by batches in the main table.

Why, because If I run the vacuum directly over the main table, and I stop it after 5 hrs, 0 records will be sorted. I would like to run the vacuum over the main table, stop when I need but get vacuumed some records. Like incremental process.

I have used this solution for around three years.

We did encounter stability issues, i.e., if you are using more than 25 nodes (ds2.xlarge), the cluster is totally unstable.

I have not experienced any scalability issues.

I would rate the technical support a 9/10 for normal issues.

However, for advanced issues, I would give it a 5/10 since I had to go directly with the AWS engineers support.

Initially, we were using the Microsoft SQL solution. We decided to move over to this product due to the DWH volume and performance.

In my opinion, the setup was normal.

Based on quality of the product and its price, it is the one of the best options available in the market now.

We also looked at the Oracle solution.

You need to make sure that the space used in DWH has to be a maximum of 50% of the total space.

You must create processes to vacuum and analyze tables frequently. Also, before creating the tables, you should choose the right encoding, DISTKEY and sort keys.

The most valuable features of this product are:

• Processing huge data in petabytes
• Massively Parallel Processing (MPP)
• Concept of data compression
• The way it stores the data in drives especially with the distribution key
• Supports BI tools like MicroStrategy (MSTR) and Tableau
• Supports all the data warehouse core features such as SCD1 and SCD2, and different schemas like the star schema

It has helped us to understand the response and interest of the customers and the user conversion rate in this competitive world. Thus, it has helped us in the decision-making process.

In most of the scenarios, the data source for Redshift will be traditional RDBMS like MySQL, PostgreSQL, SQL server, etc. After migrating to Redshift, we will find few disconnects for w.r.t data types, the stored procedures and other complex functionalities. There is a need for improvement in these aspects, mainly in the scope of data types and some complex functionalities which we can perform in RDBMS.

I have used this solution for more than a year.

I have not encountered any issues with stability. In terms of performance, Redshift is highly stable.

I have not encountered any issues with scalability. We can easily scale the nodes in AWS only with a few clicks.

I would give the technical support a 6 out of 10 rating.

We have not used any other solution.

The setup was straightforward for those who know AWS.

The Redshift pricing policy is easy to understand.

We did not evaluate other options prior to selecting this solution.

As of now, Redshift is far better than the other products in the market.

Lastly, I would like to mention that Redshift is more about scaling and stabilizing your data. One should also focus on data modeling from time to time.

The most valuable features to us are: speed, DML, the fact that it is cloud-based, the management console, and Boto3.

Because we are dealing with a lot of data, speed is always important. Redshift is blistering fast when doing "deep" copies and inserts. Conceptually, my data-transformation pipelines are a series of proprietary "waves" that leverage Redshift's DML/"deep" copy/insert strengths. Doing all this in the cloud allows us to easily test alternatives. We create different sized Redshift clusters and orchestrate them by using the SDK (Python Boto3). We go beyond the traditional DWH to "infrastructure-as-software".

Redshift has helped to transform Makerbot into a data-driven company.

Integrating database security/access rights with AWS IAM would be great. I would also like to see more DML features that might aid in processing unstructured or log-file data. This would allow us to avoid having to use EMR/Hadoop.

We’ve used Amazon Redshift for 3 years.

We did not encounter any deployment issues.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

Customer Service:

I think the customer services is adequate.

Technical Support:

The level of technical support is good.

We tried prior solutions, but they had limited or no scalability/agility.

The initial setup was straightforward.

It took less than a year for the product to pay for itself.

Regarding pricing and licensing, I advise to start small and have your developers/DBA use table compression and partitioning from the start.

We have used different options over the last 20 years. We found AWS Redshift to be the leader in capability and provides an ecosystem of related services from AWS, many of which are free.

My advice to other is to prototype, prototype, prototype! Everything depends on your data and what you need to do to it. No two projects are the same.

We use Amazon Redshift to store customer data. Basically, it's just to store our customer data so that we can use our own data.

I use Redshift Spectrum a lot, so that integration is good. Also, Amazon Redshift offers a relatively flexible structure, especially in terms of like, nodes that you can assign. Moreover, it is serverless, which is great.

Specifically, with Redshift Spectrum, some SQL commands have to run on Redshift instead of Redshift Spectrum, which slows down a few things in the tool. In the solution, user-based access is quite hard. In general, certain permissions are difficult to manage. The solution is expensive compared to Snowflake. I have used Snowflake because they're cheaper than Amazon Redshift. Some of the commands are run on Redshift itself, and some of the commands are completed by Spectrum, which is problematic. However, it is faster when computed by Spectrum.

I have been using Amazon Redshift for six to seven years. Also, I don't remember the version of the solution I am using. I think it's multiple different versions across the platform. So, I think it would be the latest version for some areas of our platform and older versions for other areas. My company has a partnership with Amazon.

Stability-wise, I rate the solution an eight out of ten. I can't remember what stability issues we had faced in the past, but I feel that it was due to overloading clusters.

Once we moved to a serverless version, it became more scalable. The concurrency of queries on the same cluster has a big scalability issue. Scalability-wise, I rate the solution a seven out of ten.

Around 300 people in my company use the solution.

The solution's technical support is good since we have a partnership with Amazon and we have individual support. I rate the technical support a nine out of ten.

Positive

Previously, we were using Snowflake in our company. We switched since Amazon Redshift was cheaper. Now, I use Snowflake and Amazon Redshift.

I wasn't involved in the solution's initial installation. The deployment model is largely managed by our platform teams. Also, we have a team of engineers who constantly update and maintain the solution. Probably a team of engineers is specifically focused on improving our Amazon infrastructure.

I am not sure about the pricing of the tool since that's not my department. I know that Snowflake is cheaper to set up, manage, and store data. On a scale of one to ten, where one is a low price and ten is a high price, I rate the pricing a seven.

I recommended it for data storage. I don't recommend integrated solutions, like Pacemaker unless you have an advanced team to handle it. I like using it, but it's too expensive. So, I rate the overall solution a seven out of ten.

Private Cloud

Redshift's Excel features are handy. Redshift spectrum allows you to directly query the data on an Excel sheet. Now, SQL Server also allows this, but Redshift has many more features.

Amazon should provide more cloud-native tools that can integrate with Redshift like Microsoft's development tools for Azure. 

I've only used Redshift a couple of times to do a proof of concept.

Redshift has had some scaling issues, but Redshift's performance overall is excellent. 

We haven't encountered many challenges so far.

Redshift setup is easy. It's not an issue. 

I rate Redshift nine out of 10. If you're thinking about implementing Redshift, I would recommend focusing on the use case. It's a warehouse database, not a transactional system, so they need to plan their workload before migrating to Redshift.

We primarily use Amazon Redshift for data warehousing.

The user interface of Amazon Redshift is easy to use, even though we do not use it a lot. The stability has been great as I have not experienced any glitches. Scalability is also a strong point; I can scale it however I want without any limitations. However, pricing is a major disadvantage as it is expensive.

Pricing needs improvement as the solution is expensive.

We have been using Amazon Redshift for approximately two years.

Amazon Redshift is stable. I have not experienced or heard about any glitches.

Amazon Redshift is scalable with no limitations that I am aware of.

The pricing of Amazon Redshift is expensive.

I do not want to continue this call. I hope you have gotten input from me. I would rate Amazon Redshift a ten on a scale of one to ten.

Public Cloud

Amazon Web Services (AWS)