Migrating Oracle Databases to Open Source Technologies

AUTHOR John Schulz Principal Consultant, Microsoft MCM & MVP

V01-012021-HW MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 2

Introduction Some Oracle customers today are beginning to weigh other options, often for a host of reasons including Oracle’s license and contract restrictions, customer audits, concern about eventually being locked in, and high support costs. One option they may choose is to migrate to open source databases (OSDBs) with much less restrictive licenses and no license fees. In this document, we will review the options current Oracle users have to migrate to open source database technology.

We will start with what Oracle database technologies are currently in use, compare those to the many Open source options available, and then review how best to get there, including an evaluation of many of the robust tools available to help.

All OSDBs offer a subset of the capabilities and feature options of the Oracle database, so first reviewing the Pythian white paper “Considerations For Converting From Oracle To Other RDBMS Platforms” is highly recommended. This will help ensure that the options, features, and non-functional capabilities unique to Oracle are either not used or are a palatable loss.

No matter which Oracle database technologies are in use, there are three general approaches to migrating to an OSDB:

1. Direct migration Migrate the schema into the new OSDB format, modify the data manipulation language (DML) to work with the new OSDB technology, and copy over the data to the new database. This approach, while straightforward, is usually only practical for a small subset of OSDB technologies and in some cases not even for those.

2. Refactor the application and re-write for the new OSDB technologies chosen This approach, while daunting, is often the better one as it allows for a new application which eliminates technical debt and improves operability, including scaling and availability and faster features to market. It is also a major undertaking, and the return on investment is likely to be years away.

3. Find the right off-the-shelf application which supports the OSDB of your choice. The application itself may be either proprietary or open-source.

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 3

Oracle Single-Instance vs RAC vs Exadata Oracle offers several products, and Oracle Database can roll out several specific feature sets to suit certain workloads. The kind of workload will, at least in part, drive the final decision as to which OSDB technologies are good use cases for the migration.

Single-Instance Oracle Databases Many Oracle databases run on a single host, optionally with one or more standby databases providing disaster recovery (DR) , backup or query off-loading. These configurations are typically used by most small to medium-sized businesses for the majority of their database traffic. The workloads tend to vary extensively and can include transactional, content management, business intelligence, and data warehouse use cases.

Oracle RAC This is Oracle’s premier high-volume transactional engine, designed for high availability (HA) via horizontal scalability. It operates as a cluster of computers with shared storage designed to scale beyond a single system while offering HA without replication. For DR, RAC installations also replicate to one or more standby RAC (or non-RAC) databases as part of Oracle’s Maximum Availability Architecture (MAA).

Exadata Exadata is Oracle’s hardware-based product (with unique hardware and software capabilities, not replicable outside of the Exadata platform) designedto support large data warehouse applications and high volume OLTP applications. It is the only Oracle Database product that supports on-disk column store technology.

Business Requirements Before thinking about which database technology to which you might want to migrate, you should evaluate your business requirements. Knowing what your real business requirements are will help you select the best OSDB technology in terms of the database itself, along with the way you’ll configure it and what tools you’ll use.

High Availability (HA) We all want our databases to be highly available. But there is always a cost to keeping a database up 24X7, 365 days a year with 99.9999% uptime. Understanding your real needs will help identify what technologies you should investigate and how you might want to configure them.

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 4

Disaster Recovery (DR) What are your DR requirements? Will you need an active disaster site able to seamlessly take over from the primary? Will a passive backup be acceptable? Can you just rebuild from the data you have in another database, meaning the cost of DR may not even be justified?

Global Data Distribution Will your database need to be available globally, with data replicated between nodes more or less transparently? Or will you want a single central database with geographically distributed copies? Or maybe you just want to store customer data in the closest datacenter, and then safely replicate it in just one other place.

Rapid Response to Changing Requirements Will your database need to support rapid changes due to fluctuations in market conditions? To take advantage of new business opportunities? Or will the database structure be more or less static, changing only slightly over time?

Regulatory Requirements What are your regulatory and compliance requirements? This matters a good deal. Depending on what kind of data you have, one or more of the OSDB databases may not meet your needs – or you may need additional software to make it work. If you are thinking of migrating to a public cloud, is the cloud or the database offering in the cloud certified and able to meet your compliance requirements?

