NoSQL-dan-Column Based

Saat ini permasalahan yang muncul sudah mencapai tahap yang berskala dunia (web) dengan
pelibatan data besar (big data). Pendekatan secara relational dianggap kurang mendukung
kebutuhan tersebut. Hal ini disebabkan secara teknologi kemampuan untuk mudah diperluas jika
data dengan cepat bertambah sukar dipenuhi karena pada RDBMS kemudahan tersebut hanya
dalam bentuk vertical scalable. Dengan perluasan secara vertical suatu saat resources tidak
mungkin dapat diperluas lagi. Oleh karena itu perluasan diperlukan secara horizontal dimana
data secara fisik disimpan di banyak tempat (terdistribusi). Selain itu model relational
mempunyai sifat yang terstruktur sedemikian sehingga data dalam keadaan ternormalisasi.
Dengan keadaan data yang ternormalisasi maka untuk memperoleh informasi sering dibutuhkan
operasi join dari dua atau lebih table, yang mana pada jumlah data yang besar dan terdistribusi
hal ini akan membutuhkan tambahan waktu pemrosesan yang tidak sedikit.

1. Nosql Dan Pergeseran Arsitektur Database

Pergeseran paradigma mulai terjadi pada akhir 1990-an dan awal milenium baru. Evolusi
Internet, dan ledakan data yang dihasilkannya, memaksa banyak raksasa Internet yang sedang
berkembang untuk mempertimbangkan kembali cara-cara baru untuk menangani data mereka.
Hal yang sama dapat dikatakan untuk organisasi yang lebih kecil, dan startup yang melihat
pertumbuhan pemrosesan berbasis web sebagai tambang emas tanpa akhir. Maka dimulailah
pergeseran yang diperlukan dari penyimpanan data relasional ke penyimpanan data non-
relasional, yang sekarang dikenal sebagai NoSQL atau “Not Only SQL.” Perkembangan
arsitektur non-relasional telah menjadi bagian dari diskusi database selama beberapa dekade,
tetapi tidak benar-benar berakar sampai akhir 1990-an dengan karya Carlo Strozzi dan lainnya.
Strozzi menciptakan istilah "NoSQL" pada tahun 1998 dengan penciptaan model databasenya
yang masih relasional, yang tidak lagi menggunakan SQL sebagai bahasa pemrogramannya
(istilah itu diperkenalkan kembali pada pertemuan tahun 2009 oleh Eric Evans dan Johan
Oskarsson dan sejak itu macet). Pemain besar lain yang membantu menyebabkan perubahan
seismik dalam teknologi basis data saat ini adalah:
1997 – Publikasi Standar MDX Microsoft
2000 - Neo4j
2000 - Dr. Eric Brewer’s CAP Theorem
2003 - Pengembangan Memcached
2003 - Publikasi artikel “The Google File System”
2004 – Publikasi artikel “MapReduce: Simplified Data Processing on Large Clusters”
2005 - CouchDB
2006 – Publikasi artikel “Bigtable: A Distributed Storage System for Structured Data”
2006 – Spesifikasi bahasa XQuery oleh WC3
2007 – Publikasi artikel “Dynamo: Amazon’s Highly Available Key-value Store”
Pergeseran telah dimulai dimana sekarang telah lebih banyak lagi penyimpanan data non-
relasional terdistribusi, seperti MongoDB, Cassandra, Project Voldemort, Terrastore, Redis,
Riak, HBase, dan lainnya tersedia di pasar. Peristiwa yang tercantum di atas hanyalah ringkasan
dari begitu banyak pekerjaan lain yang juga terjadi di industri pada saat itu. Mereka mewakili

