Playbook bukti konsep Spanner

Halaman ini memberikan strategi untuk merencanakan dan menjalankan bukti konsep (POC) dengan Spanner. Panduan ini memberikan referensi dan insight mendalam tentang aspek penting POC, seperti konfigurasi instance, desain skema, pemuatan data, dan evaluasi performa. Bagian ini menyoroti langkah-langkah penting untuk mengevaluasi kemampuan Spanner dan membantu Anda mengidentifikasi potensi risiko dan manfaat yang terkait dengan adopsi Spanner.

Selain memvalidasi kemampuan teknis Spanner, POC memiliki dua tujuan:

  • Untuk membantu Anda memahami manfaat yang ditawarkan Spanner untuk kasus penggunaan Anda
  • Untuk membantu Anda mengidentifikasi risiko yang terkait dengan penggunaan Spanner

POC Spanner mencakup berbagai aspek evaluasi, yang masing-masing disesuaikan untuk memenuhi tujuan bisnis dan teknis spesifik Anda, seperti yang ditunjukkan dalam diagram berikut.

Bukti Konsep Spanner

Panduan dalam dokumen ini membantu Anda mengevaluasi setiap area ini.

  • Performa dan skalabilitas membantu Anda memahami cara Spanner menangani workload tertentu, persyaratan latensi, dan dampak berbagai konfigurasi instance. Pengujian ini dapat mendemonstrasikan kemampuan Spanner untuk melakukan penskalaan dengan lancar.

  • Kemampuan pemantauan membantu Anda menilai apakah Spanner memberikan insight yang diperlukan untuk operasi database yang efektif. Evaluasi ini mencakup:

    • Opsi untuk menganalisis rencana eksekusi kueri
    • Penggunaan resource sistem
    • Opsi untuk mengonfigurasi pemberitahuan

    POC dapat mengungkapkan kesenjangan yang perlu diatasi untuk mengoptimalkan efisiensi operasional sepenuhnya.

  • Keamanan dan kepatuhan adalah kunci untuk menentukan kesesuaian Spanner bagi organisasi Anda. Hal ini mencakup penilaian untuk memastikan Spanner dapat memitigasi risiko keamanan sekaligus memberikan manfaat kepatuhan yang andal, seperti berikut:

    • Opsi enkripsi, seperti CMEK atau EKM untuk data yang dalam pengiriman dan dalam penyimpanan
    • Postur kontrol akses dengan hak istimewa terendah
    • Logging audit
    • Kepatuhan terhadap persyaratan peraturan
  • Kemampuan pencadangan dan pemulihan dari bencana (DR) sangat penting untuk memastikan ketahanan operasional dan data. POC dapat memvalidasi fitur DR Spanner, seperti pemulihan point-in-time dan ketersediaan.

  • Kelayakan migrasi melibatkan pemahaman tentang kompleksitas transisi dari solusi database Anda saat ini ke Spanner. Mengevaluasi kompatibilitas skema, alat migrasi, dan perubahan aplikasi membantu Anda mengukur investasi yang diperlukan, serta menentukan risiko dan manfaat penerapan Spanner.

Selama evaluasi, Anda mungkin ingin mempelajari set fitur Spanner untuk memastikan fitur tersebut memenuhi persyaratan fungsional aplikasi Anda. Hal ini dapat mencakup pengujian konsistensi global, kemampuan kueri SQL, atau integrasi dengan layanan Google Cloud lainnya.

Meskipun evaluasi dapat menyoroti keunggulan unik Spanner, seperti konsistensi di seluruh region, evaluasi juga dapat memunculkan potensi risiko, seperti upaya integrasi dengan arsitektur aplikasi yang ada.

Siklus proses aktivitas POC

POC ini akan memandu Anda melalui langkah-langkah berikut. Ikuti rekomendasi dalam dokumen ini untuk menyiapkan dan menilai Spanner untuk kasus penggunaan spesifik Anda.

Siklus proses mencakup perencanaan, konfigurasi, penentuan ukuran, pemuatan data, pengujian beban, pemantauan, dan pengoptimalan.

Merencanakan POC Anda

Langkah perencanaan

Dasar dari POC yang berhasil terletak pada penetapan sasaran yang jelas dan terukur yang selaras dengan prioritas teknis dan bisnis. Hindari tujuan yang tidak jelas seperti menjelajahi potensi Spanner, karena sering kali menyebabkan upaya yang tidak fokus dan hasil yang ambigu. Sebagai gantinya, kaitkan sasaran POC Anda dengan target konkret, seperti mencapai ketersediaan 99,999%, mengurangi waktu henti, atau melakukan penskalaan untuk menangani peningkatan throughput sebesar 200% sambil mempertahankan latensi transaksi di bawah 20 md.

