Database Kolom Sangat Cepat. Ini Alasannya.

Bahasa IndonesiaالعربيةDeutschEnglishEspañolFrançaisहिन्दी日本語한국어PortuguêsРусский中文
BBetter Stack
Computing/Software

Transcript

00:00:00meskipun saya sangat menyukai postgres, basis data ini bukan yang terbaik untuk semuanya. Ada jenis
00:00:04basis data berbeda yang disebut basis data kolom yang dapat menjalankan kueri tertentu hingga 40 kali lebih cepat. Basis data
00:00:10ini bekerja dengan menyimpan kolom secara bersamaan alih-alih baris, yang berarti Anda mendapatkan manfaat besar
00:00:15untuk kasus penggunaan tertentu seperti platform analitik. Tentu saja, semuanya memiliki kelebihan dan kekurangan,
00:00:20tetapi hari ini kita akan melihat apa itu basis data kolom dan membandingkan beberapa kueri terhadap
00:00:25postgres untuk melihat kelebihan dan kekurangannya. Kita akan membandingkan postgres dengan clickhouse dan duckdb,
00:00:31jadi tonton terus dan pada akhirnya Anda akan memiliki pemahaman yang kuat tentang basis data berbasis kolom
00:00:36serta kapan harus memilih teknologi yang tepat.
00:00:43Jadi di awal tadi saya bilang Anda dapat menjalankan kueri tertentu 40 kali lebih cepat, dan itu benar jika kita mengambil
00:00:49tabel basis data di sini. Saya telah memuat seratus juta baris dan saya akan menjalankan kueri group by dengan
00:00:55postgres. Ini membutuhkan waktu sekitar 9,7 detik untuk dieksekusi karena kita mengagregasi pendapatan dari setiap
00:01:00baris tunggal. Jika kita menjalankan kueri yang sama pada set data yang sama menggunakan basis data kolom—dan itu
00:01:06menjalankan SQL yang persis sama, baik clickhouse maupun duckdb memiliki sintaks SQL yang mirip dengan postgres sehingga Anda akan
00:01:13merasa familier—clickhouse mencatat waktu 0,28 detik dan duckdb 0,24 detik. Itu lebih dari 40 kali lebih cepat!
00:01:22Bagaimana ini mungkin? Rasanya sulit dipercaya, bukan? 100 juta baris yang sama selesai hanya dalam 0,24 detik.
00:01:30Sementara itu, basis data kolom melakukan pekerjaan yang jauh lebih sedikit untuk memberikan hasil yang sama.
00:01:36Mari kita lihat kueri lainnya beraksi. Dan catatan singkat teman-teman, kami merilis konten tentang AI dan teknologi secara terus-menerus,
00:01:42jadi jika Anda menyukai ini, mengapa tidak berlangganan Better Stack? Kali ini kita menghitung jumlah
00:01:47kejadian antara dua waktu dengan kode negara gb. Dalam kasus ini, kita melihat data pada
00:01:53bulan Maret. Hasilnya: postgres 5,9 detik, clickhouse 0,06 detik, dan duckdb 0,03 detik. Bulan Maret berisi
00:02:02sekitar 13 persen dari total kejadian di sini, jadi postgres masih harus memeriksa jutaan baris. Kita bisa
00:02:09menambahkan pengindeksan agresif di sini untuk membantu, tetapi itu tidak akan mendekati kecepatan clickhouse dan duckdb. Jadi mengapa
00:02:15penyimpanan kolom jauh lebih cepat di sini? Nah, clickhouse tidak mengindeks baris individual sama sekali. Saat Anda membuat
00:02:20tabel, Anda memberikan kunci urut (sort key), dan data diurutkan berdasarkan waktu (timestamp), lalu membagi data yang diurutkan menjadi blok-blok
00:02:32dan mencatat stempel waktu pertama di setiap blok. Untuk 100 juta baris, itu sekitar 12.000 catatan,
00:02:39dan jumlah itu cukup kecil untuk dimuat di memori. Jadi ketika kita meminta bulan Maret, sistem melakukan pencarian cepat melalui catatan tersebut,
00:02:44menemukan blok yang mungkin berisi bulan Maret, dan hanya membaca blok-blok itu saja. Dalam kasus kita, itu adalah 1.633 blok dari
00:02:52total 12.208 blok, dan semua data lainnya di diska dilewati. Duckdb melakukan hal serupa karena menyimpan nilai minimum
00:03:00dan maksimum untuk setiap potongan kolom, sehingga kita dapat melihat suatu potongan, melihat stempel waktu dari Januari sampai
00:03:06Februari, dan melewati seluruh bagian tersebut tanpa membacanya. Ditambah trik sebelumnya di mana sistem hanya
00:03:10membuka kolom yang dibutuhkannya, Anda pun mendapatkan waktu 0,03 detik. Namun, keadaan berbalik 180 derajat ketika Anda ingin
00:03:17memilih satu baris berdasarkan id. Kueri sederhana ini mengungkap banyak hal: postgres membutuhkan 2 milidetik, clickhouse 168
00:03:26milidetik, dan duckdb—menariknya—tetap di angka 2 milidetik. Postgres memiliki indeks pohon biner pada
00:03:32id, sehingga ia menelusuri pohon tersebut, langsung menuju ke satu halaman yang memuat baris itu, dan selesai hanya dalam 2
00:03:37milidetik. Tetapi dengan clickhouse, kita memiliki masalah: satu-satunya indeks adalah kunci urut tersebut, dan tabel ini
00:03:43diurutkan berdasarkan stempel waktu terlebih dahulu dan id kedua. Jadi ketika kita meminta id tunggal, ia tidak tahu di blok mana id tersebut
00:03:51berada, dan akhirnya memeriksa setiap dari 12.208 blok. Dan begitu menemukan barisnya, ia masih
00:03:57harus membuka kedelapan berkas kolom dan menyatukan kembali baris tersebut, yang merupakan pekerjaan berat untuk kueri yang
00:04:03sederhana. Jadi, bagaimana duckdb bisa lolos dari masalah ini? Ia beruntung dengan data kita: id dimasukkan secara
00:04:09berurutan sehingga nilai minimum dan maksimum pada setiap potongan sejajar rapi dengan id, dan duckdb dapat melompat langsung ke
00:04:16bagian yang tepat. Jika id diacak, ia akan memindai seluruh kolom seperti halnya clickhouse. Sekarang mari kita lihat
00:04:21pembaruan baris. Kita memiliki satu kueri untuk postgres dan duckdb, serta versi yang sedikit berbeda untuk
00:04:26clickhouse. Postgres mencatat waktu 5 milidetik, clickhouse 5,8 detik, dan duckdb lagi-lagi hanya puluhan
00:04:34milidetik. Postgres hanya menulis ulang satu baris dan memperbarui satu entri indeks. Di clickhouse, berkas data
00:04:40bersifat tidak dapat diubah (immutable), tidak pernah diedit di tempat, sehingga untuk mengubah satu nilai pendapatan, ia harus menulis ulang
00:04:46seluruh berkas kolom pendapatan untuk potongan tabel tersebut. Clickhouse bahkan mengharuskan Anda menulis ini sebagai
00:04:51perintah alter table karena memperlakukannya sebagai mutasi seluruh tabel. Ada pembaruan yang lebih ringan dalam
00:04:56tahap beta, tetapi itu hanya dimaksudkan untuk jumlah baris yang kecil, sekitar 10% dari tabel paling banyak. Duckdb berada di antara
00:05:03keduanya karena berkasnya dapat diubah langsung di tempat (in-place), sehingga pembaruan satu baris selesai dalam beberapa puluh
00:05:08milidetik. Terakhir, mari kita hitung jumlah pengguna unik dalam tabel kita, dengan sedikit
00:05:14variasi kueri untuk clickhouse. Hasilnya adalah: postgres 38,4 detik, clickhouse 0,78 detik,
00:05:22dan duckdb di bawah satu detik. Sekali lagi, postgres menderita karena melakukan agregasi pada seluruh tabel sebesar ini,
00:05:28yang membutuhkan kerja yang sangat besar. Sekarang, Anda sering kali ingin menggunakan basis data kolom untuk hal-hal seperti analitik
00:05:34di mana mengagregasi data di berbagai kolom adalah tugas yang umum. Di sini kita melihat dua opsi: clickhouse
00:05:41adalah peladen terhos (hosted server) sumber terbuka dan tersedia di sebagian besar platform utama. Untuk menjalankan ini secara lokal, Anda harus menjalankan
00:05:47peladen clickhouse di mesin Anda, yang mirip dengan cara kerja postgres. Namun, duckdb lebih seperti sqlite;
00:05:54ia adalah pustaka yang berjalan di dalam prosesnya sendiri dan seluruh basis data berada dalam satu berkas tunggal di diska,
00:06:00sehingga berkas tersebut dapat dikunci saat satu pembaruan sedang berlangsung, yang mengurangi konkurensi. Keduanya adalah basis data kolom
00:06:06tetapi mengambil pendekatan yang sangat berbeda. Jadi basis data mana yang akhirnya Anda gunakan bergantung pada lebih banyak hal
00:06:12daripada yang bisa saya asumsikan di sini; ini bukan hanya tentang kecepatan kueri mentah saat menjalankan demo di mesin lokal Anda,
00:06:17tetapi tentang skalabilitas, redundansi, dan ekstensibilitas. Tentu saja, postgres memiliki ekosistem plugin yang kaya untuk
00:06:24memperluas rangkaian fiturnya dalam berbagai cara, yang bisa Anda lihat di video berikutnya.

