• Tidak ada hasil yang ditemukan

J00459

N/A
N/A
Protected

Academic year: 2017

Membagikan " J00459"

Copied!
9
0
0

Teks penuh

(1)

MongoDB: Implementasi VLDB (

Very Large Database

)

Untuk Sistem Basis Data Tersebar (

Distributed Database

)

Dra. Sri Hartati, MSc, PhD1, Adi Nugroho, ST, MMSI2

Abstrak

Selama 4 dekade sistem basis data relasional (RDBMS-Relational Database Management System) hampir selalu digunakan sebagai sumber data bagi aplikasi-aplikasi tersebar (distributed system). Sesungguhnya tidak ada yang salah dengan konsep „relasional‟ serta implementasinya dalam sistem-sistem basis data yang populer saat ini, seperti Oracle, SQL Server, MySQL, dan sebagainya. Meski demikian, pada saat ini, dengan munculnya aplikasi-aplikasi tersebar yang menuntut kinerja aplikasi (baca: kecepatan) yang semakin tinggi, sistem basis data relasional memiliki kelemahan saat menangani tabel-tabel yang dipartisi baik secara vertikal maupun horizontal. Sistem basis data ini akan menurun kinerjanya saat aplikasi-aplikasi membutuhkan data yang berasal dari 2 atau lebih tabel sekaligus. Hal inilah yang coba diatasi oleh sistem-sistem basis data NoSQL (Not Only SQL) yang juga sering disebut sebagai VLDB (Very Large Database) saat ini seperti Apache Cassandra (Facebook), Hadoop, HBase, BigTable (Google), serta MongoDB. Pada tulisan ini, kami akan mencoba mengeksplorasi sistem MongoDB, yaitu berkaitan dengan konsep dasarnya, operasi-operasi dasarnya, serta implementasinya untuk menangani data dalam sistem tersebar.

Kata kunci: MongoDB, VLDB, Distributed Database

1

PENDAHULUAN

Sistem basis data relasional (RDBMS-Relational Database Management System) yang konsepnya diperkenalkan oleh Pete r Chen (1970) dan diimplementasikan dalam bentuk sistem basis data DB2 di IBM (International Bussines Machine) oleh DR. Edgar F. Codd beberapa tahun sesudahnya merupakan sistem yang sangat tangguh karena ditopang oleh landasan matematika (Kalkulus Relasional) yang sangat mumpuni [9]. Sistem basis data relasional ini (misalnya Oracle, SQL Server, MySQL, dan sebagainya) hingga saat ini masih digunakan pada sebagian besar sistem di seluruh dunia. Sesungguhnya tidak ada yang „salah‟ dengan konsep dan implementasi „relasional‟ dalam sistem basis data. Meski demikian, karena karakteristik sistem „relasional‟ yang seringkali menuntut data yang berkaitan dengan entitas tertentu disimpan dalam 2 atau lebih tabel yang saling berhubungan (baca: berelasi) maka sebagai

1

Staf Pengajar Program S3 Ilmu Komputer Fakultas Matematika dan Ilmu Pengetahuan Alam - Universitas Gadjah Mada (FMIPA–UGM) di Jogyakarta. Email :shartati@ugm.ac.id

2

(2)

konsekuensinya muncul juga kebutuhan untuk menggabungkan 2 atau lebih tabel itu saat aplikasi membutuhkan data yang utuh/lengkap [1]. Penggabungan tabel ini bisa dilakukan menggunakan pernyataan SQL (Structured Query Language) JOIN (pada tabel yang dipartisi secara vertikal) atau UNION (pada tabel yang dipartisi secara horizontal) [1, 7]. Pada gilirannya, kedua operasi penggabungan tabel ini akan sangat membebani kerja server basis data sebab, untuk melakukannya, server basis data harus terus menerus melakukan pencarian data (lookup) pada tabel-tabel yang akan digabungkan [2, 6]. (Pada umumnya pencarian ini dilakukan berdasarkan kesamaan nilai „kunci primer‟ [primary key] pada tabel utama/tabel induk dengan „kunci tamu‟ [foreign key] yang ada pada tabel-tabel anak.) Pencarian data ini seringkali menurunkan kinerja (baca: kecepatan) sistem.