Arsitektur unik Spanner sangat ideal untuk beban kerja yang memerlukan skalabilitas besar, sehingga menilai skalabilitas untuk kasus penggunaan Anda adalah titik awal yang baik. Skenario pengujian harus mencakup:

  • Menangani beban operasional umum
  • Mengelola lonjakan traffic
  • Memperkecil skala secara efisien

Pengujian ini membantu Anda memahami performa Spanner dalam berbagai kondisi dan apakah Spanner memenuhi persyaratan teknis Anda untuk skalabilitas. Tujuan yang spesifik dan dapat ditindaklanjuti tidak hanya membantu menyusun POC, tetapi juga menciptakan dasar yang kuat untuk mengevaluasi kesuksesan.

Menentukan rubrik evaluasi terkuantifikasi

Rubrik yang terdiri dari metrik yang jelas dan terukur serta kriteria keberhasilan yang berbeda-beda sangat penting untuk menyimpulkan apakah POC memenuhi tujuannya. Misalnya, daripada hanya menguji performa, Anda juga harus menentukan sasaran seperti:

  • Menayangkan QPS (kueri per detik) tingkat produksi tertentu
  • Mempertahankan latensi di bawah 20 md di bawah beban puncak yang telah ditentukan sebelumnya
  • Menangani lonjakan traffic yang jelas tanpa penurunan performa

Kriteria yang ditentukan dengan baik membantu Anda mengevaluasi Spanner secara objektif untuk workload Anda dan memberikan insight yang dapat ditindaklanjuti untuk langkah berikutnya. Tentukan secara spesifik dan tentukan target persentil untuk latensi operasi baca dan tulis (seperti p50 dan p95). Definisi yang jelas tentang batas latensi yang dapat diterima membantu Anda mendesain pengujian performa Spanner yang selaras dengan kebutuhan bisnis Anda.

Contoh rubrik evaluasi mungkin terlihat seperti berikut:

Facet Evaluasi Kriteria Keberhasilan
Ketersediaan 99,999%
Keamanan CMEK dengan EKM diperlukan
Jaminan Toleransi Jumlah Data yang Hilang (RPO) jika terjadi gangguan regional 0
Batas latensi untuk transaksi paling penting p50 di bawah 20 md
Latensi untuk kueri yang paling penting yang dihadapi pengguna p50 di bawah 100 md
Skalabilitas Mendemonstrasikan bahwa penskalaan dari 10.000 transaksi per detik menjadi 100.000 transaksi per detik dengan latensi p50 di bawah 20 md dapat dilakukan selama satu jam

Menentukan cakupan kasus evaluasi Anda

POC tidak memerlukan migrasi skala penuh. Sebagai gantinya, berfokuslah untuk menguji beban kerja representatif atau komponen penting sistem Anda. Misalnya, identifikasi kueri utama, bentuk transaksi penting, atau alur kerja berbasis data tertentu yang penting untuk operasi Anda. Persempit cakupan untuk mengurangi kompleksitas sekaligus memastikan bahwa hasilnya relevan dan bermakna. Pendekatan ini memberikan cara yang mudah dikelola untuk mengevaluasi kemampuan Spanner tanpa terbebani oleh kerumitan migrasi seluruh sistem.

Memilih konfigurasi instance Spanner

Langkah konfigurasi Spanner

Saat membuat instance Spanner untuk tujuan evaluasi, pilih konfigurasi instance yang memenuhi persyaratan bisnis Anda untuk lokasi geografis dan SLA ketersediaan layanan. Spanner menawarkan berbagai konfigurasi, termasuk satu region, multi-region, dan dual-region. Setiap konfigurasi dirancang untuk memenuhi persyaratan latensi, ketersediaan, dan redundansi yang berbeda.

  • Konfigurasi satu region menyimpan data di satu region Google Cloud, sehingga menawarkan latensi rendah dalam region tersebut dan efektivitas biaya. Topologi ini ideal untuk beban kerja yang memerlukan redundansi zonal intra-region yang memberikan ketersediaan 99,99%.
  • Konfigurasi dual-region mereplikasi data di dua region dalam satu negara dengan replika saksi di setiap region untuk failover. Konfigurasi ini memberikan ketersediaan yang lebih tinggi (99,999%) dan fault tolerance daripada penyiapan satu region. Topologi ini cocok untuk beban kerja dengan kepatuhan ketat (seperti persyaratan residensi data) atau persyaratan kedekatan geografis.
  • Konfigurasi multi-region mereplikasi data di beberapa region, sehingga memastikan ketersediaan dan ketahanan yang sangat tinggi terhadap pemadaman layanan regional. Topologi ini ideal untuk aplikasi yang memerlukan geo-redundansi dengan ketersediaan hingga 99,999%.

Pertimbangan latensi di instance lintas region

Dalam konfigurasi dual-region dan multi-region, distribusi geografis replika Spanner dapat memengaruhi latensi. Latensi penulisan bergantung pada kedekatan region pemimpin, yang mengoordinasikan transaksi baca-tulis, dan region lain, yang mengonfirmasi setiap operasi penulisan. Menempatkan resource komputasi aplikasi Anda di dekat region leader akan mengurangi penundaan round-trip dan meminimalkan latensi.

Anda dapat mengubah region paling dominan dalam database agar sesuai dengan kebutuhan aplikasi Anda. Untuk operasi hanya baca, Spanner dapat menyajikan bacaan usang dari replika terdekat, sehingga mengurangi latensi, sementara bacaan kuat mungkin melibatkan region pemimpin, yang berpotensi meningkatkan latensi operasi. Untuk mengoptimalkan latensi dalam penyiapan multi-region, pilih region leader secara strategis, lakukan kolokasi resource komputasi untuk layanan Anda dengan region leader, dan manfaatkan pembacaan yang tidak valid untuk beban kerja baca yang berat.

Konfigurasi yang memenuhi persyaratan aplikasi Anda

Saat Anda memilih konfigurasi instance untuk aplikasi, pertimbangkan faktor-faktor seperti ketersediaan, latensi, dan persyaratan residensi data. Misalnya, jika aplikasi Anda memerlukan respons latensi rendah untuk pengguna di area geografis tertentu, instance regional mungkin sudah cukup. Namun, untuk aplikasi yang memerlukan ketersediaan lebih tinggi atau melayani pengguna yang terdistribusi secara global, konfigurasi multi-region akan lebih tepat.

Mulailah dengan konfigurasi yang sangat sesuai dengan persyaratan produksi aplikasi Anda untuk mengevaluasi performa. Perlu diingat bahwa latensi dan biaya bervariasi di antara konfigurasi, jadi sesuaikan lingkungan POC Anda untuk mencerminkan kebutuhan kasus penggunaan Anda. Untuk deployment multi-region, simulasikan distribusi layanan geografis dan uji latensi untuk memastikan konfigurasi sesuai dengan persyaratan produksi Anda. Untuk mengetahui detail selengkapnya, lihat Panduan penempatan pemimpin multi-region Spanner.

Penentuan ukuran Spanner

Menentukan ukuran langkah Spanner

Sediakan kapasitas komputasi awal untuk instance Spanner Anda guna memastikan instance tersebut dapat menangani workload evaluasi Anda secara efektif selama POC. Ukuran instance awal harus sesuai dengan beban kerja yang diharapkan, dengan mempertimbangkan campuran kueri baca dan tulis per detik (QPS), kompleksitas kueri, dan tingkat serentak.

Memulai dengan asumsi yang wajar memungkinkan Anda menetapkan dasar pengukuran dan meningkatkan skala secara bertahap berdasarkan performa yang diamati. Anda dapat menggunakan panduan penentuan ukuran dari tolok ukur referensi Spanner untuk membuat konfigurasi instance dasar.

Penentuan ukuran selama POC harus dilakukan secara iteratif. Mulai dengan penyiapan awal, lalu pantau metrik utama seperti latensi dan penggunaan CPU, serta sesuaikan kapasitas komputasi yang ditetapkan sesuai kebutuhan. Hal ini memastikan bahwa Anda dapat memvalidasi kemampuan skalabilitas dan performa Spanner sambil mereplikasi kondisi yang mirip dengan lingkungan produksi Anda.

Pola workload umum, seperti traffic yang konsisten versus permintaan yang berfluktuasi, harus memengaruhi pendekatan penentuan ukuran Anda. Saat Anda mengaktifkan penskalaan otomatis, Spanner menyediakan kapasitas resource komputasinya secara dinamis agar sesuai dengan intensitas workload.

Desain skema

Langkah desain skema

Desain skema adalah aspek penting dari POC Spanner karena cara Anda mengatur data dapat secara langsung memengaruhi performa dan skalabilitas.

Skema yang dirancang dengan baik adalah fondasi untuk mendemonstrasikan kemampuan Spanner dalam POC. Uji beban sering kali mengungkapkan potensi hambatan atau inefisiensi, sehingga menginformasikan penyempurnaan iteratif yang menciptakan skema optimal.

Mendesain untuk skalabilitas

Saat membuat skema database untuk Spanner, Anda harus mempertimbangkan arsitektur terdistribusinya. Beberapa pertimbangan dan pengoptimalan utama meliputi:

  • Kunci utama: pilih kunci utama yang mendistribusikan data secara merata di seluruh ruang kunci, hindari kunci yang meningkat secara monoton seperti stempel waktu yang dapat menyebabkan hotspot pada pemisahan.
  • Indeks: desain indeks untuk mengoptimalkan performa kueri sekaligus memperhatikan dampaknya terhadap performa penulisan dan biaya penyimpanan. Terlalu banyak atau indeks yang direncanakan dengan buruk dapat menimbulkan beban yang tidak perlu.
  • Penyisipan tabel: gunakan penyisipan tabel untuk mengoptimalkan pola akses untuk data terkait. Hal ini dapat mengurangi komunikasi lintas proses dan meningkatkan efisiensi kueri.

Lihat praktik terbaik desain skema Spanner untuk menghindari kesalahan umum dan mendesain skema yang mendukung performa dan skalabilitas tinggi.

Anda dapat membuat draf skema di konsol Google Cloud seperti yang ditunjukkan pada gambar berikut.

Buat skema draf di Konsol.

Migrasi skema dengan alat migrasi Spanner

Alat migrasi Spanner (SMT) dapat menyederhanakan pembuatan skema saat melakukan migrasi dari database relasional, termasuk MySQL atau PostgreSQL. SMT mengotomatiskan pembuatan skema dan mencakup pengoptimalan dasar, seperti menyarankan indeks dan penyesuaian skema. Meskipun SMT memberikan titik awal yang kuat, penyempurnaan manual sering kali diperlukan untuk menyelaraskan skema dengan kasus penggunaan atau pola beban kerja tertentu.

Menggunakan proses desain skema iteratif

Meskipun skema awal memberikan titik awal, kemungkinan skema tersebut tidak sempurna. Pembuatan skema untuk POC bukanlah tugas satu kali, melainkan proses berulang yang berkembang seiring Anda mendapatkan insight dari pengujian. Skema yang kuat sangat penting untuk performa aplikasi; untuk mencapainya, diperlukan desain awal yang dipikirkan dengan matang, memanfaatkan alat seperti SMT, dan penyempurnaan berulang berdasarkan hasil pengujian beban. Dengan mengikuti proses ini, Anda dapat memastikan skema Anda secara efektif memenuhi kebutuhan aplikasi Anda. Anda juga akan mempelajari cara terbaik untuk memanfaatkan fitur Spanner.

Pemuatan data

POC Spanner yang berhasil bergantung pada pemuatan data representatif ke dalam database untuk memvalidasi desain skema dan menyimulasikan alur kerja aplikasi. Ada beberapa alat yang direkomendasikan yang dapat menyederhanakan proses ini. Untuk memuat data Anda sendiri, Spanner menyediakan opsi berikut:

  • Ekstraksi, transformasi, dan pemuatan (ETL) terbalik BigQuery ke Spanner adalah mekanisme pemuatan data terintegrasi yang mudah digunakan yang memungkinkan Anda menggunakan transformasi berbasis SQL untuk memuat data ke Spanner. Metode ini ideal untuk berbagai format data, termasuk data semi-terstruktur seperti JSON.
  • Untuk database relasional seperti MySQL dan PostgreSQL, alat migrasi Spanner (SMT) mengotomatiskan pembuatan skema, pemetaan jenis data, dan pemuatan data massal.
  • Untuk format file datar, Google menyediakan template Dataflow untuk CSV ke Spanner dan Avro ke Spanner guna membuat definisi skema manual untuk pemuatan data massal. Untuk database yang kompatibel dengan JDBC, Google menyediakan template Dataflow JDBC ke Spanner.

Untuk mengetahui informasi selengkapnya tentang opsi ini, lihat Menggunakan data Anda sendiri.

Jika tidak ada data sampel, Anda dapat menggunakan alat pembuatan data sintetis seperti JMeter dari Machmeter dan QuickPerf untuk membantu Anda membuat set data yang disesuaikan dengan skema dan kasus penggunaan Anda. Untuk mengetahui informasi selengkapnya, lihat Membuat data contoh.

Membawa data Anda sendiri

Langkah-langkah membawa data Anda sendiri

Jika memiliki data sampel yang tersedia dan ingin digunakan untuk POC, Anda memiliki beberapa opsi untuk memuat data tersebut ke Spanner.

