Performa Saja Tidak Cukup

• Jika dalam memilih database hanya melihat kecepatan kueri mentah dan benchmark umum, kita mudah melewatkan total waktu yang dibutuhkan pengguna untuk sampai dari pertanyaan ke jawaban
• Benchmark GigaOm 2019 menempatkan Azure Data Warehouse dan Redshift di depan, tetapi di pasar nyata Snowflake dan BigQuery terjual lebih baik, menunjukkan kuatnya faktor selain performa
• Meski waktu eksekusi server dipangkas, jalur di sekitarnya seperti driver JDBC, pengunduhan hasil, parsing CSV, dan tingkat kesulitan menulis SQL bisa menjadi bottleneck yang lebih besar
• ClickBench, TPC-H, dan TPC-DS berguna, tetapi kesimpulannya berubah tergantung ada tidaknya JOIN, pemindaian satu tabel, tuning skema, serta syarat akurasi dan jaminan ACID
• Performa engine database akan cenderung konvergen seiring waktu, sehingga kriteria pilihan jangka panjang seharusnya bukan peringkat saat ini, melainkan kecepatan dari ide ke jawaban dan integrasi workflow

---

Latensi Nyata yang Terlewat oleh Benchmark

• Dalam perjalanan 4,5 jam dari rumah di Seattle ke kantor di San Francisco, sekalipun kecepatan jelajah pesawat dinaikkan 10 kali lipat, total waktu mungkin hanya berkurang sekitar 20% karena perjalanan ke bandara, pemeriksaan keamanan, boarding, menunggu di landasan, bagasi, dan perjalanan di tujuan
• Database juga serupa
  • Meski engine menjadi lebih cepat, pengguna tetap menghadapi file CSV yang aneh, kesulitan mengekspresikan pertanyaan dalam SQL, dan masalah koneksi tool
  • Produk yang menang dalam perang benchmark mudah dipromosikan, tetapi itu tidak berarti waktu pengguna untuk menyelesaikan masalah otomatis berkurang
• Dalam memilih database, kemudahan penggunaan, ekosistem, kecepatan pembaruan, dan integrasi workflow bisa menjadi kriteria penilaian yang lebih baik
• Performa hanya menunjukkan waktu tugas tertentu pada momen tertentu, dan bisa membuat kita giat mengoptimalkan bottleneck yang salah

Hasil GigaOm 2019 dan Ketidaksesuaian dengan Pasar

• Pada 2019, GigaOm menjalankan benchmark TPC-H dan TPC-DS untuk cloud data warehouse
  • Sasarannya adalah tiga vendor cloud besar dan Snowflake
  • Hasilnya, Azure Data Warehouse paling cepat, disusul Redshift, sementara Snowflake dan BigQuery tertinggal jauh
• Saat itu, dalam evaluasi pengguna BigQuery, banyak pelanggan yang membandingkannya langsung dengan Azure justru memilih BigQuery
• Hasil pasar hampir berkebalikan dengan peringkat benchmark
  • Snowflake dan BigQuery terjual lebih banyak daripada Redshift
  • Redshift terjual lebih baik daripada Azure
• TPC-H dan TPC-DS adalah standar industri dan juga digunakan untuk menilai performa internal, tetapi jika pelanggan lebih banyak membeli sistem yang mendapat peringkat rendah dalam benchmark performa yang baik, berarti ada faktor yang lebih penting daripada performa

Kecepatan yang Dirasakan Pengguna Bukanlah Waktu Server

• Orang-orang yang membuat database cenderung berfokus pada waktu eksekusi server sejak pengguna menekan tombol “run” hingga hasil siap
• Waktu yang penting bagi pengguna adalah total waktu untuk menyelesaikan pekerjaan, dan itu berbeda dari waktu database server menjalankan kueri
• Kasus driver JDBC BigQuery menunjukkan perbedaan ini dengan baik
  • Driver JDBC adalah antarmuka umum yang digunakan programmer dan tool BI untuk terhubung ke database
  • Kueri BigQuery berjalan hanya dalam 1–2 detik, tetapi karena cara driver melakukan polling penyelesaian dan mengunduh hasil, bagi pengguna kueri terlihat beberapa detik atau beberapa menit lebih lambat
  • Saat hasilnya banyak, driver mengambil semua data per halaman, termasuk data yang tidak dibutuhkan pengguna, sehingga latensi membesar dan kadang crash karena kehabisan memori
