9 Tipe Database yang Harus Diketahui Seorang Developer

Database Relasional

Database relasional tetap menjadi fondasi perangkat lunak perusahaan karena alasan yang baik, yaitu database ini mengatur data ke dalam tabel terstruktur dengan skema yang telah ditentukan sebelumnya, menegakkan hubungan yang ketat antara tabel-tabel tersebut melalui foreign key, dan menjamin integritas data melalui kepatuhan ACID, yaitu properti yang memastikan suatu transaksi selesai sepenuhnya atau tidak terjadi sama sekali, yang merupakan jaminan yang kita inginkan saat memproses sesuatu seperti transfer keuangan di mana pembaruan sebagian akan menjadi bencana nyata.

Model relasional, yang dibangun di sekitar Structured Query Language (SQL), telah terbukti sangat tahan lama karena secara alami sesuai dengan sebagian besar data bisnis dunia nyata, yaitu pelanggan memiliki pesanan, pesanan memiliki item baris, item baris merujuk pada produk, dan semua hubungan tersebut dapat diekspresikan dengan bersih melalui penggabungan antara tabel yang terdefinisi dengan baik. Sistem seperti PostgreSQL, MySQL, dan Microsoft SQL Server tetap menjadi titik awal default untuk sebagian besar aplikasi baru, dan karena alasan yang baik — ketelitian model relasional seputar skema dan hubungan menangkap sejumlah besar bug integritas data sebelum mencapai produksi, hanya dengan menolak untuk menerima data yang salah format sejak awal.

Konsekuensinya adalah kekakuan ini menjadi kendala nyata pada titik tertentu. Skema yang kaku mempersulit akomodasi data yang tidak sesuai dengan baris dan kolom, dan penskalaan horizontal database relasional di banyak mesin sambil mempertahankan jaminan konsistensi yang kuat merupakan masalah sistem terdistribusi yang benar-benar sulit. Inilah celah yang memotivasi munculnya jenis database lain, yaitu masing-masing, dengan cara yang berbeda, melonggarkan beberapa jaminan model relasional sebagai imbalan atas kinerja yang lebih baik atau fleksibilitas pada jenis beban kerja tertentu yang kurang mudah ditangani oleh model relasional.

Database Key-Value

Secara struktural, database key-value adalah tipe database paling sederhana dalam daftar ini, yaitu setiap bagian data disimpan sebagai pasangan, kunci unik dan nilai terkait, dan seluruh tugas database adalah mengambil nilai secara instan ketika diberikan kuncinya, tanpa konsep relasi, skema, atau kueri kompleks yang terlibat. Kesederhanaan inilah intinya — dengan mengabaikan kemampuan untuk melakukan kueri pada apa pun selain kunci itu sendiri, penyimpanan key-value mencapai kinerja baca dan tulis yang sangat cepat dan dapat diprediksi, seringkali diukur dalam milidetik satu digit bahkan pada skala besar.

Redis dan Amazon DynamoDB (dalam pola penggunaan yang lebih sederhana) adalah sistem yang paling banyak digunakan developer ketika mereka membutuhkan bentuk kinerja spesifik ini. Kasus penggunaan kanonik adalah semua skenario di mana kita sudah tahu persis apa yang kita cari dan hanya membutuhkannya dengan cepat, yaitu lapisan caching yang berada di depan database yang lebih lambat untuk menyerap kueri identik yang berulang, penyimpanan sesi yang perlu memeriksa apakah token sesi tertentu valid pada setiap permintaan yang dibuat oleh pengguna yang masuk, dan data keranjang belanja di mana "key" adalah sesi pengguna dan "value" adalah isi keranjang mereka saat ini.

Keterbatasannya justru merupakan kebalikan dari kekuatannya, yaitu karena database tidak memahami struktur di dalam nilai yang disimpannya, kita tidak dapat memintanya untuk menemukan "semua pengguna yang menambahkan item ke keranjang mereka dalam satu jam terakhir" tanpa memelihara indeks terpisah sendiri atau mengambil dan memeriksa setiap nilai secara manual, yang mengalahkan seluruh keunggulan kinerja yang diberikan oleh model key-value. Penyimpanan key-value paling baik dipahami bukan sebagai pengganti database tujuan umum, tetapi sebagai lapisan khusus yang sangat cepat untuk kelas pencarian yang sempit dan terdefinisi dengan baik, biasanya diterapkan bersamaan dengan database yang lebih terstruktur daripada sebagai penggantinya.

