Ringkasan AlloyDB Omni

Pilih versi dokumentasi:

AlloyDB Omni adalah paket software database yang dapat didownload dan memungkinkan Anda men-deploy versi AlloyDB untuk PostgreSQL yang dioptimalkan di lingkungan komputasi Anda sendiri. AlloyDB Omni dan layanan AlloyDB yang terkelola sepenuhnya di Google Cloud berbagi komponen inti yang sama. AlloyDB menggunakan lapisan penyimpanan berbasis cloud yang mengoptimalkan performa WAL, sedangkan AlloyDB Omni menggunakan antarmuka sistem file standar yang sama yang digunakan oleh PostgreSQL.

Portabilitas AlloyDB Omni memungkinkan Anda menjalankannya di banyak lingkungan, termasuk yang berikut:

  • Pusat data
  • Laptop
  • Instance VM berbasis cloud

Kasus penggunaan AlloyDB Omni

AlloyDB Omni sangat cocok untuk skenario berikut:

  • Anda memerlukan versi PostgreSQL yang skalabel dan berperforma tinggi, tetapi Anda tidak dapat menjalankan database di cloud karena persyaratan peraturan atau kedaulatan data.
  • Anda memerlukan database yang tetap berjalan meskipun terputus dari internet.
  • Untuk meminimalkan latensi, Anda ingin menempatkan database sedekat mungkin secara geografis dengan pengguna Anda.
  • Anda ingin cara untuk bermigrasi dari database lama, tetapi tanpa melakukan migrasi cloud penuh.

AlloyDB Omni tidak menyertakan fitur AlloyDB yang mengandalkan operasi di Google Cloud. Jika ingin mengupgrade project Anda ke fitur penskalaan, keamanan, dan ketersediaan AlloyDB yang terkelola sepenuhnya, Anda dapat memigrasikan data AlloyDB Omni ke cluster AlloyDB seperti halnya impor data awal lainnya.

Fitur utama

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 jalankan AlloyDB Omni di sistem Linux dengan penyimpanan SSD dan memori minimal 8 GB per CPU.

Operator AlloyDB Omni Kubernetes 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 Anda, seperti halnya aplikasi terhubung dan berkomunikasi dengan database PostgreSQL standar dengan server database PostgreSQL. Kontrol akses pengguna juga mengandalkan standar PostgreSQL.

Mulai dari logging hingga vacuuming hingga columnar engine, 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, container memberikan keuntungan berikut:

  • Pengelolaan dependensi yang transparan: Semua dependensi yang diperlukan digabungkan 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 berbagai lingkungan.
  • Isolasi keamanan: Anda memilih apa yang dapat diakses oleh container AlloyDB Omni di mesin host.
  • Pengelolaan resource: Anda dapat menentukan jumlah resource komputasi yang ingin digunakan oleh container AlloyDB Omni.
  • Patching dan upgrade yang lancar: Untuk menerapkan patch pada container, Anda hanya perlu mengganti image yang ada dengan yang baru.

Pencadangan dan pemulihan data

AlloyDB Omni memiliki sistem pencadangan dan pemulihan berkelanjutan yang memungkinkan Anda membuat cluster database baru berdasarkan titik waktu mana pun dalam periode retensi data yang dapat disesuaikan. Hal ini memungkinkan Anda pulih dengan cepat dari kecelakaan 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 disaster recovery lebih lanjut, Anda dapat mencapai replikasi lintas pusat data dengan membuat cluster database sekunder di pusat data terpisah. AlloyDB Omni melakukan streaming data secara asinkron dari cluster database utama yang ditentukan ke setiap cluster sekundernya. Jika 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.

Diagram arsitektur komponen AlloyDB Omni yang memisahkan komponen khusus AlloyDB untuk PostgreSQL dari komponen PostgreSQL.

Gambar 1. Arsitektur AlloyDB Omni

Mesin database

Dokumen ini menjelaskan arsitektur database di AlloyDB Omni dalam container. Dokumen ini mengasumsikan bahwa Anda sudah memahami PostgreSQL.

Mesin database melakukan tugas berikut:

  1. Menerjemahkan kueri dari klien ke dalam rencana yang dapat dieksekusi
  2. Menemukan data yang diperlukan untuk memenuhi kueri
  3. Melakukan pemfilteran, pengurutan, dan agregasi yang diperlukan
  4. Menampilkan hasil ke klien
Diagram yang menunjukkan cara aplikasi klien berinteraksi dengan lapisan database.
Gambar 1. Menampilkan lapisan database yang bekerja sama untuk merespons kueri dari aplikasi klien.

Saat aplikasi klien mengirim kueri ke AlloyDB Omni, tindakan berikut akan terjadi:

  1. Lapisan pemrosesan kueri mengubah kueri menjadi rencana eksekusi yang masuk ke lapisan eksekusi kueri.
  2. Lapisan eksekusi kueri melakukan operasi yang diperlukan untuk menghitung respons terhadap kueri.
  3. 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 dari mesin database berperforma tinggi adalah merespons kueri menggunakan resource sesedikit mungkin. Tujuan ini dimulai dengan model data dan desain kueri yang baik.

  • Bagaimana kueri dapat dijawab saat melihat jumlah data yang 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 ukuran 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 buffer pool, AlloyDB Omni akan membaca halaman yang diperlukan dari sistem file. Mengakses data dari buffer pool jauh lebih cepat daripada membaca dari sistem file. Oleh karena itu, memaksimalkan ukuran buffer pool untuk jumlah data yang akan diakses oleh aplikasi adalah faktor penting.

