Perf Saja Tidak Cukup

Budaya Obsesi terhadap Kinerja Database

• Industri database berfokus pada peningkatan kinerja, tetapi pengalaman pengguna yang sebenarnya sering kali dipengaruhi oleh faktor lain.
• Bagi pengguna yang mengolah data, hal yang benar-benar penting bisa jadi bukan optimasi kueri, melainkan format data atau kemampuan menyusun pertanyaan dalam SQL.
• Kinerja database memang penting, tetapi mungkin lebih baik memilih database berdasarkan faktor lain seperti kemudahan penggunaan, ekosistem, kecepatan pembaruan, dan integrasi dengan alur kerja.

Akhir dari Perang Benchmark

• Pada 2019, GigaOm menerbitkan benchmark yang membandingkan data warehouse cloud, tetapi hasil pasar nyata menunjukkan pola yang berbeda.
• Jika hasil benchmark tidak selaras dengan pengalaman pengguna, itu menunjukkan bahwa benchmark tersebut salah, menguji hal yang keliru, atau bahwa kinerja mungkin tidak sepenting itu.

Arti dari Cepat

• Di ranah database cloud, ada kecenderungan untuk berfokus pada waktu sejak pengguna mengklik tombol 'run' hingga hasil siap.
• Yang benar-benar berdampak bagi pengguna adalah waktu yang dibutuhkan untuk menyelesaikan pekerjaan, dan ini tidak sama dengan waktu yang dihabiskan server database.

Kinerja Itu Subjektif

• Kinerja harus diukur dari sudut pandang pengguna dan, sebagai masalah UX, tidak bisa dijelaskan dengan satu angka.
• Sifat subjektif dari kinerja berarti mana yang lebih cepat ditentukan oleh bagaimana database itu digunakan.

Kecepatan Perubahan

• DuckDB terus membaik dengan sangat cepat, sehingga benchmark saat ini menjadi kurang bermakna.
• Saat memilih database, bukan hanya kinerja saat ini yang penting, tetapi juga perubahan kinerja dan fitur di masa depan.

Tidak Ada Kacang Ajaib

• Jika semua database dipelihara secara aktif, kinerjanya pada akhirnya akan saling mendekat seiring waktu.
• Perbedaan kinerja yang besar kemungkinan tidak akan bertahan lama.

Masalahnya Ada di Antara Kursi dan Keyboard, serta Antara Keyboard dan Database

• Ukuran kinerja yang penting bagi pengguna adalah waktu yang dibutuhkan dari memiliki pertanyaan hingga memperoleh jawaban.
• Fitur yang penting bukanlah lamanya database mengeksekusi kueri, melainkan kecepatan berpindah dari ide ke jawaban.

Tentang Anggur yang Terasa Asam

• DuckDB saat ini berada di papan atas dalam benchmark ClickBench dan h20.ai, serta menunjukkan kinerja yang cukup baik di TPC-H dan TPC-DS.
• Sebelum menganggap sebuah database cepat, penting untuk mencobanya pada beban kerja nyata.

Kesimpulan

• Perusahaan database yang paling sukses bukan berhasil karena memiliki kinerja lebih cepat daripada pesaing.
• Database yang menjadikan kinerja sebagai nilai jual utama tidak berhasil di pasar.
• Saat memilih database, disarankan untuk mengambil keputusan berdasarkan faktor lain di luar kecepatan mentah.

Pendapat GN⁺

• Artikel ini menekankan bahwa yang penting bukan hanya berfokus pada kinerja database, tetapi juga mengoptimalkan pengalaman pengguna dan alur kerja. Ini memberi pelajaran penting bahkan bagi insinyur perangkat lunak pemula bahwa saat memilih database, pendekatan yang berpusat pada pengguna perlu dipertimbangkan di atas metrik kinerja semata.
• Kinerja database cenderung saling mendekat seiring waktu karena kemajuan teknologi menyebar ke berbagai platform. Ini menunjukkan bahwa dalam memilih teknologi, dukungan jangka panjang dan potensi peningkatan perlu dipertimbangkan lebih daripada kinerja jangka pendek.
• Proyek open source seperti DuckDB dapat berkembang pesat berkat laju perbaikan yang cepat dan dukungan komunitas. Ini berarti bahwa saat mengadopsi teknologi baru, aktivitas komunitas dan kecepatan perkembangan proyek juga perlu diperhatikan.
• Saat memilih database, penting untuk tidak hanya bergantung pada hasil benchmark kinerja, tetapi juga mengujinya pada beban kerja nyata. Ini dapat membantu memilih database yang lebih sesuai untuk kasus penggunaan sebenarnya.
• Ditekankan bahwa pemilihan teknologi database perlu mempertimbangkan bukan hanya aspek teknis, tetapi juga kebutuhan bisnis, kemudahan pemeliharaan, dan efisiensi pemrosesan data.

[GN⁺]

Komentar Hacker News

