Sesi

Halaman ini menjelaskan konsep lanjutan sesi di Spanner, termasuk praktik terbaik untuk sesi saat membuat library klien, menggunakan REST atau RPC API, atau menggunakan library klien Google.

Ringkasan Sesi

Sesi mewakili saluran komunikasi dengan layanan database Spanner. Sesi digunakan untuk melakukan transaksi yang membaca, menulis, atau mengubah data di database Spanner. Setiap sesi berlaku untuk satu database.

Sesi dapat menjalankan satu atau beberapa transaksi sekaligus. Saat melakukan beberapa transaksi, sesi tersebut disebut sesi multipleks.

Pembacaan, penulisan, dan kueri mandiri menggunakan satu transaksi secara internal.

Manfaat performa kumpulan sesi

Membuat sesi itu mahal. Untuk menghindari biaya performa setiap kali operasi database dilakukan, klien harus menyimpan kumpulan sesi, yang merupakan kumpulan sesi yang tersedia dan siap digunakan. Kumpulan harus menyimpan sesi yang ada dan menampilkan jenis sesi yang sesuai saat diminta, serta menangani pembersihan sesi yang tidak digunakan. Untuk contoh cara menerapkan kumpulan sesi, lihat kode sumber untuk salah satu library klien Spanner, seperti library klien Go atau library klien Java.

Sesi dimaksudkan untuk berumur panjang, sehingga setelah sesi digunakan untuk operasi database, klien harus mengembalikan sesi ke kumpulan untuk digunakan kembali.

Ringkasan saluran gRPC

Saluran gRPC digunakan oleh klien Spanner untuk komunikasi. Satu saluran gRPC kira-kira setara dengan koneksi TCP. Satu saluran gRPC dapat menangani maksimal 100 permintaan serentak. Artinya, aplikasi akan memerlukan setidaknya sebanyak channel gRPC dengan jumlah permintaan serentak yang akan dijalankan aplikasi, dibagi dengan 100.

Klien Spanner membuat kumpulan saluran gRPC saat Anda membuatnya.

Praktik terbaik saat menggunakan library klien Google

Berikut ini penjelasan praktik terbaik saat menggunakan library klien Google untuk Spanner.

Mengonfigurasi jumlah sesi dan saluran gRPC dalam kumpulan

Library klien memiliki jumlah sesi default di kumpulan sesi dan jumlah saluran gRPC default di kumpulan saluran. Kedua setelan default tersebut memadai untuk sebagian besar kasus. Berikut adalah sesi minimum dan maksimum default serta jumlah default saluran gRPC untuk setiap bahasa pemrograman.

C++

MinSessions: 100
MaxSessions: 400
NumChannels: 4

C#

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Go

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Java

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Node.js

Klien Node.js tidak mendukung beberapa saluran gRPC. Oleh karena itu, sebaiknya buat beberapa klien, bukan meningkatkan ukuran kumpulan sesi di luar 100 sesi untuk satu klien.

MinSessions: 25
MaxSessions: 100

PHP

Klien PHP tidak mendukung jumlah saluran gRPC yang dapat dikonfigurasi.

MinSessions: 1
MaxSessions: 500

Python

Python mendukung empat jenis kumpulan sesi yang dapat Anda gunakan untuk mengelola sesi.

Ruby

Klien Ruby tidak mendukung beberapa saluran gRPC. Oleh karena itu, sebaiknya buat beberapa klien, bukan meningkatkan ukuran kumpulan sesi di luar 100 sesi untuk satu klien.

MinSessions: 10
MaxSessions: 100

Jumlah sesi yang digunakan aplikasi Anda sama dengan jumlah transaksi serentak yang dijalankan aplikasi Anda. Anda harus mengubah setelan kumpulan sesi default hanya jika Anda mengharapkan satu instance aplikasi untuk menjalankan lebih banyak transaksi serentak daripada yang dapat ditangani kumpulan sesi default.

Untuk aplikasi konkurensi tinggi, sebaiknya gunakan:

1. Tetapkan MinSessions ke jumlah transaksi serentak yang diharapkan yang akan dijalankan oleh satu klien.
2. Tetapkan MaxSessions ke jumlah maksimum transaksi serentak yang dapat dijalankan oleh satu klien.
3. Tetapkan MinSessions=MaxSessions jika konkurensi yang diharapkan tidak banyak berubah selama masa aktif aplikasi. Hal ini mencegah kumpulan sesi diskalasikan ke atas atau ke bawah. Menskalakan kumpulan sesi ke atas atau ke bawah juga akan menggunakan beberapa resource.
4. Tetapkan NumChannels ke MaxSessions / 100. Satu saluran gRPC dapat menangani hingga 100 permintaan secara serentak. Tingkatkan nilai ini jika Anda mengamati latensi ekor tinggi (latensi p95/p99), karena hal ini dapat menjadi indikasi kemacetan saluran gRPC.

Meningkatkan jumlah sesi aktif akan menggunakan resource tambahan di layanan database Spanner dan di library klien. Meningkatkan jumlah sesi di luar kebutuhan aplikasi yang sebenarnya dapat menurunkan performa sistem Anda.

Meningkatkan kumpulan sesi versus meningkatkan jumlah klien

Ukuran kumpulan sesi untuk aplikasi menentukan jumlah transaksi serentak yang dapat dijalankan oleh satu instance aplikasi. Meningkatkan ukuran kumpulan sesi melebihi konkurensi maksimum yang dapat ditangani oleh satu instance aplikasi tidak direkomendasikan. Jika aplikasi menerima lonjakan permintaan yang melebihi jumlah sesi dalam kumpulan, permintaan akan diantrekan sembari menunggu sesi tersedia.

Resource yang digunakan oleh library klien adalah sebagai berikut:

1. Setiap saluran gRPC menggunakan satu koneksi TCP.
2. Setiap pemanggilan gRPC memerlukan thread. Jumlah maksimum thread yang digunakan oleh library klien sama dengan jumlah maksimum kueri serentak yang dieksekusi aplikasi. Thread ini berada di atas thread apa pun yang digunakan aplikasi untuk logika bisnisnya sendiri.

Meningkatkan ukuran kumpulan sesi di luar jumlah maksimum thread yang dapat ditangani oleh satu instance aplikasi tidak direkomendasikan. Sebagai gantinya, tingkatkan jumlah instance aplikasi.

Mengelola fraksi sesi tulis

Untuk beberapa library klien, Spanner mencadangkan sebagian sesi untuk transaksi baca-tulis, yang disebut fraksi sesi tulis. Jika aplikasi Anda menggunakan semua sesi baca, Spanner akan menggunakan sesi baca-tulis, bahkan untuk transaksi hanya baca. Sesi baca-tulis memerlukan spanner.databases.beginOrRollbackReadWriteTransaction. Jika pengguna berada dalam peran IAM spanner.databaseReader, panggilan akan gagal dan Spanner akan menampilkan pesan error ini:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

Untuk library klien yang mempertahankan fraksi sesi tulis, Anda dapat menetapkan fraksi sesi tulis.

C++

Semua sesi C++ sama. Tidak ada sesi hanya baca atau baca-tulis.

C#

Fraksi sesi tulis default untuk C# adalah 0,2. Anda dapat mengubah fraksi menggunakan kolom WriteSessionsFraction dari SessionPoolOptions.

Go

Semua sesi Go sama. Tidak ada sesi hanya baca atau baca-tulis.

Java

Semua sesi Java sama. Tidak ada sesi hanya baca atau baca-tulis.

Node.js

Semua sesi Node.js sama. Tidak ada sesi hanya baca atau baca-tulis.

PHP

Semua sesi PHP sama. Tidak ada sesi hanya baca atau baca-tulis.

Python

Python mendukung empat jenis kumpulan sesi yang dapat Anda gunakan untuk mengelola sesi baca dan baca-tulis.

Ruby

Fraksi sesi tulis default untuk Ruby adalah 0,3. Anda dapat mengubah fraksi menggunakan metode inisialisasi klien.

Praktik terbaik saat membuat library klien atau menggunakan REST/RPC

Berikut ini menjelaskan praktik terbaik untuk menerapkan sesi di library klien untuk Spanner, atau untuk menggunakan sesi dengan API REST atau RPC.