Sumber Alat Pembuatan skema Transformations Ukuran Data
MySQL SMT otomatis Hanya konversi jenis data kecil
PostgreSQL SMT otomatis Hanya konversi jenis data kecil
JDBC apa pun JDBC ke Spanner manual Hanya konversi jenis data besar
CSV CSV ke Spanner manual Hanya konversi jenis data besar
Reverse ETL BigQuery manual Transformasi kompleks yang didukung besar
Avro Avro ke Spanner manual Hanya konversi jenis data besar
Reverse ETL BigQuery manual Transformasi kompleks yang didukung besar
JSON Reverse ETL BigQuery manual Transformasi kompleks yang didukung besar

Reverse ETL BigQuery ke Spanner

BigQuery reverse ETL ke Spanner memungkinkan Anda menyerap berbagai sumber data dengan cepat dan mengubahnya menjadi tabel BigQuery menggunakan SQL. Selanjutnya, Anda dapat mengekspor data dari tabel BigQuery ke tabel Spanner. Alat ini sangat berguna untuk data semi-terstruktur, seperti JSON, yang sering kali berasal dari ekspor dari sumber data NoSQL. Meskipun BigQuery memiliki deteksi skema otomatis, pembuatan skema Spanner dilakukan secara manual, sehingga Anda harus menentukan skema sebelum memuat data.

Alat migrasi Spanner

Untuk memulai POC, Anda dapat menggunakan alat migrasi Spanner (SMT) untuk memigrasikan data dari sumber MySQL dan PostgreSQL ke Spanner. SMT mengotomatiskan proses pembuatan skema, memetakan jenis data dari database sumber ke jenis yang setara di Spanner. Alat ini juga memberikan rekomendasi pengoptimalan skema khusus Spanner. Hal ini membuatnya sangat berguna untuk migrasi sederhana yang konversi skemanya otomatis sudah cukup.

SMT menyediakan antarmuka pengguna yang memandu Anda melalui proses migrasi. Selama proses ini, Anda memilih database sumber, dan meninjau rekomendasi dan opsi untuk desain skema.

Template Dataflow

Dataflow adalah layanan terkelola sepenuhnya yang dirancang untuk pemrosesan data yang skalabel, sehingga menjadi pilihan yang tepat untuk memuat data dalam jumlah besar.

Google menyediakan template open source berikut untuk pola pemuatan umum:

Setiap template ini mengharuskan Anda membuat skema Spanner secara manual sebelum memulai pemuatan data.

Dataflow otomatis menskalakan untuk mengakomodasi set data dengan ukuran apa pun, sehingga memastikan penyerapan data berkinerja tinggi ke Spanner, bahkan untuk set data skala terabyte. Skalabilitas ini diberikan dengan beberapa trade-off:

  • Pipeline Dataflow memerlukan konfigurasi manual untuk menentukan skema, pemetaan data, dan parameter eksekusi untuk eksekusi yang optimal.
  • Dataflow memberikan fleksibilitas dan kemampuan yang diperlukan untuk migrasi data skala besar, tetapi penyiapan dan pengelolaannya mungkin memerlukan lebih banyak upaya dibandingkan alat lain.

Membuat data sampel

Langkah pembuatan data sampel.

Jika Anda tidak memiliki data contoh, tetapi memiliki kasus penggunaan tertentu, Anda dapat memodelkan skema berdasarkan persyaratan Anda, dan menggunakan alat untuk membuat set data representatif. Alat ini memungkinkan Anda mengisi Spanner dengan data yang bermakna untuk memvalidasi desain skema dan alur kerja aplikasi Anda.

JMeter dari Machmeter

JMeter dari Machmeter memberikan contoh yang menggunakan JMeter untuk membuat data sampel untuk Spanner. Fokus Machmeter pada contoh berbasis kasus penggunaan menjadikannya titik awal yang bagus untuk membuat pola data yang secara struktural mirip dengan skema produksi yang Anda harapkan. Contoh yang diberikan mencakup skrip untuk penyisipan massal dan operasi lainnya. Anda dapat menyesuaikan skrip untuk membuat set data sintetis dalam skala besar. Untuk mengetahui informasi selengkapnya, lihat repositori Machmeter atau dokumentasi.

QuickPerf

QuickPerf didistribusikan dengan driver JDBC Spanner. QuickPerf menyediakan skrip berbasis SQL yang dengan cepat membuat set data representatif untuk menguji integritas skema dan perilaku database. Ini adalah pilihan yang mudah untuk membuat set data berukuran kecil hingga sedang yang tidak terlalu kompleks dengan cepat.

Pengujian beban

Langkah pengujian beban