Key Takeaway

Basis data kolom seperti clickhouse dan duckdb menawarkan kecepatan kueri analitik puluhan kali lebih cepat daripada postgres melalui penyimpanan berbasis kolom dan pemangkasan blok, tetapi memiliki kelemahan pada pembaruan data dan pencarian baris tunggal.

Highlights

  • Basis data kolom dapat menjalankan kueri tertentu hingga 40 kali lebih cepat daripada postgres pada dataset berukuran 100 juta baris.

  • Clickhouse mencatat waktu 0,28 detik dan duckdb mencatat waktu 0,24 detik untuk kueri group by yang membutuhkan waktu 9,7 detik di postgres.

  • Clickhouse tidak menggunakan indeks baris individual melainkan kunci urut berdasarkan stempel waktu yang membagi data menjadi blok-blok di memori.

  • Postgres menyelesaikan kueri pemilihan satu baris berdasarkan id dalam 2 milidetik, sementara clickhouse memerlukan 168 milidetik karena harus memindai seluruh blok.

  • Berkas data clickhouse bersifat tidak dapat diubah sehingga pembaruan satu nilai memerlukan penulisan ulang seluruh berkas kolom untuk potongan tabel tersebut.

Timeline

Perbandingan Kecepatan Kueri Dasar

  • Basis data kolom menyimpan kolom secara bersamaan untuk memberikan manfaat besar pada platform analitik.
  • Kueri group by pada 100 juta baris memerlukan waktu 9,7 detik menggunakan postgres.
  • Clickhouse menyelesaikan kueri yang sama dalam 0,28 detik dan duckdb dalam 0,24 detik.