Praktik terbaik ini hanya berlaku jika Anda mengembangkan library klien, atau jika Anda menggunakan REST/RPC API. Jika Anda menggunakan salah satu library klien Google untuk Spanner, lihat Praktik terbaik saat menggunakan library klien Google.

Membuat dan menentukan ukuran kumpulan sesi

Untuk menentukan ukuran kumpulan sesi yang optimal untuk proses klien, tetapkan batas bawah ke jumlah transaksi serentak yang diharapkan, dan tetapkan batas atas ke nomor pengujian awal, seperti 100. Jika batas atas tidak memadai, tingkatkan. Meningkatkan jumlah sesi aktif akan menggunakan resource tambahan di layanan database Spanner, sehingga kegagalan untuk membersihkan sesi yang tidak digunakan dapat menurunkan performa. Untuk pengguna yang menggunakan RPC API, sebaiknya jangan memiliki lebih dari 100 sesi per saluran gRPC.

Menangani sesi yang dihapus

Ada tiga cara untuk menghapus sesi:

• Klien dapat menghapus sesi.
• Layanan database Spanner dapat menghapus sesi saat sesi tidak ada aktivitas selama lebih dari 1 jam.
• Layanan database Spanner dapat menghapus sesi jika sesi tersebut berumur lebih dari 28 hari.

Mencoba menggunakan hasil sesi yang dihapus di NOT_FOUND. Jika Anda mengalami error ini, buat dan gunakan sesi baru, tambahkan sesi baru ke kumpulan, dan hapus sesi yang dihapus dari kumpulan.

Mempertahankan sesi tidak ada aktivitas

Layanan database Spanner berhak menghapus sesi yang tidak digunakan. Jika Anda benar-benar perlu mempertahankan sesi tidak ada aktivitas, misalnya, jika diperkirakan akan terjadi peningkatan penggunaan database dalam waktu dekat, Anda dapat mencegah sesi dihapus. Lakukan operasi yang tidak mahal seperti menjalankan kueri SQL SELECT 1 untuk menjaga sesi tetap aktif. Jika Anda memiliki sesi tidak ada aktivitas yang tidak diperlukan untuk penggunaan jangka pendek, biarkan Spanner menghapus sesi, lalu buat sesi baru saat sesi diperlukan lagi.

Salah satu skenario untuk menjaga sesi tetap aktif adalah menangani permintaan puncak reguler di database. Jika penggunaan database yang berat terjadi setiap hari dari pukul 09.00 hingga 18.00, Anda harus menjaga beberapa sesi tidak ada aktivitas tetap aktif selama waktu tersebut, karena sesi tersebut kemungkinan diperlukan untuk penggunaan puncak. Setelah pukul 18.00, Anda dapat mengizinkan Spanner menghapus sesi tidak ada aktivitas. Sebelum pukul 09.00 setiap hari, buat beberapa sesi baru agar sesi tersebut siap untuk memenuhi permintaan yang diharapkan.

Skenario lainnya adalah jika Anda memiliki aplikasi yang menggunakan Spanner, tetapi harus menghindari overhead koneksi saat melakukannya. Anda dapat mempertahankan kumpulan sesi agar tidak ada overhead koneksi.

Menyembunyikan detail sesi dari pengguna library klien

Jika Anda membuat library klien, jangan mengekspos sesi ke konsumen library klien. Memberikan kemampuan bagi klien untuk melakukan panggilan database tanpa kerumitan pembuatan dan pemeliharaan sesi. Untuk contoh library klien yang menyembunyikan detail sesi dari konsumen library klien, lihat library klien Spanner untuk Java.

Menangani error untuk transaksi tulis yang tidak idempoten

Transaksi tulis tanpa perlindungan replay dapat menerapkan mutasi lebih dari sekali. Jika mutasi tidak idempoten, mutasi yang diterapkan lebih dari sekali dapat menghasilkan kegagalan. Misalnya, penyisipan mungkin gagal dengan ALREADY_EXISTS meskipun baris tidak ada sebelum upaya penulisan. Hal ini dapat terjadi jika server backend melakukan mutasi, tetapi tidak dapat menyampaikan keberhasilannya kepada klien. Dalam hal ini, mutasi dapat dicoba lagi, sehingga menyebabkan kegagalan ALREADY_EXISTS.