Pengelolaan resource

AlloyDB Omni uses pengelolaan memori dinamis untuk memungkinkan buffer pool bertambah dan berkurang secara dinamis dalam batas yang dikonfigurasi, bergantung pada permintaan memori sistem. Oleh karena itu, tidak perlu menyesuaikan ukuran buffer pool. Saat mendiagnosis masalah performa, metrik pertama yang perlu dipertimbangkan adalah rasio hit buffer pool dan rasio 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, agregasi, pengurutan, dan proyeksi data 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 status stabil sekitar 70%. Jumlah ini menyisakan headroom yang cukup di server untuk lonjakan penggunaan atau perubahan pola akses dari waktu ke waktu. Menjalankan dengan penggunaan yang lebih mendekati 100% akan menimbulkan overhead karena penjadwalan proses dan pengalihan konteks serta dapat membuat bottleneck di bagian lain sistem. Penggunaan CPU yang tinggi adalah metrik utama 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 perangkat penyimpanan yang mendasarinya ke database. Untuk menghindari batas IOPS penyimpanan database, minimalkan pembacaan dan penulisan ke penyimpanan dengan memaksimalkan jumlah data yang dapat masuk ke buffer pool.

Columnar engine

Columnar engine mempercepat pemrosesan kueri SQL untuk pemindaian, penggabungan, dan agregasi dengan menyediakan komponen berikut:

  • Penyimpanan kolom dalam memori: Berisi data tabel dan tampilan materialisasi 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 di postgresql.conf yang digunakan oleh instance AlloyDB Omni Anda.

    Untuk mengetahui informasi selengkapnya tentang cara mengubah parameter, lihat Mengubah parameter konfigurasi.

  • Mesin eksekusi dan perencana kueri berbasis kolom: Mendukung penggunaan penyimpanan kolom dalam kueri.

Pengelolaan memori otomatis

Pengelola memori otomatis terus memantau dan mengoptimalkan penggunaan memori di seluruh instance AlloyDB Omni. Saat Anda menjalankan workload, modul ini akan 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 vacuuming. Penyesuaian otomatis ini membantu database berjalan dengan performa puncak, meskipun workload berubah, tanpa gangguan dari proses vacuum.

Autovacuum adaptif menggunakan faktor berikut untuk menentukan frekuensi dan intensitas operasi vacuuming:

  • Ukuran database
  • Jumlah tuple yang tidak aktif dalam database
  • Usia data dalam database
  • Jumlah transaksi per detik dibandingkan dengan perkiraan kecepatan vacuum

Autovacuum adaptif memberikan manfaat berikut:

  • Pengelolaan resource vacuum dinamis: Daripada menggunakan batas biaya tetap, AlloyDB Omni menggunakan statistik resource real-time untuk menyesuaikan pekerja vacuum. Saat sistem sibuk, proses vacuum dan penggunaan resource terkait akan dibatasi. Jika memori yang tersedia cukup, memori tambahan akan dialokasikan untuk maintenance_work_mem guna mengurangi waktu vacuum end-to-end.
  • Pembatasan XID Dinamis: Memantau progres vacuuming 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 ke pekerja vacuum untuk memproses tabel yang memblokir kemajuan dan pelepasan ruang ID transaksi. Selama proses ini, keseluruhan transaksi per detik akan dikurangi hingga ID transaksi berada di zona aman (dapat diamati sebagai sesi yang menunggu AdaptiveVacuumNewXidDelay). Saat usia ID transaksi meningkat, pekerja vacuum akan ditingkatkan secara dinamis.
  • Vacuuming yang efisien untuk tabel yang lebih besar: Logika PostgreSQL default yang digunakan untuk menentukan kapan harus melakukan vacuum pada tabel didasarkan pada statistik khusus tabel yang disimpan di pg_stat_all_tables, yang berisi rasio tuple yang tidak aktif. Logika ini berfungsi untuk tabel kecil, tetapi mungkin tidak berfungsi secara efisien untuk tabel yang lebih besar dan sering diupdate. AlloyDB Omni menyediakan mekanisme pemindaian yang diupdate yang membantu memicu autovacuum lebih sering. Mekanisme pemindaian ini memindai bagian tabel besar dan menghapus tuple yang tidak aktif secara 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 secara tepat waktu.

Worker AI/ML

Di AlloyDB Omni, worker latar belakang AI/ML menyediakan semua kemampuan yang diperlukan untuk memanggil model Vertex AI langsung dari database. Worker AI/ML berjalan sebagai proses yang disebut omni ml worker.

Untuk mengetahui informasi selengkapnya, lihat Membangun aplikasi AI generatif menggunakan AlloyDB AI.

Langkah berikutnya