Berkaitan dengan hal di atas, para pakar di bidang pemrograman dan basis data di seluruh dunia mencoba mencari suatu teknik yang baru sedemikian rupa sehingga fakta penurunan kinerja sistem itu bisa diatasi. Dalam hal ini, suatu teknik yang relatif berbeda, yang berkaitan dengan query, dikembangkan. Teknik ini pada dasarnya melakukan penyimpanan data bukan dengan basis query terhadap tabel-tabel yang saling berelasi satu terhadap yang lainnya, melainkan menyimpan data sesuai dengan query yang diharapkan akan dilakukan oleh aplikasi [15]. Pendekatan ini kadang melanggar prinsip-prinsip „tabel yang normal‟ pada basis data relasional, tetapi akan sangat meningkatkan kinerja sistem sebab, saat melakukan query, sistem basis data tidak perlu melakukan pencarian (lookup) pada berbagai tabel yang berbeda. Query

hanya dilakukan pada 1 tabel saja! Hal inilah (ditambah dengan harapan akan adanya suatu sistem penyimpanan data yang mampu menangani data yang jumlahnya sangat besar/banyak serta tersimpan secara tersebar) pada akhirnya memunculkan suatu sistem basis data yang baru, yang sering dinamakan sebagai VLDB (Very Large Database) (karena mampu menangani data hingga satuan Petabyte [1015 byte] bahkan lebih besar lagi) atau yang juga sering dinamakan sebagai sistem NoSQL (Not Only SQL) karena operasi-operasi dasarnya tidak menggunakan bahasa nirprosedural SQL lagi melainkan menggunakan teknik-teknik yang umum dikenali dalam bahasa-bahasa pemrograman berorientasi objek pada umumnya [8, 15]. (Dalam tulisan ini, kami nanti akan mencoba melakukan akses ke sistem basis data MongoDB menggunakan bahasa pemrograman Java.)

Jika kita membahas sistem-sistem basis data/tempat penyimpanan data yang tidak beradaptasi dengan konsep sistem relasional, sesungguhnya (selain konsep NoSQL yang digunakan oleh MongoDB) dunia Teknologi Informasi juga mengenal beberapa konsep-konsep sistem-sistem basis data/tempat penyimpanan data (Data Store) yang lainnya (tidak dibahas dalam tulisan ini) misalnya [2, 3, 13, 15]: sistem basis data graf (Neo4j, OrientDB), sistem basis data berorientasi objek (OODBMS-Object Oriented Database Management System) (misalnya Versant, GemFire), sistem basis data XML (Oracle Berkeley DB XML, MonetDB/XQuery), dan sebagainya. Selain itu, dari sudutpandang sistem NoSQL seperti MongoDB, kita juga mengenal beberapa konsep yang secara umum serupa, tetapi tidak tepat sama, misalnya Key-Values Store (Voldemort, Riak, Redis, Scalaris, Tokyo Cabinet), Document Store

(3)

2

KONSEP DASAR MONGODB

MongoDB, tidak seperti sistem basis data relasional, sering disebut sebagai tempat penyimpanan data yang berorientasi pada dokumen (document) dan dapat menyimpan data yang memiliki berbagai tipe [4, 5]. MongoDB menyimpan data dalam format serupa dengan notasi JSON (Java Script Object Notation) -lebih tepat menggunakan format penyimpanan data BSON (Binary JSON) karena, selain menangani data teks, juga mampu untuk menyimpan data biner (binary) [4, 5]. Contohnya adalah sebagai berikut.

{

"First_Name": "Adi", "Last_Name" : "Nugroho", "phone_numbers": [

"+0222 1234 5678", "+62 1234 456 678" ]

}

Gambar 1

Struktur Penyimpanan Data Dalam MongoDB

Adapun kelebihan dari BSON dibandingkan JSON pada umumnya adalah karena elemen-elemennya juga mampu menyimpan data berformat biner (binary) [5, 6]. Sementara itu, kelebihan notasi JSON/BSON ini dibandingkan dengan apa yang disimpan dalam sistem basis data relasional pada umumnya adalah bahwa pemrogram tidak harus menyediakan nilai pada setiap elemennya. Dalam sistem basis data relasional, nilai yang tidak ada pada dasarnya tetap akan disimpan dalam basis data (meskipun mungkin cuma bernilai NULL) sehingga penyimpanan data di MongoDB akan lebih hemat ruang. Sebaliknya, yang juga merupakan kelebihan notasi BSON dari struktur tabel pada sistem basis data relasional adalah bahwa, dalam notasi BSON ini, kita juga sangat dimungkinkan untuk menambahkan elemen yang baru (yang tidak dimiliki oleh dokumen-dokumen yang lainnya), misalnya untuk dokumen yang baru (mengikuti contoh berkas BSON di atas) kita bisa menambahkan elemen Fax yang tidak dimiliki dokumen sebelumnya, sehingga pemanfaatannya secara umum lebih fleksibel.

