Desain skema untuk data deret waktu

Halaman ini menjelaskan pola desain skema untuk menyimpan data deret waktu di Bigtable. Halaman ini dibuat berdasarkan Mendesain skema dan mengasumsikan bahwa Anda sudah memahami konsep dan rekomendasi yang dijelaskan di halaman tersebut.

Deret waktu adalah kumpulan data yang terdiri dari pengukuran dan waktu saat pengukuran dicatat. Contoh deret waktu mencakup hal berikut:

  • Plot penggunaan memori di komputer Anda
  • Suhu dari waktu ke waktu dalam laporan berita
  • Harga pasar saham selama jangka waktu tertentu

Skema yang baik menghasilkan performa dan skalabilitas yang sangat baik, sedangkan skema yang buruk dapat menyebabkan sistem berperforma buruk. Namun, tidak ada satu desain skema yang paling cocok untuk semua kasus penggunaan.

Pola yang dijelaskan di halaman ini memberikan titik awal. Set data unik dan kueri yang ingin Anda gunakan adalah hal terpenting yang perlu dipertimbangkan saat mendesain skema untuk data deret waktu.

Pola desain dasar untuk menyimpan data deret waktu di Bigtable adalah sebagai berikut:

Data untuk contoh

Untuk mengilustrasikan perbedaan antara pola, contoh di halaman ini mengasumsikan bahwa Anda menyimpan data untuk aplikasi yang mencatat pengukuran yang dilakukan balon cuaca setiap menit sekali. Kami menggunakan peristiwa untuk mengartikan satu permintaan yang menulis satu atau beberapa sel secara bersamaan. ID lokasi sesuai dengan wilayah Google Cloud .

Pengukuran Contoh
  1. Stempel waktu di halaman ini diformat seperti `tYYYY-MM-DD-HHMM` agar dapat dibaca manusia. Dalam tabel produksi, stempel waktu biasanya dinyatakan sebagai jumlah mikrodetik sejak 1970-01-0100:00:00 UTC, seperti `1616264288050807`.
Tekanan (pascal) 94587
Suhu (Celsius) 9,5
Kelembapan (persentase) 65
Ketinggian (meter) 601
Data terkait Contoh
ID Balon 3698
Lokasi asia-southeast1
Stempel waktu1 t2021-03-05-1204

Bucket waktu

Dalam pola bucket waktu, setiap baris dalam tabel Anda mewakili "bucket" waktu, seperti jam, hari, atau bulan. Row key menyertakan ID non-stempel waktu, seperti week49, untuk jangka waktu yang dicatat dalam baris, beserta data identifikasi lainnya.

Ukuran bucket yang Anda gunakan — seperti menit, jam, atau hari — bergantung pada kueri yang ingin Anda gunakan dan batas ukuran data Bigtable. Misalnya, jika baris yang berisi data satu jam lebih besar dari ukuran maksimum yang direkomendasikan per baris sebesar 100 MB, baris yang mewakili setengah jam atau satu menit mungkin merupakan pilihan yang lebih baik.

Keuntungan pola bucket waktu meliputi:

  • Anda akan melihat performa yang lebih baik. Misalnya, jika Anda menyimpan 100 pengukuran, Bigtable akan menulis dan membaca pengukuran tersebut lebih cepat jika berada dalam satu baris daripada jika berada dalam 100 baris.

  • Data yang disimpan dengan cara ini dikompresi secara lebih efisien daripada data dalam tabel yang tinggi dan sempit.

Kekurangan meliputi:

  • Pola desain skema bucket waktu lebih rumit daripada pola stempel waktu tunggal dan dapat memerlukan lebih banyak waktu dan upaya untuk dikembangkan.

Menambahkan kolom baru untuk peristiwa baru

Dalam pola bucket waktu ini, Anda menulis kolom baru ke baris untuk setiap peristiwa, menyimpan data di penentu kolom, bukan sebagai nilai sel. Artinya, untuk setiap sel, Anda mengirim grup kolom, penentu kolom, dan stempel waktu, tetapi tanpa nilai.

