Tag: Oracle database

  • Database Virtualization: Breaking Vendor Lock-In

    Database Virtualization: Breaking Vendor Lock-In

    Every enterprise is battling vendor lock-in—constantly. Ask any IT leader about what keeps them up at night and vendor lock-in is certainly near, if not at, the top of the list. And while network, storage and compute have long been democratized by virtualization, one discipline has held out as the last bastion of vendor lock-in: Databases.

    How bad can it be? Take Amazon, for example. They celebrated their retirement of the last internal Oracle database exuberantly. People familiar with the matter suggested that replacing Oracle was at least a decade in the making, probably longer. It is anybody’s guess how much effort it took to accomplish this feat. A big celebration was in order, indeed.

    Now, let’s take a look at database virtualization. As a relatively new discipline, the idea of virtualizing critical systems like data warehouses made a big splash recently. But does it apply to your systems? And the ubiquitous question: Does it come with performance penalties?

    What Is Database Virtualization?

    Database virtualization is the concept of abstracting applications and databases from each other. Using virtualization, an application written for, say, an Oracle database can run on an open source database like PostgreSQL without making changes to SQL or to associated APIs. As an aside, this is not to be confused with data virtualization—which is really a data integration play.

    A database virtualization platform translates queries and data in real-time. Through emulation, it bridges functional gaps between the source and destination system so applications remain unchanged while moving to a different database. Database virtualization doesn’t make migrations easier; it makes them effectively obsolete.

    The idea is rather compelling. So much so that Amazon developed and released their own version of a database virtualization product recently that targeted small standalone database systems.

    Why You Need Database Virtualization

    Here’s a simple rule of thumb. The cost of migrating a typical data warehouse—without virtualization—is about the total cost of the database over the next five years. So, if your current data warehouse runs you, say, $5 million a year, (which is typical for a mid-range system) your cost to migrate it will probably be close to $25 million. Moreover, the project could take up to five years.

    But wait; there’s more. The true downside of conventional database migrations is actually their abysmal failure rate. Analysts put it typically above 80%. For large data warehouse systems, it seems to be higher still. That’s what makes databases the ultimate bastion of vendor lock-in.

    As an IT leader, you naturally don’t have the time, the budget or the appetite for such a risky undertaking; you’d probably rather deploy that kind of money toward creating new revenue. Database virtualization lets you do just that: Sidestep these risks and, instead, focus on what’s really relevant.

    When to Use Database Virtualization

    Database virtualization is particularly suitable for replatforming data warehouse workloads. These workloads are notorious for their complexity and for the effort a rewrite would entail. Often, these workloads have been grown and curated for years—sometimes decades. Maintaining the workload while replatforming makes economic sense: It means preserving and protecting long-standing investments.

    However, for database virtualization to be successful, both the source and destination systems need to be of comparable performance and scale. This should be obvious: Moving a workload from, say, a Teradata system to a Postgres instance is unlikely to satisfy your business users.

    But there is good news. Over the past few years, cloud data warehouses have increasingly reached competitive performance targets. They have become viable alternatives to legacy on-premises appliances. From an IT leader’s perspective, that is great timing. Most IT leaders today are currently tasked with sunsetting these appliances over the course of the next few years. Database virtualization couldn’t be any timelier.

    Goodbye, Vendor Lock-In

    Virtualization, as a general concept, has revolutionized the IT stack over the past 20 years. Server virtualization, which started as a niche for QA and developers, became the foundation of cloud computing; virtualization then spread to network and storage. Databases are one of the few remaining disciplines that have bucked the virtualization trend—until now.

    Not surprisingly, the premise of database virtualization resonates greatly with practitioners. And even though the initial success in the data warehousing arena is yet to be replicated in other areas, it seems like it’s just a matter of time before the concept becomes ubiquitous.

  • Introduction to Materialized Views

    Introduction to Materialized Views

    More often than not, the types of queries that use materialized views are both faster, and use fewer resources than those that are still processing queries directly to base tables. But the key to understanding the potential that materialized views bring with them involves first understanding as much about them as possible.

    What is a Materialized View?

    In the world of computing, a materialized view is a database object made up of any results that were obtained from a query. Note that this could be a local copy of data that is also stored in a separate remote location, or it could have been derived from a join result. Sometimes, a materialized view could even be created after a user performed an aggregate function, thus allowing it to act as a summary of that database information.

    Oracle Database first made materialized views available in version 8i of their software, and it has been a part of every release since. Just a few of the environments that support materialized views include, but are not limited to, others like SQL Server, BigQuery, PostgreSQL and Sybase SQL Anywhere.

    View vs. Materialized View

    What’s the difference between a regular view versus a materialized view? There are a number of important things you’ll need to keep in mind.

    Chief among them, the fact that a view itself is a precise type of virtual table created via the “Create View” command. As the name suggests, it collects all data obtained from any relevant query that you’ve executed. A view will always be compiled every time it is either used or accessed in any way. This is how a view is able to make sure that you’re always getting the most updated data, no matter what – it’s literally designed to do that.

    If you make any changes to the data contained inside that view, it will get pushed out to the table in which it originated. Along the same lines, any changes made to that base table are automatically pushed to the view so that the same information is in both places at once.

    Because of this extra step, a view will always be a bit slower than a materialized view when it comes to performance. The upside is that this really doesn’t require much in the way of storage space. But it does mean that you’ll be sacrificing a bit in terms of performance.

    With a materialized view, you’re talking about a physical copy of the information contained in that original table. This means that it isn’t updated every time you interact with it – you have to go out of your way to update it manually. Or, if you’d prefer, you can have it update using pre-defined triggers.

    Because of this, a materialized view is always going to respond much faster than its traditional counterpart. However, if you don’t make an effort to confirm that it has been updated, you also run the risk of retrieving stale data.

    Why Use a Materialized View?

    So at this point, you’re likely asking yourself, “Why use a materialized view in the first place? What can this do for me that a simple view cannot?” The key thing to understand has to do with the costs that you accrue whenever a database is queried.

    Even a simple query still needs to be parsed, validated, planned, optimized and executed. In an operational sense, this equates to CPU time. This means memory usage. This even directly impacts your opportunity costs as time goes on. All of this adds up – especially as the application you’re working with continues to evolve and become more resource-intensive.

    Savvy developers are always looking for a way to cut costs, and materialized views are a big part of how they’re able to do it. Remember that the results obtained are always kept in memory – meaning that they are only updated when absolutely needed. This is the opposite of what happens when you query tables or use logical views; those results are updated constantly. Therefore, using materialized views is a great way to significantly reduce your costs without impacting performance in a way that will also affect your end users.

    Materialized Views Best Practices

    For best results, you should always make sure that your materialized view reflects query patterns against the original table you’re working with. Don’t just create a materialized view for every iteration of a query. Instead, create one to help focus on a broader set of queries.

    Likewise, if the base table you’re working with is partitioned, your materialized view may grow to a size larger than you’re comfortable with. Therefore, it should be partitioned, as well, to preserve the performance benefits it is supposed to bring with it.

  • RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX this week launched a set of tools designed to make it easier to convert applications running on an Oracle database to Amazon Aurora, an instance of an open source PostgreSQL database running on the Amazon Web Service (AWS) cloud that is compatible with Oracle databases.

    Announced at the AWS Summit event in Washington D.C., the clckwrk Refactoring Service for Oracle promises to reduce the amount of manual effort associated with refactoring applications for the Amazon Aurora platform by automating as much as 60% of the database schema conversion process.

    James Ball, chief strategy officer for RDX, said in addition to reducing costs, many organizations want to shift applications to open source databases in the cloud to further their DevOps ambitions. Each time an application needs to scale, an organization will incur additional Oracle licensing fees. In contrast, an open source database enables DevOps teams to scale database instances as required automatically, he said.

    AWS has been making a concerted effort to convince customers to give up proprietary databases in favor of open source databases running on its cloud platform. That competitive pressure is a driving force behind new alliances that previously would have been considered unimaginable. Oracle, for example, recently partnered with Microsoft to promote the integration of the Oracle Cloud platform with the Microsoft Azure cloud. Oracle would prefer its database run on its cloud, but through the alliance is signaling its willingness to work with Microsoft to deploy Oracle database on Azure, a cloud platform that is the leading industry alternative to AWS. Microsoft, of course, has its proprietary database to adopt in the form of Microsoft SQL Server.

    Ball said RDX not only provides tools to accelerate the conversion to Amazon Aurora, but it also provides managed services for customers that want to outsource the management of Amazon Aurora to RDX.

    It takes most organizations several months to migrate a legacy application on to a public cloud. AWS has a vested interested in helping accelerate that process whenever possible. But many organizations that have embraced best DevOps practices find their efforts are hampered by reliance on proprietary databases. In fact, one of the reasons so many developers tend to favor open source databases is to avoid all the headaches associated with getting approvals for new database licenses.

    It’s unclear to what degree the rise of DevOps in the enterprise will ultimately shift database allegiances. Oracle is trying to maintain as much control as possible by making its databases available as a managed service that eliminates some of the purchasing overhead associated with spinning up new instances. However, the cost of an Oracle database license is still buried in the cost of the managed service.

    Not every organization is looking to transition away from a proprietary database, but there is now enough momentum around the “open source first” movement to make it worthwhile to build tools that automate the refactoring of legacy databases not just to reduce costs, but also to make IT a lot more agile.

    — Mike Vizard