Nice article.
Pahlevi Fikri Auliya
11

Thanks responnya Mas Levi,

Beberapa pendekatan yang aku tau:

  • Faktor teknologi, ada “abstraksi” lain yang mempermudah atau enggak. Misal Cassandra ada secondary index, HBase bisa pake Phoenix, dll. Tapi dalam hal ini efek sampingnya biasanya sama, storage membengkak (tergantung teknologi yg dipakai sih).
  • Pre computed, ada kalanya raw data itu bisa dibuat “sederhana”, jadi kita bisa menyimpan data se-general dan se-atomic mungkin, misal, “transaction”, isinya summary transaksi, semacam highest, mean, median, lowest, average, users, dll. User bisa disimpan transaksi yg udah well cooked dalam sehari, jadi misal tabel utamanya bener2 “raw transaction”, tabel user ini gak usah nyimpan semua record, summary-nya aja. Dari data general yg bersifat atomic ini query dilakukan. Jadi kita punya 2 tabel, tapi gak mentah dua2nya, yang satu sudah pre-computed, ini bisa merampingkan konsumsi A LOT.
  • Secondary tabel cuman nyimpen referensi, ini tetep duplikasi, tapi yg duplikat key nya aja. Misal di tabel yg dipartisi berdasarkan user, isi per transaksinya cuman “referensi” ke tabel utama (raw source) id berapa. Tapi pas baca ada drawback, jadi ada 2x IO. Nah IO nya ini biasanya kita bisa bikin in-house tools untuk optimize nya. Mungkin dengan caching, dll. suka2 kita.

— — —

Tapi menurutku disitu memang seninya big data sih :p mangkanya saya tulis gini buat dokumentasi juga karena sebenernya konsepnya “simpel” tapi kadang menghambat banget dan dalam satu team butuh sama dulu pemahamannya kalau yang kita hadapi masalahnya sebenernya se-”simple” ini :D

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.