Continuous Availability during Migration When it comes time to migrate to the new database technology, will users of the source Oracle Database and the target OSDB database(s) require continuous uninterrupted access to all the data? Will access to most of the data be acceptable? Will it be okay for applications to be down? If so, for how long?

Migrating data in a batch inside of a downtime window is clearly the easiest and simplest route but is not always acceptable. What is your requirement?

Migration Approaches We mentioned up top that there are three general options when migrating from your Oracle Database. However, within those three options are many additional considerations.

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 5

Direct Migration With direct migration, you will need to evaluate the existing schema and SQL code, especially any stored program code (PL/SQL). There are a number of tools available to help in this effort, such as Ora2Pg and AWS Database Migration Services (DMS).

After determining what features and functions are missing or just named differently, you will need to convert the schema and code. In many cases, this means changing at least some program logic. If your code used an object-relational mapper (ORM), this may prove relatively painless. If not, and if there are many lines of code to change, this could be a major effort.

Once you complete the analysis and translation phases, you will next need to set up a test environment to validate the schema and code changes. After all these considerations are carefully weighed, it’s finally time to migrate the data. There are two approaches you can take:

1. Batch Shut down the existing application, dump the data, and restore it to the new database. This can be done through utilities like Ora2Pg or AWS DMS. It also can typically be done by performing a SQL-level dump from Oracle, suitably modifying it, and restoring it into the new database. This approach is generally straightforward and if downtime is acceptable, it’s often the simplest approach

2. Online heterogeneous replication In this case, you bring up both databases, load a copy of the production data into the new database, and start replicating from the existing Oracle Database to the new one. Oracle Golden Gate can target many databases and do this for you. You can also use AWS DMS (if you are migrating to AWS). There are also numerous other third-party options, with one of the most versatile being Kafka. In that case, you use an Oracle sink to write to Kafka, which can be done via Golden Gate. You must then use a source for your database to write to your new database. This approach allows for transformation work to take place between the source and destination, which is sometimes useful.

Method two is the most common since it requires no downtime and can sometimes accommodate a slow roll migration with replication going in both directions. But it is also much harder to implement.

Refactor and Rewrite For many large, complex databases using many Oracle-specific features and large amounts of stored program code, this is the correct approach.

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 6

It also provides additional benefits:

• Eliminate Technical debt – Old code and workarounds to resolve compatibility with old features make code fragile and difficult to fix or enhance • Move to a modern microservice framework – Allows developers to create new features faster with generally lower error rates • An updated codebase is a golden opportunity to implement data governance best practices from the ground up When taking this approach it is common to break a single monolithic database into multiple components, including:

• Microservice transaction and configuration stores – Transaction stores going to a relational database and configuration data in a document store • Event stores – Not really addressed here but Elasticsearch, Solr, and Kafka can often fill this requirement. Kafka can be used as a buffer to Elasticsearch or to queue requests between microservices • Data warehouse/Data lake – For analytic processing of column stores like MariaDB AX, Spark with Parquet, or Clickhouse Once the redesign and refactoring is done – which will likely take a year or more – migrating to the new database will require a replication as described in the direct migration plan above, ideally using the Kafka/ Sink/Source approach.

Migrate to a New Application This is a subject worthy of its own paper, so we won’t talk about this in- depth beyond pointing out that you will still need to get your data from the old system to the new one, and you will need a plan. Some software vendors will help, but many will leave it all up to you.

Where to Migrate

In Place In this scenario you migrate to a server in the same location. If your Oracle Database is in your own data center or a colocation center, you simply put the new OSDB server in the same place.

If your Oracle server is running in a private cloud such as VMware, OpenStack or another cloud, you put your new database there. And if your Oracle Database is already running in a public cloud, you put the new database in a public cloud.

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 7

The Cloud If you’re considering migrating from Oracle to another database, it’s much more likely in today’s world that you’re also thinking about migrating to one of the public clouds.

If that’s the case, you have two additional choices:

• Migrate to the cloud using their infrastructure-as-a-service (IaaS) tools, for example creating virtual machines (VMs) or containers which will run much the same as if your database were running on regular hardware. • Migrate to the cloud vendor’s database-as-a-service (DBaaS) offering for your chosen database, which allows the cloud offering to take care of most day-to-day operational tasks.

