gcp alloydb - ghdrako/doc_snipets GitHub Wiki

• https://docs.cloud.google.com/alloydb/docs

• AlloyDB for PostgreSQL Intelligent Scalable Storage

• AlloyDB for PostgreSQL under the hood: Columnar engine

• Deep Dive into Google’s AlloyDB Architecture for PostgreSQL

• AlloyDB for PostgreSQL under the hood: Business continuity

• Verify Columnar Engine Usage with AlloyDB Operational Views by Anish Nair

• Leverage Google Cloud Logging + Monitoring for Custom Cloud SQL for Postgres or AlloyDB Alerts by Shane Borden

• Essential SQL for exploring AlloyDB Columnar Engine by Deepak Mahto

• Enhancing Google Cloud AlloyDB Interaction with Custom psql Shortcuts by Deepak Mahto

• An Initial Test of Google’s AlloyDB Columnar Engine by Simon Pane

• https://www.youtube.com/watch?v=o5pKfH0Tonw

AlloyDB is actually a cluster of virtual machines with shared storage. This allows you to have one machine acting as the principal for data collection, but other VMs can be used as readable secondaries, offloading some of the work. This also adds redundancy and resiliency to your PostgreSQL instance.

Operations within the AlloyDB are mostly the same as within any other PostgreSQL instance. Monitoring is a little different since you’re monitoring both an instance of PostgreSQL, but also a cluster of virtual machines.

Citus and Timescale are postgres extensions that focus on partitioning data primarily. Citus focused on scaling out across multiple nodes based on whatever primary key you wanted. Timescale focused on single-node and then added multiple nodes later, focused on time (or other integer-based values) and more utilities around time-based analysis. The Citus team also had a columnar data storage extension that's finally more production ready and Timescale created their own implementation by using columnar data but still storing it in the default rowstore and handling the differences in the query layer.

Aurora Postgres and AlloyDB are fundamentally the same thing and involve taking the "top" portion of actual PostgreSQL (wire protocol, parser, query planner, etc) and attaching it to their own rebuilt storage layer. Since storage is the bottleneck, they can scale that out using their cloud architecture and make it seamless to the DB compute layer on top. Other open-source databases like Yugabyte also follow this approach with their own data layer implementation to add distribution and replication.

• https://cloud.google.com/alloydb/pricing
• https://cloud.google.com/alloydb/docs/columnar-engine/about
• https://cloud.google.com/alloydb/docs/omni/omni-cli
• https://cloud.google.com/alloydb/docs/cluster-create#gcloud

AlloyDB Omni

• install AlloyDB Omni
• Install AlloyDB Omni on a VM
• https://weidongzhou.wordpress.com/2023/08/18/gcp-alloydb-blog-series-part-2-install-alloydb-omni/

AlloyDB Omni - Downloadable edition of AlloyDB, designed to run anywhere—in your data center, on your laptop, at the edge, and in any cloud.

• https://cloud.google.com/alloydb/omni?hl=pl
• https://cloud.google.com/alloydb/docs/omni/quickstart