Database Dokumen

Database dokumen menyimpan data sebagai dokumen mandiri, biasanya diformat sebagai JSON atau struktur biner mirip JSON, di mana setiap dokumen dapat memiliki struktur internalnya sendiri tanpa perlu menyesuaikan diri dengan skema yang kaku dan telah ditentukan sebelumnya yang dibagi di setiap catatan dalam koleksi. Ini adalah model yang sangat berbeda dari database relasional yang bersikeras bahwa setiap baris dalam tabel harus memiliki kolom yang sama persis — database dokumen nyaman dengan satu dokumen produk yang memiliki lima bidang dan yang lain memiliki dua belas, jika memang demikian variasi data yang mendasarinya.

MongoDB tetap menjadi database dokumen yang paling dikenal luas, meskipun Couchbase dan Amazon DocumentDB melayani kasus penggunaan yang serupa. Model ini sangat cocok untuk data yang benar-benar hierarkis dan mandiri, yaitu seperti katalog produk di mana kategori produk yang berbeda memiliki atribut yang berbeda secara signifikan, sistem manajemen konten yang menyimpan artikel dengan struktur yang bervariasi, atau sistem profil pengguna di mana pengguna yang berbeda mungkin memiliki bidang opsional yang berbeda. Alih-alih pendekatan model relasional yang membagi jenis data ini ke dalam beberapa tabel terkait dan menyusunnya kembali melalui penggabungan (join) pada saat kueri, database dokumen menyimpan seluruh struktur bersarang bersama-sama sebagai satu unit yang dapat diambil, yang seringkali lebih alami sesuai dengan cara aplikasi benar-benar memikirkan dan menggunakan data tersebut dalam kode.

Kelemahannya adalah database dokumen umumnya menawarkan jaminan konsistensi yang lebih lemah di seluruh dokumen daripada yang ditawarkan database relasional di seluruh tabel, dan hubungan antar dokumen — meskipun didukung — biasanya kurang efisien untuk dikueri daripada hubungan yang dinyatakan melalui penggabungan relasional yang tepat. Database dokumen cenderung unggul khususnya ketika data aplikasi secara alami berbentuk dokumen dan tidak memerlukan jaminan transaksional multi-entitas yang kompleks; database ini cenderung menjadi canggung ketika aplikasi benar-benar membutuhkan jenis penegakan hubungan yang ketat dan saling terkait yang menjadi tujuan awal model relasional.

Database Wide-Column

Database wide-column, terkadang disebut database keluarga kolom, menempati posisi tengah yang khas, yaitu database ini diorganisir berdasarkan baris dan kolom seperti database relasional, tetapi setiap baris dapat memiliki kumpulan kolom yang berbeda dan dinamis, dan penyimpanan yang mendasarinya diorganisir untuk membuatnya sangat efisien dalam menulis dan membaca volume data yang sangat besar di seluruh klaster terdistribusi yang terdiri dari banyak mesin. Apache Cassandra dan Google Bigtable adalah sistem yang paling terkait dengan model ini, dan keduanya secara khusus dibangun untuk memecahkan masalah yang dihadapi database relasional tradisional, yaitu mempertahankan throughput penulisan yang sangat tinggi, secara andal, di seluruh klaster yang mencakup banyak server dan berpotensi banyak wilayah geografis, tanpa satu titik kegagalan pun.

Arsitektur yang memungkinkan hal ini melibatkan pelonggaran beberapa jaminan konsistensi ketat yang diberikan oleh database relasional, sebagai imbalan atas ketersediaan dan toleransi partisi, yaitu kemampuan untuk tetap berfungsi dan menerima penulisan bahkan jika beberapa node dalam klaster menjadi tidak dapat dijangkau untuk sementara waktu. Kompromi ini, yang diformalkan dalam teori sistem terdistribusi sebagai teorema CAP, adalah keputusan desain yang disadari daripada sebuah batasan, yaitu database wide-column dibangun untuk kelas aplikasi spesifik di mana kemampuan untuk selalu menerima penulisan lebih penting daripada setiap pembaca melihat nilai terbaru absolut setiap saat.

