Migrating Oracle Workloads to Google Cloud – Cloud Spanner

Posted in: Technical Track

There are plenty of database migration options out there, and we love working with clients to help them assess and evaluate which one is best for them.

Options include:

  1. Bare Metal Solution (BMS)
  2. PostgreSQL:
    1. On Cloud SQL
    2. On GCE (Google Compute Engine)
  3. Cloud Spanner

Some organizations choose BMS for its stability, durability and reliability. Others like PostgreSQL to reduce licensing and maintenance costs while maintaining core application code.

Today we’re taking a closer look at the option of Cloud Spanner, to understand why an organization might choose it.

Cloud Spanner

If your application requires a relational database with global reach and scalability, you’ll have to undergo a rewrite. Fortunately, you can also take advantage of cloud-native databases such as Cloud Spanner which combine the benefits of a relational database structure with non-relational horizontal scaling.

Cloud Spanner is the only enterprise-grade, globally distributed database service and storage solution specifically built for the cloud. It provides features such as global transactions, strongly consistent reads and automatic multi-site replication and failover.

When migrating your application to Cloud Spanner, it’s important to take into account the different features available. You’ll also almost certainly need to redesign / rewrite your application architecture to fit with Cloud Spanner’s feature set, which includes:

  • Strongly consistent scale-out relational database management system (RDBMS) cluster.
  • Cross-table transactional support – transactions can span multiple tables.
  • Primary key (PK) design driven tables – all tables must have a declared primary key, which can be composed of multiple table columns.
  • Interleaved tables – tables can have physical dependencies with each other.
  • Indexes – supports secondary indexes.

The typical chronology of a Cloud Spanner migration includes the following steps:

  1. Schema and data model conversion.
  2. SQL queries translation.
  3. Refactoring of your application to use Cloud Spanner.
  4. Bulk export of data from Oracle and import into Cloud Spanner using Cloud Dataflow.
  5. Consistency maintenance between both database systems during the migration.
  6. Cut-over and go live of the application away from Oracle.

Benefits:

  • Focus on your app logic instead of spending time managing hardware and software.
  • Scale out RDBMS solutions without complex sharding or clustering.
  • Gain horizontal scaling without migration from relational to NoSQL databases.

Challenges:

  • No support for server side code such as stored procedures and triggers.
  • Lack of implementation of a sequence generator.
  • Support only for database-level access controls using IAM access permissions and roles.

Conclusion

Several Oracle databases are good-to-great candidates for migrating to Google Cloud, by taking advantage of services like BMS, or transforming to PostgreSQL on Cloud SQL or on GCE or Cloud Spanner. However, for anything except the most trivial of databases, the effort can be very complex. For this reason, before diving in, it’s vital to clearly understand just how much effort your migration will entail.

Pythian can provide a detailed assessment to help you understand not only the complexity of effort required, but also exactly what value you’ll receive from migrating.

Once you’re ready to move, our expertise can help engineer the optimal solution for your business; mitigating the risks of migration while maximizing throughput. Our proven approach to migration lets you move or transform your Oracle workloads with complete confidence.

To review the information about all your Google Cloud migration options in one handy document, please download our “Migrating Oracle Workloads to Google Cloud” white paper.

Ready to start a conversation? Email us at googlecloud@pythian.com for more information.

email

Author

Interested in working with John? Schedule a tech call.

About the Author

Pricipal Consultant
John has 40 of years experience working with data. Data in files and in Databases from flat files through ISAM to relational databases and, most recently, NoSQL. For the last 15 year he's worked on a variety of Open source technologies including MySQL, PostgreSQL, Cassandra, Riak, Hadoop, and Hbase. As a Chief Database Architect at AOL he brought MySQL in to replace Sybase and has worked hands on with MySQL databases holding hundreds of billions of rows and running millions of transactions per second. For the last three years he has been working for Pythian to help their customers improve their existing databases and select new ones for new applications.

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *