Understand the five key points of database virtualization


According to library virtualization, it claims to break the supplier’s lock on data warehouse technology. How applicable is it? How do it leaders evaluate the technology?

We are experiencing an incredible revival. Databases, long derided as outdated, have suddenly become the darling of the industry. Many years after authorities announced that the database was almost dead, a new type of start-up attracted the attention of Wall Street. However, it leaders still have difficulty effectively migrating their existing workloads to these systems.

Vendor locking of databases is legendary. No other department has had such a big impact on its users. Naturally, supplier lock-in makes customers grateful for existing technology. However, it also discourages competition and upstarts. Snowflake’s CEO once lamented how difficult it was to break into this market. At that time, he said: “Teradata makes it difficult for them to leave their platform.”

With the emergence of database Virtualization (dbv) (rather than data virtualization), a new method has entered the stage. Dbv claims to have broken the supplier’s lock on data warehouse technology. How applicable is it? How do it leaders evaluate the technology? Here are five things about dbv.

1) How does a dbv work?

The dbv platform is located between the database and the application. It enables applications written for one database to run locally on another database. All queries and communications are translated in real time. For example, applications written for Teradata can run directly on Microsoft azure synapse without even “knowing” that they no longer run on Teradata.

The dbv is completely transparent so that the application does not require any or very little tuning. This includes not only standard SQL, but also proprietary extensions. To be successful in practice, loaders, drivers, and utilities must also be supported.

Because the dbv system realizes the conversion of query and data, they can run with very low overhead. The actual data processing is always executed on the data warehouse itself, and the large-scale parallel processing (MPP) function of the system is used.

2) When to use dbvs instead of traditional migrations?

In traditional migration, all existing SQL code, drivers, tools and utilities are replaced with the corresponding items of the new target system. This may be the preferred method for compact data warehouse systems with a small number of applications. A data mart with only a limited number of users may be eligible to do so.

However, in the case of complex enterprise data warehouse (EDW), dbv can be significantly better than traditional migration. Dbvs migrate workloads with minimal time, cost, and risk.

3) Can the dbv cover my workload?

Some workloads use specialized features extensively. There are also features that use earlier than standardization. In other words, no two data warehouses have the same workload. This makes it difficult to assess the coverage of the dbv system.

A complete documentation of supporting functions seems desirable, but it is not very helpful in practice. Most customers cannot succinctly describe what features their workloads are currently using. More complicated, the original author of a query or function usually no longer works in the company.

However, this is not necessarily an obstacle to the adoption of dbv. Since the adoption risk of dbv is low, it can achieve a very effective proof of concept (POC) implementation. Customers can use dbvs without changing their applications. They can test their actual application directly in POC.

The POC can then quickly identify any missing coverage. It is important to understand that while 100% coverage seems desirable, 90% is usually sufficient. Dealing with the remaining problems usually requires little effort.

4) How is dbv different from data virtualization?

Data virtualization is a somewhat related but completely different approach. To make data virtualization successful, we first need to rewrite all applications and adopt Abstract SQL dialect. Then, only in this way can it prevent future supplier locking. The main application field is the “green space” scenario that does not need to consider existing applications.

In contrast, dbv breaks the existing supplier lock-in. It keeps the application as it is. Over time, this may lead to a variety of different application technologies. However, this may not be a big problem and is well offset by the adoption of new data technologies.

5) Can dbv re platform EDW into any technology?

Every few years, a new technology will challenge the dominance of enterprise data warehouse system. Newcomers usually outperform existing stacks in a significant dimension. For example, new technologies may be more scalable. Another may simplify the sharing of data. Some are more attractive to open source developers.

Typically, expert teams can build custom solutions to shift the workload from EDW to most new technologies. However, the greater the functional gap, the more software engineering is required to run these systems. For example, migrating EDW to NoSQL system may be technically feasible, but it is not always economically desirable.

For a dbv to succeed, the source and target must be meaningfully similar. However, this does not require equivalent functionality. Dbv can make up for the shortcomings of most advanced functions, such as stored procedures, macros, and even unsupported data types. At present, the cloud native PAAS solution is the most successful in the dbv environment.

Choose the correct migration method

Many factors need to be considered when selecting a new target system for an existing EDW. One often overlooked is the migration method. Dbv is very effective in breaking the supplier’s lock on the legacy data warehouse.

By taking the migration approach into account in their choice of target systems, it leaders can optimize rapid adoption while controlling risks and costs.