Portabilitas AlloyDB Omni memungkinkan Anda menjalankannya di banyak lingkungan, termasuk:
- Pusat data
- Laptop
- Instance VM berbasis cloud
Kasus penggunaan AlloyDB Omni
AlloyDB Omni cocok untuk skenario berikut:
- Anda memerlukan PostgreSQL versi yang skalabel dan berperforma tinggi, tetapi Anda tidak dapat menjalankan database di cloud karena persyaratan peraturan atau kedaulatan data.
- Anda memerlukan database yang terus berjalan meskipun koneksinya terputus dari internet.
- Untuk meminimalkan latensi, Anda harus menempatkan database sedekat mungkin dengan pengguna secara geografis.
- Anda ingin cara untuk bermigrasi dari database lama, tetapi tanpa melakukan migrasi cloud penuh.
AlloyDB Omni tidak menyertakan fitur AlloyDB untuk PostgreSQL yang mengandalkan operasi di Google Cloud. Jika ingin mengupgrade project ke fitur penskalaan, keamanan, dan ketersediaan yang terkelola sepenuhnya dari AlloyDB untuk PostgreSQL, Anda dapat memigrasikan data AlloyDB Omni ke cluster AlloyDB untuk PostgreSQL seperti yang dapat Anda lakukan dengan impor data awal lainnya.
Fitur utama
- Server database yang kompatibel dengan PostgreSQL.
- Dukungan untuk AlloyDB AI, yang membantu Anda membangun aplikasi AI generatif tingkat perusahaan menggunakan data operasional Anda.
- Integrasi dengan ekosistem AI, termasuk Vertex AI Model Garden dan alat AI generatif open source. Google Cloud
Dukungan untuk fitur autopilot dari AlloyDB untuk PostgreSQL di Google Cloud yang memungkinkan AlloyDB Omni mengelola sendiri dan menyesuaikan diri sendiri.
Misalnya, AlloyDB Omni mendukung pengelolaan memori otomatis dan autovacuum adaptif data usang.
Penasihat indeks yang menganalisis kueri yang sering dijalankan dan merekomendasikan indeks baru untuk performa kueri yang lebih baik.
Columnar engine AlloyDB Omni, yang menyimpan data yang sering dikueri dalam format kolom dalam memori untuk performa yang lebih cepat pada business intelligence, pelaporan, dan pemrosesan transaksional serta analitis hybrid (HTAP).
Dalam pengujian performa kami, workload transaksional di AlloyDB Omni lebih dari 2X lebih cepat, dan kueri analitis hingga 100X lebih cepat, daripada PostgreSQL standar.
Cara kerja AlloyDB Omni
Anda dapat menginstal AlloyDB Omni sebagai server mandiri atau sebagai bagian dari lingkungan Kubernetes.
AlloyDB Omni berjalan dalam container Docker yang Anda instal ke lingkungan Anda sendiri. Sebaiknya Anda menjalankan AlloyDB Omni di sistem Linux dengan penyimpanan SSD dan memori minimal 8 GB per CPU.
Operator Kubernetes AlloyDB Omni adalah ekstensi ke Kubernetes API yang memungkinkan Anda menjalankan AlloyDB Omni di sebagian besar lingkungan Kubernetes yang sesuai dengan CNCF. Untuk mengetahui informasi selengkapnya, lihat Menginstal AlloyDB Omni di Kubernetes.
Aplikasi Anda terhubung dan berkomunikasi dengan penginstalan AlloyDB Omni, seperti aplikasi yang terhubung dan berkomunikasi dengan server database PostgreSQL standar. Kontrol akses pengguna juga mengandalkan standar PostgreSQL.
Mulai dari logging hingga pembersihan hingga mesin columnar, Anda dapat mengonfigurasi perilaku database AlloyDB Omni menggunakan flag database.
Keuntungan menjalankan AlloyDB Omni sebagai container
Google mendistribusikan AlloyDB Omni sebagai container yang dapat Anda jalankan dengan runtime container seperti Docker dan Podman. Secara operasional, penampung memberikan keuntungan berikut:
- Pengelolaan dependensi yang transparan: Semua dependensi yang diperlukan dipaketkan dalam container dan diuji oleh Google untuk memastikan bahwa dependensi tersebut sepenuhnya kompatibel dengan AlloyDB Omni.
- Portabilitas: Anda dapat mengharapkan AlloyDB Omni beroperasi secara konsisten di seluruh lingkungan.
- Isolasi keamanan: Anda memilih apa yang dapat diakses oleh penampung AlloyDB Omni di mesin host.
- Pengelolaan resource: Anda dapat menentukan jumlah resource komputasi yang Anda inginkan untuk digunakan oleh penampung AlloyDB Omni.
- Patching dan upgrade yang lancar: Untuk mem-patch container, Anda hanya perlu mengganti image yang ada dengan image baru.
Pencadangan data dan pemulihan dari bencana
AlloyDB Omni memiliki sistem pencadangan dan pemulihan berkelanjutan yang memungkinkan Anda membuat cluster database baru berdasarkan titik waktu mana pun dalam periode retensi yang dapat disesuaikan. Hal ini memungkinkan Anda memulihkan data dengan cepat dari kecelakaan yang menyebabkan kehilangan data.
Selain itu, AlloyDB Omni dapat membuat dan menyimpan cadangan lengkap data cluster database Anda, baik sesuai permintaan maupun sesuai jadwal rutin. Kapan saja, Anda dapat memulihkan dari cadangan ke cluster database AlloyDB Omni yang berisi semua data dari cluster database asli pada saat pembuatan cadangan.
Untuk mengetahui informasi selengkapnya, lihat Mencadangkan dan memulihkan AlloyDB Omni.
Sebagai metode pemulihan dari bencana lebih lanjut, Anda dapat mencapai replikasi lintas pusat data dengan membuat cluster database sekunder di pusat data terpisah. AlloyDB Omni secara asinkron melakukan streaming data dari cluster database utama yang ditetapkan ke setiap cluster sekundernya. Kapan pun diperlukan, Anda dapat mempromosikan cluster database sekunder menjadi cluster database AlloyDB Omni utama.
Untuk mengetahui informasi selengkapnya, lihat Tentang replikasi lintas pusat data
Komponen VM AlloyDB Omni
AlloyDB Omni di VM terdiri dari dua set komponen arsitektur: komponen PostgreSQL dengan peningkatan AlloyDB untuk PostgreSQL dan komponen AlloyDB untuk PostgreSQL. Diagram berikut menguraikan kedua set komponen, lapisan infrastruktur tempat komponen tersebut berada di VM atau server, dan fitur terkait yang dapat Anda harapkan untuk setiap komponen.
Gambar 1. Arsitektur AlloyDB Omni
Mesin database
Dokumen ini menjelaskan arsitektur database di AlloyDB Omni dalam penampung. Dokumen ini mengasumsikan bahwa Anda sudah memahami PostgreSQL.
Mesin database melakukan tugas berikut:
- Menerjemahkan kueri dari klien menjadi rencana yang dapat dieksekusi
- Menemukan data yang diperlukan untuk memenuhi kueri
- Melakukan pemfilteran, pengurutan, dan agregasi yang diperlukan
- Menampilkan hasil ke klien