• Setelah beberapa tahun menerima banyak keluhan pelanggan, mereka menyadari bahwa bug pada driver JDBC menurunkan performa. Banyak waktu para engineer dihabiskan untuk mempercepat kueri, tetapi konektor yang digunakan sebagian besar pengguna justru menambahkan latensi yang jauh lebih besar daripada waktu yang berhasil dihemat. Lebih parah lagi, mereka sama sekali tidak menyadari hal ini. Karena tidak ada seorang pun di Google yang menggunakan driver JDBC secara internal, mereka tidak bisa melihat waktu kueri yang dialami pengguna, dan menganggapnya sebagai masalah orang lain.

  • Komentar ini menyatakan kekecewaan bahwa Google "benar-benar buta" terhadap keluhan pelanggan dan tidak menggunakan produknya sendiri. Bagian tentang JDBC sangat mengesankan.
• Google membangun database yang bekerja dengan baik secara internal, tetapi membuat lapisan adaptor untuk dunia luar lewat outsourcing, dan itu tidak bekerja dengan baik sehingga dunia luar akhirnya memakai database yang buruk. Inti canggih yang digunakan Google dikelilingi adaptor yang tidak sempurna, sehingga hasil akhirnya menjadi kacau secara tidak perlu. Secara internal mereka tidak menyadari hal ini, dan orang luar sulit mengetahuinya.
  • Komentar ini menilai bahwa hal tersebut sangat tepat menggambarkan strategi open source Google.
• Saya merasa aneh bahwa blog itu menyatakan "performa itu subjektif". Mengukur performa saja memang tidak cukup, tetapi dalam satu-satunya contoh yang diberikan, performa itu penting dan objektif. Hanya saja yang diukur adalah hal yang salah.
  • Komentar ini mempertanyakan klaim blog tersebut tentang pengukuran performa.
• Ini terdengar seperti masalah organisasi perusahaan. Jika tujuan akhirnya adalah membuat pelanggan memakai cloud dan memberikan nilai, maka metrik yang dipakai tidak boleh berbeda dari hal yang dianggap penting oleh pelanggan. Di dalam Google seharusnya ada orang yang aktif mendengarkan masalah pelanggan dan menyampaikannya kepada para engineer agar mereka tahu apa yang harus diperbaiki.
  • Komentar ini menekankan perlunya struktur organisasi agar Google memahami kebutuhan pelanggan dan memperbaikinya.
• Dari rumah di Seattle ke kantor San Francisco butuh sekitar 4,5 jam dari pintu ke pintu.
  • Komentar ini menyoroti bahwa para founder sudah tidak lagi bergerak cepat, sambil bercanda bahwa mungkin ini karena Federal Reserve menaikkan suku bunga.
• Saya tidak menganggap performa itu sekunder seperti yang dikatakan di sini. Setelah memastikan performanya cukup baik, barulah semua hal lain dievaluasi. Penulis sendiri menyebut bahwa "DuckDB itu cepat". Kalau tidak, mereka akan terpaksa ikut berlomba soal performa.
  • Komentar ini tidak setuju dengan anggapan bahwa performa bersifat sekunder, dan berargumen bahwa memastikan performa cukup baik harus menjadi prioritas.
• Performa itu bukan "subjektif", melainkan "relatif". Maknanya bergantung pada pekerjaan yang sedang dilakukan.
  • Komentar ini menjelaskan sifat relatif dari performa, dan membedakannya dari kesan performa yang terkait dengan desain antarmuka pengguna.
• Aplikasi web populer pertama menyimpan seluruh state dalam Python dict dan melakukan dump ke disk setiap beberapa menit. API-nya sangat cepat, tetapi setelah dipindahkan ke MongoDB, performanya tidak pernah pulih. Meski begitu, saat membuat situs web hari ini, saya tidak akan memilih "pickledb".
  • Komentar ini membagikan pengalaman tentang performa aplikasi web awal dan penurunan performa setelah berpindah database.
• Saya ingin membangun sistem database sendiri dan membandingkan performanya dengan database populer lain (Postgres, Sqlite, MySQL, SQL Server).
  • Komentar ini menjelaskan bahwa mereka tidak akan puas sampai database mereka lebih cepat di berbagai kueri, diukur sampai waktu sejak pengguna menekan tombol 'run' hingga hasil muncul di layar.
• "Tentu saja, ada pengecualian untuk aturan ini, yaitu ketika perbedaan arsitektur sulit diatasi. Database shared nothing berada pada posisi yang kurang menguntungkan dibanding shared disk, dan Redshift membutuhkan waktu bertahun-tahun untuk sebagian besar beralih ke arsitektur shared disk. Lakehouse yang menyimpan metadata secara persisten di object storage akan kesulitan melakukan update cepat; ini melekat pada modelnya."
  • Komentar ini menunjukkan masalah yang berkaitan dengan perbedaan arsitektur database, dan menyebut bahwa mereka sedang mencari literatur yang bagus tentang topik ini.