0
mikrokosmos ratusan, jika bukan ribuan, organisasi yang lebih kecil dan pemimpin pemikiran
yang bekerja untuk memajukan industri ke tempat ia berdiri saat ini. Dorongan untuk perubahan
seperti itu terjadi karena banyak faktor, yang paling tidak meliputi:
• Data yang tidak terstruktur tidak cocok dengan struktur tabular relasional, dan proliferasi
begitu banyak format data yang berbeda memerlukan kemampuan penyimpanan baru.
• Penskalaan vertikal terbukti terlalu mahal dan tidak dapat menangani ekspansi data besar.
• RBDMS tradisional tidak lagi dapat menangani kebutuhan throughput tinggi yang diperlukan
oleh organisasi seperti Google atau Amazon.
• Kompleksitas pemetaan objek-relasional tidak diperlukan untuk banyak tugas aplikasi
berbasis web.
• Predefined Schema terlalu membatasi di dunia baru di mana skema perlu cepat beradaptasi.
• Biaya administrasi paradigma lama, di mana server dimiliki sendiri, menjadi terlalu mahal;
"Cloud" off-site dapat memberikan alternatif yang lebih murah dan "out scaling" sistem
terdistribusi yang lebih cepat.
• Persyaratan ACID terlalu membatasi untuk banyak permintaan Internet; beberapa kendala
harus dilonggarkan.
Pengembang aplikasi membutuhkan inovasi baru di luar arsitektur basis data tradisional berbasis
tabel SQL yang telah mengatur industri sejak awal. Raksasa internet seperti Google, Amazon,
Facebook, LinkedIn, dan lainnya membangun desain mereka sendiri atau mengubah yang
tersedia secara bebas di pasar, dan membantu merevolusi industri dalam prosesnya. Banyaknya
startup yang lebih kecil membutuhkan alternatif yang lebih murah, dan komunitas open source
melangkah untuk mengisi kekosongan dengan pengembangan banyak desain database gratis atau
berbiaya rendah. Pergeseran telah menyebar ke seluruh penjuru industri, dan ada beberapa
alternatif.
Daftar di atas sama sekali tidak lengkap, tetapi hanya menguraikan beberapa insentif utama yang
membantu mempercepat munculnya penyimpanan data non-relasional dan akronim yang
sekarang populer di dunia keandalan transaksi basis data adalah BASE.

Model Keandalan (Reliability) Transaksi

Masalah utama yang dibahas dalam makalah ini bermuara pada dua model keandalan database
yang berbeda:
- ACID (Atomicity, Consistency, Isolasi, dan Durability) dan
- BASE (Pada dasarnya Tersedia, Soft state, Akhirnya konsistensi).
Yang pertama (ACID) telah ada selama sekitar 30+ tahun, adalah standar industri yang telah
terbukti untuk database SQL-centric dan relasional lainnya, dan bekerja sangat baik di dunia
yang lebih tua, namun masih ada, dunia penskalaan vertikal.
Yang kedua (BASE) baru-baru ini mendapatkan popularitas selama 10 tahun terakhir, terutama
dengan munculnya jejaring sosial, Big Data, NoSQL, dan mahluk besar (leviathans) lain di dunia
baru Manajemen Data. Persyaratan BASE muncul dari kebutuhan untuk memperluas jaringan
terdistribusi berskala horizontal, dengan penyimpanan data non-relasional, dan kendala
ketersediaan waktu nyata dari pemrosesan transaksi berbasis web. Sementara sekarang ada lebih
banyak penyebrangan dan negosiasi antara kedua model, mereka pada dasarnya mewakili dua

1
kelompok yang bersaing, dengan Teorema CAP Brewer bertindak sebagai wasit di tengah-tengah
memaksa keputusan sulit pada setiap tim.
Sistem basis data relasional hampir selalu merupakan keluhan ACID karena pengindeksan
relasional terpusat sehingga tidak ada keuntungan dalam BASE. Basis data ACID berfungsi
seperti unit yang sepenuhnya konsisten dengan pembaruan transaksional; sementara sistem
BASE berfungsi seperti unit independen yang pada akhirnya konsisten, dan tanpa pembaruan
transaksional. Tidak ada pilihan lain selain sistem relasional di masa lalu; tetapi munculnya
NoSQL sekarang memberi organisasi yang membutuhkan model berbeda lebih banyak pilihan.
Mereka dapat melakukan ACID atau BASE, sehingga varietasnya jauh lebih besar. Sekarang
dimungkinkan untuk memberikan kendala ACID dan fitur perusahaan lainnya dalam sistem
NoSQL tertentu jika itu yang diperlukan organisasi untuk memenuhi kebutuhannya.

ACID - Gambaran Umum Singkat