Dengan menggunakan pola ini untuk data balon cuaca sampel, setiap baris berisi semua pengukuran untuk satu metrik, seperti pressure, untuk satu balon cuaca, selama seminggu. Setiap row key berisi lokasi, ID balon, metrik yang Anda catat di baris, dan nomor minggu. Setiap kali balon melaporkan datanya untuk sebuah metrik, Anda menambahkan kolom baru ke baris. Penentu kolom berisi pengukuran, tekanan dalam Pascal, untuk menit yang diidentifikasi oleh stempel waktu sel.

Dalam contoh ini, setelah tiga menit, baris mungkin terlihat seperti ini:

Row key 94558 94122 95992
us-west2#3698#pressure#week1 "" (t2021-03-05-1200) "" (t2021-03-05-1201) "" (t2021-03-05-1202)

Kasus penggunaan untuk pola ini mencakup hal berikut:

Menambahkan sel baru untuk peristiwa baru

Dalam pola bucket waktu ini, Anda menambahkan sel baru ke kolom yang ada saat menulis peristiwa baru. Pola ini memungkinkan Anda memanfaatkan kemampuan Bigtable untuk menyimpan beberapa sel yang diberi stempel waktu di baris dan kolom tertentu. Penting untuk menentukan aturan pembersihan sampah memori saat Anda menggunakan pola ini.

Jika workload Anda memiliki rasio peristiwa yang tinggi, beberapa peristiwa mungkin terjadi dalam milidetik yang sama, yang dapat menyebabkan kehilangan data karena tabrakan stempel waktu. Untuk mencegah hal ini saat menambahkan sel baru untuk peristiwa baru, Anda dapat mengonfigurasi tabel untuk menggunakan perincian stempel waktu mikrodetik. Fitur ini hanya tersedia untuk instance di edisi Enterprise Plus.

Dengan menggunakan data balon cuaca sebagai contoh, setiap baris berisi semua pengukuran untuk satu balon cuaca selama seminggu. Awalan row key adalah ID untuk minggu, sehingga Anda dapat membaca data selama seminggu penuh untuk beberapa balon dengan satu kueri. Segmen row key lainnya adalah lokasi tempat balon beroperasi dan nomor ID untuk balon. Tabel ini memiliki satu grup kolom, measurements, dan grup kolom tersebut memiliki satu kolom untuk setiap jenis pengukuran: pressure, temperature, humidity, dan altitude.

Setiap kali balon mengirimkan pengukurannya, aplikasi menulis nilai baru ke baris yang menyimpan data minggu ini untuk balon tersebut, dengan menulis sel tambahan yang diberi stempel waktu ke setiap kolom. Di akhir minggu, setiap kolom di setiap baris memiliki satu pengukuran untuk setiap menit dalam seminggu, atau 10.080 sel (jika kebijakan pembersihan sampah memori mengizinkannya).

Setiap kolom di setiap baris menyimpan pengukuran untuk setiap menit dalam seminggu. Dalam hal ini, setelah tiga menit, dua kolom pertama dalam satu baris mungkin terlihat seperti ini:

Row key tekanan suhu
asia-south2#3698#week1 94558 (t2021-03-05-1200) 9.5 (t2021-03-05-1200)
94122 (t2021-03-05-1201) 9.4 (t2021-03-05-1201)
95992 (t2021-03-05-1202) 9.2 (t2021-03-05-1202)

Kasus penggunaan untuk pola ini mencakup hal berikut:

  • Anda ingin dapat mengukur perubahan pengukuran dari waktu ke waktu.

Baris stempel waktu tunggal

Dalam pola ini, Anda membuat baris untuk setiap peristiwa atau pengukuran baru, bukan menambahkan sel ke kolom di baris yang ada. Akhiran row key adalah nilai stempel waktu. Tabel yang mengikuti pola ini cenderung tinggi dan sempit, dan setiap kolom dalam baris hanya berisi satu sel.

Diserialisasi dengan stempel waktu tunggal

Dalam pola ini, Anda menyimpan semua data untuk satu baris dalam satu kolom dalam format serial seperti JSON atau buffering protokol (protobuf). Pendekatan ini dijelaskan secara lebih mendetail di Praktik terbaik desain skema.

