{"id":994,"date":"2025-10-02T08:15:08","date_gmt":"2025-10-02T08:15:08","guid":{"rendered":"https:\/\/binus.ac.id\/malang\/computer-science\/?p=994"},"modified":"2025-10-02T08:15:08","modified_gmt":"2025-10-02T08:15:08","slug":"database-scalability-elasticity-and-autonomy-in-the-cloud","status":"publish","type":"post","link":"https:\/\/binus.ac.id\/malang\/computer-science\/2025\/10\/02\/database-scalability-elasticity-and-autonomy-in-the-cloud\/","title":{"rendered":"Database Scalability, Elasticity, and Autonomy in the Cloud"},"content":{"rendered":"

Beberapa orang akan berpendapat bahwa teknologi penyimpanan data telah memperkaya kehidupan pengguna juga telah menimbulkan beberapa tantangan dan kompleksitas baik dari sudut pandang pengguna maupun dari penyedia layanan atau perspektif sistem. Dari sudut pandang pengguna, pengguna harus menavigasi beberapa platform komputasi dan penyimpanan melalui web untuk menyelesaikan pekerjaan mereka. Singkatnya, tren teknologi saat ini adalah teknologi yang menjadikan internet sebagai pusat pengelolaan data dan aplikasi, di mana pengguna komputer diberikan hak akses baik perseorangan maupun banyak orang (<\/span>sharing<\/span><\/i>) disebut sebagai cloud.<\/span><\/p>\n

Tantangannya sekarang adalah untuk mengembangkan <\/span>platform<\/span><\/i> aplikasi <\/span>server-centric<\/span><\/i> yang tersedia untuk jumlah pengguna yang hampir tidak terbatas 24\u00d77 melalui internet menggunakan kebanyakan teknologi berbasis web modern. Pengalaman yang diperoleh dalam dekade terakhir dari beberapa pemimpin teknologi yang menyediakan layanan melalui internet (misalnya Google, Amazon, eBay, dll.), menunjukkan bahwa infrastruktur aplikasi dalam konteks <\/span>cloud<\/span><\/i> harus sangat andal (<\/span>reliability<\/span><\/i>), tersedia (<\/span>available<\/span><\/i>), dan memiliki kemampuan skalabilitas (<\/span>scalability<\/span><\/i>) yang tinggi. Reliabilitas adalah persyaratan utama untuk memastikan akses berkelanjutan ke layanan dan didefinisikan sebagai jaminan bahwa aplikasi atau sistem yang diberikan akan berfungsi ketika diperlukan selama jangka waktu tertentu. Demikian pula, ketersediaan adalah persentase waktu yang diberikan sistem akan berfungsi sesuai kebutuhan. Persyaratan skalabilitas muncul karena fluktuasi beban terjadi dalam konteks layanan berbasis web. Bahkan fluktuasi beban ini terjadi pada berbagai frekuensi: harian, mingguan, dan periode yang lebih lama.<\/span><\/p>\n

Ada kekhawatiran bahwa DBMS dan RDBMS tidak ramah dengan sistem penyimpanan <\/span>cloud<\/span><\/i>. Ini karena tidak seperti komponen teknologi lain untuk layanan cloud seperti server web dan server aplikasi, yang dapat dengan mudah menskalakan dari beberapa mesin menjadi ratusan atau bahkan ribuan mesin), DBMS tidak dapat diskalakan dengan sangat mudah. Bahkan, teknologi DBMS saat ini gagal untuk menyediakan alat dan panduan yang memadai jika penyebaran database yang ada perlu skala dari beberapa mesin ke sejumlah besar mesin.<\/span><\/p>\n

Perbedaan utama adalah bahwa dalam DBMS tradisional, semua data dalam database diperlakukan sebagai “keseluruhan kesatuan data” dan itu adalah tanggung jawab DBMS untuk menjamin konsistensi seluruh data. Dalam konteks penyimpanan <\/span>key-value<\/span><\/i>, hubungan ini sepenuhnya dipecah menjadi <\/span>key-value<\/span><\/i> di mana setiap entitas dianggap sebagai unit independen dari data atau informasi dan karenanya dapat dipindahkan secara bebas dari satu mesin ke yang lain. Selanjutnya, <\/span>atomicity<\/span><\/i> aplikasi dan akses pengguna dijamin hanya pada level <\/span>single-key<\/span><\/i>. Penyimpanan <\/span>key-value<\/span><\/i> bersama dengan kerangka kerja komputasi <\/span>cloud<\/span><\/i> telah bekerja dengan sangat baik dan sejumlah besar aplikasi web telah menggunakan kombinasi teknologi komputasi <\/span>cloud<\/span><\/i> ini.<\/span><\/p>\n

Skalabilitas adalah properti yang menunjukkan kemampuan untuk menangani jumlah beban kerja yang semakin berkembang atau kemampuan untuk meningkatkan throughput ketika sumber daya tambahan (biasanya perangkat keras) ditambahkan. Ada dua metode untuk skalabilitas yaitu secara vertikal dan horizontal. Untuk menskalakan secara vertikal (meningkatkan) berarti menambahkan sumber daya ke satu <\/span>node<\/span><\/i> dalam suatu sistem, biasanya melibatkan penambahan prosesor atau memori ke satu komputer. Untuk skala horizontal (skala keluar) berarti menambahkan lebih banyak <\/span>node<\/span><\/i> ke sistem, seperti menambahkan komputer baru ke aplikasi perangkat lunak terdistribusi.<\/span><\/p>\n

Key-value store<\/span><\/i> menyediakan skalabilitas yang hampir tak terbatas di mana setiap entitas dapat (berpotensi) ditangani oleh <\/span>node<\/span><\/i> independen, persyaratan aplikasi baru muncul yang memerlukan banyak entitas (atau kunci yang setara) untuk diakses secara atom. Berbagai penyimpanan <\/span>key-value<\/span><\/i> berbeda dalam hal model data, ketersediaan, dan jaminan konsistensi, tetapi properti yang umum untuk semua sistem adalah abstraksi key-value di mana data dilihat sebagai pasangan <\/span>key-value<\/span><\/i> dan akses skala kecil hanya didukung pada perincian <\/span>single-key<\/span><\/i>. Semantik akses atom tunggal ini secara alami memungkinkan partisi data horizontal efisien dan menyediakan dasar untuk skalabilitas dan ketersediaan dalam sistem ini. Meskipun mayoritas aplikasi web saat ini memiliki pola akses kunci tunggal, banyak aplikasi saat ini, dan sejumlah besar aplikasi Web 2.0 (seperti yang didasarkan pada kolaborasi) melampaui semantik akses satu tombol dan terjun ke ruang akses <\/span>multi-key<\/span><\/i>.<\/span><\/p>\n

Paradigma Big Data yang\u00a0 muncul, karena proliferasi teknologi, telah menarik perhatian banyak solusi manajemen basis data. Karena variasinya, volume dan variasinya, sulit untuk mengumpulkan, mentransfer, dan menyimpan data sambil menjanjikan kinerja yang baik dalam hal skalabilitas. Karena ledakan <\/span>big data<\/span><\/i> dan kebutuhan untuk skala aplikasi yang sesuai, merancang sistem database <\/span>scalabel<\/span><\/i> telah melihat serangkaian solusi. Namun penyebaran dan penskalaan aplikasi melalui <\/span>cloud<\/span><\/i> telah menghadapi banyak tantangan <\/span>\u00a0dan untuk <\/span>mengatasi tantangan ini, solusi yang ada telah mengadopsi berbagai skalabilitas metrik seperti partisi, replikasi, kontrol konkurensi, dan konsistensi. Keputusan desain ini memastikan skalabilitas baca\/tulis, load balancing tingkat sistem, ketersediaan dan elastisitas. Karena fitur-fitur penting tertentu seperti kemampuan untuk menskalakan secara horizontal, memiliki skema yang fleksibel, konsistensi santai, ketersediaan tinggi (<\/span>high availibility<\/span><\/i>), kemampuan untuk menyimpan data dengan cara terdistribusi dan query sederhana, database NoSQL muncul sebagai pilihan yang mungkin untuk penyimpanan <\/span>big data<\/span><\/i>. Beberapa basis data skalabel utama termasuk Bigtable Google, Dynamo DB Amazon, dan PNUTS milik Yahoo.<\/span><\/p>\n

    \n
  1. Solusi penyimpanan <\/span>big data<\/span><\/i>:<\/span><\/li>\n<\/ol>\n
      \n
    • Google Bigtable<\/b><\/li>\n<\/ul>\n

      Bigtable adalah peta terdistribusi multi-dimensi yang diindeks menggunakan baris dan kunci kolom dan stempel waktu. Setiap nilai dalam bigtable adalah array byte yang tidak diinterpretasi yaitu: (baris: string, kolom: string, timestamp: int64) -> string. Baris dipartisi secara dinamis ke dalam sejumlah rentang baris yang disebut tablet. Tablet berfungsi sebagai dasar untuk load balancing dan partisi. Klien dapat menggunakan konsep ini untuk membentuk kelompok-kelompok lokalitas dan karenanya menghemat waktu untuk secara efektif mencari serangkaian kunci baris. Kunci kolom dikelompokkan bersama untuk membentuk keluarga kolom yang masing-masing mewakili aspek tertentu dari aplikasi. Kunci kolom membentuk dasar untuk kontrol akses di bigtable. Cap waktu memungkinkan penyimpanan beberapa salinan atau versi dari objek yang sama di setiap sel dengan nilai timestamp unik.<\/span><\/p>\n

        \n
      • Amazon\u2019s Dynamo DB<\/i><\/b><\/li>\n<\/ul>\n

        Model data Dynamo terdiri dari pasangan kunci-nilai yang disimpan dalam struktur seperti tabel. Setiap baris dalam tabel memiliki banyak kolom. Ini berbeda dari bigtable dalam konteks bahwa ia tidak memiliki keluarga kolom tetapi memiliki pasangan nama-nilai kolom [4]. Dynamo Amazon menerapkan sejenis arsitektur <\/span>peer-to-peer<\/span><\/i> yaitu semua node simetris dan berbagi kumpulan tanggung jawab yang sama. Dynamo melakukan dua operasi: <\/span>get<\/span><\/i> (<\/span>key<\/span><\/i>) dan put (<\/span>key, context, object<\/span><\/i>), untuk mencari atau menambahkan objek data. Konteks digunakan untuk memverifikasi validitas objek.\u00a0<\/span><\/p>\n

          \n
        • Yahoo\u2019s PNUTS<\/i><\/b><\/li>\n<\/ul>\n

          Tidak seperti Google\u2019s Bigtable, ia memiliki model data relasional yang terdiri dari rekaman dan atribut. Tabel dapat diimplementasikan seperti yang diperintahkan atau didistribusikan dengan hash menyimpan data atau bahkan keduanya. Dalam penyimpanan data yang dipesan, tabel diurutkan berdasarkan kunci primer dan dalam penyimpanan data yang di-hash adalah hash dan kemudian nilai hash itu digunakan untuk mengakses catatan tabel. Predikat atau operasi multi-get digunakan untuk memindai rekaman tertentu. Di kemudian satu set kunci primer dilewatkan ke fungsi dan beberapa catatan kemudian diambil. Ini tidak memiliki fitur batasan referensial. Tabel lebih lanjut dibagi secara horizontal menjadi sekelompok catatan yang disebut tablet yang tersebar di server yang berbeda.\u00a0<\/span><\/p>\n

            \n
          • Google\u2019s BigData<\/b><\/li>\n<\/ul>\n

            Implementasi Bigtable memiliki tiga komponen utama: satu server master, banyak server tablet dan sebuah perpustakaan yang terhubung ke setiap klien. Server master bertanggung jawab untuk mengalokasikan, menghapus atau mempertahankan beban tablet, dll. Server tablet lebih lanjut menangani permintaan baca\/tulis ke tablet yang dimuat di bawahnya dan membagi tablet ke lebih banyak tablet jika peningkatan ukuran <\/span>melampaui ambang batas. Dengan demikian, skalabilitas dicapai secara otomatis segera setelah ukuran tablet melewati ambang batas. Bigtable menggunakan tiga model hierarki tingkat untuk implementasinya seperti yang ditunjukkan pada. Chubby menyimpan file yang berisi lokasi tablet root. Tablet root di sisi lain berisi lokasi tablet yang berbeda di tabel Metadata. Tablet akar diperlakukan khusus dengan cara yang tidak pernah terpecah. Tablet metadata berisi set tabel pengguna<\/span><\/p>\n

              \n
            • Dynamo DB dari Amazon<\/b><\/li>\n<\/ul>\n

              Salah satu persyaratan desain utama Dynamo adalah skalabilitas inkremental. Untuk mencapai ini, partisi dinamis dilakukan menggunakan hashing konsisten. Rentang output hashing yang diambil sebagai cincin melingkar untuk mencapai replikasi, setiap objek data direplikasi pada N host lain. Selain mereplikasi item data, kunci juga direplikasi pada N-1 searah jarum jam node di cincin. Ini menghindari korban di antara versi melalui rekonsiliasi menggunakan jam vektor. Dynamo menggunakan jam vektor, dari format [node, counter], untuk menentukan korban di antara berbagai versi objek.<\/span><\/p>\n

                \n
              • FluteDB<\/b>: <\/span>An efficient and scalable in-memory time series database for sensor-cloud<\/span><\/i><\/li>\n<\/ul>\n

                Kepopuleran dari <\/span>Internet of Things<\/span><\/i> (IoT), <\/span>wireless sensor network<\/span><\/i> (WSN), <\/span>Smart City<\/span><\/i> (SC), dan lain sebagainya yang berhubungan dengan internet hotspot membuat banyaknya data time series ter<\/span>generate <\/span><\/i>secara terus menerus untuk mengantri dalam hal pemrosesannya. Dengan adanya kepopuleran data time series secara terus menerus berbagai penemuan algoritma mining telah banyak dikembangkan, seperti Real Time Vehicle Traffic (RTVT), Smart Grid (SG). Sebagai dasar beberapa downstream algoritma, cara penyimpanan dan query pada data time series yang efisien serta stabil merupakan fokus perhatian utama dalam servis cloud. Peningkatan permintaan <\/span>source data<\/span><\/i> dan komputasi <\/span>realtime<\/span><\/i> pada servis cloud, perangkat multimedia yang tersedia dan interval yang sangat cepat beberapa waktu terakhir ini mengakibatkan perkembangan skala yang sangat cepat pada data <\/span>time series<\/span><\/i> langsung. Disamping itu, servis yang terpercaya serta ketersediaan jaminan servis <\/span>time series <\/span><\/i>juga harus dipersiapkan sebaik mungkin untuk mengindari kesalahan dan recovery data yang sangat diperlukan<\/span>.<\/span><\/p>\n

                Beberapa spesifikasi yang menjadi target dari proyek <\/span>time series<\/span><\/i> database <\/span><\/i>(TSDB) adalah efisiensi, reliabilitas, dan ketersediaan dari semua sub modul dan sistem didalamnya. Beberapa batasan baku pada TSDB diantaranya:<\/span><\/p>\n

                Write<\/i><\/b> yang mendominasi<\/b>: kebutuhan primer pada TSDB adalah untuk menjaga servis tetap stabil walaupun dengan rata-rata keadaan <\/span>write<\/span><\/i> yang sangat tinggi. Karena realita saat ini aplikasi cloud (<\/span>time series <\/span><\/i>servis) selalu <\/span>write <\/span><\/i>jutaan permintaan pada tiap detiknya.<\/span><\/p>\n

                Manajemen Query<\/b>: pada kenyataannya mendapatkan query yang efisien masih sangat sulit pada skala time series data yang sangat besar<\/span><\/p>\n

                Kontrol Sumber Daya<\/b>:\u00a0 Kualitas hardware (mencakup memory dan disk) adalah indikator yang penting dalam evaluasi penyimpanan cloud. Karena dengan banyaknya logs, teks, dan streaming data akan sangat banyak mengonsumsi banyak ruang penyimpanan,<\/span><\/p>\n

                Reliabilitas dan ketersediaan yang tinggi<\/b>: apabila kedua indicator ini terpenuhi maka kemampuan servis cloud yang normal dan <\/span>fault tolerant<\/span><\/i> akan terpenuhi.<\/span><\/p>\n

                \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span> FluteDB adalah TSDM terbarukan dimana dapat menjawab segala batasan yang telah dijelaskan sebelumnya, serta menyediakan efisiensi, skalabilitas, dan kestabilan servis cloud. Salah satu ide dibalik fluteDB adalah untuk membuat keseluruhan arsitektur lebih cenderung<\/span> untuk optimasi operasi <\/span>write<\/span><\/i> yaitu mengubah performa <\/span>write <\/span><\/i>saat operasi query maupun penerimaan data yang presisi. Untuk mencapai tujuan tersebut maka fluteDB mengubah pengaturan sruktur indexing, komponen query, optimasi konfigurasi, kompressi data, enkapsulasi data serta penggunaan dari berbagai <\/span>resource <\/span><\/i>yang berbeda.<\/span><\/p>\n

                  \n
                • SCADIS<\/b>: <\/span>Supporting Reliable Scalability in Redis Replication on Demand<\/span><\/i><\/li>\n<\/ul>\n

                  Melalui replikasi, Redis telah memainkan peran utama dalam peningkatan keandalan dan kinerja sistem <\/span>database <\/span><\/i>NoSQL di samping menerapkan karakteristik tambahan seperti fleksibilitas dan skalabilitas basis data. Namun, sementara Redis memungkinkan replikasi data yang cukup mudah, replikasi menjadi sulit ketika diterapkan ke <\/span>database<\/span><\/i> bervolume tinggi. Akibatnya, <\/span>scalling database<\/span><\/i> yang efektif menjadi tugas besar dalam pengembangan dan pemeliharan skala besar. Pendekatan baru, SCADIS, dapat meringankan masalah kritis dalam skalabilitas <\/span>database<\/span><\/i>. Pendekatan ini menyajikan tiga fitur utama: 1) mengurangi waktu konfigurasi selama proses yang mendukung pada <\/span>foreground<\/span><\/i> atau <\/span>background<\/span><\/i>, 2) kemampuan\u00a0 <\/span>master node failover <\/span><\/i>otomatis, dan 3) layanan <\/span>High Availability<\/span><\/i> (ketersediaan tinggi) untuk monitoring <\/span>cluster <\/span><\/i>Redis.<\/span><\/p>\n

                  Scadis dijalankan dengan Zookeeper dan ditulis dengan bahasa pemrograman Java. SCADIS dirancang ke dalam dua bagian. Salah satu bagiannya adalah Daemon Server, yang mengeksekusi <\/span>background <\/span><\/i>untuk memantau <\/span>database<\/span><\/i> cluster<\/span><\/i>. Selain untuk pemantauan, Daemon Server juga menyediakan layanan pemberitahuan untuk program klien. Bagian kedua adalah <\/span>client stub<\/span><\/i> dimana penulis menyediakan\/menyesuaikan kode berdasarkan <\/span>requirement <\/span><\/i>yang berbeda. Arsitektur Scadis terdiri dari 3 modul:<\/span><\/p>\n

                    \n
                  1. Modul Konfigurasi<\/b>. Modul ini menawarkan waktu konfigurasi ulang paling sedikit yang juga mendukung proses <\/span>background <\/span><\/i>dan <\/span>foreground <\/span><\/i>ketika slave node sedang dijalankan ataupun tidak.<\/span><\/li>\n
                  2. Modul Failover Otomatis<\/b>. Modul ini menyediakan cluster database yang handal melalui manipulasi <\/span>master node<\/span><\/i> dan <\/span>slave node<\/span><\/i> dengan gangguan seminimal mungkin. Jika pada <\/span>master node<\/span><\/i> mengalami kegagalan, maka<\/span> slave node<\/span><\/i> secara otomatis menggantikan <\/span>master node<\/span><\/i> tersebut. Setelah <\/span>master node <\/span><\/i>tadi sudah pulih, ia akan secara otomatis diturunkan menjadi <\/span>slave node<\/span><\/i>.<\/span><\/li>\n
                  3. Modul Monitoring HA<\/b> (<\/span>High Availability<\/span><\/i>). Modul ini sangat berkaitan dengan layanan Zookeeper. Karena properti koordinasi (<\/span>the coordination property<\/span><\/i>) dalam Zookeeper, Modul Monitoring HA menjadi dapat diprogram dan dikelola untuk memantau metadata, status server, dan beban kerja semua <\/span>node <\/span><\/i>dalam Scadis.\u00a0<\/span><\/li>\n<\/ol>\n

                    Note:\u00a0<\/span><\/i><\/p>\n

                    * Konsep <\/span>failover<\/span><\/i> menggambarkan apabila suatu node <\/span>down <\/span><\/i>maka node yang lainnya akan mengambil alih tugas node yang <\/span>down <\/span><\/i>tersebut. Dalam infrastruktur <\/span>high availability cluster<\/span><\/i> yang hanya terdiri dari dua node, hal ini dapat diistilahkan sebagai hubungan antara <\/span>master <\/span><\/i>(<\/span>primary<\/span><\/i>) dan <\/span>slave <\/span><\/i>(<\/span>secondary<\/span><\/i>). Jika pada <\/span>master node<\/span><\/i> mengalami kegagalan, maka <\/span>slave node<\/span><\/i> yang akan bertugas menggantikan tugas dari <\/span>master node<\/span><\/i> tersebut.<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

                    \u00a0<\/span><\/p>\n

                    Referensi:<\/b><\/p>\n

                    Agrawal D., Abbadi A., Das S., Elmore A., 2011, <\/span>Database Scalability, Elasticity, and Autonomy in the Cloud<\/span><\/i>. University of California Santa Barbara. Santa Barbara.<\/span><\/p>\n

                    Kaur P., Sharma., 2015, <\/span>Scalable Database Management in Cloud Computing<\/span><\/i>, International Conference on Eco-friendly Computing and Communication System.<\/span><\/p>\n

                    Li Z., Kimm H., Kimm H., 2017, <\/span>SCADIS:<\/span><\/i> Supporting Reliable Scalability in Redis Replication on Demand<\/span><\/i>, 2017, IEEE International Conference on Smart Cloud.<\/span><\/p>\n

                    Li C., Li B., Bhuiyan M., Wang L., Si J., Wei., Li J., 2018, <\/span>FluteDB: An Efficient and Scalable In-memory Series Database for Sensor-cloud<\/span><\/i>, J. Parallel Distrib. Comput, 122(2018) 95-108.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                    Beberapa orang akan berpendapat bahwa teknologi penyimpanan data telah memperkaya kehidupan pengguna juga telah menimbulkan beberapa tantangan dan kompleksitas baik dari sudut pandang pengguna maupun dari penyedia layanan atau perspektif sistem. Dari sudut pandang pengguna, pengguna harus menavigasi beberapa platform komputasi dan penyimpanan melalui web untuk menyelesaikan pekerjaan mereka. Singkatnya, tren teknologi saat ini adalah […]<\/p>\n","protected":false},"author":45,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-994","post","type-post","status-publish","format-standard","hentry","category-articles"],"_links":{"self":[{"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/posts\/994","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/users\/45"}],"replies":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/comments?post=994"}],"version-history":[{"count":1,"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/posts\/994\/revisions"}],"predecessor-version":[{"id":995,"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/posts\/994\/revisions\/995"}],"wp:attachment":[{"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/media?parent=994"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/categories?post=994"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/binus.ac.id\/malang\/computer-science\/wp-json\/wp\/v2\/tags?post=994"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}