Hal ini menjadikan database wide-column sebagai pilihan alami untuk sistem operasional skala besar yang perlu menyerap volume data yang sangat besar dan berkelanjutan secara andal, yaitu seperti platform perpesanan yang memproses miliaran pesan, platform IoT yang merekam aliran data perangkat secara konstan, dan mesin rekomendasi yang mencatat setiap interaksi pengguna di seluruh basis pengguna yang besar. Netflix, misalnya, secara historis sangat bergantung pada Cassandra khususnya karena infrastruktur riwayat tontonan dan rekomendasinya perlu menyerap volume penulisan yang besar dan berkelanjutan di seluruh basis pengguna yang terdistribusi secara global tanpa adanya satu titik kegagalan pun yang menyebabkan sistem mati.

Database Time Series

Database time series dirancang khusus untuk satu bentuk data spesifik yang sangat umum, yaitu aliran data kontinu, masing-masing diberi stempel waktu, biasanya mewakili pengukuran yang berubah seiring waktu. Meskipun secara teknis kita dapat menyimpan jenis data ini dalam database relasional, database time series seperti InfluxDB, TimescaleDB, dan Prometheus dioptimalkan secara arsitektur dengan cara yang tidak dimiliki oleh database tujuan umum — mereka menggunakan teknik kompresi khusus yang memanfaatkan fakta bahwa nilai-nilai berstempel waktu yang berurutan seringkali mirip satu sama lain, dan mereka dibangun di sekitar pola kueri khusus untuk analisis berbasis waktu, seperti menghitung rata-rata selama jendela bergulir, mendeteksi anomali terhadap garis dasar historis, atau secara otomatis membuang data yang lebih lama dari periode retensi yang ditentukan.

Kasus penggunaan untuk jenis database ini telah berkembang pesat seiring dengan perluasan perangkat yang terhubung dan infrastruktur observabilitas, yaitu seperti jaringan sensor industri yang melacak kesehatan peralatan secara real-time, sistem perdagangan keuangan yang mencatat setiap perubahan harga sepanjang hari, sistem pemantauan kinerja aplikasi yang melacak metrik server seperti penggunaan CPU dan memori di ribuan mesin, dan sistem infrastruktur cerdas yang mencatat pembacaan berkelanjutan dari segala hal mulai dari meteran utilitas hingga sensor lingkungan. Dalam setiap kasus ini, volume data yang dihasilkan sangat besar, sebagian besar kueri secara khusus memperhatikan pola dan tren selama jendela waktu yang ditentukan daripada titik data individu tunggal, dan data yang lebih lama biasanya menjadi semakin kurang berharga dan dapat diagregasi atau dibuang sesuai dengan kebijakan retensi yang ditentukan — persis pola yang menjadi dasar arsitektur basis data deret waktu sejak awal.

Database relasional yang diminta untuk menangani beban kerja yang sama dalam skala besar biasanya mulai kewalahan karena volume penulisan berkelanjutan yang sangat besar dan kesulitan dalam mengekspresikan kueri agregasi jendela waktu secara efisien, yang merupakan celah yang membuat database time series khusus layak untuk kompleksitas operasional tambahan dalam menjalankan sistem khusus daripada menggunakan kembali infrastruktur yang sudah kita miliki.

Database Graph

Database graph mengatur data secara fundamental berbeda dari setiap jenis database lain dalam daftar ini, yaitu alih-alih baris, dokumen, atau kolom, unit penyimpanan inti adalah relasi itu sendiri. Data direpresentasikan sebagai node (entitas, seperti orang atau produk) yang dihubungkan oleh edge (hubungan di antara mereka, seperti "mengikuti" atau "dibeli"), dan baik node maupun edge dapat membawa properti mereka sendiri. Neo4j tetap menjadi database graph yang paling dikenal luas, dengan Amazon Neptune sebagai alternatif terkelola yang populer.

Masalah spesifik yang dipecahkan oleh database graph adalah penelusuran, yaitu menjawab pertanyaan secara efisien yang memerlukan penelusuran rantai relasi, yang berpotensi memiliki banyak langkah, yang menjadi sangat lambat dalam database relasional karena setiap langkah tambahan dalam rantai biasanya memerlukan penggabungan (join) yang mahal. Sebaliknya, database graph menyimpan relasi itu sendiri sebagai koneksi kelas satu yang dapat ditelusuri secara langsung, sehingga penelusuran rantai relasi beberapa langkah tetap cepat terlepas dari berapa banyak lompatan yang terlibat, karena database tidak perlu merekonstruksi relasi tersebut melalui pencarian tabel berulang pada saat kueri.

