Oracle Exadata vs. Amazon Redshift

• First, get the database on Oracle. If you are in an Oracle stack, it would be much better to use the Oracle products. If you are driving a Ferrari, you wouldn’t put a Mercedes engine in it. If you are writing a query, you cannot rely on other brands. Since I'm an architect, when I look for a product, I look for performance.
• The installation is easy because it comes out-of-the-box and you just start using it.
• Previous to Oracle Exadata, we were using a normal Oracle RAC service. We were just waiting for this product to come out.
• I'm currently writing a data warehouse on Exadata. Before this solution, we were aiming for this to be completed by 8 a.m., when our ETLs would finish. With the help of Exadata's special features, this was reduced to 3 a.m. This solution allows us to bring more data within the same time period. It provides us with more subject areas that provide more reports to our users. Our ETL times reduced to 65%, then to 50%.

Incentivized

If the number of connections is expected to be low, but the amounts of data are large or projected to grow it is a good solutions especially if there is previous exposure to PostgreSQL. Speaking of Postgres, Redshift is based on several versions old releases of PostgreSQL so the developers would not be able to take advantage of some of the newer SQL language features. The queries need some fine-tuning still, indexing is not provided, but playing with sorting keys becomes necessary. Lastly, there is no notion of the Primary Key in Redshift so the business must be prepared to explain why duplication occurred (must be vigilant for)

Incentivized

• Customize-able for specific functionality optimized for combination of online transaction or analytical processing.
• Ability to serve mix workloads with resource management feature enables prioritizing allocation for certain workload.
• Scale-able on-premise with compatibility for cloud deployment offers flexible solution for organization considering to transition from on-premise solution.

Incentivized

• Redshift is fully managed. Small teams do not have the resources to maintain a cluster. CloudWatch metrics are provided out-of-the-box, and it is easy to configure alarms.
• Redshift's console allows you to easily inspect and manage queries, and manage the performance of the cluster.
• Redshift is ubiquitous; many products (e.g., ETL services) integrate with it out-of-the-box.
• Writing .csvs to S3 and querying them through Redshift Spectrum is convenient.

Incentivized

• Patching can often become quite involved and convoluted. It should be more transparent and straightforward.
• Storage metrics can be difficult and time consuming to obtain.
• Basic administrative functions can be hard to repair when discovered.
• Vendor support can take a while to obtain. Generally several attempts are necessary to reach the right area of vendor expertise.

Incentivized

• It could benefit from adding data integrity and programming tools common to other database management systems.
• Amazon Redshift is based on PostgreSQL 8.0.2. That version of PostgreSQL was released in December 2006. While PostgreSQL was much improved since then, the new features were not implemented in Redshift. Many basic features are missing from it.
• Primary keys can be declared but not enforced. Referential integrity (foreign keys) can be declared but not enforced. UNIQUE and CHECK constraints are not supported and cannot be declared.
• IDENTITY can be declared on a column, and Redshift will put unique values into it. However: IDENTITY values in the newly inserted rows won’t be incremental or sequential. To implement a sequential number, you need to write your own custom code.
• There are no stored procedures in Redshift. We are writing SQL script files, and then parsing and running them one statement at a time from a Python program. This also enabled us to implement execution-time error logging.
• In SQL scripts, to check for the row count of affected rows, a complicated join query against some system tables or views has to be executed.
• Data Control Language (DCL) does not exist. No statements like IF, WHILE, DO, RAISERROR, etc.
• On performance of views… Views do not “pass-through” a query parameter which is a potential problem for performance.
• When selecting against a view with the WHERE clause outside of the view, the inner query of the view will be executed first without consideration for the WHERE clause, and only then the WHERE clause will be applied.
• Certain clauses of SQL work many times faster than other clauses. So be careful and test your statements for performance earlier rather than later, especially if working with a large data set.
• There was a situation when DELETE FROM JOIN was unacceptably slow. Replacing JOIN with the USING clause made DELETE instantaneous.

Incentivized

I am comparing Exadata with the Oracle RAC database experience. In addition to Oracle RAC features, Exadata provides automatic performance optimization through Smart Scan and storage indexes. Deep integration with the Oracle ecosystem and tight coupling with Oracle Enterprise Manager
for monitoring and management. Some downsides of Exadata are: a steep learning curve, concepts like cell offloading, IORM, and flash cache behavior aren’t intuitive initially. Operating
Exadata requires specialized DBA skills.

Incentivized

Overall it serves all our aspects of data management like data cleaning, data manipulation, and data reporting on the cloud platform. We can create stored procedures and triggers in it very easily as all the options are self suggested in it. We can easily attach the results of ARS to the other tools as well for drawing the statistical results.

Incentivized

The support was great and helped us in a timely fashion. We did use a lot of online forums as well, but the official documentation was an ongoing one, and it did take more time for us to look through it. We would have probably chosen a competitor product had it not been for the great support

Incentivized

I couldn’t find all the options listed here, so I’m
summarizing the ones we considered during our evaluation before selecting
Oracle Exadata Service on AWS:


Continuing
to use the Oracle RAC on‑premise database
Running
Oracle Database on AWS EC2
Using
Oracle Database through the AWS RDS service


Since we wanted to retain Oracle RAC capabilities while
achieving high performance and maintaining our presence in the AWS public
cloud, we selected the Oracle Database @AWS Exadata service.

Incentivized

We evaluated [Amazon] Redshift vs BigQuery vs Amazon EMR, back in 2014. Back then BigQuery cost was slightly higher than that of [Amazon] Redshift price structure. Amazon EMR, needs lots more management (Admin tasks) and EMR is designed to be ephemeral and not designed to be a data store. [Amazon] Redshift was ideal with the price structure, performance and ROI[.]

Incentivized

• One of the central critical systems was migrated from a large 4-node Oracle RAC running on legacy hardware. This application was experiencing severe performance issues literally causing loss of service for numerous customers. Once it was migrated to a 2-node Exadata server, its average performance improved almost by a level of magnitude, therefore eliminating any signs of application slowness.
• Numerous application databases were migrated to Exadata servers which reduced the overall cost of hardware due to Exadata's price structure.

Incentivized

• It allows for an almost seamless integration of our data which can then be used by other departments for analytical purposes.
• No in house resources are needed for keeping the data alive and performing backup/migration tasks of the data in its end state.

Incentivized