Pekerjaan utama dengan kendala keandalan database dimulai pada 1970-an dengan Jim Gray.
Dia merumuskan tiga elemen pertama dari akronim - Atomicity, Consistency, dan Durability -
dalam seminal works1 "Konsep Transaksi: Kebajikan dan Keterbatasan" yang diterbitkan pada
tahun 1981. Makalah ini melihat transaksi dalam hal hukum kontrak, dimana setiap transaksi
harus sesuai dengan "transformasi kondisi sistem" tertentu. Semua transaksi harus mematuhi
undang-undang yang ditentukan dalam parameter kontrak. Menurut Gray, setiap transaksi dalam
basis data harus mematuhi protokol, baik yang terjadi atau tidak terjadi, dan tidak dapat diubah
setelah commited. Pada 1979, Bruce Lindsay et al. diperluas pada temuan awal Grey dengan
makalah mereka "Catatan tentang Basis Data Terdistribusi." Makalah ini berfokus pada hal-hal
penting untuk mencapai konsistensi dalam sistem manajemen basis data terdistribusi, replikasi
data, otorisasi dan kontrol akses, manajemen pemulihan, komitmen dua tahap (two phase
protocol), dan lainnya. Elemen dasar terakhir ACID datang pada tahun 1983 dengan publikasi
makalah Andreas Reuter dan Theo Härder "Prinsip Pemulihan Basis Data Berorientasi
Transaksi." Mereka menambahkan prinsip Isolasi ke dalam diskusi dan secara resmi
menciptakan akronim ACID; telah bertahan selama 30 tahun terakhir sebagai batasan yang
sangat diperlukan untuk mencapai keandalan dalam transaksi basis data, dan secara sederhana
berarti:
• Atomicity: Semua operasis dilaksanakan atau tidak sama sekali. Jika satu bagian dari
transaksi gagal maka semua gagal.
• Consistency: Transaksi harus mematuhi semua aturan yang didefinisikan oleh sistem
pada semua waktu; tidak ada transaksi selesai setengah.
• Isolation: Setiap transaksi independen.
• Durability: Setelah selesai transaksi tidak dapat dikembalikan (undone)
Kendala ACID telah menyediakan pemrosesan transaksi dengan fondasi yang dapat diandalkan
untuk membangun selama beberapa dekade, dan akan terus berlanjut jika bukan karena
munculnya Internet, pertumbuhan penyimpanan data terdistribusi, peningkatan volume dan
variabilitas data yang belum pernah terjadi sebelumnya, kebutuhan untuk mendokumentasikan
dan menyimpan data yang tidak terstruktur, dan kebutuhan selanjutnya akan lebih banyak
fleksibilitas dalam hal penskalaan, desain, pemrosesan, biaya, dan pemulihan kerusakan. Ini
bukan klaim bahwa persyaratan ACID tidak lagi penting untuk pemrosesan transaksi, karena

2
mereka tetap penting. Aplikasi skala web, penyimpanan data non-relasional, dan distribusi pusat
data global membutuhkan penciptaan alternatif baru.
Namun demikian, dengan evolusi baru di bidang basis data, sekarang dimungkinkan untuk
memiliki basis data NoSQL yang berfungsi penuh yang sesuai dengan kepatuhan ACID yang
ketat - sistem seperti itu masih jarang ada dalam industri saat ini, tetapi sekarang ada untuk
organisasi yang membutuhkan sebuah evolusi.

CAP Dan BASE