Pengujian beban memungkinkan Anda mengamati performa Spanner saat menangani beban kerja untuk memastikan database Anda memiliki konfigurasi yang optimal untuk permintaan produksi. Dua alat yang diperkenalkan sebelumnya, yaitu JMeter dari Machmeter dan QuickPerf, sangat efektif untuk menyimulasikan workload dan mengukur metrik performa seperti throughput, latensi, dan penggunaan resource.

Apache JMeter, yang ditingkatkan melalui project Machmeter, menyediakan framework yang andal untuk pengujian beban terdistribusi dengan Spanner. Machmeter menyertakan konfigurasi JMeter bawaan yang dirancang khusus untuk menyimulasikan workload Spanner. Konfigurasi ini dapat disesuaikan untuk mengeksekusi kueri, transaksi, dan operasi batch yang representatif, sehingga Anda dapat mengukur performa Spanner dalam berbagai skenario.

Kemampuan JMeter untuk menyimulasikan pengguna dan transaksi serentak menjadikannya pilihan yang baik untuk menguji skalabilitas dan ketahanan instance Spanner Anda. Anda dapat men-deploy JMeter dalam mode terdistribusi menggunakan Kubernetes atau layanan terkelola GKE untuk menskalakan lingkungan pengujian Anda. Hasilnya memberikan insight tentang cara Spanner mengelola workload tertentu, melakukan penskalaan saat permintaan meningkat, dan berperforma selama beban puncak.

Untuk mengetahui informasi selengkapnya dan contoh konfigurasi, lihat repositori Machmeter.

QuickPerf adalah alat benchmark ringan yang dirancang untuk pengujian performa dengan Spanner. Layanan ini berfokus pada pembuatan metrik performa dengan penyiapan minimal, sehingga Anda dapat melakukan iterasi pengoptimalan dengan cepat. QuickPerf mudah dikonfigurasi dan sangat cocok untuk pengujian skala kecil dan skenario saat Anda ingin mengukur dengan cepat dampak performa dari pengoptimalan skema atau kueri tertentu.

Praktik terbaik untuk pengujian beban

Saat melakukan pengujian beban, Anda harus mengikuti praktik terbaik Spanner untuk memastikan hasil yang akurat dan dapat ditindaklanjuti.

  • Periode pemanasan: izinkan periode pemanasan (biasanya 30 menit atau lebih) agar Spanner mencapai kondisi stabil setelah menskalakan node atau memperkenalkan workload baru.
  • Ukur metrik yang relevan: berfokus pada metrik, seperti throughput (operasi per detik), persentil latensi (misalnya, p50, p95), dan pemakaian CPU untuk memahami cara Spanner melayani workload Anda.
  • Jalankan benchmark yang panjang: Untuk mendapatkan hasil yang lebih representatif, jalankan uji beban selama jangka waktu yang lebih lama (misalnya, lebih dari satu jam) untuk memperhitungkan perilaku sistem seperti penyeimbangan ulang dan tugas pemeliharaan di latar belakang.
  • Pengujian penskalaan: uji skenario penskalaan dan penurunan skala untuk mengamati perilaku Spanner dalam berbagai konfigurasi node dan beban puncak.

Anda dapat menggunakan alat seperti JMeter Machmeter dan QuickPerf, beserta praktik terbaik untuk pengujian beban, guna mengevaluasi performa Spanner secara efektif, mengidentifikasi hambatan, dan mengoptimalkan database Anda untuk memenuhi permintaan beban kerja Anda.

Pemantauan

Langkah pemantauan

Untuk mendemonstrasikan performa dan skalabilitas Spanner secara efektif selama POC, terutama saat berada di bawah beban, Anda harus memahami karakteristik operasionalnya secara mendalam. Spanner menyediakan serangkaian alat pemantauan dan diagnostik yang komprehensif yang dirancang untuk memberi Anda insight terperinci tentang setiap aspek performa database Anda. Kumpulan alat ini menawarkan berbagai resource, mulai dari dasbor metrik hingga tabel sistem mendetail, yang membantu Anda mengidentifikasi bottleneck, memvalidasi pilihan desain, dan mengoptimalkan performa.

Analisis sistem memberikan kemampuan observasi mendalam terkait performa dan kondisi operasional instance Spanner. Alat ini menawarkan metrik dan insight ke dalam beberapa area, termasuk pemakaian CPU, latensi, throughput, dan lainnya, pada tingkat perincian yang dapat disesuaikan. Selama POC, ini adalah titik awal untuk mengamati perilaku Spanner selama pengujian Anda. Insight sistem memungkinkan Anda mengidentifikasi dengan cepat hambatan performa, seperti pemakaian CPU yang tinggi atau peningkatan latensi baca atau tulis. Hal ini menjadi dasar untuk penyelidikan selanjutnya.

