Anda Mungkin Tidak Membutuhkan Redis

• Redis adalah salah satu teknologi dengan reputasi paling positif di industri teknologi
  • Ini adalah teknologi luar biasa yang dirancang dengan sangat baik dan tidak cacat pada dirinya sendiri, tetapi mungkin tidak selalu diperlukan
• Selama 10+ tahun di 3 perusahaan, penulis melihat pola yang sama:
  • Muncul masalah dan Redis tampak cocok, tetapi pada kenyataannya tidak memperbaiki situasi atau tidak menyelesaikan masalah mendasar
  • Itu hanya menambah kompleksitas demi kompleksitas

Kasus pertama: pengalaman di Tantan

• Tantan adalah aplikasi kencan terbesar kedua di Tiongkok dan mengoperasikan 50~100 server database berkinerja tinggi berbasis PostgreSQL
• Setiap server di-shard berdasarkan ID pengguna sehingga data pengguna tertentu hanya disimpan di satu server
• Situasi masalah
  • Muncul kebutuhan untuk menyimpan jumlah swipe dan memperbaruinya dengan cepat
  • Pada awalnya diputuskan bahwa menyimpannya di Redis adalah pendekatan yang tepat
  • Diperkirakan beberapa server Redis berkinerja tinggi saja sudah cukup, lalu konfigurasi pun disiapkan
• Peninjauan ulang dan solusi
  • Di dalam tim, dibahas opsi untuk menyimpan langsung ke PostgreSQL alih-alih Redis
  • Karena beban server PostgreSQL sudah tinggi, beban tambahan diperkirakan hanya kecil
  • Setelah disimpan di PostgreSQL, tidak ada penurunan performa, dan penerapan Redis ternyata tidak diperlukan

Kasus kedua: pengalaman di Bannerflow

• Latar belakang
  • Bannerflow adalah platform pembuatan dan publikasi iklan
  • Diputuskan untuk memperkenalkan Redis di microservice baru guna mendukung publikasi iklan ke jejaring sosial seperti Facebook
• Situasi masalah
  • Dalam kondisi beban yang jauh lebih rendah dibanding Tantan, tidak jelas apakah Redis benar-benar perlu diperkenalkan
  • Setelah pengembang awal pergi, tidak ada orang yang bisa menjelaskan dengan jelas alasan penerapan Redis
• Hasil
  • Redis sebenarnya tidak diperlukan karena bebannya rendah
  • Dalam jangka panjang, disimpulkan bahwa menghapus Redis adalah pilihan terbaik

Kasus ketiga: pengalaman di MAJORITY

• Latar belakang
  • MAJORITY adalah perusahaan fintech yang memperkenalkan Redis untuk melakukan caching hasil pemanggilan API eksternal
  • Redis diperkenalkan untuk meng-cache data pencarian lokasi agar mempercepat pemrosesan dan mengurangi biaya
• Situasi masalah
  • Data yang sama juga disimpan di DB (Azure SQL)
  • Diperkirakan hampir tidak ada peningkatan beban meskipun pemanggilan Redis diganti dengan pemanggilan DB
  • Redis sempat ingin terus digunakan karena diperlukan penanganan lock, tetapi Azure SQL ternyata sudah cukup mampu menanganinya
• Hasil
  • Disimpulkan bahwa penerapan Redis tidak diperlukan
  • Disusun rencana untuk beralih menggunakan Azure SQL alih-alih Redis

Kesimpulan

• Ketiga kasus ini terjadi di domain, tech stack, dan kondisi beban yang semuanya berbeda
• Kesamaannya adalah penerapan Redis yang tidak perlu
• Sebelum memperkenalkan Redis, kebutuhan nyata dan keuntungan performanya harus dipertimbangkan dengan matang
• Rekomendasi ceramah Dan McKinley, 'Choose Boring Technology'

[iolothebard]

Terlepas dari apakah memakai Redis atau tidak, menyisipkan lapisan cache antara domain dan persistence—dengan implementasi default bypass—sama sekali bukan overengineering. Untuk logging, data palsu, debugging, profiling, mungkin bahkan caching sungguhan…