Hal ini menjadikan database graph sangat cocok untuk jenis masalah di mana hubungan, bukan hanya entitas, adalah intinya, yaitu jaringan sosial yang memodelkan siapa yang terhubung dengan siapa dan seberapa dekat, mesin rekomendasi yang menalar melalui "orang yang membeli ini juga membeli itu, dan orang yang mirip dengan mereka juga menyukai hal lain ini," sistem deteksi penipuan yang melacak rantai transaksi mencurigakan atau atribut bersama di berbagai akun yang tampaknya tidak terkait, dan grafik pengetahuan yang memetakan bagaimana konsep, entitas, dan fakta saling berhubungan di seluruh kumpulan informasi yang besar dan saling terhubung. Kapan pun wawasan menarik dalam data kita secara khusus terletak pada struktur hubungan antar catatan — bukan hanya catatan itu sendiri — database graph layak dipertimbangkan secara serius dibandingkan alternatif relasional.

Database Vektor

Database vektor adalah jenis database terbaru dalam daftar ini yang mencapai adopsi arus utama, dan peningkatannya terkait langsung dengan ledakan aplikasi AI yang dibangun di atas large language model. Database vektor menyimpan data sebagai vektor numerik berdimensi tinggi, yang disebut embedding, yang dihasilkan oleh model machine learning untuk merepresentasikan makna semantik dari suatu konten — teks, gambar, audio, atau video — dalam bentuk yang dapat dibandingkan secara matematis untuk kesamaan. Alih-alih melakukan kueri untuk kecocokan yang tepat seperti yang dilakukan database relasional, database vektor dibangun untuk menjawab jenis pertanyaan yang pada dasarnya berbeda: "temukan item yang maknanya paling mirip dengan yang ini," bahkan ketika kata-kata atau piksel yang tepat sama sekali tidak cocok.

Pasar untuk database vektor yang dirancang khusus telah terkonsolidasi secara signifikan saat ini, dengan Pinecone, Weaviate, Qdrant, Milvus, dan Chroma mewakili opsi yang paling banyak diadopsi, bersama dengan pgvector, sebuah ekstensi yang menambahkan kemampuan pencarian vektor langsung ke database PostgreSQL yang ada daripada memerlukan sistem yang sepenuhnya terpisah. Masing-masing mengambil pendekatan yang benar-benar berbeda, yaitu Pinecone menawarkan pengalaman serverless yang dikelola sepenuhnya yang menghilangkan biaya operasional sepenuhnya dengan harga premium; Qdrant, yang ditulis dalam Rust, sering disukai karena rasio harga-kinerjanya dan kinerja pencarian terfilternya yang sangat kuat; Weaviate membedakan dirinya dengan pencarian hibrida yang dibangun secara native ke dalam database, menggabungkan pencocokan kata kunci tradisional dengan kesamaan vektor semantik dalam satu kueri daripada mengharuskan penggabungan tersebut untuk dirakit secara manual; dan pgvector secara khusus menarik bagi tim yang sudah menjalankan PostgreSQL dan ingin menghindari pengenalan sistem yang sepenuhnya terpisah dalam infrastruktur mereka sampai skala mereka benar-benar membutuhkannya.

Kasus penggunaan utama di balik hampir semua adopsi ini adalah Retrieval-Augmented Generation (RAG), yaitu teknik untuk mendasarkan respons model bahasa pada dokumen aktual dan spesifik suatu organisasi dengan terlebih dahulu mengambil bagian yang paling relevan secara semantik dari database vektor dan kemudian menyediakannya ke model sebagai konteks. Di luar RAG secara khusus, database vektor juga mendukung pencarian semantik yang memahami maksud daripada memerlukan kecocokan kata kunci yang tepat, sistem rekomendasi berdasarkan kesamaan konten yang sebenarnya daripada sekadar penandaan, dan pencarian kesamaan gambar atau audio. Teknik algoritma inti yang mendasari hampir semua database vektor modern adalah HNSW (Hierarchical Navigable Small World), yaitu metode pencarian tetangga terdekat yang efisien hingga miliaran vektor dengan mengorbankan sedikit presisi yang terjamin untuk kinerja kueri yang jauh lebih cepat — sebuah kompromi yang ternyata sepenuhnya dapat diterima untuk sebagian besar aplikasi pencarian semantik dan RAG di dunia nyata.