Insight kueri memberikan tampilan menyeluruh eksekusi kueri, dimulai dengan mengidentifikasi kueri yang paling sering dan paling mahal berdasarkan metrik seperti waktu CPU, jumlah eksekusi, dan latensi rata-rata. Lebih lanjut, insight kueri memungkinkan Anda memeriksa rencana eksekusi terperinci, termasuk statistik untuk setiap langkah kueri, dan menunjukkan operasi tertentu yang menyebabkan perlambatan. Laporan ini juga menawarkan fitur yang menyelidiki tren performa historis dan membandingkan performa kueri di berbagai jangka waktu. Hal ini membantu Anda mengidentifikasi regresi atau dampak perubahan skema dan kode. Alat tambahan, seperti penasihat indeks, menganalisis kueri Anda untuk merekomendasikan indeks baru atau yang diubah yang dapat meningkatkan performa kueri Anda.

Insight transaksi memberikan visibilitas ke dalam performa transaksi dengan metrik mendetail tentang latensi transaksi, waktu tunggu commit, jumlah baris dan byte yang dibaca dan ditulis, serta peserta dalam transaksi terdistribusi. Metrik ini mengungkapkan transaksi yang memiliki latensi tinggi atau dibatalkan dan memberikan detail tentang karakteristiknya. Selama pengujian beban POC, insight transaksi sangat penting untuk menilai efisiensi transaksional sistem dalam kondisi tertekan. Dengan begitu, Anda dapat memantau dan mengidentifikasi penurunan kualitas saat beban meningkat. Menganalisis transaksi individual membantu Anda menentukan penyebab perlambatan, seperti transaksi yang berjalan lama yang memblokir transaksi lain atau transaksi tunggal yang membaca atau menulis data dalam volume yang sangat besar. Informasi dari insight transaksi memungkinkan Anda melakukan penyesuaian yang ditargetkan, seperti mengoptimalkan batas transaksi, menyempurnakan kueri dalam transaksi, atau menyesuaikan skema untuk mengurangi jumlah data yang terlibat dalam transaksi umum. Hal ini memastikan POC menunjukkan kemampuan Spanner dalam mempertahankan konsistensi dan performa transaksional pada tingkat beban yang diharapkan.

Insight kunci memberikan visibilitas ke dalam perilaku penguncian transaksi, sehingga membantu Anda mengidentifikasi dan menyelesaikan masalah pertentangan kunci. Fitur ini menampilkan informasi tentang waktu tunggu penguncian, termasuk rentang kunci baris tertentu yang menyebabkan masalah. Selama pengujian beban POC, insight kunci sangat penting untuk mengidentifikasi apakah konflik kunci transaksional menyebabkan batasan skalabilitas. Seiring peningkatan beban serentak, transaksi mungkin mulai bersaing untuk memperbarui data yang sama, sehingga menyebabkan peningkatan waktu tunggu dan penurunan throughput. Informasi ini membantu Anda melakukan pengoptimalan skema, modifikasi batas transaksi, dan penyesuaian logika aplikasi. Tindakan ini mengurangi persaingan dan memastikan bahwa database Spanner mempertahankan performa di bawah beban kerja yang diproyeksikan, sehingga mencegah penurunan kualitas karena mekanisme penguncian.

Insight hotspot mengidentifikasi hambatan performa, khususnya peningkatan latensi, yang disebabkan oleh kondisi hotspot. Hotspot biasanya terjadi saat ada beban yang tinggi dan tidak merata. Penyebab hotspot sering kali adalah:

  • Desain skema yang kurang optimal
  • Pemilihan kunci utama
  • Pola akses yang memusatkan operasi pada subkumpulan data kecil, bukan mendistribusikannya secara merata di seluruh node

Selama uji beban POC, insight hotspot membantu Anda memutuskan tempat untuk mengoptimalkan skema. Misalnya, Anda mungkin perlu menyesuaikan kunci primer atau mengubah indeks sekunder untuk mencegah hotspot.

Key Visualizer memberikan representasi visual pola penggunaan database dari waktu ke waktu di seluruh ruang kunci tabel dan indeks. Fitur ini menghasilkan peta panas yang menunjukkan aktivitas baca dan tulis, yang menandai area dengan intensitas tinggi dan potensi pola yang bermasalah. Selama POC, alat ini membantu memvalidasi desain skema dan mengidentifikasi potensi batasan skalabilitas. Saat beban meningkat, Anda dapat mengamati cara workload didistribusikan di seluruh ruang kunci serta tabel dan indeks masing-masing.