DATABASE

COLLECTION

(4)

Dalam sistem basis data MongoDB, pengembang juga tidak perlu memberikan nilai kunci primer (primary key) untuk setiap elemen yang ada pada masing-masing dokumen, karena secara otomatis setiap elemen dalam dokumen yang masuk ke basis data akan memiliki _id-nya masing-masing yang bernilai unik, yang didapatnya dari sistem (terutama berdasarkan waktu elemen masuk ke sistem serta nama/alamat komputer yang digunakan) [4, 5]. Dengan demikian, setiap dokumen yang disimpan dalam MongoDB pada dasarnya akan berupa elemen-elemen pasangan „kunci/nilai‟ (key/value) yang masing-masing memiliki _id-nya yang unik. Elemen “First_Name” pada contoh di atas, memuat di dalamnya kunci (key) dan nilai (value)-nya. Kunci-kunci biasanya ditulis dalam bentuk string, tetapi nilai-nilainya bisa saja merupakan tipe-tipe data yang beragam seperti [4, 5]: (1) String, yang digunakan untuk menyimpan nilai teks, (2) Integer (32b dan 64b) yang digunakan untuk menyimpan nilai-nilai numerik, (3) Boolean yang menyimpan nilai TRUE atau FALSE, (4) Double yang digunakan untuk menyimpan bilangan bertitik desimal, (5) Min/Max yang digunakan untuk membandingkan nilai terkecil dan terbesar untuk elemen-elemen BSON, (6) Array yang digunakan untuk menyimpan nilai-nilai larik (array), (7) Timestamp yang menyimpan tanggal dan waktu saat data disisipkan ke basis data, (7) Object yang digunakan untuk menyimpan dokumen-dokumen yang menyimpan dokumen lain di dalamnya (nested object), (8) Null yang menyimpan data yang tidak diketahui nilainya, (9) Symbol yang serupa dengan string tetapi bisa digunakan untuk menyimpan simbol-simbol dalam bahasa-bahasa Jepang, Cina, India, Arab, Jawa, dan sebagainya, (10) ObjectID yang digunakan sebagai pengidentifikasi suatu dokumen, serta (11) Binary Datayang digunakan untuk menyimpan data biner (binary).

Sistem basis data MongoDB ditulis menggunakan bahasa pemrograman C++, tetapi sesungguhnya para penciptanya tidak mengharuskan aplikasi-aplikasi ditulis menggunakan bahasa C++ juga [4, 5]. Tersedia

driver-driver yang memungkinkan MongoDB diakses oleh aplikasi-aplikasi yang ditulis menggunakan C#, Ruby, PHP, Java, dan sebagainya. Secara umum, tempat penyimpanan utama data dalam MongoDB dinamakan sebagai koleksi (collection) yang analog dengan tabel pada sistem basis data relasional (Gambar 1). Secara sederhana dapat dikatakan bahwa koleksi menyimpan sejumlah elemen data yang serupa (tidak harus sama!). Sementara itu, terminologi basis data, yang dalam sistem basis data relasional merupakan kumpulan dari sejumlah tabel, dalam MongoDB didefinisikan sebagai kumpulan dari koleksi-koleksi. Selain itu, dalam MongoDB, seperti juga dalam sistem basis data relasional, dikenal konsep indeks (index) [4, 5], yang dibentuk oleh MongoDB dari hasil pengindeksan _id yang dimiliki oleh setiap elemen dokumen.

Kelas MongoManager

package MongoDBProgram;

// Package-package dari driver Java untuk MongoDB. import com.mongodb.DB;

import com.mongodb.DBCollection; import com.mongodb.DBCursor; import com.mongodb.DBObject; import com.mongodb.Mongo;

(5)

// Package-package dari JDK (Java Development Kit).

public MongoManager(String dbname) { this.dbname = dbname;

// Metoda untuk mendapatkan nama database. public String getDBName() {

return this.dbname; }

// Metoda untuk menambahkan dokumen (CREATE).

public void addDocument(DBObject object, String collectionName) { db.getCollection(collectionName).insert(object);

}

// Metoda untuk mendapatkan elemen-elemen dokumen (READ/RETRIEVE). public ArrayList getCollectionData(String collectionName) {