The Cloud: IaaS Why stick with IaaS when you can use DBaaS? It depends on your needs and the offerings available from the vendor, including:

• The OSDB technology you’ve chosen is not available from the vendor • To make their DBaaS offering point and click and manageable for them, the cloud vendor may not support one or more of the features you need • The configuration options you need for good performance is not available • The DBaaS high availability implementation does not meet your needs • You are a control freak and don’t like the idea of a DBaaS service doing things that are out of your control. For example: AWS regularly performs minor upgrades to their RDS service with little warning, and have been known to force upgrades when a database version reaches end of life.

The Cloud: DBaaS If the cloud vendor offers a DBaaS solution, then there are several compelling reasons why it may be a good choice:

• Point-and-click provisioning • Built-in HA • Automatic backups • Automatic recovery from backups • Point-and-click replica creation • Point-and-click failover

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 8

• Near-zero or zero downtime hardware upgrades and downgrades • Auto-scaling (not available for all DBaaS offerings) Most database users find the benefits of DBaaS offerings very worthwhile.

OSDB Technologies There are many OSDB database technologies to consider. Each has its own history and design characteristics that make it best for certain workloads. Below, we will go over each at a fairly high level.

Rank Score DBMS When to use Jul 2020 Jun 2020 Jul 2019 Jul 2020

1 1 1 Oracle 1340.26

Very popular, but not as close to 2 2 2 MySQL 1268.51 Oracle as PostgreSQL. Good for most use cases. Popular Oracle migration Target. 4 4 4 PostgreSQL 527 Good for transactional and content store applications. Good for redesign efforts with 5 5 5 MongoDB 443.48 content stores. Good for redesign efforts with high 10 10 10 Cassandra 121.09 volume writes and time series data. 12 12 13 MariaDB 91.13 MySQL with PL/SQL support. Good for redesign efforts with 23 21 18 HBase 48.66 high volume writes to a key values store. Good for redesign efforts with a 34 34 35 Spark SQL 18.4 heavy analytics component. Amazon 45 45 52 8.64 PostgreSQL or MySQL DBaaS Aurora Good for redesign efforts with a 65 67 86 ClickHouse 5.31 heavy analytics component. Distributed scalable PostgreSQL 68 74 89 CockroachDB 4.97 dialect but not as mature. Good for transactional and content stores. Distributed scalable PostgreSQL 159 166 213 YugabyteDB 1.04 dialect but not as mature. Good for transactional and content stores.

Source data: https://db-engines.com/en/ranking July 2020 db-engines.com score definition: https://db-engines.com/en/ranking_ definition

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 9

PostgreSQL1 If you are migrating directly from Oracle to an opensource database, PostgreSQL should be given serious consideration. Due to the similarities in dialect between Oracle and PostgreSQL, especially between PL/SQL and PostgreSQL stored procedures, most successful migrations from Oracle directly to an OSDB have been to PostgreSQL

Postgres was created as a research project at the University of California, Berkeley as a successor project to the Ingres project – hence the name, which essentially means post Ingres. The project was initiated in 1985, although it did not get SQL added to it for another decade.

PostgreSQL is one of the oldest popular OSDBs, along with being the most developer-friendly. It is very feature-rich and its SQL and stored procedure language dialects are very similar to those of Oracle.

But it doesn’t include all Oracle’s features and capabilities, meaning server-side code translations may not be seamless.

Until recently the PostgreSQL community was fairly insular, slow to develop and, like Oracle, the technology was hard to install and its learning curve was steep. But that’s changed recently, very likely due to increased interest due to the similarity of its SQL dialect to that of Oracle.

PostgreSQL has now become the default choice for many users migrating directly from Oracle to an OSDB. But PostgreSQL’s surface similarities to Oracle can become a trap if you are not careful. One common example is Oracle’s number data type, which corresponds to PostgreSQL’s numeric data type almost exactly. However, Oracle optimizes its storage depending on the size and required precision. PostgreSQL stores all numeric columns in exactly the same way, which can become inefficient both in terms of space and performance.