Berikut adalah kemungkinan cara untuk mengatasi skenario ini saat Anda menerapkan library klien Anda sendiri atau menggunakan REST API:

• Susun penulisan Anda agar idempoten.
• Gunakan operasi tulis dengan perlindungan replay.
• Terapkan metode yang menjalankan logika "upsert": menyisipkan jika baru atau memperbarui jika ada.
• Tangani error atas nama klien.

Mempertahankan koneksi yang stabil

Untuk performa terbaik, koneksi yang Anda gunakan untuk menghosting sesi harus tetap stabil. Saat koneksi yang menghosting sesi berubah, Spanner mungkin membatalkan transaksi aktif pada sesi dan menyebabkan sedikit beban tambahan pada database saat memperbarui metadata sesi. Tidak masalah jika beberapa koneksi berubah secara sporadis, tetapi Anda harus menghindari situasi yang akan mengubah sejumlah besar koneksi secara bersamaan. Jika menggunakan proxy antara klien dan Spanner, Anda harus mempertahankan stabilitas koneksi untuk setiap sesi.

Memantau sesi aktif

Anda dapat menggunakan perintah ListSessions untuk memantau sesi aktif di database dari command line, dengan REST API, atau dengan RPC API. ListSessions menampilkan sesi aktif untuk database tertentu. Hal ini berguna jika Anda perlu menemukan penyebab kebocoran sesi. (Kebocoran sesi adalah insiden saat sesi dibuat, tetapi tidak dikembalikan ke kumpulan sesi untuk digunakan kembali.)

ListSessions memungkinkan Anda melihat metadata tentang sesi aktif, termasuk saat sesi dibuat dan saat sesi terakhir digunakan. Menganalisis data ini akan mengarahkan Anda ke arah yang benar saat memecahkan masalah sesi. Jika sebagian besar sesi aktif tidak memiliki approximate_last_use_time terbaru, hal ini dapat menunjukkan bahwa sesi tidak digunakan kembali dengan benar oleh aplikasi Anda. Lihat referensi RPC API untuk informasi selengkapnya tentang kolom approximate_last_use_time.

Lihat referensi REST API, referensi RPC API, atau referensi alat command line gcloud untuk mengetahui informasi selengkapnya tentang penggunaan ListSessions.

Pembersihan otomatis kebocoran sesi

Pratinjau — Automatic cleanup of session leaks

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dalam Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Saat Anda menggunakan semua sesi dalam kumpulan sesi, setiap transaksi baru akan menunggu hingga sesi dikembalikan ke kumpulan. Jika sesi dibuat, tetapi tidak dikembalikan ke kumpulan sesi untuk digunakan kembali, hal ini disebut kebocoran sesi. Jika terjadi kebocoran sesi, transaksi yang menunggu sesi terbuka akan macet tanpa batas waktu dan memblokir aplikasi. Kebocoran sesi sering kali disebabkan oleh transaksi bermasalah yang berjalan dalam waktu yang sangat lama dan tidak di-commit.

Anda dapat menyiapkan kumpulan sesi untuk otomatis menyelesaikan transaksi tidak aktif ini. Saat Anda mengaktifkan library klien untuk menyelesaikan transisi tidak aktif secara otomatis, library akan mengidentifikasi transaksi bermasalah yang dapat menyebabkan kebocoran sesi, menghapusnya dari kumpulan sesi, dan menggantinya dengan sesi baru.

Logging juga dapat membantu mengidentifikasi transaksi yang bermasalah ini. Jika logging diaktifkan, log peringatan akan dibagikan secara default saat lebih dari 95% kumpulan sesi Anda sedang digunakan. Jika penggunaan sesi lebih besar dari 95%, Anda harus meningkatkan sesi maksimum yang diizinkan dalam kumpulan sesi, atau Anda mungkin mengalami kebocoran sesi. Log peringatan berisi pelacakan stack transaksi yang berjalan lebih lama dari yang diharapkan dan dapat membantu mengidentifikasi penyebab penggunaan kumpulan sesi yang tinggi. Log peringatan akan dikirimkan bergantung pada konfigurasi eksportir log Anda.