• Para engineer menghabiskan banyak waktu untuk memangkas waktu kueri beberapa per sekian detik, tetapi konektor yang banyak dipakai pengguna nyata justru menciptakan latensi yang lebih besar
• Benchmark internal berjalan setiap hari, tetapi performa end-to-end dan waktu yang dirasakan pengguna tidak terlihat

Performa Tidak Tetap sebagai Satu Angka

• Performa harus diukur dari sudut pandang pengguna, bukan sudut pandang database, dan seperti UX, sulit dijelaskan sepenuhnya dengan satu angka
• Database mana yang lebih cepat bergantung pada workload nyata
  • Meski Lamborghini lebih cepat daripada Prius, di tengah kemacetan waktu berangkat kerja bisa saja tidak berbeda
  • Perbedaan performa ClickHouse dan Redshift juga bergantung pada cara penggunaannya
• ClickBench dari ClickHouse menunjukkan hasil bahwa ClickHouse lebih cepat daripada berbagai database
  • Benchmark tersebut berjalan pada satu tabel tanpa JOIN, dan sangat bergantung pada distinct count
  • Ini bisa menjadi proxy metric yang baik untuk analisis log atau perhitungan pengguna unik situs web
  • Namun bisa menimbulkan kesalahpahaman untuk workload star schema pada data warehouse tradisional
• Benchmark vendor biasanya berfokus pada bagian yang menjadi keunggulan vendor tersebut
• BigQuery mungkin terlihat rendah dalam benchmark, tetapi karena hampir tidak memiliki knob dan umumnya melakukan tuning sendiri, pengalaman pengguna nyata bisa terasa baik
• Instance SingleStore yang sangat di-tuning dapat mengungguli BigQuery dalam banyak pekerjaan, tetapi membutuhkan waktu tuning skema dan respons saat workload baru ditambahkan
• Demi meningkatkan performa, pengaman atau akurasi juga bisa dikurangi
  • menghapus overflow check
  • melewatkan write flush
  • memberikan hasil aproksimasi untuk sebagian operasi
  • tidak menyediakan jaminan ACID
• Jalan pintas seperti ini bisa menjadi opsi yang tidak ingin digunakan kecuali dalam lingkungan terkendali

Kecepatan Peningkatan Lebih Bertahan Lama daripada Peringkat Saat Ini

• Saat membangun perusahaan berbasis DuckDB, ada yang menunjukkan bahwa DuckDB tertinggal jauh dalam benchmark h2o.ai
• Ada dua alasan mengapa itu tidak dikhawatirkan
  • Performa adalah faktor sekunder
  • DuckDB sedang membaik dengan sangat cepat
• Peningkatan cepat DuckDB dipengaruhi oleh sejumlah keputusan arsitektur, codebase yang relatif baru dan bersih, serta engineer yang hebat
• Dalam hasil publik untuk rilis DuckDB terbaru pada benchmark yang sama, DuckDB bergerak dari papan tengah ke jajaran terdepan dengan selisih besar
• Memilih database adalah keputusan yang berlangsung bertahun-tahun, sehingga yang penting bukan hanya performa dan fitur saat ini, tetapi juga kemampuan yang mungkin ada satu tahun lagi
• Jika dua database membaik dengan kecepatan berbeda, kemungkinan lebih baik memilih yang bergerak lebih cepat

Kesenjangan Performa Menyempit Seiring Waktu

• Jika beberapa database yang aktif dipelihara terus ditingkatkan selama beberapa tahun, performanya cenderung konvergen
• Teknik performa dari satu produk dapat diimplementasikan juga di produk lain seiring waktu
  • Jika ClickHouse menggunakan teknik yang unggul dalam kecepatan scan, Snowflake bisa memiliki fitur serupa dalam 1–2 tahun
  • Jika Snowflake menambahkan incremental materialized view, BigQuery juga bisa segera menyusul
• Setiap database memiliki teknik berbeda untuk menghasilkan performa
  • mengompilasi kueri menjadi machine code
  • melakukan caching data di SSD lokal
  • memproses shuffle dengan hardware jaringan khusus
• Teknik yang efektif dapat diimplementasikan siapa pun jika diberi waktu, dan jika bekerja dengan baik, kemungkinan akan menyebar ke banyak sistem
• Dalam perbandingan performa data warehouse oleh CEO Fivetran George Fraser, pada 2020 waktu tercepat adalah 8 detik dan terlambat 18 detik, tetapi pada 2022 tiga vendor mendekati sekitar 7 detik, sementara vendor paling lambat 9 detik
• Namun, perbedaan arsitektur sulit diatasi
  • database shared nothing bisa kurang menguntungkan dibanding shared disk
  • Redshift memerlukan beberapa tahun untuk beralih terutama ke arsitektur shared disk
  • lakehouse yang menyimpan metadata di object store bisa mengalami kesulitan pada pembaruan cepat