BASE adalah akronim yang cerdas, terutama ketika disejajarkan dengan ACID - para profesional
data adalah ahli kimia dari jagat TI. Meskipun tidak diketahui secara pasti siapa yang mengawali
istilah tersebut, kebanyakan orang memberikan kredit kepada Dr. Eric Brewer untuk paling tidak
mempopulerkan istilah tersebut. Pada tahun 2000, pidatonya di Simposium ACM berjudul
“Menuju Sistem Terdistribusi Kuat” terbukti menjadi momen yang bersinar ketika banyak orang
di industri menganggukkan kepala dan tahu, setidaknya dalam keberanian mereka, bahwa
perubahan penting ada di cakrawala. BASE pada dasarnya adalah kebalikan dari ACID, dengan
batasan yang mensyaratkan:
Basically Available – Sistem menjamin beberapa level ketersediaan data bahkan karena terdapat
node gagal. Data mungkin stale (tidak up to date-basi), tetapi ia masih memberikan dan
menerima responses.
Contoh: Couchbase Server adalah penyimpan dokumen yang dibangun untuk
ketersediaan tinggi dalam lingkungan NoSQL terdistribusi. Ia memberikan
skalabilitas yang mudah di dalam Cloud atau di server komoditas standar. Ini
memberikan konsistensi penuh, dengan nol downtime aplikasi, extensive range of
query dan dukungan indeks, MapReduce tambahan, sharding otomatis, replikasi
lintas-cluster, dan dukungan native untuk dokumen JSON.
Soft State – data dalam keadaan konstan aliran, jadi sementara respons mungkin diberikan,
kesegaran atau konsistensi data tidak dijamin paling mutakhir.
Eventual Consistency – data pada akhirnya akan konsisten melalui semua node dan di semua
basis data, tetapi tidak setiap transaksi setiap saat. Ini akan mencapai beberapa kondisi terjamin
pada akhirnya.
Berikut penjelasan Brewer sifat-sifat penting dari kedua model:
ACID BASE
Strong Consistency Weak Consistency – stale data OK
Isolation Availability first
Focus on “commit” Best effort
Nested transactions Approximate answers OK
Availability? Aggressive (optimistic)
Conservative (pessimistic) Simpler!
Difficult evolution (e.g. schema) Faster
Easier evolution
Dia menekankan bahwa seluruh keseimbangan antara keduanya adalah spektrum; insinyur
database harus memilih secara spesifik apa yang mereka butuhkan dan inginkan dibandingkan
dengan apa yang bisa mereka capai ketika mengembangkan aplikasi khusus mereka. Fokus nyata
3
dari pertentangan antara dua model yang bersaing ditunjukkan dengan Teorema CAP Brewer,
yang menguraikan tiga karakteristik utama dari pemrosesan transaksi basis data, dan berpendapat
bahwa hanya dua karakteristik yang dapat dipenuhi pada waktu tertentu. Tiga elemen utama
CAP (Consistency, Availability, dan Toleransi Partition) telah diperluas untuk mencakup lebih
banyak detail, bersama dengan eksperimen ekstensif oleh para insinyur di seluruh dunia untuk
memverifikasi dan mengukur hasil dunia nyata dari teorema semacam itu.

Konsistensi - Bagaimana Data Diberi?

Batasan ACID memberikan konsistensi yang kuat, sepanjang waktu, apa pun yang terjadi.
Namun, persyaratan semacam itu sering berakibat terutama tentang ketersediaan. Jika sistem
harus selalu tetap dalam kondisi yang konsisten, sehingga semua pihak melihat tampilan data
yang sama di awal dan akhir transaksi, maka di ribuan node bahwa data mungkin tidak selalu
tersedia. Dampak yang sama mempengaruhi pemulihan kerusakan dan hilangnya node - jika satu
bagian dari database terdistribusi runtuh, maka konsistensi yang kuat tidak akan memungkinkan
pembaruan lebih lanjut sampai seluruh sistem disesuaikan. Dengan demikian, kita sampai pada
sejumlah jaminan konsistensi lainnya:
A. Strong (Strict) Consistency - Semua operasi baca mengembalikan nilai dari operasi penulisan
terakhir yang diselesaikan. Tidak masalah di replica mana operasi penulisan tersebut terjadi;
semua replika harus dalam keadaan yang sama agar operasi berikutnya terjadi pada nilai-nilai itu.
B. Eventual Consistency - Ini memiliki variabilitas terbesar dari potensi nilai yang dikembalikan.
Pada titik tertentu pembaca akan melihat beberapa nilai tertulis, tetapi tidak ada jaminan bahwa
dua pembaca akan melihat tulisan yang sama persis. Semua replika pada akhirnya akan memiliki
pembaruan terbaru; hanya masalah waktu kapan itu akan terjadi.
C. Monotonic Read Consistency - Ini juga dikenal sebagai jaminan sesi. Pembacaan mirip
dengan eventual consistency dalam data yang masih bisa basi; tetapi monotonic read consistency
menjamin bahwa seiring waktu klien akan mendapatkan pembacaan yang lebih baru (atau
pembacaan yang sama) jika mereka meminta pembacaan dari objek yang sama.
D. Read Your Own Write (atau Read My Writes) - menjamin bahwa klien selalu membaca
tulisan terbaru mereka, tetapi yang lain mungkin tidak melihat pembaruan yang sama. Tidak
masalah replika apa yang akan ditulis, klien selalu melihat yang paling baru.
E. Causal Consistency - jika klien membaca satu nilai (a) dan kemudian menulis nilai berikutnya
(b), dan klien lain kemudian membaca nilai (b) mereka juga akan melihat nilai (a) karena mereka
terhubung ke satu sama lain. Oleh karena itu, setiap tulisan yang terkait secara kausal harus
dilihat oleh semua proses dalam urutan spesifik yang dituliskan.