Saat aplikasi klien mengirim kueri ke AlloyDB Omni, tindakan berikut akan terjadi:
- Lapisan pemrosesan kueri mengubah kueri menjadi rencana eksekusi yang diteruskan ke lapisan eksekusi kueri.
- Lapisan eksekusi kueri melakukan operasi yang diperlukan untuk menghitung respons terhadap kueri.
- Selama eksekusi, data dapat dimuat dari cache buffer atau dimuat langsung dari penyimpanan. Jika data dimuat dari penyimpanan, data dari penyimpanan akan disimpan dalam cache untuk penggunaan di masa mendatang.
Resource yang digunakan saat memproses kueri klien mencakup CPU, memori, I/O, jaringan, dan primitif sinkronisasi seperti kunci database. Penyesuaian performa bertujuan untuk mengoptimalkan penggunaan resource selama setiap langkah dalam eksekusi kueri.
Tujuan mesin database berperforma tinggi adalah merespons kueri menggunakan resource sesedikit mungkin. Tujuan ini dimulai dengan desain kueri dan model data yang baik.
- Bagaimana kueri dapat dijawab dengan melihat jumlah data paling sedikit?
- Indeks apa yang diperlukan untuk mengurangi ruang penelusuran dan I/O?
- Mengurutkan data memerlukan CPU dan, sering kali, akses disk untuk set data besar, jadi bagaimana cara menghindari pengurutan data?
Penyimpanan data
AlloyDB Omni menyimpan data dalam halaman berukuran tetap yang disimpan dalam sistem file yang mendasarinya. Saat kueri perlu mengakses data, AlloyDB Omni akan memeriksa buffer pool terlebih dahulu. Jika halaman yang berisi data yang diperlukan tidak ditemukan di kumpulan buffer, maka AlloyDB Omni akan membaca halaman yang diperlukan dari sistem file. Mengakses data dari kumpulan buffer jauh lebih cepat daripada membaca dari sistem file, sehingga memaksimalkan ukuran kumpulan buffer untuk jumlah data yang akan diakses oleh aplikasi adalah faktor penting.
Pengelolaan resource
AlloyDB Omni menggunakan pengelolaan memori dinamis untuk memungkinkan kumpulan buffer bertambah dan berkurang secara dinamis dalam batas yang dikonfigurasi, bergantung pada permintaan memori sistem. Oleh karena itu, tidak perlu menyesuaikan ukuran pool buffer. Saat mendiagnosis masalah performa, metrik pertama yang perlu dipertimbangkan adalah rasio hit buffer pool dan kecepatan baca untuk melihat apakah aplikasi Anda mendapatkan manfaat dari buffer pool. Jika tidak, hal ini menunjukkan bahwa set data aplikasi tidak sesuai dengan buffer pool, dan Anda dapat mempertimbangkan untuk mengubah ukuran ke mesin yang lebih besar dengan lebih banyak memori.
Proses pengambilan, pemfilteran, penggabungan, pengurutan, dan proyeksi data semuanya memerlukan resource CPU di server database. Untuk mengurangi jumlah resource CPU yang diperlukan untuk proses ini, minimalkan jumlah data yang perlu dimanipulasi. Pantau penggunaan CPU di server database untuk memastikan penggunaan dalam kondisi stabil sekitar 70%. Jumlah ini memberikan ruang kosong yang cukup di server untuk lonjakan penggunaan atau perubahan pola akses dari waktu ke waktu. Menjalankan dengan pemakaian yang mendekati 100% akan menimbulkan overhead karena penjadwalan proses dan pengalihan konteks serta dapat menimbulkan hambatan di bagian lain sistem. Penggunaan CPU yang tinggi adalah metrik penting lainnya yang dapat digunakan saat membuat keputusan tentang spesifikasi mesin.
Operasi Input/Output Per Detik (IOPS) adalah faktor penting dalam performa aplikasi database -- berapa banyak operasi input atau output per detik yang dapat diberikan oleh perangkat penyimpanan yang mendasarinya ke database. Untuk menghindari batas IOPS penyimpanan database, minimalkan operasi baca dan tulis ke penyimpanan dengan memaksimalkan jumlah data yang dapat masuk ke kumpulan buffer.
Mesin kolom
Columnar engine mempercepat pemrosesan kueri SQL untuk pemindaian, penggabungan, dan agregasi dengan menyediakan komponen berikut:
Penyimpanan kolom dalam memori: Berisi data tabel dan tampilan materialisir untuk kolom yang dipilih dalam format berorientasi kolom. Secara default, penyimpanan kolom menggunakan memori yang tersedia sebesar 1 GB. Untuk mengubah jumlah memori yang dapat digunakan oleh penyimpanan kolom, tetapkan parameter
google_columnar_engine.memory_size_in_mb
dipostgresql.conf
yang digunakan oleh instance AlloyDB Omni Anda.Untuk mengetahui informasi selengkapnya tentang cara mengubah parameter, lihat Mengubah parameter konfigurasi.
Perencana kueri dan mesin eksekusi berorientasi kolom: Mendukung penggunaan penyimpanan kolom dalam kueri.
Pengelolaan memori otomatis
Pengelola memori otomatis terus memantau dan mengoptimalkan konsumsi memori di seluruh instance AlloyDB Omni. Saat Anda menjalankan
workload, modul ini menyesuaikan ukuran cache buffer bersama berdasarkan tekanan
memori. Secara default, pengelola memori otomatis menetapkan batas atas ke 80%
memori sistem dan mengalokasikan 10% memori sistem untuk cache buffer bersama.
Untuk mengubah batas atas ukuran cache buffer bersama, tetapkan parameter
shared_buffers
di postgresql.conf
yang digunakan oleh instance
AlloyDB Omni Anda.
Untuk mengetahui informasi selengkapnya, lihat Pengelolaan memori otomatis.
Autovacuum adaptif
Autovacuum adaptif menganalisis operasi berdasarkan workload database, dan secara otomatis menyesuaikan frekuensi proses vacuum. Penyesuaian otomatis ini membantu database berjalan dengan performa puncak, bahkan saat beban kerja berubah, tanpa gangguan dari proses vacuum.
Autovacuum adaptif menggunakan faktor berikut untuk menentukan frekuensi dan intensitas operasi pembersihan:
- Ukuran database
- Jumlah tuple tidak aktif dalam database
- Usia data dalam database
- Jumlah transaksi per detik versus perkiraan kecepatan vacuum
Autovacuum adaptif memberikan manfaat berikut:
- Pengelolaan resource vakum dinamis: Daripada menggunakan batas biaya tetap,
AlloyDB Omni menggunakan statistik resource real-time untuk menyesuaikan
pekerja vakum. Saat sistem sibuk, proses pengosongan dan penggunaan resource terkait akan dibatasi. Jika memori yang tersedia cukup, memori tambahan akan dialokasikan untuk
maintenance_work_mem
guna mengurangi waktu vakum end-to-end. - Throttling XID Dinamis: Memantau kemajuan penyedotan debu dan kecepatan penggunaan ID transaksi secara otomatis dan berkelanjutan. Jika risiko wraparound ID transaksi terdeteksi, AlloyDB Omni akan memperlambat transaksi untuk membatasi penggunaan ID. Selain itu, AlloyDB Omni mengalokasikan lebih banyak resource untuk pekerja vacuum guna memproses tabel yang memblokir kemajuan dan pelepasan ruang ID transaksi. Selama proses ini, keseluruhan transaksi per detik akan berkurang hingga ID transaksi berada di zona aman (dapat diamati sebagai sesi yang menunggu
AdaptiveVacuumNewXidDelay
). Saat usia ID transaksi meningkat, pekerja vakum akan ditingkatkan secara dinamis. - Pembersihan yang efisien untuk tabel yang lebih besar: Logika PostgreSQL default yang digunakan untuk memutuskan kapan harus membersihkan tabel didasarkan pada statistik khusus tabel yang disimpan di
pg_stat_all_tables
, yang berisi rasio tuple yang tidak digunakan. Logika ini berfungsi untuk tabel kecil, tetapi mungkin tidak berfungsi secara efisien untuk tabel yang lebih besar dan sering diperbarui. AlloyDB Omni menyediakan mekanisme pemindaian yang diperbarui yang membantu memicu autovacuum lebih sering. Mekanisme pemindaian ini memindai potongan tabel besar dan menghapus tuple yang tidak digunakan dengan lebih efisien daripada logika PostgreSQL default. - Pesan peringatan log: Di AlloyDB Omni, pemblokir vacuum, seperti transaksi yang berjalan lama atau transaksi yang disiapkan atau slot replikasi yang kehilangan targetnya, akan terdeteksi dan peringatan akan dicatat dalam log PostgreSQL sehingga Anda dapat mengatasi masalah tepat waktu.
Pekerja AI/ML
Di AlloyDB Omni, pekerja latar belakang AI/ML menyediakan semua
kemampuan yang diperlukan untuk memanggil model Vertex AI langsung dari
database. Pekerja AI/ML berjalan sebagai proses yang disebut omni ml worker
.
Untuk mengetahui informasi selengkapnya, lihat Membangun aplikasi AI generatif menggunakan AlloyDB AI.