AlloyDB is a fully-managed database system that is a fork from PostgreSQL created by Google Cloud. AlloyDB separates the database layer from the storage layer. The disaggregated storage layer first handles write operations by writing the write-ahead log (WAL) to storage. A log processing service (LPS) then processes these WAL records and generates database blocks. The storage layer can be independently sharded and replicated for durability due to its disaggregated nature. For read operations, the read query can be processed either by the primary instance or a replica instance, which can be independently scaled. Results are returned if the data block is in the instance’s memory cache. If not, a fetch request is sent to the storage layer. AlloyDB further extends the caching capacity of the read instance by using local SSD as cache as well. [03]
- Developer
- Country of Origin
- US
- Start Year
- 2022
- Project Type
- Commercial
- Derived From
- PostgreSQL
- Compatible With
- PostgreSQL
- Operating System
- Hosted
- License
- Proprietary
AlloyDB also uses an automatic adaptive columnar engine, memory management, and vacuum. The adaptive columnar engine utilizes a machine learning approach to determine the optimal data storage format for the workload and applies potential optimizations for query processing. Additionally, AlloyDB employs automatically adjusted memory management and vacuum techniques.
In addition, AlloyDB announced an edition AlloyDB Omni which containerizes the AlloyDB database engine to be deployed in Linux environments.
AlloyDB is a fully-managed database system that is a fork from PostgreSQL created by Google Cloud. AlloyDB separates the database layer from the storage layer. The disaggregated storage layer first handles write operations by writing the write-ahead log (WAL) to storage. A log processing service (LPS) then processes these WAL records and generates database blocks. The storage layer can be independently sharded and replicated for durability due to its disaggregated nature. For read operations, the read query can be processed either by the primary instance or a replica instance, which can be independently scaled. Results are returned if the data block is in the instance’s memory cache. If not, a fetch request is sent to the storage layer. AlloyDB further extends the caching capacity of the read instance by using local SSD as cache as well.
AlloyDB also uses an automatic adaptive columnar engine, memory management, and vacuum. The adaptive columnar engine utilizes a machine learning approach to determine the optimal data storage format for the workload and applies potential optimizations for query processing. Additionally, AlloyDB employs automatically adjusted memory management and vacuum techniques.
In addition, AlloyDB announced an edition AlloyDB Omni which containerizes the AlloyDB database engine to be deployed in Linux environments.[03]
Checkpoints[03]
In AlloyDB, WAL records are written to the storage layer synchronously by the primary database instance. Then, the log processing service in the storage layer is responsible for replaying the logs continuously. AlloyDB supports checkpoints but there is no need for flushing the changes in the database layer to the storage layer.
Hardware Acceleration[08]
The system runs on Google Cloud instances but there is no specific hardware required, although two VM instances are required for an AlloyDB primary instance.
Indexes[09]
Same as PostgreSQL
AlloyDB provides the same index types as PostgreSQL: B-tree, Hash, GIST, SP-GIST, GIN and BRIN index types.
Isolation Levels[10]
Same as PostgreSQL
Isolation level in AlloyDB can be set through the configuration flag "default_transaction_isolation", where it can be set to either “read uncommitted”, “read committed”, “repeatable read”, or “serializable”. By default, the isolation level is set to "read committed".
Joins[11]
Same as PostgreSQL
AlloyDB supports the following three join strategies: nested loop join and it is possible to utilize the values from the row of the left relation as keys for scanning the right relation's index given that the right relation can be processed with index scan, merge join and hash join.
Logging[12]
Same as PostgreSQL
AlloyDB uses the same logging format as PostgreSQL, which uses physical logging
Parallel Execution[13][14]
Same as PostgreSQL
AlloyDB supports both inter-operation parallelism, allowing for parallel execution of parts of the plan, and intraoperator parallelism, enabling partitioning and sharing of specific operators such as scans, joins, aggregation, and append across multiple processes.
Query Execution[15]
The columnar engine of AlloyDB uses a vectorized model where SIMD instructions are used when deemed suitable. Bloom filters are also used for optimization purposes, depending on the selectivity of the workload. The row-based engine uses the traditional postgreSQL execution node with Tuple-at-a-Time model.
Query Interface[16]
AlloyDB supports SQL and Stored Procedures. Additional REST API and CLI tools are available for managing the database system resources including Google Cloud projects, project backups, clusters, cluster instances, etc.
Storage Architecture[03]
Same as PostgreSQL
For AlloyDB, all the WAL records are written synchronously to the storage layer, where the records get processed by the log processing service.
Storage Model[15]
AlloyDB stores the data in the storage layer following the same format as PostgreSQL. However, a columnar engine is used where the data that gets loaded into memory can take on either the row-based format or the columnar format based on the workload, which is decided using machine learning models. As a result, query optimizations relating to columnar formats can be applied to the relevant data.
Storage Organization[03][17]
Same as PostgreSQL
PostgreSQL uses heap files to store the database data. For AlloyDB, after the log processing service processes the WAL records, the resulting database blocks get sent back to the primary and replica instances from the storage layer.
Stored Procedures[16][18]
Same as PostgreSQL
AlloyDB supports stored procedures. SQL, PL/pgSQL, and C are supported by default. In addition, extensions to PL/proxy and PL/v8 can be added to support additional procedural languages.
System Architecture[03]
AlloyDB disaggregates its database layer and its storage layer. As a result, each component of the database system becomes more elastic to scale. AlloyDB refers to the main unit of resource as a cluster, which consists of one primary instance and multiple read pool instances. The primary instance handles read/write requests while the read pool instances only have read access. The storage layer is shared between all cluster resources.
Views[19][20]
Same as PostgreSQL
AlloyDB follows the same rule as PostgreSQL where both Materialized Views and Virtual Views are supported.
Citations
20 sources- AlloyDB for PostgreSQL | Google Cloud google.com
- https://cloud.google.com/alloydb/docs google.com
- AlloyDB for PostgreSQL intelligent scalable storage | Google Cloud Blog google.com
- 5. Concurrency Control :: Hironobu SUZUKI @ InterDB interdb.jp
- PostgreSQL: Documentation: 7.1: Multi-Version Concurrency Control postgresql.org
- PostgreSQL: Documentation: 18: 1. What Is PostgreSQL? postgresql.org
- PostgreSQL: Documentation: 18: 3.3. Foreign Keys postgresql.org
- View instance details | AlloyDB for PostgreSQL | Google Cloud Documentation google.com
- PostgreSQL: Documentation: 18: 11.2. Index Types postgresql.org
- Supported database flags | AlloyDB for PostgreSQL | Google Cloud Documentation google.com
- PostgreSQL: Documentation: 18: 51.5. Planner/Optimizer postgresql.org
- 9. Write Ahead Logging (WAL) :: Hironobu SUZUKI @ InterDB interdb.jp
- PostgreSQL: Documentation: 18: 15.1. How Parallel Query Works postgresql.org
- PostgreSQL: Documentation: 18: 15.3. Parallel Plans postgresql.org
- AlloyDB for PostgreSQL Columnar Engine | Google Cloud Blog google.com
- PostgreSQL: Documentation: 18: CREATE PROCEDURE postgresql.org
- Introduction to PostgreSQL physical storage rachbelaid.com
- Supported database extensions | AlloyDB for PostgreSQL | Google Cloud Documentation google.com
- PostgreSQL: Documentation: 18: 39.3. Materialized Views postgresql.org
- PostgreSQL: Documentation: 18: CREATE VIEW postgresql.org