Misalnya, jika Anda menggunakan pola ini untuk menyimpan data balon cuaca, tabel Anda mungkin terlihat seperti ini setelah empat menit:

Row key measurements_blob
us-west2#3698#2021-03-05-1200 protobuf_1
us-west2#3698#2021-03-05-1201 protobuf_2
us-west2#3698#2021-03-05-1202 protobuf_3
us-west2#3698#2021-03-05-1203 protobuf_4

Keuntungan dari pola ini mencakup hal berikut:

  • Efisiensi penyimpanan

  • Kecepatan

Kekurangan meliputi:

  • Jika tidak menggunakan fitur kueri SQL Bigtable untuk JSON atau buffering protokol, Anda tidak dapat mengambil kolom tertentu saja saat membaca data, melainkan harus membaca semua data untuk sel tertentu.

  • Kebutuhan untuk melakukan deserialisasi data setelah dibaca

Kasus penggunaan untuk pola ini mencakup hal berikut:

  • Anda hampir selalu perlu mengambil semua pengukuran untuk peristiwa tertentu secara bersamaan.

  • Anda memprioritaskan efisiensi penyimpanan karena hampir selalu mengambil semua pengukuran untuk peristiwa tertentu secara bersamaan. Meskipun Anda dapat menggunakan kemampuan SQL Bigtable untuk memfilter data di sisi server, pola ini paling bermanfaat jika Anda tidak perlu sering memfilter.

  • Setiap peristiwa berisi begitu banyak pengukuran sehingga Anda mungkin melebihi batas 100 MB per baris jika menyimpan data dalam beberapa kolom.

Stempel waktu tunggal tidak diserialisasi

Dalam pola ini, Anda menyimpan setiap peristiwa di barisnya sendiri, meskipun Anda hanya mencatat satu pengukuran. Data dalam kolom tidak diserialisasi.

Keuntungan dari pola ini mencakup hal berikut:

  • Pola ini umumnya lebih mudah diterapkan daripada pola bucket waktu.

  • Anda mungkin menghabiskan lebih sedikit waktu untuk menyempurnakan skema sebelum menggunakannya.

Kekurangan pola ini sering kali lebih besar daripada kelebihannya:

  • Bigtable kurang berperforma dengan pola ini.

  • Data yang disimpan dengan cara ini tidak dikompresi seefisien data dalam kolom yang lebih lebar.

  • Meskipun stempel waktu berada di akhir row key, pola ini dapat menghasilkan hotspot.

Kasus penggunaan untuk pola ini mencakup hal berikut:

  • Anda ingin selalu mengambil semua kolom, tetapi hanya rentang stempel waktu tertentu, dan Anda memiliki alasan untuk tidak menyimpan data dalam struktur serial.

  • Anda ingin menyimpan peristiwa dalam jumlah tak terbatas.

Dengan menggunakan contoh data balon cuaca, grup kolom dan penentu kolom sama dengan contoh yang menggunakan bucket waktu dan sel baru. Namun, dalam pola ini, setiap set pengukuran yang dilaporkan untuk setiap balon cuaca ditulis ke baris baru. Tabel berikut menunjukkan lima baris yang ditulis menggunakan pola ini:

Row key tekanan suhu kelembapan altitude
us-west2#3698#2021-03-05-1200 94558 9.6 61 612
us-west2#3698#2021-03-05-1201 94122 9,7 62 611
us-west2#3698#2021-03-05-1202 95992 9,5 58 602
us-west2#3698#2021-03-05-1203 96025 9,5 66 598
us-west2#3698#2021-03-05-1204 96021 9.6 63 624

Strategi tambahan

Jika Anda perlu mengirim beberapa kueri berbeda untuk set data yang sama, pertimbangkan untuk menyimpan data Anda dalam beberapa tabel, masing-masing dengan row key yang dirancang untuk salah satu kueri.

Anda juga dapat menggabungkan pola dalam beberapa kasus. Misalnya, Anda dapat menyimpan data yang diserialisasi dalam baris yang mewakili bucket waktu, asalkan Anda tidak membiarkan baris menjadi terlalu besar.

Langkah berikutnya