ArrayList list = new ArrayList();

DBCursor cursor = db.getCollection(collectionName).find(); while (cursor.hasNext()) {

// Metoda untuk meng-update dokumen (UPDATE).

public void updateDocument(DBObject criteria, DBObject newObject, String collectionName) {

db.getCollection(collectionName).update(criteria, newObject); }

// Metoda untuk menghapus dokumen (DELETE).

(6)

3

OPERASI-OPERASI DASAR PADA MONGODB

Operasi-operasi dasar dalam basis data sering dinamakan sebagai operasi-operasi CRUD ( Create-Read/Retrieve-Update-Delete). Untuk sistem basis data MongoDB, untuk melaksanakan operasi-operasi CRUD dari arah aplikasi, pemrogram tidak bisa lagi menggunakan bahasa nirprosedural SQL yang bersifat baku untuk sistem basis data relasional [4, 5], melainkan harus menggunakan teknik-teknik pemrograman pada umumnya. (Yang terbaik adalah saat pemrogram menggunakan bahasa-bahasa pemrograman berorientasi objek sebab pemrogram yang bersangkutan akan lebih mudah menyesuaikan program/aplikasinya dengan struktur penyimpanan data seperti yang diperlihatkan dalam Gambar 1.) Perhatikan Gambar 2 di atas, dimana kita dapat melihat kelas MongoManager yang memuat operasi-operasi CRUD dasar terhadap basis data MongoDB dilakukan menggunakan bahasa pemrograman Java. Kelas MongoManager pada Gambar 2 selanjutnya bisa dimanfaatkan untuk operasi-operasi CRUD yang akan dilakukan pada sistem MongoDB.

Seperti terlihat melalui Gambar 2, operasi-operasi CRUD pada sistem MongoDB dilakukan menggunakan paradigma “pemrograman berorientasi objek” pada umumnya [8]. Baik basis data, koleksi, dokumen, maupun elemen-elemen di dalamnya, diperlakukan seperti objek-objek, dimana objek dasar pada sistem MongoDB dinamakan sebagai BasicDBObject. Dalam hal ini, pemrogram aplikasi sistem tersebar harus membuat objek dalam bahasa Java (objek BasicDBObject) kemudian, untuk operasi penambahan (CREATE/INSERT) menambahkannya menjadi elemen-elemen dalam dokumen yang dikelola oleh MongoDB. Dalam hal ini, operasi-operasi CRUD itu difasilitasi oleh kelas-kelas yang tersedia pada driver Java untuk sistem MongoDB. Perlu dicatat juga bahwa, dalam sistem MongoDB, untuk melakukan query terhadap sistem MongoDB, perlu digunakan struktur data koleksi yang dimiliki oleh bahasa pemrograman yang digunakan. Berbagai struktur data berjenis koleksi bisa digunakan [8]. Dalam contoh operasi CRUD pada Gambar 2, khususnya untuk operasi pembacaan (READ/RETRIEVE), kami menggunakan struktur data ArrayList. Meski demikian, sesungguhnya struktur-struktur data yang lainnya dalam bahasa Java (misalnya Map, HashTable, List, dan sebagainya) juga dapat digunakan dengan penyesuaian-penyesuaian tertentu pada program. Pada dasarnya, pemrogram aplikasi yang memahami konsep “pemrograman berorientasi objek” dengan baik kemungkinan besar tidak akan mengalami kesulitan saat ia bekerja dengan sistem basis data MongoDB.

4

PENGGUNAAN MONGODB PADA SISTEM TERSEBAR

(7)

memungkinkan terjadinya transparansi basis data dari pemrogram dan yang memungkinkan beban server yang merata adalah konsep shard [5]. Shard sesungguhnya adalah himpunan bagian dari keseluruhan data dimana hal ini pada dasarnya serupa dengan partisi horisontal seperti yang dikenal pada sistem basis data tersebar selama ini [8]. Sebagai contoh, misalkan sistem basis data MongoDB untuk suatu aplikasi tersebar memiliki 10 juta dokumen dan sistem yang berangkutan menggunakan 5 server data, maka masing-masing server data itu mungkin (bergantung pengaturan-pengaturan saat konfigurasi awal MongoDB [5]) akan memiliki 1 shard yang berkapasitas 2 juta dokumen.

Gambar 3

Mekanisme Penyeimbangan Beban

Shard

Oleh MongoDB

Shard pada masing server, jika kapasitas/ukurannya sama, akan mengakibatkan beban masing-masing server akan sama [1, 10, 11]. Tetapi bagaimana hal itu dapat diupayakan secara kontinyu? Kami akan konsisten menggunakan contoh di atas. Gambar 3 memperlihatkan bahwa masing-masing shard

pada awalnya masing-masing berisi 2 juta dokumen (dengan total data basis data MongoDB berjumlah 10 juta dokumen). Seiring berjalannya waktu, maka mungkin saja ada operasi-operasi CRUD yang lebih intensif di beberapa shard (misalnya Shard 2 dan Shard 4). Dalam hal ini, shard 2 isinya mungkin berubah menjadi 2,1 juta dokumen; shard 4 isinya mungkin berubah menjadi 1,9 juta dokumen. Jika ini benar-benar terjadi, sistem basis data MongoDB akan mendeteksinya dan kemudian memindahkan 100 ribu dokumen dari shard 2 ke shard 4 sehingga secara keseluruhan bebannya akan menjadi seimbang dan, yang lebih menakjubkan, semuanya ini bersifat transparan dari pandangan pemrogram.

Dalam sistem basis data MongoDB, ukuran masing-masing shard ditentukan saat konfigurasi awal [5]. Konfigurasi awal ini juga dilakukan dengan menentukan shard key yaitu elemen mana dalam dokumen yang akan ditentukan sebagai basis proses sharding akan dilakukan [5]. Selain itu, dalam MongoDB, pengembang juga bisa menentukan basis data dan/atau dokumen mana yang nantinya akan bisa

di-sharding [5]. Saat aplikasi berkembang, pengembang mungkin akan merasa perlu menambahkan lebih banyak shard (misalnya pada contoh di atas, shard yang ke-6). Saat pengembang menambahkan shard

yang baru, MongoDB akan secara otomatis memindahkan data dari shard yang ada ke shard yang baru tadi dengan masih melakukannya di luar pengetahuan pemrogram. Dalam melakukan pemindahan data

Shard 2

2100000

Shard 4

1900000

Shard 1

2000000

100000 data dipindah

Shard 3

2000000

Shard 5

(8)

(sharding), MongoDB memiliki suatu proses yang dinamakan mongos [5] dimana proses mongos ini akan mengelola klien-klien yang akan melakukan koneksi ke server MongoDB. Mongos ini akan meneruskan permintaan-permintaan (request) ke server (atau server-server) yang sesuai (sejumlah server yang menangani permintaan tunggal dari aplikasi sering dinamakan sebagai cluster [2, 10, 11]) dan mengirimkan kembali tanggapannya (response) ke klien yang mengirimkan permintaan tadi.

5

KESIMPULAN

MongoDB merupakan sistem basis data NoSQL (Not Only SQL)/VLDB (Very Large Database) yang cukup ideal digunakan sebagai tempat penyimpanan data pada sistem tersebar (distributed system) karena kemampuannya untuk menangani data yang berjumlah sangat besar. Fitur pemerataan beban (load balancing) dengan pola sharding yang dimiliki oleh MongoDB melalui proses mongos yang dimilikinya juga menjadikan basis data MongoDB sangat layak untuk digunakan sebagai basis bagi sistem tersebar. Lebih bagusnya lagi, proses sharding ini juga bersifat transparan dari pandangan pemrogram sehingga pemrogram bisa lebih berfokus pada pembuatan logika bisnis aplikasi alih-alih harus juga berpikir tentang dimana sesungguhnya data yang dibutuhkan aplikasi berada.

Biaya perolehan MongoDB yang sangat rendah (gratis!) juga merupakan nilai tambah yang signifikan selain ukuran berkas (file)-nya yang relatif kecil (kurang dari 20 MB!). Meski demikian, di sekian banyak keunggulannya, MongoDB juga memiliki kekurangan karena sintak bahasa pengaksesnya sangat bergantung pada bahasa pemrograman yang digunakan (tidak seperti SQL yang bersifat baku untuk hampir semua sistem basis data relasional). (Meski sesungguhnya hal terakhir ini tidak menjadi masalah yang terlalu signifikan sepanjang pemrogram-pemrogram yang akan mengembangkan aplikasi di atas MongoDB memahami dengan baik konsep dan implementasi “pemrograman berorientasi objek” dalam bahasa pemrograman yang akan digunakan.) Selain itu, yang juga merupakan kekurangan MongoDB (sekaligus juga mungkin merupakan kelebihannya karena dengan demikian ukuran berkas instalasi akan menjadi sangat kecil dibandingkan kebanyakan sistem basis data relasional yang ada saat ini, seperti Oracle, SQL Server, MySQL, dan sebagainya) adalah fitur administrasi (pengaturan hak akses basis data oleh pengguna, pengaturan alokasi memori server, prosedur penyalinan dan pemulihan [backup and recovery], pemantauan kinerja, dan sebagainya) yang tidak dijumpai di dalamnya karena semuanya diserahkan pada aplikasi.

DAFTAR PUSTAKA

1. Alsultany, Yas, 2010. Database Management and Partitioning to Improve Database Processing Performance. Journal of Database Marketing & Customer Strategy Management (2010) 17, 271 – 276. doi: 10.1057/dbm.2010.14; published online 11 October 2010.

(9)

3. Basis data NoSQL. www.wikipedia.com. Diakses 3 Maret 2011.

4. Chodorow, Kristina, Michael Dirolf, 2010. MongoDB : The Definitive Guide. O‟Relly Media Inc.,

Sebastopol-USA.

5. Chodorow, Kristina, 2011. Scaling MongoDB. O‟Reily Media, Inc., Sebastopol.

6. Giroux, David Paul, 2009. DBCC CheckedDB for Very Large Databases. SQL Server Magazine. www.sqlmag.com. Diakses 28 Februari 2011.

7. Kemne, Bettina, Gustavo Allonso, 2010. Database Replication : A Tale About Research Across Communities. VLDB Concept from ETH Zurich and McGill University Montreal.

8. Nugroho, Adi, 2008. Algoritma dan Struktur Data Menggunakan Bahasa Java. Penerbit ANDI OFFSET, Jogyakarta.

9. Nugroho, Adi, 2004. Konsep-konsep Pengembangan Sistem Basis Data. Penerbit INFORMATIKA, Bandung.

10. Load balancing pada sistem basis data Microsoft SQL Server. http://www.ristinet.com/index.php?ch=8&lang=&s=83dffd757167487d9410d5ef58eeee7e&n=215. 11. Load balancing pada sistem basis data terdistribusi Oracle 11g.

http://blogs.oracle.com/stevenChan/entry/optimizing_r12_performance_via.

12. Plugge, Eelco, Peter Membrey, Tim Hawkins, 2010. The Definitive Guide to MongoDB: The NoSQL Database for Cloud and Desktop Computing. Springer-Verlag, New York.

13. Situs perbandingan basis data-basis data NoSQL. http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis.

14. Situs resmi MongoDB. www.mongodb.org.

Gambar

Gambar 1 Struktur Penyimpanan Data Dalam MongoDB
Gambar 2 Operasi CRUD Pada Sistem MongoDB

Referensi

Garis besar

Dokumen terkait

Berdasarkan tiga contoh puisi di atas menunjukkan bahwa gaya bahasa perbandingan yang sering digunakan oleh pengarang yakni gaya bahasa simile, personifikasi dan

sedangkan yang lunak (soft bottom) akan menghasilkan echo dengan amplitudo yang melebar dan rendah (Gambar 10). Bentuk kurva energi kumulatif sinyal yang berasal dari hard

Banyaknya kriteria (multiple criteria) yang digunakan dalam proses penilaian kinerja karyawan menyulitkan pihak manajemen untuk memberi bobot setiap kriteria oleh karena

Penelitian ini bertujuan untuk mengetahui respon pimpinan rektor PTS dan PTN di seluruh Indonesia mengenai pembebasan UKT secara penuh kepada para mahasiswa yang terkena dampak

Melalui kutipan di atas ditemukan bahwa kejadian yang dapat menyebabkan munculnya trauma sudah pasti menimbulkan keterkejutan karena kemunculannya yang sangat tiba-tiba sehingga

Hasil dari studi pengenalan masalah melalui proses indepth interview kepada manajemen UPT BPI LIPI, staf pemasaran yang ada di Seksi Penyebarluasan Hasil

5.9.3 Kesesuaian Sistem Distribusi Karbon Dioksida pada Gas Turbin, Generator , Auxiliary PLTGU dan Gudang 4 PLTU

Menguji hubungan tingkat kekompakan kota (urban compactness) dan tingkat kesehatan kota (urban health) di Kawasan Perkotaan Yogyakarta, apakah kota yang kompak merupakan