Desain Table untuk replikasi

  Hi, sudah lama blog ini tidak saya update, tentu saja alasan paling utama adalah kesibukan. Klise sekali ya, jadi ingat para blogger yang lain, selalu memakai alasan yang sama, sibuk.

Baiklah, topik kita kali ini adalah desain tabel yang akan di pergunakan untuk replikasi. Replikasi data ditempat kita adalah Master to Master, artinya setiap lokasi dapat melakukan update data dan masing masing lokasi akan melakukan sinkronisasi dengan lokasi lainnya. Desain tabel ini berdasarkan pengalaman yang kita miliki selama ini, yaitu :

  • Primary Key
    • Setiap record yang tercatat harus memiliki primary key, yang dapat dipergunakan untuk identifikasi unik record tersebut. Tingkat ke-unik-annya harus mempertimbangkan kode lokasi dan kode perusahaan.
    • Dengan pertimbangan di atas, pada saat replikasi, kita yakin bahwasannya data setiap record itu adalah unik, tidak akan mungkin tercampur / bertabrakan dengan data dari lokasi lainnya.
    • Contoh primary key nya :
      • A1   : A untuk kode lokasi, 1 untuk no urut data
      • XA1 : X untuk kode perusahaan, A untuk kode lokasi, 1 untuk no urut data.
  • Tanggal Pembuatan
    • Kita harus mencatat juga kapan record tersebut di catat di dalam tabel. Umumnya kita kombinasikan dengan constraint DEFAULT.
    • Contoh untuk Postgresql dan Oracle :
      • created_date timestamp default NOW()
      • created_by numeric(8)
  • Tanggal Perubahan
    • Kita juga harus mencatat kapan record tersebut berubah/diubah di dalam tabel. Pencatatannya dilakukan pada saat kita menjalankan perintah UPDATE atau REPLACE.
    • Contoh untuk Postgresql dan Oracle :
      • modified_date timestamp
      • modified_by numeric(8)

ID yang unik adalah suatu keharusan, sementara untuk tanggal Pembuatan dan perubahan sebagai data pendukung terhadap status record tersebut. Tentusaja data pendukungnya dapat bertambah sesuai kebutuhan, tetapi kolom kolom yang diatas itu adalah keharusan di tempat kita. Jadi standard DDL untuk tabel yang akan di replikasi seperti berikut :

<!-- Center Pane -->
Create Table Master_tbl
( id varchar(16),
  ...
  ...
  created_date timestamp default NOW(),
  created_by numeric(8),
  modified_date timestamp,
  modified_by numeric(8),
  contraint master_tbl_pk primary key (id)
);

Bagaimana dengan teman teman ?

Nulls hanya untuk tipe data berbasis character dan timestamp

  Bruse momjian adalah salah satu orang penting di dunia PostgreSQL, salah satu pendiri The PostgreSQL Global Development Group, dan dia sudah bekerja dengan PostgreSQL sejak tahun 1996. Beliau juga menulis buku yang berjudul “PostgreSQL: Introduction and Concepts“.

Menurut beliau, nulls adalah nothing atau pointer yang tidak menunjuk kemana mana. Untuk itipe data character, nulls dapat ditulis dengan spasis kosong atau zero length, sedangkan untuk numeric dan timestamp, nulls harus di tulis dengan apa ? 0, -1 atau yang lain ? timestamp dengan 01/01/01 ?

Berikut adalah file presentasi beliau mengenai Nulls, silahkan diambil disini. Presentasi ini telah di presentasikan dalam ajang pgCon 2013. Bruce juga menjelaskan apa, mengapa dan bagaimana pemakaian nulls yang benar. Benar benar penjelasan yang menarik untuk disimak. Sayangnya tidak ada penjelasan mengenai performance database apabila kita menggunakan nulls, jadi kita tidak tahu apa efek dari pemakaian nulls terhadap performance database kita, lebih cepat atau lebih lambat.

Berdasarkan presentasi tersebut, saya dapat mengambil kesimpulan bahwa nulls sebaiknya hanya dipergunakan untuk tipe data yang berbasis character, semisal tipe data character, text, atau variable character. Untuk tipe data berbasis numeric dan timestamp lebih baik menghindari nulls.

Untuk tipe data numeric, saya memiliki trik untuk menghindari nulls yakni dengan selalu menambahkan integrity NOT NULL DEFAULT 0. Jadi jika saya melakukan insert terhadap tabel tersebut dan tidak mencantumkan suatu value, maka secara otomatis database akan menambahkan angka 0.