Tabel introspeksi, terutama sistem tabel Spanner_SYS, memberikan banyak informasi tentang performa dan status internal database. Tabel ini menampilkan statistik mendetail tentang eksekusi kueri, perilaku transaksi, persaingan kunci, dan detail skema. Selama uji beban POC, tabel introspeksi ini memberikan pendekatan berbasis data untuk diagnostik performa, di luar yang ditawarkan oleh alat insight yang disebutkan sebelumnya. Misalnya, Anda dapat menggunakannya untuk memecahkan masalah penyebab utama konflik penguncian di database yang sulit dideteksi dan mendapatkan insight yang dapat ditindaklanjuti untuk pengoptimalan.

Pengoptimalan

Langkah pengoptimalan

Pengujian beban adalah langkah penting dalam mengidentifikasi masalah performa dan potensi hambatan dalam penerapan Spanner Anda. Insight yang diperoleh dari pengujian ini akan memandu upaya pengoptimalan di seluruh desain skema, perilaku transaksi, dan performa kueri untuk memastikan Spanner memenuhi tuntutan beban kerja Anda.

Mengoptimalkan desain skema

Meskipun desain skema awal didasarkan pada praktik terbaik untuk skalabilitas dan performa, menjalankan workload dalam kondisi dunia nyata sering kali mengungkapkan area yang memerlukan peningkatan. Uji beban memberikan insight berharga tentang performa skema dalam kondisi tertentu, yang menyoroti masalah seperti hotspotting, distribusi data yang tidak merata, atau inefisiensi dalam performa kueri.

Pengoptimalan berfokus pada penyesuaian area berikut agar selaras dengan karakteristik beban kerja aplikasi Anda.

  • Penyesuaian kunci utama: jika uji beban mengungkapkan hotspot atau distribusi data yang tidak seimbang, tinjau desain kunci utama. Misalnya, pertimbangkan untuk menambahkan keacakan di awalan kunci untuk mendistribusikan data secara lebih merata di seluruh node sekaligus mempertahankan efisiensi kueri.
  • Penyempurnaan indeks: pengujian beban dapat mengungkapkan apakah indeks yang berlebihan atau pengindeksan berlebih berdampak buruk pada throughput penulisan. Hapus indeks yang tidak perlu atau susun ulang indeks yang ada untuk performa kueri yang lebih baik. Mengevaluasi selektivitas indeks dan memastikan indeks selaras dengan pola kueri umum.
  • Hierarki dan tabel sisipan: analisis apakah tabel terkait dapat memperoleh manfaat dari penyisipan tabel untuk mengurangi latensi kueri. Sesuaikan keputusan penyisipan berdasarkan pola akses yang diamati selama pengujian. Sebaliknya, pertimbangkan untuk memodelkan tabel tersebut secara terpisah jika struktur hierarkis menyebabkan overhead yang tidak terduga.

Untuk mengetahui informasi tentang cara membuat skema yang skalabel, lihat praktik terbaik desain skema Spanner.

Mengoptimalkan semantik dan kueri transaksi

Uji beban sering kali menyoroti inefisiensi dalam eksekusi transaksi dan kueri, seperti masalah pertentangan atau penguncian yang tinggi. Mengoptimalkan semantik transaksi dan struktur kueri untuk memaksimalkan throughput dan meminimalkan latensi:

  • Mode transaksi: gunakan mode transaksi yang sesuai untuk setiap operasi workload. Misalnya, gunakan transaksi hanya baca untuk kueri yang tidak mengubah data, atau DML berpartisi untuk update dan penghapusan massal.
  • Batching: jika memungkinkan, gunakan operasi tulis batch untuk mengurangi overhead yang terjadi akibat beberapa perjalanan pulang pergi.
  • Pengoptimalan kueri: refaktor kueri untuk menyertakan hanya kolom dan baris yang diperlukan, manfaatkan indeks, dan gunakan parameter kueri di aplikasi Anda untuk mengurangi overhead.

Untuk mengetahui informasi tentang strategi pengoptimalan, lihat Ringkasan transaksi dan Praktik terbaik SQL.

Pengujian beban iteratif

Pengoptimalan adalah proses iteratif. Lakukan uji beban setelah setiap perubahan skema atau kueri yang signifikan untuk memvalidasi peningkatan dan memastikan tidak ada hambatan baru yang muncul.

Simulasikan skenario aplikasi yang realistis dengan berbagai tingkat serentak, jenis transaksi, dan volume data untuk mengonfirmasi bahwa Spanner berfungsi seperti yang diharapkan dalam kondisi puncak dan kondisi stabil.

Metrik utama yang harus dipantau

Lacak metrik utama seperti latensi (p50, p99), throughput, dan pemakaian CPU selama pengoptimalan.

Langkah berikutnya