Mengaktifkan library klien untuk menyelesaikan transaksi yang tidak aktif secara otomatis

Anda dapat mengaktifkan library klien untuk mengirim log peringatan dan secara otomatis menyelesaikan transaksi yang tidak aktif, atau mengaktifkan library klien untuk hanya menerima log peringatan.

Java

Untuk menerima log peringatan dan menghapus transaksi yang tidak aktif, gunakan setWarnAndCloseIfInactiveTransactions.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Untuk hanya menerima log peringatan, gunakan setWarnIfInactiveTransactions.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Go

Untuk menerima log peringatan dan menghapus transaksi yang tidak aktif, gunakan SessionPoolConfig dengan InactiveTransactionRemovalOptions.

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

Untuk hanya menerima log peringatan, gunakan customLogger.

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

Sesi multipleks

Sesi multipleks memungkinkan Anda membuat permintaan serentak dalam jumlah tidak terbatas sekaligus. Sesi multipleks memiliki keunggulan berikut:

• Mengurangi persyaratan resource backend. Misalnya, mereka menghindari aktivitas pemeliharaan sesi yang terkait dengan pemeliharaan kepemilikan sesi dan pengumpulan sampah.
• Sesi berdurasi panjang yang tidak memerlukan permintaan keep-alive saat tidak ada aktivitas.
• Library klien standar dapat menggunakan satu sesi multipleks untuk setiap klien. Jumlah sesi reguler yang digunakan lebih rendah untuk klien yang menggunakan sesi multipleks untuk beberapa operasi jika dibandingkan dengan klien yang hanya menggunakan sesi reguler.
• Tidak perlu memiliki afinitas hanya ke satu saluran gRPC. Klien dapat mengirim permintaan di beberapa saluran untuk sesi multipleks yang sama.

Sesi multipleks mendukung hal berikut:

• Library klien Java dan Go".
• Alat ekosistem Spanner yang bergantung pada Library klien Java dan Go, seperti PGAdapter, JDBC, Hibernate, driver database/sql, dan GORM.
• Spanner API untuk transaksi hanya baca

Anda menggunakan metrik OpenTelemetry untuk melihat cara traffic dibagi antara kumpulan sesi yang ada dan sesi multipleks. OpenTelemetry memiliki filter metrik, is_multiplexed, yang menampilkan sesi multipleks saat disetel ke true.

Sesi multipleks diaktifkan secara default untuk adaptor JDBC dan PG. Untuk library klien Java dan Go, opsi ini dinonaktifkan secara default. Anda menggunakan library klien Java atau library klien Go untuk mengaktifkan sesi multipleks. Untuk mengaktifkan sesi multipleks menggunakan Java atau Go, lihat Mengaktifkan sesi multipleks.

Mengaktifkan sesi multipleks

Untuk mengaktifkan sesi multipleks menggunakan klien Java atau Go, tetapkan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS ke true.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Melihat traffic untuk sesi reguler dan multipleks

Opentelemetry memiliki filter is_multiplexed untuk menampilkan traffic untuk sesi multipleks. Anda menetapkan filter ini ke true to view multiplexed sessions andfalse` untuk melihat sesi reguler.

1. Siapkan OpenTelemetry untuk Spanner menggunakan prosedur di bagian Sebelum memulai di OpenTelemetry Spanner.

2. Buka Metrics Explorer.

   Buka Metrics Explorer

3. Di menu drop-down Metric, filter berdasarkan generic.

4. Klik Generic Task, lalu buka Spanner > Spanner/num_acquired_sessions.

5. Di kolom Filter, pilih dari opsi berikut:

   a. is_multiplexed = false untuk melihat sesi reguler. b. is_multiplexed = true untuk melihat sesi multipleks.

   Gambar berikut menampilkan opsi Filter dengan sesi multipleks yang dipilih.

Untuk informasi selengkapnya tentang cara menggunakan OpenTelemetry dengan Spanner, lihat Manfaatkan OpenTelemetry untuk mendemokratisasi Observabilitas Spanner dan Memeriksa latensi di komponen Spanner dengan OpenTelemetry.