PostgreSQL is designed from the ground up as a transactional engine. It shines in transaction processing applications, does well for content management, and special proprietary branches have even been created for data warehousing applications. Amazon RedShift and Green Plumb are examples of data warehousing implementations.

PostgreSQL database replication is built into the server. HA is managed through external utilities to route traffic to replicas and manage the failover process, while sharding/horizontal scaling of writes for PostgreSQL requires third party tools.

1 https://en.wikipedia.org/wiki/PostgreSQL

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 10

MySQL and MariaDB2 MySQL is the most widely used OSDB in the world today, and is second to only Oracle itself overall. Born in the 1990s as an easy-to-use database for the burgeoning internet, it was originally very small, easy to install, and with a limited feature set. Nowadays it is generally still much simpler to operate than both Oracle and PostgreSQL, but its SQL dialect is poorer, although MySQL 8 and MariaDB 10.5 both have significant new language features that narrow the gap.

If your database and application are fairly straightforward and you are not using Procedural Language for SQL (PL/SQL), migration to MySQL is a viable option. You will find a lot more DBAs available for something like this than you would with PostgreSQL.

If you do have some PL/SQL, the MariaDB branch of MySQL supports the Oracle PL/SQL language.

MySQL and the MariaDB branch, through their support of multiple storage engines, can and do support a very wide array of workloads including transactional, content management, business intelligence (BI), and moderate-sized data warehouses.

MongoDB3 MongoDB does not support SQL, is in no way relational – in fact, MongoDB does not require a schema of any kind for many use cases. A developer simply opens a connection and specifies which database and collection (such as a table) to write or read from.

MongoDB has limited support for transactions and should not be considered a transactional database. MongoDB is an excellent choice for content management and the storage of plain text. MongoDB also has an excellent aggregation platform which makes it a good choice for some BI workloads. It is also great as a persistent object store because its native storage format is JSON.

MongoDB, first released in 2009, was created by a company not originally interested in databases at all. Its developers wanted to store data in a convenient way for later retrieval, so they created their own database using a modified JSON format (JSON allows a developer writing code in an object-oriented language to easily store and retrieve objects). Although MongoDB was branded a document store given its similarity to databases of this type, it could also have been called a simple object store, with the exception that it does not support some object features such as inheritance.

2 https://en.wikipedia.org/wiki/MySQL 3 https://en.wikipedia.org/wiki/MongoDB

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 11

It wasn’t long before MongoDB became more popular than the developer’s original product, so they changed the name of the company and became a database company.

MongoDB has built-in replication in the form of replica sets and HA through the MongoDB library, and a supplied router called mongoS. HA is a basic feature of the product.

MongoDB also has built-in sharding, allowing it to scale writes across multiple replica sets. The sharding feature also supports geographic routing of data to local replica sets.

Although MongoDB is not a candidate for direct migration from Oracle, it’s often very successfully used in refactored migrations.

Cassandra4 Not being a relational database and having no support for ACID transactions, Cassandra is, like MongoDB, also not a candidate for direct migration. Instead, it’s a good potential choice for a write-intensive redevelopment project (for weblogging or internet of things (IoT) applications, for example).

Initially released in 2008, Cassandra was spawned from a marriage of Google’s Bigtable and Amazon DynamoDB. It initially did not have a query language, just an API. Later, when the Cassandra community realized that most Cassandra use cases seemed to fit a subset of SQL, they invented the Cassandra Query Language (CQL).

Cassandra is designed to handle very high volumes of writes with a moderate level of reads. It is not relational, despite CQL looking much like SQL. Cassandra was created from the ground up to be sharded – the Cassandra community calls it partitioned – highly available and geographically distributed. It is frequently used for IoT applications and time-series databases (TSDBs). Due to its inherently distributed nature, it works well with Spark, which is what most use to collect analytic data from Cassandra.

By its basic design, Cassandra replicates, locally and geographically, in an asynchronous fashion. There are no primary/replica nodes in a Cassandra cluster. All nodes are equal. Cassandra is often referred to as eventually consistent – meaning, you can write to the database and then read back a different value if care is not taken to ensure a quorum of replicas are queried.

4 https://en.wikipedia.org/wiki/Apache_Cassandra

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 12