Database Columnar

Database columnar menyimpan data yang diorganisir berdasarkan kolom, bukan berdasarkan baris. Ini terdengar seperti detail implementasi kecil, tetapi menghasilkan karakteristik kinerja yang sangat berbeda untuk kategori beban kerja tertentu dan sangat umum, yaitu kueri analitik yang mengagregasi satu bidang di jutaan atau miliaran catatan, seperti menghitung total pendapatan di setiap transaksi dalam setahun terakhir. Database berorientasi baris tradisional, bahkan yang terindeks dengan baik, harus membaca seluruh setiap baris untuk mengekstrak hanya satu kolom yang diagregasi, membuang sebagian besar I/O disk untuk membaca data yang sebenarnya tidak relevan dengan kueri. Database columnar, dengan menyimpan semua nilai untuk satu kolom secara berurutan, dapat membaca data yang benar-benar dibutuhkan oleh kueri analitik tertentu dan tidak lebih, dan dapat menerapkan kompresi yang jauh lebih efektif, karena nilai dalam satu kolom cenderung jauh lebih mirip satu sama lain daripada nilai di seluruh baris.

Sistem seperti Amazon Redshift, Google BigQuery, Snowflake, dan ClickHouse sumber terbuka adalah database kolumnar dominan yang digunakan dalam produksi saat ini, dan membentuk tulang punggung sebagian besar infrastruktur gudang data dan intelijen bisnis modern. Beban kerja yang dirancang untuk database kolumnar pada dasarnya berbeda dari beban kerja yang menjadi keunggulan database relasional (berorientasi baris): alih-alih mencari, memasukkan, atau memperbarui catatan individual satu per satu — pola transaksional klasik — database kolumnar dioptimalkan untuk memindai dan mengagregasi volume data historis yang sangat besar untuk menjawab pertanyaan analitis, pola yang biasanya disebut sebagai OLAP (Online Analytical Processing), berbeda dengan pola OLTP (Online Transaction Processing) yang menjadi dasar database relasional berorientasi baris.

Dalam praktiknya, ini berarti sebagian besar organisasi besar menjalankan kedua jenis database secara berdampingan daripada memilih salah satunya, yaitu database relasional atau dokumen berorientasi baris menangani aplikasi transaksional langsung — memproses pesanan individual, memperbarui catatan pengguna individual — sementara gudang data berbasis kolom, yang diisi oleh alur kerja reguler yang mengekstrak dan mengubah data dari sistem operasional, menangani pelaporan, dasbor, dan kueri intelijen bisnis yang perlu diagregasi secara efisien di seluruh kumpulan data historis organisasi.

Database Ledger

Database ledger atau database buku besar adalah jenis database yang lebih khusus dan kurang umum dibahas, yang dirancang khusus berdasarkan satu persyaratan spesifik yang tidak dapat dinegosiasikan, yaitu catatan yang tidak dapat diubah dan dapat diverifikasi secara kriptografis dari setiap perubahan yang pernah dilakukan pada data, tanpa kemampuan bagi pihak mana pun — termasuk administrator database dengan akses sistem penuh — untuk mengubah atau menghapus riwayat setelahnya. Amazon QLDB (meskipun sejak itu dihentikan dalam bentuk mandirinya yang asli) dan semakin banyak sistem yang dibangun di atas arsitektur yang berdekatan dengan blockchain, mewakili kategori ini, bersamaan dengan pola yang lebih luas untuk mempertahankan log transaksi yang dirantai secara kriptografis dan hanya dapat ditambahkan sebagai sumber kebenaran yang otoritatif untuk riwayat sistem.