[nodelay]

+1 Saya juga setuju. Hanya dengan menambahkan satu layer saja, sudah muncul ruang gerak, dan itu memberi kita ruang untuk menyelesaikan begitu banyak hal.

[galadbran]

Daripada ada masalah dengan Redis itu sendiri, sudut pandangnya tampaknya lebih ke: kalau database saja sudah cukup, mengapa harus menambahkan komponen lain dan meningkatkan beban pengelolaan? Penjelasannya juga cenderung cukup ringkas, jadi sebaiknya diterima sebatas sebagai pengingat bahwa sudut pandang seperti ini juga perlu dipertimbangkan. Ada juga situasi di mana memperkenalkan cache Redis sambil menjaga logika aplikasi tetap sederhana bisa menjadi pilihan yang lebih baik, jadi pada akhirnya harus dipilih sesuai konteks.

[zinisuni]

Judulnya benar-benar bikin terpancing, ya. Hehe, saya setuju~~

[GN⁺]

Opini Hacker News

• Saat bekerja di Uber pada 2015, ada upaya untuk mengalihkan pembagian geografis berbasis kode pos ke pendekatan berbasis heksagon

  • Alih-alih membagi kota menjadi puluhan kode pos, kota dibagi menjadi ratusan ribu heksagon dan wilayah dibuat secara dinamis
  • Peluncuran pertama dilakukan di Phoenix, dan tim begadang untuk memperluas sistem surge pricing
  • Peluncuran global tertunda
  • Ada banyak engineer yang menyukai Redis
  • Layanan penetapan harga berbasis Redis dan menangani jutaan permintaan
  • Biayanya mahal dan ada juga masalah skalabilitas
  • Dengan memperbaiki algoritme, perhitungan wilayah dinamis untuk beberapa kota bisa dilakukan pada satu mesin
  • Seorang engineer bernama Isaac mengimplementasikan dan menerapkannya selama akhir pekan

• Ada perdebatan tentang penggunaan Redis yang berlebihan

  • Redis memang keren, tetapi penggunaannya menimbulkan latensi jaringan dan overhead serialisasi
  • Jika data sudah terpartisi, hash map biasa mungkin lebih baik
  • Di Java ada ConcurrentHashMap, Guava Caches, dan Caffeine Caches
  • Implementasi caching lokal hampir selalu lebih cepat daripada menggunakan jaringan
  • Redis cenderung digunakan secara berlebihan

• Budaya penggunaan Redis belum berkembang sebanding dengan popularitasnya

  • Redis mendukung berbagai struktur data, dan seiring budaya perusahaan berkembang, lebih banyak pola bisa dipelajari
  • Sangat disayangkan tidak ada kumpulan pola Redis

• Ini bukan soal Redis versus non-Redis, melainkan soal bekerja dengan data yang tidak mudah diserialisasi

  • Counter, news feed, chat message, dan sejenisnya mungkin lebih efisien dengan Redis
  • Dalam kebanyakan kasus, MySQL juga sudah cukup memadai

• Pengembangan perangkat lunak sering kali cenderung mengulang cara yang dilakukan orang lain

  • Berawal dari Memcached lalu berkembang ke Redis
  • Ada kecenderungan memakai cache untuk menghindari kompleksitas database
  • Database tetap kompleks dan sulit

• Redis adalah satu-satunya "server struktur data" yang siap produksi

  • Berguna ketika layanan yang sama diakses dari beberapa instance

• Mungkin Anda tidak memerlukan cache

  • Ada pengalaman berfokus pada perbaikan arsitektur tanpa memperkenalkan cache

• API Redis sangat bagus, tetapi ada risiko operasional

  • Bagus sebagai cache, tetapi tidak dapat sepenuhnya diandalkan sebagai penyimpanan data produksi

• Cukup mengejutkan ada kecenderungan untuk tidak merekomendasikan penggunaan Redis

  • Redis tetap menawarkan struktur data dan performa yang sangat baik

• Redis tidak masalah untuk cache sementara, tetapi kurang memadai untuk transaksi atau penyimpanan terdistribusi

  • Perlu mempelajari masalah distributed locking