Sementara untuk tipe data berbasis timestamp, saya memiliki kesulitan, karena dalam beberapa kasus kolom tersebut tidak dapat dikenakan integrity NOT NULL, sehingga nulls tetap diperkanankan. Integrity DEFAULT juga tidak dapat dikenakan karena saya tidak dapat menentukan tanggal berapa yang di pergunakan sebagai nilai default. Contoh, setiap tabel saya memiliki kolom MODIFIED_DATE, dan kolom ini hanya berisikan data pada saat terjadi perintah UPDATE. Sehingga pada saat dia berisikan nulls,saya dapat mengetahui bahwa memang belum pernah terjadi perintah UPDATE pada baris data tersebut. Seandainya saya menentukan default tanggalnya adalah 17/08/1945 dan menerapkan integrity NOT NULL DEFAULT TO_DATE(’17/08/1945′,’DD/MM/YYY’), maka akan muncul permasalahan pada penampilan data, karena secara default nilai kolom tersebut adalah ’17/08/1945′ padahal saya ingin melihat kolom tersebut dengan kosong untuk menyatakan tidak ada proses UPDATE.

Jadi, untuk saat ini, nulls akan saya terapkan untuk tipe data berbasis charcter dan timestamp. Bagaimana dengan teman teman ?

RedHat akan mengganti MySQL dengan MariaDB

  Collin Charles melaporkan dari blognya bahwa Red Hat Enterprise Linux 7 akan melepas database MySQL dan menggantinya dengan database MariaDB. Pengumuman ini dikeluarkan pada #rhsummit yang sedang berlangsung di xxx.

Sejak MySQL di akuisisi oleh ORACLE pada tahun 2010, para pengembang MySQL memisahkan diri dan membuat versi terbuka dan mandri yang di beri nama MariaDB. MariaDB masih kompatible dengan MySQL, sehingga jikalau applikasi kita beralih dari database MySQL ke MariaDB dapat langsung berjalan.

Kabar ini tentu saja akan menggembirakan para pengguna MariaDB dan membantu para pemakai MySQL yang risau setelah pengakuisisian MySQL oleh Oracle. Termasuk saya tentunya, bagaimana dengan anda ?

Apa itu NoSQL Database ?

  NOSQL adalah istilah untuk menyatakan berbagai hal yang didalamnya termasuk database sederhana yang berisikan key danvalue seperti Memcache, ataupun yang lebih canggih yaitu non-database relational seperti MongoDBCassandraCouchDB, dan yang lainnya.

Wikipedia menyatakan NoSQL adalah sistem menejemen database yang berbeda dari sistem menejemen database relasional yang klasik dalam beberapa hal. NoSQL mungkin tidak membutuhkan skema table dan umumnya menghindari operasi join dan berkembang secara horisontal. Akademisi menyebut database seperti ini sebagai structured storage, istilah yang didalamnya mencakup sistem menejemen database relasional.

Database relasional sudah ada semenjak tahun 70-an sehingga teknologi mereka sudah sangat matang. Secara umum mereka mendukung operasi transaksi, yang mengijinkan kita merubah sebagian data, melakukan kontrol terhadap operasi database, support terhadap constraint seperti unique, primary key, foreign key dan check. Mereka juga memiliki bahasa SQL atau Simplified Query Language untuk mengakses data, merubah data seperti operasi insert, update dan delete.

Walaupun SQL dalam arti sesungguhnya adalah simple atau sederhana, dan developer selama bertahun tahun menggunakannya, tetapi mereka merasa kurang puas bahkan cenderung tidak menyukainya. Alasan lainnya, RDBMS atau Relational Database Management System tidak dapat berkembang horisontal secara baik. Seringnya kita mendapatkan database yang berkembang tetapi secara read-only melalui kemampuan replikasi database dan untuk mendapatkan database yang berkembang horisontal secara read-write itu sangat sulit. Oracle saja sampai perlu membangun ORACLE RAC atau Real Application Cluster, yang menemui banyak tantangan untuk melakukan sinkronisasi data di internal cache melalui inter-koneksi khusus. Faktanya, perubahan data yang terjadi itu memerlukan waktu untuk mengirimkannya ke berbagai sistem. Selama data tersebut belum terkirimkan, kita memakai data yang tidak valid atau stale data/delta data.

Adanya database NoSQL seperti MongoDB yang mencoba untuk menyelesaikan permasalahan ini. Disini, Data tidak ditulis/dibaca dari database dengan menggunakan bahasa SQL, tetapi menggunakan metode object-oriented yang lebih disukai oleh developers. Kelebihan lainnya adalah adanya dukungan adanya banyaknya tipe index yang berbeda beda untuk lookupsterhadap data tertentu. Mereka juga memiliki kemampuan clustering secara default.

Setelah sekian lama muncul, database NoSQL tidak serta merta memiliki banyak penggemar. Untuk pastinya, banyak perusahaan besar yang menggunakan NoSQL database, tetapi secara umum mereka menggunakannya untuk kebutuhan kebutuhan yang spesial. Mereka perlu melihat apakah database ini bisa berkembang dengan kapasitas data yang sangat besar dan banyak dipergunakan di berbagai applikasi, jika tidak, mereka tidak melihat alasan untuk berpindah.

Lain kesempatan akan saya coba membahas satu persatu feature yang dimiliki database database NoSQL ini.