Sifat teknis utama dari database ledger adalah bahwa setiap perubahan dicatat sebagai entri baru yang ditambahkan ke rantai yang terhubung secara kriptografis dan tidak terputus, di mana integritas setiap entri dapat diverifikasi secara independen terhadap entri sebelumnya — artinya setiap upaya untuk mengubah data historis akan memutus rantai kriptografis dengan cara yang langsung terdeteksi, bukan berhasil secara diam-diam seperti halnya pernyataan UPDATE atau DELETE yang tidak sah terhadap database konvensional. Ini adalah jaminan yang secara fundamental berbeda dari log audit yang ditambahkan ke database konvensional setelah kejadian, yang biasanya masih memungkinkan administrator yang memiliki hak istimewa yang cukup untuk mengubah data yang mendasarinya secara diam-diam jika log audit itu sendiri tidak dilindungi secara kriptografis secara independen.

Kasus penggunaan untuk jenis database ini terkonsentrasi secara khusus di domain di mana persyaratan peraturan, hukum, atau keuangan menuntut riwayat yang tidak dapat disangkal dan terbukti tidak dapat diubah, yaitu layanan keuangan yang melacak silsilah lengkap transaksi dan kepemilikan aset, sistem rantai pasokan yang perlu membuktikan asal usul barang yang tidak diubah saat berpindah tangan melalui banyak pihak, sistem perawatan kesehatan yang memelihara riwayat catatan pasien yang dapat diverifikasi, dan industri yang diatur di mana kemampuan untuk membuktikan — bukan hanya mengklaim — bahwa catatan historis belum diubah memiliki bobot hukum dan keuangan yang nyata. Untuk sebagian besar aplikasi, database konvensional dengan jejak audit yang dirancang dengan baik sudah cukup; database ledger ada khusus untuk serangkaian kasus yang lebih sempit di mana "cukup" tidak cukup baik dan kekebalan yang dapat dibuktikan secara kriptografis merupakan persyaratan yang mutlak, bukan sekadar fitur tambahan.

Memilih Database yang Tepat untuk Pekerjaan

Jika kita melihat kesembilan jenis database ini, benang merahnya adalah bahwa masing-masing mewakili serangkaian kompromi yang berbeda dan disengaja, dan tidak ada satu pun yang secara mutlak lebih baik atau lebih buruk dari yang lain. Skema yang kaku dan konsistensi yang kuat dari database relasional adalah persis apa yang kita inginkan untuk transaksi keuangan, dan persis apa yang memperlambat kita ketika data kita benar-benar tidak sesuai dengan baris dan kolom yang dapat diprediksi. Kecepatan luar biasa dari penyimpanan key-value berasal langsung dari mengorbankan kemampuan untuk melakukan kueri pada apa pun selain kunci. Kemampuan database kolom lebar untuk menyerap volume penulisan yang besar dan berkelanjutan di seluruh klaster terdistribusi berasal dari pelonggaran jaminan konsistensi ketat yang sebenarnya dibutuhkan oleh aplikasi keuangan. Memahami kompromi ini, daripada menghafal produk spesifik mana yang harus dipilih, adalah apa yang sebenarnya ditransfer dari satu proyek ke proyek berikutnya karena alat-alat spesifik di setiap kategori terus berkembang.

Dalam praktiknya, arsitektur aplikasi modern semakin berarti memilih beberapa jenis database ini secara sengaja dan menggunakan masing-masing secara spesifik untuk beban kerja yang benar-benar paling sesuai, daripada memaksakan setiap jenis data melalui satu sistem serbaguna. Platform e-commerce mungkin menggunakan database relasional untuk pesanan dan inventaris di mana konsistensi yang ketat benar-benar penting, database dokumen untuk katalog produk yang fleksibel dan beragam, penyimpanan key-value untuk data sesi dan keranjang belanja yang perlu sangat cepat, database time series untuk melacak metrik kinerja situs, gudang data kolumnar untuk pelaporan intelijen bisnis, dan semakin sering, database vektor yang mendukung pencarian dan rekomendasi produk berbasis AI — semuanya sebagai bagian yang terkoordinasi dari satu sistem yang koheren, bukan sebagai kumpulan pilihan teknologi yang tidak terkait dan kacau.

Jadi, masa-masa "cukup gunakan database relasional untuk segalanya" telah berlalu, bukan karena database relasional menjadi lebih buruk, tetapi karena berbagai masalah yang perlu dipecahkan oleh aplikasi modern telah meluas jauh melampaui apa yang dapat ditangani oleh satu model data saja. Database relasional tetap menjadi fondasi yang tepat untuk data terstruktur dan transaksional dengan hubungan yang jelas.