Some supporting Materials

4
ACID Properties
o Atomicity- All included statements in a transaction are either executed or the whole
transaction is aborted without affecting the database.
o Consistency- A database is in a consistent state before and after a transaction.
o Isolation- Transactions can not see uncommitted changes in the database.
o Durability- Changes are written to a disk before a database commits a transaction so that
committed data cannot be lost through a power failure.
Consistency
o Strong consistency- After an update completes, any subsequent access will return the
updated value.

o Eventual consistency
• Does not guarantee that subsequent accesses will return the updated value.
• Inconsistency window.
• If no new updates are made to the object, eventually all accesses will return the last
updated value.

5
 C

Consistency vs. Availability

o The large-scale applications have to be reliable: availability + redundancy
o These properties are dificult to achieve with ACID properties.
o The BASE approach forfeits the ACID properties of consistency and isolation in favor of
availability, graceful degradation, and performance.
BASE Properties
o Basic Availability- Possibilities of faults but not a fault of the whole system.
o Soft-state- Copies of a data item may be inconsistent
o Eventually consistent- Copies becomes consistent at some later time if there are no more
updates to that data item

CAP Theorem

o Consistency- Consistent state of data after the

execution of an operation.
o Availability- Clients can always read and
write data.
o Partition Tolerance- Continue the operation in
the presence of network partitions.
You can choose only two!

Availability: Each client can

always read and write

Aster Data
GreenPlum
Dynamo Cassandra
RDBMSs Vertica CA AP Voldemort SimpleDB
(MySQL,
Tokyo CouchDB
PostGres,
Cabinet Riak
Etc) Pick Two KAI
C P
CP Partition Tolerance: The
Consistency: All system work well despite
clients always Big Table MongoDB BerkeleyDB physical network partitions
have the same Hypertable TerraStore MemCache
view of the data HBase Scalaris Redis

