AlloyDB overview
For your most demanding workloads, such as hybrid transactional and analytical processing, AlloyDB for PostgreSQL is a fully managed database service that is compatible with PostgreSQL. AlloyDB Google cloud provides enterprise-grade performance, availability, and reliability by combining a cloud-based, multi-node architecture with a database engine developed by Google.
How AlloyDB works
An application uses common PostgreSQL methods and protocols to establish a connection with AlloyDB instances. The program then interacts with the database using the PostgreSQL query syntax.
Beneath the surface, AlloyDB makes use of a cloud-based hierarchy of elements and functionalities that are intended to optimize query performance and throughput while optimizing your data’s availability. With the help of Google Cloud administrative tools, you can keep an eye on the health of your AlloyDB Google Cloud deployment and modify its size and scope to best suit your workload’s evolving needs.
Clusters
Within a specific Google Cloud region, a single AlloyDB deployment groups all of its resources into a single cluster. All of your databases, logs, and other metadata are included in this. AlloyDB uses a cloud-based file system that was created by Google and tailored for AlloyDB, and it deploys all of the resources of a single cluster within a single Virtual Private Cloud (VPC).
Nodes and instances
A cluster has many nodes, which are instances of virtual machines devoted to executing the database engine compatible with PostgreSQL that is used by applications to query the data in your cluster. Nodes in your VPC are grouped by AlloyDB into instances, each of which has a private, static IP address. In reality, PostgreSQL protocols are used by your apps to connect to instances at these IP addresses. SQL queries are subsequently sent to respective nodes by the instances.
There are two types of instances in AlloyDB:
- One primary instance, which serves as a read/write access point to your data, is present in each cluster. There are two types of primary instances: basic and highly available (HA).
- Two nodes make up a HA primary instance: an active node and a backup node. When necessary, AlloyDB automatically moves the standby node into the active node while keeping an eye on the active node’s availability.
- Basic instance: Basic instances are optional for non-production settings that don’t need high availability. A basic instance lacks a standby node and has just one node. See Reduce costs using basic instances for further details.
- Read pool instance: Up to a maximum of 20 read pool instances, each with one or more read-only nodes, are optionally allowed in your cluster. All requests delivered to a read pool instance are automatically load-balanced by AlloyDB and routed to the nodes of the instance.
Applications can use the primary instance for all queries in a cluster that only contains the primary instance and no read pools for simpler use cases. Read pool instances can be added to the cluster for more taxing tasks. After that, you set up your analytical or reporting apps to send read requests to them. By distributing the load among several nodes, this method increases scalability while lessening the strain on your core instance.
As the requirements of your application evolve, you can alter the number of nodes in a read pool instance at any moment. Additionally, there is little latency while resizing the memory and vCPU count of an instance’s component nodes. Since AlloyDB keeps your data in the cluster’s flexible storage layer rather than in the instances, scaling your instances doesn’t increase the risk of data loss.
AlloyDB Google Cloud features
AlloyDB Google Cloud differs from a stock PostgreSQL installation in several aspects, in addition to the benefits of vertical and horizontal scaling that come with the multi-node design previously discussed. The main characteristics of AlloyDB are examined in further detail in the sections that follow.
Automatic and adaptive database features
Several elements of the fully PostgreSQL-compatible database engine that drives each AlloyDB node continuously examine the frequency and structure of the queries handled by your instances, using this data to automatically apply optimizations or recommend schema changes:
- Based on your usage patterns, an index advisor assists you in identifying chances to use new indexes to optimize your database structure.
- By employing a columnar format for data storage in memory, a columnar engine can speed up the execution of analytical queries. This enables AlloyDB to efficiently read a huge quantity of table data when necessary by utilising sophisticated processing algorithms.
- The PostgreSQL stale-data autovacuum function has an adaptive variant that automatically modifies vacuum-related parameters to best fit the structure of your workload.
- Utilizing the cloud-based architecture that AlloyDB is built on, automatic memory and storage management tools continuously allocate and release memory and storage as needed to maintain your cluster operating at peak speed and resource efficiency.
High accessibility
An AlloyDB cluster by default provides availability (HA) via the redundant nodes of its primary instance, which are situated in two distinct zones and have automated failover.
Basic, single-zone primary instances are an optional alternative for clusters functioning in non-production environments that do not require HA.
Additional load-balanced, multi-zonal, high-availability access points to your data are created by adding read pool instances with a minimum of two nodes. Every instance of the read pool operates separately from the main instance.
Disaster recovery and data backup
With the help of AlloyDB’s continuous backup and recovery technology, you can build a new cluster at any time during a customizable retention period. This enables speedy recovery from data loss incidents.
Furthermore, AlloyDB Google Cloud has the ability to regularly or on-demand generate and store full backups of the data in your cluster. You can restore from a backup at any time to a fresh AlloyDB cluster that has all of the data from the original cluster when the backup was made.
Security and access control
A cluster can be set up to require a connection to the secure AlloyDB Auth Proxy, which controls access using Google Cloud Identity Access and Management (IAM).
With the inclusion of a few extra roles unique to AlloyDB Google Cloud, AlloyDB use the PostgreSQL user role system for authentication.
Encryption
By default, AlloyDB uses Google’s encryption techniques to safeguard all data while it is at rest. When building a cluster, you can specify a customer-managed encryption key (CMEK) if you must secure your data using a key that you supply instead. All data written to that cluster is then encrypted by AlloyDB using the CMEK key.
Backups are also covered under CMEK. When making an on-demand backup, setting up a backup plan, or recovering from a backup, you can specify a CMEK key.
Non-disruptive maintenance
The goal of AlloyDB maintenance procedures is to keep your database from experiencing too many interruptions. While read pools are always available and never go down, primary and secondary instances have downtimes of less than a second. This is achieved by setting up backup servers and promptly replacing them with the operational servers when they are ready. Any active database connections are temporarily terminated during this operation. During this process, you can keep accessing your database as usual.
As shown on the Google Cloud dashboard and the Google Cloud CLI CLI, the entire operation may take several minutes, even if this replacement procedure guarantees little downtime.
These maintenance procedures include both Google-performed routine maintenance and manual chores like instance resizing and flag tuning. Use the FORCE_APPLY database flag if you want to implement any change right away, even if it involves a longer outage.
Extension support
Many widely used PostgreSQL extensions are supported by AlloyDB Google Cloud.
A self-hosted alternative: AlloyDB Omni
Google offers AlloyDB Omni as an alternative to AlloyDB running in Google Cloud. You may operate AlloyDB’s robust database engine on your own Linux-based computer environment, wherever you may be, with this condensed, downloaded edition.