• Perbedaan seperti ini terutama muncul pada kondisi batas, dan dalam jangka panjang tidak ada alasan mendasar mengapa Redshift harus lebih cepat atau lebih lambat daripada Snowflake

Fitur yang Mengurangi Waktu dari Pertanyaan ke Jawaban

• Performa yang penting bagi pengguna adalah waktu sejak pertanyaan muncul hingga jawaban didapat
• Cara mengurangi waktu ini bukan hanya memperbaiki query plan
  • bisa membuat pertanyaan lebih mudah diekspresikan
  • bisa mengubah hasil kueri agar lebih mudah dipahami
  • bisa memberi feedback saat pengguna mengajukan pertanyaan yang salah
  • bisa membantu memahami masalah data
  • bisa membuat data yang dibutuhkan siap di lokasi dan bentuk yang tepat
• Snowflake memiliki kekuatan dalam membuat SQL yang diketik pengguna “langsung jalan”
  • Saat menghitung selisih tanggal, DATEDIFF dan TIMEDIFF sama-sama bisa digunakan
  • Jika tipenya masuk akal, keduanya berfungsi
  • Granularity bisa ditentukan atau dihilangkan
  • Granularity boleh ditulis dengan tanda kutip maupun tanpa tanda kutip
• DuckDB juga menambahkan fitur yang memudahkan penulisan dan pemeliharaan kueri melalui Friendlier SQL
  • GROUP BY ALL mengurangi kelupaan field pada klausa GROUP BY dalam kueri agregasi
  • Karena cukup mengubah daftar SELECT, saat kueri berevolusi tidak perlu mengubah banyak lokasi
  • Setelah fitur ini terbukti berguna, beberapa vendor database menambahkan fitur serupa
• File CSV adalah format yang memuat banyak data dunia, tetapi banyak file tersusun buruk dan parsing-nya sebenarnya sulit
  • CSV splitter awal BigQuery tidak bisa melakukan inference, dan kebingungan saat skema sedikit berbeda antarfile
  • Parsing CSV adalah masalah yang lebih rumit daripada kelihatannya
• Jika dua engineer harus membaca data CSV dan menghitung hasil yang sama, pihak yang lebih mudah melakukan ingest CSV dengan benar bisa mendapatkan jawaban lebih dulu, terlepas dari kecepatan engine kueri
• Cara pemrosesan hasil juga sangat memengaruhi pengalaman pengguna
  • Jika SELECT * mengembalikan halaman pertama dan cursor seperti MySQL, hasil bisa langsung terlihat
  • Jika harus membuat salinan tabel di sisi server seperti BigQuery, pada tabel besar bisa memakan waktu berjam-jam
  • Jika klien mencoba mengunduh semua data, bisa terjadi kehabisan memori
  • Koneksi panjang rentan terhadap masalah jaringan, dan polling bisa tampak lebih lambat ketika kueri selesai di antara interval polling

Petunjuk Saat Melihat Benchmark DuckDB

• DuckDB cepat, dan berada di papan atas pada ClickBench untuk beberapa machine size
  • Sebagai contoh, hasil c6a.4xlarge disajikan
• DuckDB juga menunjukkan performa baik di sebagian besar benchmark h2o.ai, dan juga tidak buruk pada TPC-H serta TPC-DS
• Sebelum mengasumsikan database mana pun cepat, Anda harus mengujinya langsung pada workload sendiri

Penyelesaian Masalah yang Cepat Lebih Penting daripada Kueri yang Cepat

• Perusahaan database paling sukses tidak berhasil hanya karena lebih cepat daripada pesaing
• Redshift sempat kuat untuk beberapa waktu, tetapi alasan Snowflake bisa masuk bukanlah performa benchmark, melainkan kemudahan pemeliharaan
• Database yang menjadikan performa sebagai nilai jual utama tidak meraih hasil baik di pasar, sementara database yang membantu pengguna menyelesaikan pekerjaan dengan mudah lebih mampu bertahan
• Sumbu yang harus dilihat saat memilih database lebih luas
  • Tidak ada teknik rahasia yang ajaib, dan kecuali perbedaan arsitektur, performa akan konvergen seiring waktu
  • Kecepatan peningkatan engine database sangat berbeda, dan pihak yang bergerak cepat lebih unggul dalam jangka panjang
  • Vendor database yang paling terobsesi pada performa bisa menjadi lambat dalam jangka panjang
  • Performa database tidak memiliki satu metrik tunggal, dan database yang cepat pun bisa buruk untuk workload tertentu
  • Fitur yang penting bukan seberapa cepat dari kueri ke hasil, melainkan seberapa cepat dari ide ke jawaban