6
The Question Of Database Transaction Processing: An Acid, Base, Nosql Primer
By Charles Roe
Bayangkan sebuah dunia di mana Teorema CAP salah. Insinyur basis data dan perancang
aplikasi sekarang memiliki kendali mutlak atas setiap transaksi, setiap saat, di seluruh planet,
tidak peduli berapa banyak node terdistribusi yang dimiliki perusahaan. Sistem relasional
sekarang dengan senang hati hidup bersama dengan agregat dari setiap dan semua desain non-
relasional. Tidak lagi menjadi masalah jika perusahaan ingin menggunakan serangkaian basis
data SQL-sentris dalam koleksi Key-Value, Berbasis Dokumen, Berorientasi Kolom, dan Graf
yang berkembang - semuanya cocok bersama-sama. Aplikasi BI mereka bekerja bersama untuk
mengumpulkan data secara tepat waktu dari setiap platform, mereka telah mencapai 99,999%
uptime, node dengan cepat dan mudah ditambahkan dengan hanya mengklik tombol, setiap
transaksi konsisten dalam dirinya sendiri setiap saat tanpa soft state , eventuality, atau latensi,
dunia adalah tempat yang lebih baik. Jika Anda ingin konsistensi yang kuat, dengan
ketersediaan tinggi, melalui jaringan terdistribusi 100.000 server komoditas murah, dengan
kepatuhan ACID total, maka Anda beruntung!
Anekdot di atas dimaksudkan untuk menyajikan visi utopis yang sepenuhnya benar - dalam
semua kasus - akan membuat kehidupan semua orang di bidang basis data dan desain aplikasi
jauh lebih mudah. Mereka dapat merancang sistem yang murah dan sempurna yang hanya
bekerja dan bekerja, untuk semua orang, setiap saat. Pada sisi negatifnya, itu juga akan membuat
banyak pekerjaan mereka menjadi mubazir. Beruntung bagi banyak organisasi yang terlibat
dalam industri seperti itu, fantasi utopis jauh dari kenyataan. Tapi seberapa jauh jaraknya?
Apakah tidak ada beberapa platform yang menyediakan integritas transaksional lengkap dalam
sistem non-relasional? Apakah tidak ada mediasi antara model yang bersaing yang bertemu di
suatu tempat di antara keduanya?
Sebenarnya ada banyak elemen dari visi yang bekerja bersama. ACID dan NoSQL bukan
antagonis yang dulu dianggap; NoSQL bekerja dengan baik di bawah model BASE, tetapi juga
beberapa sistem NoSQL inovatif sepenuhnya sesuai dengan persyaratan ACID. Para insinyur
basis data telah bingung bagaimana caranya agar sistem non-relasional bekerja dalam lingkungan
yang menuntut ketersediaan tinggi, skalabilitas, dengan tingkat pemulihan dan toleransi partisi
yang berbeda. BASE masih merupakan inovasi terkemuka yang melekat pada model NoSQL,
dan evolusi keduanya secara bersamaan harmonis. Tetapi itu tidak berarti mereka harus selalu
bermitra; ada beberapa opsi. Jadi, meskipun anekdot pembuka adalah benar dalam banyak kasus,
organisasi yang membutuhkan lebih banyak kemungkinan beragam dapat pindah ke arena
komersial dan mendapatkan opsi spesifik yang paling sesuai untuk mereka.
Deskripsi Beberapa Model NoSQL
Secara umum yang termasuk dalam model tidak terstruktur berikut dengan beberapa contoh:
▪ Document oriented: MongoDB, CouchDB, RavenDB, Couchbase, ElasticSearch
▪ Column oriented: HBase, MapR-DB, Hypertable, Cassandra
▪ Graph database: OrientDB, DEX, Neo4J, GraphBase
▪ Key-Value: Couchbase, Riak, Citrusleaf, Redis, BerkleyDB, Membrain
Beberapa model yang akan dibahas lebih lanjut adalah column oriented dan document oriented
dan Graph database.

7
Cassandra
Best used: When you write more than you read (logging). If every component of the system must be in
Java.
For example: Banking, financial industry (though not necessarily for financial transactions, but these
industries are much bigger than that.) Writes are faster than reads, so one natural niche is real time data
analysis.

2. Model Column Oriented

Pada model relational (terstruktur) setiap data diorganisasi dalam suatu table yang terdiri dari
banyak baris dimana dalam satu baris mengandung banyak kolom. Semua baris tersebut
berukuran sama, yaitu semua baris mempunyai jenis dan jumlah kolom yang sama. Kontras
dengan model relational tersebut, model NoSQL (tidak terstruktur) mengorganisasi data dalam
suatu table dimana setiap baris dapat mempunyai kolom yang berbeda baik jenis maupun
instancesnya. Konsekuensinya model NoSQL ini akan berupa table yang bersifat tidak penuh
seperti halnya sparse matrices.
2.1. Model Data Logik (HBase)
Model data dari column oriented adalah table yang terdiri dari banyak baris dan setiap baris
terdiri dari banyak kolom dimana setiap baris dapat mempunyai kolom yang berbeda. Selain itu
nilai kolom tertentu dari baris tertentu dapat lebih dari satu, oleh karena itu dibutuhkan suatu
penanda yang disebut timestamp. Pada table, untuk setiap baris diperlukan pembeda yang disebut
sebagai rowkey dan kolom-kolom diorganisasi dalam satu atau lebih column family.
Berikut adalah table yang mewakili model data column oriented dari HBase, terdiri dari kolom A
sebagai rowkey, selanjutnya kolom B dan C yang merupakan satu column family yang sama, dan
diakhiri dengan kolom D dan E dalam satu column family lain yang sama.

RowKey Column Family-1 Column Family-2

