Satu aliran data sering menarik beberapa kelompok pembaca dengan kebutuhan yang berbeda, sehingga keputusan tentang pemisahan data antar topic ikut menentukan arsitektur seluruh aplikasi. Topik ini menjelaskan pemilihan antara topic per entitas dan topic bersama, pemetaan pesan ke beberapa topic berdasarkan isinya, dan pola tabel atas peristiwa yang menyimpan keadaan pada topic terkompaksi. Setelah membaca topik ini, pemisahan topic dapat dirancang dengan mempertimbangkan kebutuhan pembacanya.
Topic per entitas atau topic bersama#
Pemisahan data dapat dilakukan dalam dua bentuk yang berlawanan. Topic per entitas menampung satu jenis sumber atau satu kelompok data pada topic tersendiri, sedangkan topic bersama menampung banyak jenis pesan di satu topic yang sama. Topic per entitas menyederhanakan langganan karena consumer hanya membaca topic yang relevan, dan pengaturan retensi beserta jumlah partisi dapat disesuaikan dengan beban tiap jenis data. Topic bersama meringankan administrasi karena jumlah topic sedikit, tetapi setiap consumer menanggung pesan yang tidak relevan bagi tugasnya.
Tabel berikut membandingkan kedua bentuk pemisahan tersebut.
| Aspek | Topic per entitas | Topic bersama |
|---|---|---|
| Langganan | Consumer hanya membaca topic yang dibutuhkan | Consumer menyaring pesan yang tidak relevan |
| Retensi dan partisi | Diatur menurut kebutuhan tiap topic | Satu pengaturan untuk seluruh jenis pesan |
| Jumlah topic | Bertambah mengikuti jenis data | Sedikit dan mudah diadministrasikan |
| Bentuk pesan | Satu bentuk per topic | Beberapa bentuk pesan dalam satu topic |
Kedua bentuk sering digunakan bersamaan pada satu sistem. Aliran besar dengan pembaca yang berbeda-beda dipecah per jenis data, sedangkan peristiwa kecil yang tidak menarik pembaca khusus dikumpulkan pada topic bersama. Jumlah topic yang bertambah harus diperhitungkan karena setiap topic membawa jumlah partisi dan beban replikasinya sendiri. Pemisahan yang dilakukan hanya karena kebiasaan memecah data menambah biaya administrasi tanpa memperjelas alirannya.
Memetakan pesan ke topic tujuan#
Pada topic per entitas, producer menentukan topic tujuan dari isi pesan yang dikirimnya. Pemilihan ini disebut routing, yaitu pemetaan pesan ke topic tujuan berdasarkan jenis atau isi pesannya. Pemetaan dilakukan oleh satu fungsi kecil pada producer agar keputusannya berada di satu tempat dan tidak menyebar ke seluruh kode pengirim. Skrip berikut menyimulasikan router sederhana yang mengarahkan kejadian sensor ke topic sesuai tipenya, dengan topic cadangan bagi tipe yang belum terpetakan.
def pilih_topic(tipe):
"""Petakan tipe kejadian sensor ke topic tujuannya."""
if tipe == "suhu":
return "sensor-suhu"
if tipe == "kelembapan":
return "sensor-kelembapan"
return "sensor-lainnya"
aliran = [
{"tipe": "suhu", "nilai": "24.1"},
{"tipe": "kelembapan", "nilai": "62"},
{"tipe": "suhu", "nilai": "24.4"},
{"tipe": "tekanan", "nilai": "1012"},
]
for pesan in aliran:
topic = pilih_topic(pesan["tipe"])
print(f"tipe={pesan['tipe']:10s} nilai={pesan['nilai']:5s} -> topic {topic}")tipe=suhu nilai=24.1 -> topic sensor-suhu
tipe=kelembapan nilai=62 -> topic sensor-kelembapan
tipe=suhu nilai=24.4 -> topic sensor-suhu
tipe=tekanan nilai=1012 -> topic sensor-lainnyaKejadian suhu dan kelembapan diarahkan ke topic masing-masing, sedangkan kejadian tekanan ditampung oleh topic lainnya karena tipenya belum terpetakan. Topic cadangan menjaga pesan tetap tersimpan ketika jenis baru muncul sebelum pemetaannya ditambahkan. Alur pemetaan tersebut diperlihatkan oleh diagram berikut, yaitu satu producer yang mengirim kejadian sensor dan dua consumer yang masing-masing membaca satu jenis kejadian.
Consumer pada diagram itu tidak lagi menyaring pesan yang tidak relevan karena setiap topic hanya memuat satu jenis kejadian. Pemetaan yang jelas juga membuat penambahan jenis kejadian berhenti pada satu titik, yaitu fungsi pemetaan pada producer dan pembuatan topic barunya. Pemisahan yang terlalu halus, misalnya satu topic untuk setiap perangkat, sebaiknya dihindari karena jumlah topic yang dihasilkan tidak terkendali.
Pola tabel atas peristiwa#
Pola tabel atas peristiwa menyimpan perubahan keadaan pada topic terkompaksi dengan key berupa identitas entitas, sehingga log yang terkompaksi membentuk tabel keadaan terkini. Pada aplikasi pengolah teks, peristiwa catatan.diedit dan catatan.dihapus dikirim ke topic peristiwa dengan key berupa pengenal catatan. Consumer membangun tabel keadaannya dengan membaca log dari awal lalu mengikuti ujung log, dan compaction memastikan pembacaan dari awal hanya memuat satu nilai terkini per catatan.
Pola ini menempatkan dua kebutuhan pada dua topic yang berbeda. Topic sejarah dengan retensi biasa menyimpan seluruh kejadian untuk analisis dan pemrosesan ulang, sedangkan topic terkompaksi menyimpan keadaan terkini untuk layanan yang tidak membutuhkan sejarah kejadian. Banyak sistem menggunakan keduanya sekaligus, yaitu topic sejarah yang mengalirkan kejadian penuh dan topic terkompaksi yang merangkum keadaan per key. Penghapusan entitas pada topic terkompaksi ditandai dengan tombstone sebagaimana pola changelog.
Pemisahan topic memengaruhi bentuk tabel yang dibangun oleh consumer. Tabel keadaan lazim berada pada satu topic bersama untuk semua entitas sejenis karena bentuk pesannya seragam, sedangkan kejadian dengan bentuk yang beragam dipecah per jenisnya. Dengan demikian, pemilihan antara topic per entitas dan topic bersama serta pola tabel atas peristiwa saling menentukan, dan keduanya dirancang bersamaan menurut kebutuhan pembaca data.
Ringkasan#
- Topic per entitas menyederhanakan langganan, retensi, dan bentuk pesan per jenis data, sedangkan topic bersama meringankan administrasi dengan biaya penyaringan pada consumer.
- Pemetaan pesan ke topic tujuan dilakukan oleh satu fungsi pemetaan pada producer, dengan topic cadangan bagi jenis kejadian yang belum terpetakan.
- Pola tabel atas peristiwa menyimpan perubahan keadaan pada topic terkompaksi sehingga pembacaan dari awal menghasilkan keadaan terkini per key.
- Topic sejarah dan topic terkompaksi digunakan bersamaan ketika sejarah kejadian dan keadaan terkini sama-sama dibutuhkan.
Referensi#
- Apache Kafka documentation: Design — Apache Software Foundation — penjelasan log terpartisi dan log compaction yang menjadi dasar pola tabel atas peristiwa.
- Apache Kafka documentation: Getting started — Apache Software Foundation — model topic dan langganan consumer yang menjadi dasar pemisahan data antar topic.