• Kueri yang cepat lebih baik daripada kueri yang lambat, tetapi pilihan database harus didasarkan pada faktor selain kecepatan mentah

[GN⁺]

Komentar Hacker News

• Bagian yang membuat frustrasi adalah mereka “sama sekali tidak tahu” bahwa masalah driver JDBC merusak performa, padahal selama bertahun-tahun ada banyak keluhan pelanggan
  Artinya, di internal Google mereka bahkan tidak memakai produk sendiri seperti pelanggan sungguhan, dan karena waktu kueri yang dilihat pengguna tidak terlihat secara internal, masalah itu diperlakukan sebagai masalah orang lain

  • Pelajaran yang diambil di sini juga terasa agak meleset. Bukan “performa saja tidak cukup”, melainkan performa pada jalur yang benar-benar dipakai pelanggan lebih penting daripada benchmark komponen individual
    Masalahnya bukan karena terlalu banyak upaya dihabiskan untuk optimasi, melainkan karena mereka tidak mulai dari rasa sakit pelanggan lalu menelusuri sampai akar penyebabnya. Penyebab sebenarnya pada akhirnya juga masalah performa

• Cerita JDBC ini benar-benar bagus. Google membuat database yang berjalan baik secara internal, lalu lapisan adaptor untuk dunia luar dibuat lewat subkontrak, tetapi lapisan itu tidak bekerja dengan semestinya sehingga pengguna eksternal berakhir memakai database yang buruk
  Seolah-olah inti canggih yang dipakai Google dibungkus dengan kemasan yang rusak, membuat seluruh produk jadi kacau tanpa perlu; tidak ada orang internal yang menyadarinya, dan pengguna eksternal pun sulit menemukan penyebabnya. Ini tampak seperti contoh yang sangat akurat tentang strategi open source Google

  • Dari sudut pandang manajemen, ini bisa dipahami. Polanya seperti, “kita merekrut talenta ilmu komputer terbaik, jadi biarkan mereka memecahkan masalah inti ilmu komputer; driver JDBC bukan kompetensi inti, jadi kita outsourcing saja”
    Masalahnya, jika area non-inti dirusak cukup parah, kompetensi inti yang hebat pun jadi tidak berguna. Outsourcing bukan makan siang gratis
  • Wrapper Python untuk API Google semuanya seperti cerita ini
  • Ini karena kurangnya integrasi vertikal. Alasan Apple menang dalam banyak hal adalah karena mereka sangat baik dalam integrasi vertikal
  • Kontrak bisnis seperti Workspace juga persis memakai struktur ini. Di atas produk inti yang hebat, ditempelkan kontrak “dukungan” yang bukan hanya tidak berguna tetapi berbahaya, dengan perusahaan konsultan kelas terburuk di dunia mengambil sekitar 15%

• Tulisan itu mengatakan “performa itu subjektif” dan pengukuran sederhana saja tidak cukup, tetapi contoh-contohnya justru menunjukkan kasus ketika performa benar-benar penting dan objektif. Mereka hanya mengukur sasaran yang salah

  • Sejak paragraf pertama, tulisannya dimulai dengan contoh yang tepat sekali untuk Hukum Amdahl, jadi mengejutkan bahwa itu tidak pernah disebut sama sekali

• Ini terdengar seperti masalah organisasi perusahaan. Jika tujuan akhirnya adalah membuat orang menggunakan cloud dan memberikan nilai, saya tidak mengerti mengapa mereka punya metrik yang tidak selaras dengan hal-hal yang dianggap penting oleh pelanggan
  Di dalam Google seharusnya ada orang yang berbicara langsung dengan pelanggan, memahami apa masalahnya, lalu menyampaikannya kepada engineer agar mereka tahu apa yang perlu diperbaiki. Organisasi harus dirancang agar engineer menerima metrik yang mereka butuhkan, atau agar pembuatan metrik tersebut sendiri menjadi bagian dari pekerjaan

  • “Ketika anekdot dan metrik saling bertentangan, biasanya anekdotlah yang benar” — Jeff Bezos. Sayangnya, kadang-kadang ia memang mengatakan hal yang bagus
  • Google tampaknya agak alergi terhadap berbicara langsung dengan pelanggan
  • https://en.wikipedia.org/wiki/Seeing_Like_a_State
  • Jika solusi kita tidak memecahkan masalah pelanggan, maka pelanggan membutuhkan masalah lain atau kita membutuhkan pelanggan lain
  • Sangat setuju. Ini tampak seperti masalah memilih metrik yang salah untuk dijadikan target. Namun ini melampaui sekadar tim engineering yang mengukur bagian latensi yang terlalu sempit
    Saya lebih penasaran metrik apa yang dilihat oleh produk dan pimpinan organisasi sampai-sampai mereka melewatkan umpan balik pelanggan seperti ini