A B C D E
a1 b1 c1 d1 e1
a2 c2
a3 b31 c3 e31, e32
Gambar 2-1. Ilustrasi Tabel Mewakili Model Column Oriented
Seperti tampak pada Gambar 2.1, terdapat sel yang kosong dimana ini menandakan baris tersebut
tidak mempunyai kolom yang bersangkutan contoh a2 tidak mempunyai kolom B dan D. Lebih
jauh lagi terdapat situasi dimana satu sel mempunyai banyak nilai, contoh di atas adalah a3
mempunyai kolom E bernilai e31 dan e32. Dengan pembeda timestamp maka nilai kolom E dari
a3 adalah time-1 bernilai e31 dan time-2 bernilai e32. Maka secara implisit dikatakan bahwa
setiap sel mempunyai timestam p dan nilainya. Dari model yang telah dideskripsikan akan
terjadi situasi banyak kolom tidak terisi (seperti halnya sparse matrices) dan sebaliknya nilai sel
dapat multivalue juga. Untuk mendapatkan nilai sel diperlukan alamat sel tersebut, dimana

8
alamat sel ditentukan dari konstruksi key yang merepresentasikan sel tersebut atau dapat disebut
sebagai pasangan key → value.
Konstruksi key adalah sel itu sendiri seperti halnya sel pada table atau matrices yang kemudian
diperdetil dengan penanda waktu yaitu: Baris, kolom, timestamp. Konstruksi ini disesuaikan
menjadi Rowkey, ColumnFamily:kolom, timestamp, yang selanjutnya untuk membedakan dari
table mana maka konstruksi menjadi Tabel, Rowkey, ColumnFamily:kolom, timestamp.
Konstruksi ini mirip dengan model data Key → Value, bedanya adalah pada column oriented
khususnya HBase, satu sel dapat mempunyai banyak nilai (dengan penanda timestamp). Dalam
kerangka Key → Value maka konstruksi di atas menjadi:
[Tabel, Rowkey, ColumnFamily:kolom, timestamp] → Value
Pada Gambar-2.2 berikut adalah ilustrasi instances model data column oriented dari HBase.
Tabel ini merepresentasikan civitas academica JTK-Polban yang terdiri dari mahasiswa, pegawai
administrasi dan dosen.

Rowkey CF:BasicInfo CF:ClassGrades

Email Name Office Database Diskrit-2
aaa@[Link] t0:aaa t1:LH201
t2:IE339
bbb@[Link] t3:bbb t4:A t5:I
t6:A
Gambar 2-2. Tabel CivitasJTK
Penjelasan sampai sejauh ini belum memperlihatkan makna “column oriented” yang dimaksud,
namun akan lebih jelas setelah pembahasan model fisiknya.
2.2. Model Fisik (HBase)
Seperti telah disebutkan sebelumnya, model data column oriented mempunyai konsekuensi
terjadi keadaan data sparse dimana penggunaan ruang menjadi tidak efisien bila model fisik
mengikuti apa adanya. Untuk menghilangkan keadaan ini sparse tidak disertakan, dan hanya
kolom yang mempunyai nilai saja yang direpresentasikan seperti berikut ini.
Lebih jauh lagi, karena column oriented dimaksudkan untuk berurusan dengan big data yang
terdistribusi maka table dipisah berdasarkan column family dan kolom itu sendiri sebagai
qualifier-nya, dan setiap table tersebut merupakan suatu HFile terpisah satu dengan yang lain.
Hasil: table pada Gambar-2.2 di atas dipisah menjadi dua table terpisah seperti pada Gambar-2.3.

9
 RowKey:Email ColumnKey Time Value
aaa@[Link] CF:BasicInfo:Name t0 aaa
aaa@[Link] CF:BasicInfo:Office t1 LH201
aaa@[Link] CF:BasicInfo:Office t2 IE339
bbb@[Link] CF:BasicInfo:Name t3 bbb

RowKey:Email ColumnKey Time Value

bbb@[Link] CF:ClassGrades:Database t4 A
bbb@[Link] CF:ClassGrades:Diskrit-2 T5 I
bbb@[Link] CF:ClassGrades:Diskrit-2 T6 B

Gambar-2.3 Model Fisik Column Oriented - HBase

2.3 Arsitektur

10