Spark5, Hadoop6, and HBase7 Spark and Hbase do not support ACID transactions and are not designed to support transactional workloads. They cannot be considered direct replacements for an Oracle database. Spark can, however, be used to replace the analytics features of Exadata.

HBase performs well as a large-volume key-value store. These technologies are good candidates for a redevelopment project where an Oracle Analytics workload is offloaded to an OSDB. Spark, Hadoop, and HBase are three very different but related technologies used for processing massive amounts of data.

Hadoop runs the underlying framework of servers used by HBase and Spark. It is exposed to HBase and Spark as the Hadoop FileSystem (HDFS) and consists of a distributed network of servers running in a single data center. It is never distributed geographically. However, there are third-party proprietary tools that will replicate Hadoop clusters geographically.

Spark is a distributed query engine designed to perform data warehouse-style queries and data transformations. It supports standard SQL with extensions and features a rich developer API, which goes well beyond what can be done with SQL. Spark is not in any way transactional. Spark should be thought of as a query engine and ETL server.

HBase is a direct, open-source implementation of Google Bigtable. It supports very wide rows that can handle millions of columns. Like Cassandra, it can support very high volumes of writes with moderate read rates. It gives the Spark Hadoop environment a fast way to access specific data, and often used as a content store to keep dashboards up to date.

Clickhouse8 Clickhouse is not transactional. It works best when data is loaded in large batches and is intended for queries passing through billions or trillions of rows. Clickhouse should be considered only to replace the analytics functions of an Oracle, likely Exadata, database.

Initially released in 2016, Clickhouse is a distributed column-store designed to support massive data volumes in a data warehouse. It uses an extended SQL dialect which includes the ability to handle complex nested columns.

5 https://en.wikipedia.org/wiki/Apache_Spark 6 https://en.wikipedia.org/wiki/Apache_Hadoop 7 https://en.wikipedia.org/wiki/Apache_HBase 8 https://en.wikipedia.org/wiki/ClickHouse

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 13

CockroachDB⁹ CockroachDB operating as a fully functional relational and ACID- compliant transactional database may be a good target for less complex Oracle migrations, where built-in global replication and HA are attractive options.

Initially released in 2014, it is an open-source project inspired by Google’s well-known research paper on its Spanner database. It is designed from the ground up as a relational distributed database at both data center and global levels. It is also designed to be self- replicating and highly available.

CockroachDB, like Google Spanner (not open source), is fully relational and fully supports ACID transactions. If you want to establish a global presence with a fully relational OSDB, CockroachDB might be a good choice. The SQL dialect it supports is somewhat limited if you are coming from Oracle, however, so it’s unlikely to suit a direct migration.

CockroachDB uses the PostgreSQL dialect and wire protocol, allowing existing PostgreSQL client applications to read and write to the database without having to change the client code. It also has several other features:

• Horizontally scalable for writes • HA is a basic part of the design • Global replication

Yugabyte10 As in the case of CockroachDB, Yugabyte as a relational and ACID- compliant transactional database is suitable for some less complex Oracle migrations, thanks in part to built-in global replication and HA. Plus its Cassandra API makes it a good fit for heavy write workload applications like IoT and web-logging. Yugabyte is another open-source, Spanner-like distributed relational database – but with a twist. Because it’s multimodal, Yugabyte client applications can access the database via the PostgreSQL dialect and client libraries, or using CQL and client libraries.

The primary attractions to Yugabyte are:

• Horizontally scalable for writes • HA is a basic part of the design • Global replication • Multimodal 9 https://en.wikipedia.org/wiki/Cockroach_Labs 10 https://en.wikipedia.org/wiki/YugabyteDB

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 14

On the Cloud If your intent is to use IaaS to deploy in the cloud, please see the above database choices. You can deploy any of them by using VMs or containers in the cloud.

If you are looking for the cloud service to take on significant operational complexities, then each of the major cloud vendors also has a DBaaS offering that may work for you.

CloudSQL11 Google’s CloudSQL offers support for standard MySQL and PostgreSQL

Amazon RDB and Aurora12 AWS offers both RDS and Aurora database services. RDS supports:

• MySQL 5.5, 5.6, 5.7 and 8.0 • MariaDB 10.0-10.4 • PostgreSQL 9.6,10,11 and 12 • Aurora for MySQL 5.6 and 5.7 • Aurora for PostgreSQL 9.6, 10 and 11 Aurora for MySQL and PostgreSQL are the standard MySQL and PostgreSQL releases, with the storage backend re-written to support a very different clustering technology from standard open-source releases. While technically proprietary, these changes do not affect the application code, only performance and some minor differences in operation.

Azure Open Source13 Azure offers both PostgreSQL and MySQL services as DBaaS.

11 https://cloud.google.com/sql/ 12 https://aws.amazon.com/rds/ 13 https://azure.microsoft.com/en-us/free/mysql/ and https://azure.microsoft.com/en-us/services/postgresql/

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 15

Tools A few of the more commonly used tools to help with migrating from Oracle are:

• Ora2Pg – A Perl script which does an exhaustive job of analyzing an Oracle database and notifying you of the required changes. It will also create a new PostgreSQL schema for you and migrate the data in batch form from the Oracle database to the new PostgreSQL database. • SQLines – A web-based utility that converts SQL code, including Data Definition Language (DDL), from one SQL dialect to another. • AWS DMS – A set of AWS utilities that can be used to analyze a schema from one database type and create a new one in another type. It also supports online replication between the source and target databases.

Conclusion Moving away from Oracle and onto your OSDB of choice can be a great way to get out from under Oracle’s often extremely complex license and contract structure – especially if you’re worried about getting locked in, a common concern – while reducing support costs and avoiding annoying customer audits. If you’re frustrated and thinking about leaving Oracle, don’t despair: You’ve got options, although it’s worth noting that selecting the best route for your use case typically requires deep technical expertise and experience with both Oracle and other databases.

As we’ve illustrated above, there are three main ways to get off of your Oracle Database and on to an OSDB:

Direct migration – For migrations involving databases with low to moderate complexity. Because of the similarity of its SQL dialect to that of Oracle, PostgreSQL has largely become the default platform for direct migrations.

Refactoring – Preferred to a direct migration by many because it helps eliminate technical debt and facilitates a move to a microservices framework. Use whichever database you like, but make sure you have a well-tested data migration path, likely using the Kafka/Sink/source method. Refactoring is a lot of work but the end result is usually worth the effort.

Migrate to a new, off-the-shelf application – Because you’ll have to get your data from the old system to your new one, you’ll still need a data

pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 16

migration plan if you go this route – don’t count on your software vendor having one.

No matter which route you take, your migration is likely to take longer than you’d prefer, unfortunately. Case in point: A very large company recently completed a migration away from their various Oracle databases using all three approaches, and even the smallest and simplest of the migrations took six to eight weeks to complete – and most took six months to a year, with a few redevelopment/ refactoring efforts taking more than two years.

A strong migration partner, however, can help alleviate some of this pain. Pythian database experts have years of experience working with Oracle and the alternative database technologies mentioned in this paper. They can help get your new OSDB (and your data) up and running faster, for less money, and without needing to hire specialized IT resources for a one-time operation.

For more information on how Pythian can help you with your Oracle and OSDB projects, or to set up a discovery call with one of our technical experts, please contact us.

AUTHOR John Schulz Principal Consultant John has 43 years of experience working with data in files and databases, from flat files through ISAM to relational databases and, most recently, NoSQL. For the last 17 years, he’s worked on a variety of open-source technologies including MySQL, PostgreSQL, Cassandra, Riak, Hadoop, and Hbase. As Chief Database Architect at AOL, he replaced Sybase with MySQL and has worked hands-on with MySQL databases holding hundreds of billions of rows and running millions of transactions per second. For the last six years, he’s worked with Pythian to help customers improve existing databases and select new ones for new applications.

linkedin.com/company/pythian twitter.com/Pythian Contact us at +1-866-798-4426 or [email protected]

ABOUT PYTHIAN Founded in 1997, Pythian is a global IT services company that helps organizations transform how they compete and win by helping them turn data into valuable insights, predictions and products. From cloud automation to machine learning, Pythian designs, implements and supports customized solutions to the toughest data challenges. © Pythian Services Inc. 2021 OFFICES Ottawa, Canada New York City, USA Minneapolis, USA London, England Hyderabad, India