• Bagian “4,5 jam dari pintu rumah di Seattle ke pintu kantor di San Francisco” membuat saya berpikir bahwa para founder sekarang tampaknya tidak lagi bergerak dengan kecepatan 179 mil per jam. Rupanya begitulah jadinya kalau The Fed menaikkan suku bunga

  • Saat pertama membaca, saya kira maksudnya menyetir, tetapi kemungkinan itu waktu yang mencakup pesawat + perjalanan ke/dari bandara + pemeriksaan keamanan
  • Saat ini saya benar-benar sedang dalam perjalanan dari rumah di Seattle ke kantor SF. Saya berangkat 48 menit lalu, jadi setelah sampai saya akan memperbarui dan menambahkan satu data point langsung di sini

• Ada beberapa poin yang jelas bagus, tetapi kesimpulannya terasa agak meleset. Performa di sini bukan sekadar hal sekunder seperti yang dikatakan, melainkan lebih dekat ke soal cukup atau tidak
  Setelah lolos dari pertanyaan apakah sudah cukup cepat, barulah faktor lain bisa dinilai. Sebelum itu, ia bahkan belum bisa duduk di meja persaingan. Penulis juga mengatakan “DuckDB itu cepat”, dan jika tidak cepat, setidaknya sampai kotak centang itu terpenuhi, ia harus bersaing lewat performa
  Selain itu, pernyataan “mesin database yang bergerak paling cepat pada akhirnya akan menang” mungkin ada benarnya sampai batas tertentu, tetapi tidak praktis. Saat masih menjadi pemain baru, kemajuannya cepat, tetapi setelah mencapai posisi seperti Snowflake, kecepatannya pasti melambat. Dari sudut pandang memilih sistem hari ini, kita tidak bisa begitu saja mengekstrapolasi akselerasi saat ini ke masa depan
  Meski begitu, sudut pandang “bukan dari kueri ke hasil, melainkan dari ide ke jawaban, seberapa cepat perjalanannya” tampak layak ditelusuri lebih dalam secara terpisah

• Performa bukan “subjektif”, melainkan relatif. Maknanya terkait dengan pekerjaan yang sedang dihadapi
  Namun jika yang dimaksud adalah antarmuka pengguna yang membuat pengguna merasa lebih cepat, seperti progress bar yang bergerak cepat, itu cerita lain. Itu masalah antarmuka, bukan masalah database

  • “Subjektif” adalah istilah yang tepat. Pekerjaan mana yang relevan bergantung pada subjeknya
    Untuk menyebutnya “relatif”, seharusnya tidak ada cara memberi angka pada performa selain membandingkan antar-sistem, tetapi itu tidak benar

• Web app pertama yang populer menyimpan semua state dalam Python dict dan men-dump-nya ke disk setiap beberapa menit. Itu API tercepat yang pernah saya lihat seumur hidup
  Setelah pindah ke Mongo, performanya tidak pernah pulih lagi. Meski begitu, ketika membuat situs web sekarang saya tidak akan mengambil “pickledb”

  • Sebagai pengganti fopen, SQLite adalah titik tengahnya
  • Saya rasa lebih banyak orang boleh mempertimbangkan arsitektur resident di memori + snapshot sejak awal, bukan struktur database transaksional
    Ini kurang cocok untuk interaksi pengguna model request/response, tetapi untuk data statis besar atau data streaming yang dapat diputar ulang dan diproses secara inkremental atau batch, menurut saya seharusnya lebih umum daripada sekarang

• Saya sedang mencari materi bagus tentang topik “database shared-nothing memiliki kelemahan dibanding shared-disk, dan Redshift butuh bertahun-tahun untuk beralih terutama ke arsitektur shared-disk. Lakehouse yang menyimpan metadata di object storage sulit melakukan update cepat”

• Tulisan yang bagus. Saya pikir ini juga salah satu alasan pandas begitu kuat selama 10 tahun terakhir
  Performa single-machine-nya sudah cukup baik, dan bisa membaca 99% CSV yang diketahui umat manusia