Basis data kolom dirancang untuk menjalankan kueri tertentu jauh lebih cepat daripada basis data berbasis baris seperti postgres. Pengujian pada 100 juta baris menunjukkan perbedaan performa yang drastis ketika mengagregasi pendapatan dari setiap baris. Meskipun sintaks SQL yang digunakan serupa dan terasa familier, pendekatan penyimpanan data di baliknya menghasilkan efisiensi waktu eksekusi yang melampaui 40 kali lipat.

Mekanisme Penyimpanan Kolom yang Cepat

  • Clickhouse menyortir data berdasarkan stempel waktu dan membaginya ke dalam blok-blok kecil yang dimuat di memori.
  • Sistem hanya membaca blok yang relevan dan melewati data lainnya di diska.
  • Duckdb menyimpan nilai minimum dan maksimum untuk setiap potongan kolom untuk melewati data yang tidak diperlukan.

Penyimpanan kolom bekerja dengan melakukan jauh lebih sedikit pekerjaan untuk memberikan hasil yang sama pada kueri analitik. Clickhouse tidak mengindeks baris individual melainkan menggunakan kunci urut berdasarkan waktu untuk mencatat stempel waktu pertama di setiap blok. Pencarian data tertentu seperti bulan Maret hanya melibatkan sebagian kecil blok, sehingga sebagian besar data di diska diabaikan sepenuhnya.

Kelemahan pada Kueri Baris Tunggal dan Pembaruan

  • Postgres menyelesaikan pemilihan satu baris berdasarkan id dalam 2 milidetik berkat indeks pohon biner.
  • Clickhouse memerlukan 168 milidetik untuk pencarian id tunggal karena harus memeriksa ribuan blok.
  • Pembaruan data tunggal di clickhouse memerlukan penulisan ulang seluruh berkas kolom karena data bersifat tidak dapat diubah.

Keadaan berbalik ketika sistem harus memilih satu baris tunggal atau memperbarui data. Postgres unggul dalam pencarian baris tunggal menggunakan indeks pohon biner. Sebaliknya, basis data kolom mengalami kesulitan ketika mencari id tunggal karena struktur penyortirannya berbasis waktu. Selain itu, sifat berkas clickhouse yang tidak dapat diubah membuat proses pembaruan data memerlukan mutasi seluruh tabel atau berkas kolom.

Agregasi Unik dan Pemilihan Arsitektur

  • Penghitungan pengguna unik diselesaikan oleh postgres dalam 38,4 detik, sementara clickhouse dan duckdb di bawah satu detik.
  • Clickhouse beroperasi sebagai peladen terhos sumber terbuka, sedangkan duckdb berjalan sebagai pustaka dalam proses dengan satu berkas tunggal.
  • Pemilihan basis data bergantung pada skalabilitas, redundansi, dan ekstensibilitas, bukan sekadar kecepatan kueri mentah.

Agregasi skala besar seperti menghitung pengguna unik memperlihatkan keunggulan basis data kolom atas postgres. Dalam hal arsitektur, clickhouse dan duckdb menawarkan pendekatan yang berbeda di mana duckdb menyerupai sqlite dengan basis data dalam satu berkas tunggal. Pemilihan teknologi yang tepat harus mempertimbangkan kebutuhan sistem secara menyeluruh di luar pengujian kecepatan lokal.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video