devopsy.kinsta.cloud

Author: Mia Lang

  • 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.

  • The Value of OpenTelemetry in Observability

    The Value of OpenTelemetry in Observability

    As infrastructure becomes more complex, the quest for better observability continues. With increased containerization, third-party applications and generally increased network complexity, it becomes difficult for organizations to track issues of stability and performance. But OpenTelemetry can be used to improve upon observability throughout a network by enhancing and consolidating reporting throughout all applications and services.

    So, what is OpenTelemetry and how can it help your organization’s processes? Here’s what you need to know.

    What is OpenTelemetry?

    OpenTelemetry is a Cloud-Native Computing Foundation (CNCF)-curated open source set of libraries, agents and components designed to increase the visibility of services. Through OpenTelemetry, organizations are able to better collect telemetric data for the purposes of debugging and management. A scalable, flexible solution, OpenTelemetry is able to adjust to organizations as they continue to grow.

    With OpenTelemetry, data is collected through:

    • Metrics
    • Distributed Traces
    • Resource Metadata
    • Logs

    The data is then sent to back-end platforms such as Jaeger or Prometheus for processing. All of this together enhances observability for the organization, making it easier for an organization to collect the data it needs to observe and mitigate issues appropriately.

    Greater levels of observability improve an organization’s reliability and reduce downtime. With better reliability, organizations are able to track down and resolve incidents much faster. Before the OpenTelemetry solution, developers might have used OpenCensus, OpenTracing or other similar products. While these products are excellent on their own, they don’t necessarily meet all the needs of modern networks.

    How Does it Work?

    OpenTelemetry works on three major observability systems: tracing, metrics and logging. For tracing, OpenTelemetry makes it easier to identify failures and performance issues by tracking requests within the system. For metrics, processes running within the system are closely tracked and reported on, with histograms, gauges and other easy-to-read graphical reporting. For logging, application-specific messages can be analyzed.

    Observability throughout a system has always relied upon tracing, metrics and logging. But it’s more difficult to complete tracing today because each action needs to go through so many layers of application and resources. When paired with vague log data, the process of tracking down a single incident can take hours, because the information isn’t always consistently siloed. OpenTelemetry (and other similar products) work to correct this by creating a consolidated system by which metrics, tracing and logging can be brought together.

    As an open source project, OpenTelemetry is available on GitHub for those who want to be a part of the community to influence and improve it. Of course, OpenCensus and OpenTracing are also open source solutions.

    So what’s the difference between OpenTelemetry, OpenCensus and OpenTracing? When should one be used over the other? And can they be used together?

    OpenTelemetry vs. OpenCensus

    Let’s take a look at OpenTelemetry versus OpenCensus. Both are used to boost observability, but they are generally mutually exclusive platforms because they each tackle the issue of observability from different angles. OpenCensus provides distributed tracing and time-series metrics from applications via a collection of libraries. Applications need to download a metrics exporter, and which one is used depends on the application microservices involved. OpenCensus will collect trace data, but OpenCensus will also collect time-series metrics. OpenTelemetry is used to connect OpenCensus and OpenTracing, providing the benefits of both. This creates a far more robust observability solution.

    OpenTelemetry vs. OpenTracing

    OpenTelemetry versus OpenTracing is similar to OpenTelemetry versus OpenCensus. OpenTracing also solves the same problems as OpenCensus but is usually mutually exclusive. OpenTracing is a specification for tracing APIs rather than library. Developers are able to either create their own tracer or use the OpenTracing version. OpenTracing is often faster and easier to deploy and use, but may not provide as robust analytics or metrics as OpenCensus. But again, OpenTelemetry makes it possible to use both OpenTracing and OpenCensus at the same time, through its consolidated libraries and support.

    OpenTelemetry is an ideal technology for organizations that want to increase their observability. Through OpenTracing, developers are able to achieve greater levels of visibility throughout the network; track metrics and performance; and react to issues within the organization swiftly and more accurately.

    While in the past developers may have been limited to either OpenTracing or OpenCensus, today developers are able to use OpenTelemetry for both function sets. Even better, since it remains an open source solution, developers are able to contribute to the OpenTelemetry community.