online stats Tips and tricks about computer: 23 Nov 2009
Blinkie Text Generator at TextSpace.net
BERANDATENTANG SAYAFACEBOOKFRIENDSTERTWITTERCLIXSENSEGOOGLEYAHOO!MSNBLOGGER

Senin, 23 November 2009

PostgreSQL vs MySQL

Saat ini dengan mudah kita bisa mengatakan, dua produk database open source paling terkenal dan banyak digunakan adalah MySQL dan PostgreSQL. “Mana yang lebih bagus?” adalah pertanyaan yang hingga akhir zaman nanti akan selalu terlontar. Kami tahu pertanyaan ini tidak ada artinya, dan tidak membantu sama sekali. Namun di artikel ini kami mencoba menyusun beberapa aspek dari kedua database yang berbeda satu sama lain. Harapan kami, perbandingan ini membantu Anda menjawab pertanyaan “mana yang sebaiknya dipakai untuk [sebutkan kebutuhan Anda di sini].” Jangan lupa pula, sebelum memutuskan selalu ceklah dulu homepage kedua database sebab dari waktu ke waktu fitur tiap database berubah/bertambah. Perbandingan di artikel ini sendiri menggunakan versi MySQL 3.23.49/4.0.1 dan PostgreSQL 7.2.

Tujuan Desain

Dari semula latar belakang dikembangkannya kedua database ini sudah berbeda. MySQL berkembang dari solusi yang dipakai oleh pembuatnya, TcX AB, dalam memroses data untuk aplikasi Web. Fokusnya adalah pada kecepatan. PostgreSQL, di lain pihak, berkembang dari riset akademik. Fokus pengembangan PostgreSQL adalah pada fitur OO, reliabilitas, dan dukungan SQL yang mantap. Namun, seiring kedua produk ini bertambah matang, keduanya semakin banyak memiliki sifat-sifat ini. MySQL versi 4.x misalnya, berjanji menambahkan fitur-fitur yang sejak lama diidamkan pemakainya: subselect, view, dsb. Sementara PostgreSQL, yang sempat memiliki masalah stabilitas dan skalabilitas di seri awal versi 6.x, juga kini telah amat menarik dari segi kecepatan.

Pengembangan

Pengembangan MySQL diatur secara sentral oleh perusahaan komersial di Swedia bernama MySQL AB (sebelumnya TcX AB). Perusahaan ini memperoleh pemasukan utamanya dari menjual layanan support dan konsultasi MySQL. PostgreSQL dikembangkan secara lebih terdesentralisasi dan merakyat, namun tetap diatur oleh sebuah kelompok online bernama PostgreSQL Development Group.

MySQL dirilis dalam satuan yang lebih sering (sebulan bisa lebih dari satu kali), sementara PostgreSQL sekitar 4–6 bulan sekali.

Jumlah Pengguna

Menurut MySQL AB, saat ini jumlah instalasi MySQL sekitar 3 juta. PostgreSQL sendiri tidak diketahui pasti berapa jumlah penggunanya; kemungkinan masih berada di bawah MySQL karena banyaknya situs Web dan perusahaan webhosting yang hanya menggunakan MySQL. Plus secara keseluruhan popularitas MySQL (trafik milis, tutorial/artikel yang membahas, dsb) lebih besar daripada PostgreSQL. Tapi karena PostgreSQL juga disertakan secara default di distro-distro Linux seperti Red Hat dan SuSE, jumlah penggunanya pun sudah pasti banyak.

Arsitektur dan Portabilitas

MySQL memiliki arsitektur multithreading, sementara PostgreSQL multiproses (forking). Ini berarti PostgreSQL potensial memiliki stabilitas yang lebih tinggi, sebab satu proses anak yang mati tidak akan menyebabkan seluruh daemon mati—meskipun pada kenyataannya, dulu ini sering terjadi. Di sisi lain, arsitektur dengan forking ini sulit diterapkan ke Windows, sebab Windows amat thread-oriented. Karena itulah, baru MySQL yang memiliki port natif ke Windows. PostgreSQL sendiri saat ini bisa dijalankan di Windows, tapi melalui lapisan emulasi Cygwin.

ACID compliance

Sampai sekarang masih banyak yang bilang MySQL itu tidak ACID-compliant. Padahal sejak 2 tahun lalu MySQL sudah mempunyai handler tabel BerkeleyDB, dan belakangan ini InnoDB, sehingga MySQL sudah mendukung transaksi. Handler tabel MySQL yang lama, ISAM dan MyISAM, tidak ACID-compliant. PostgreSQL sendiri sejak lama telah ACID-compliant.

Lisensi

Lisensi PostgreSQL lebih liberal. Inilah sebabnya ada banyak produk closed-source dan komersial yang bisa dikembangkan dari source code PostgreSQL. MySQL, karena dilisensi di bawah GPL, tidak boleh dimodifikasi menghasilkan produk turunan yang closed-source.

Kecepatan

Soal kecepatan ini relatif dan kadang juga jadi isu sensitif. Baik kedua pihak, maupun pihak ketiga, pernah menerbitkan benchmark yang lalu ditepis atau dicibir karena tidak objektif.

Pada dasarnya perbandingan kecepatan keduanya seperti ini: MySQL terkenal cepat dalam melakukan query sederhana. Dengan kata lain, dapat memroses lebih banyak SQL per satuan waktu. Tapi dalam kondisi load tinggi (jumlah koneksi simultan besar), PostgreSQL sering mengalahkan MySQL untuk query dengan klausa JOIN yang kompleks, seperti dialami Tim Perdue saat mencoba kedua database untuk diimplementasikan di SourceForge.net. Penyebab utamanya adalah karena MySQL menggunakan locking level table dalam UPDATE, sehingga koneksi yang lain tidak bisa membaca table ybs sama sekali. Locking inilah juga sebabnya mengapa pada banyak benchmark, MySQL menunjukkan penurunan kinerja yang cukup drastis untuk kondisi jumlah klien simultan tinggi. PostgreSQL mendukung locking di level yang lebih rendah, yaitu row. Table handler baru di MySQL, InnoDB, juga mendukung row level locking. Benchmark InnoDB pada jumlah koneksi tinggi menunjukkan hasil yang cukup menjanjikan (www.innodb.com/bench.html).

Masalah locking tabel bisa diakali dengan membelah-belah tabel, agar satu kelompok row dapat dilock tanpa mengganggu kelompok row lain. Bahkan ada pengguna MySQL yang membelah sebuah tabel besar berisi jutaan record menjadi ribuan tabel kecil-kecil.

Stabilitas

Keduanya sudah bisa dibilang cukup hingga amat stabil. Tapi perlu diingat bahwa database manapun—bahkan Oracle—sesekali dapat menyebabkan kerusakan data. Karena itu backup/history periodik dan incremental tetap diperlukan.

Fungsi Built-In

MySQL terkenal kaya fungsi built-in, seperti modifikasi string (REPLACE, RIGHT, LTRIM, LCASE), matematika (LOG, LOG10), tanggal, dsb. Dalam hal ini MySQL lebih unggul.

Interface

Keduanya sudah amat solid. Mulai dari API C/C++, driver database Perl/Python/PHP/Tcl, ODBC, JDBC telah didukung. Anda tidak akan kesulitan menggunakan database ini dari berbagai sistem dan bahasa pemrograman. MySQL juga mendukung OLEDB dan memiliki versi embedded untuk dilink bersama aplikasi buatan Anda sendiri.

Full Text Indexing

MySQL mendukung indeks full text secara natif. PostgreSQL mendukung full text searching lewat program lain (contohnya: OpenFTS, openfts.sourceforge.net) yang memanfaatkan tipe data arraynya untuk menyimpan indeks dokumen. Secara umum dapat dikatakan bahwa indexing dengan MySQL lebih praktis, tapi dengan program ketiga lebih banyak fitur dan opsi yang bisa diatur (mis: stemming, parsing kata non-Inggris, dsb). MySQL juga, tentu saja, dapat dipakai sebagai backend bagi program search eksternal (contoh: DBIx::KwIndex, search.cpan.org/search?dist=DBIx-KwIndex), meski mungkin tidak seefisien dibandingkan array di PostgreSQL.

Replikasi

Keduanya sudah memiliki replikasi, meski replikasi di MySQL barulah satu arah. Replikasi di PostgreSQL sendiri belum disertakan dalam distribusi standarnya, namun Anda dapat mengunjungi situs gborg.postgresql.org/project/pgreplication/ (proyek pgreplication).

Manajemen User dan Keamanan

Kedua database menyimpan informasi user di sebuah database khusus. Sistem perizinan MySQL lebih mendetil daripada PostgreSQL. Misalnya, kita dapat mengeset agar user tertentu yang datang dari host tertentu hanya bisa membaca tabel saja tanpa bisa UPDATE. Di PostgreSQL ini masih bisa dilakukan dengan VIEW misalnya.

Untuk masalah enkripsi koneksi, keduanya mendukung SSL. Ada ekstensi PKIX bagi PostgreSQL yang menarik, sebab dapat membuat tabel terenkripsi: http://www.dimensional.com/~bgiles/pkixdoc/.

Tool Web/GUI

MySQL AB mengklaim lebih banyak tool grafis/web yang tersedia untuk MySQL, dan ini nampaknya cukup benar.

Tipe Data

PostgreSQL lebih kaya dalam hal tipe data (terutama yang domain-specific seperti tipe data geometris dan MONEY), tapi MySQL sudah mendukung semua tipe data umum.

Di PostgreSQL sebelum 7.1, masih ada keterbatasan yang cukup menyesakkan yaitu ukuran data BLOB maksimum adalah 8–32KB. Sejak 7.1, PostgreSQL juga dapat menyimpan data BLOB besar.

CHAR dan VARCHAR di PostgreSQL dapat menampung hingga 8 juta karakter (bandingkan dengan MySQL yang hanya 255).

Modifikasi Tabel

MySQL lebih fleksibel dalam ALTER TABLE. PostgreSQL sendiri terbatas hanya bisa melakukan penambahan kolom, penggantian nama kolom, dan penggantian nama tabel. MySQL mendukung penambahan/penghapusan kolom, penggantian definisi kolom, dsb.

Fitur OO dan SQL

Dalam waktu beberapa tahun PostgreSQL akan tetap memiliki fitur yang lebih lengkap dibandingkan MySQL. Lebih banyak fitur dari standar SQL92 yang diimplementasi oleh PostgreSQL. MySQL bahkan belum mendukung subselek. View, trigger, foreign key checking (meski ini sudah ada di InnoDB) dan stored procedure semua hanya ada di PostgreSQL. Sebagai pengembang yang memutuskan memilih salah satu database, Anda perlu menanyakan kepada diri sendiri dulu apakah ingin lebih bersusah-payah melakukan code around fasilitas-fasilitas yang tidak ada di MySQL tersebut melalui bahasa pemrograman (misalnya, stored procedure diganti dengan user-defined function, subselek diganti beberapa kali SQL yang dibungkus dengan locking, dan tidak ada “trigger” berarti Anda harus melakukan pengecekan secara manual). Jika tidak ingin repot, lebih baik memilih PostgreSQL. Tapi jika tidak butuh fitur SQL yang rumit-rumit, Anda masih punya kebebasan memilih satu dari dua.

Di samping itu MySQL pun tidak memiliki fitur OO seperti pewarisan tabel dan tipe data, atau tipe data array yang kadang praktis untuk menyimpan banyak item data di dalam satu record.

Fitur Unik

MySQL memiliki arsitektur yang memungkinkan sebuah database terdiri dari beberapa jenis tabel, misalnya: yang transaksional dan tidak, yang berbasis di memori atau di disk, yang terkompresi dan yang read-only. MySQL mendukung protokol terkompresi yang bisa menghemat bandwidth dan mengurangi latensi.

PostgreSQL memiliki tipe data array, pewarisan tabel dan tipe data, serta sistem rule. PostgreSQL memiliki tipe-tipe data “antik.” Di PostgreSQL Anda dapat menulis stored procedure (atau procedural language, istilah di PostgreSQL) dalam beberapa bahasa: PL/Perl, PL/Tcl, atau PL/PgSQL. PostgreSQL mendukung set/himpunan.

Baca Selengkapnya...

Bagaimana Database Oracle Memandang Perintah SQL?

Sebagaimana lazimnya, sebuah perintah SQL diketik berdasarkan permintaan yang diinginkan. Misal kita ingin melihat seluruh isi tabel dept (deptno, dname, loc) yang dimiliki oleh scott. Perintah-perintah yang bisa dilakukan bervariasi, misalnya :

SQL> connect scott/tiger

à login sebagai scott

SQL> select * from dept;

SQL> select deptno, dname, loc from dept;

SQL> select * from scott.dept;

SQL> select * from SCOTT.dept;

SQL> select * from SCOTT.DEPT;

Semua perintah SQL di atas menghasilkan output sama, yaitu semua isi tabel dept. Seringkali kita menganggap bahwa jika hasil sesuai dengan yang diinginkan, maka apa pun perintah yang kita tulis sah-sah saja. Apakah memang seperti itu? Mari kita lihat bagaimana cara Oracle memandang perintah SQL yang kita kirim.

1. Bila semua user menggunakan perintah sama

a. User scott grant select on dept to public agar semua user bisa mengakses tabel dept

SQL> connect scott/tiger

SQL> grant select on dept to public;

b. Shutdown Oracle untuk memastikan memori (SGA) belum pernah digunakan

SQL> connect sys/inix2009 as sysdba

SQL> shutdown immediate;

SQL> startup

c. Buka SQL window I

SQL> connect scott/tiger

SQL> select * from scott.dept

d. Buka SQL window II

SQL> connect hr/hr

SQL> select * from scott.dept

e. Buka SQL window III

SQL> connect system/inix2009

SQL> select * from scott.dept

f. Buka SQL window IV

SQL> connect sys/inix2009 as sysdba

SQL> select * from scott.dept

g. Lihat bagaimana perintah-perintah tersebut dipandang oleh Oracle

SQL> connect sys/inix2009 as sysdba

SQL> desc v$sqltext;

Name Null? Type

————————— ——– ————

ADDRESS RAW(4)

HASH_VALUE NUMBER

SQL_ID VARCHAR2(13)

COMMAND_TYPE NUMBER

PIECE NUMBER

SQL_TEXT VARCHAR2(64)

SQL> select address, sql_text

from v$sqltext

where lower(sql_text) like ‘%dept%’;

ADDRESS SQL_TEXT

——– ——————————————

51341368 ere lower(sql_text) like ‘%dept%’

513733B8 select * from scott.dept

. . .

Terlihat bahwa Oracle memandang semua perintah sama sehingga hanya terlihat satu buah perintah di Shared Pool, yaitu “select * from scott.dept”. Hal ini menghemat ukuran Shared Pool sekaligus mempercepat proses karena perintah yang ditulis dianggap sama.

2. Bila setiap user menggunakan perintah berbeda yang penting hasil sama

a. Shutdown Oracle untuk memastikan memori (SGA) belum pernah digunakan

SQL> connect sys/inix2009 as sysdba

SQL> shutdown immediate;

SQL> startup

b. Buka SQL window I

SQL> connect scott/tiger

SQL> select * from dept

c. Buka SQL window II

SQL> connect scott/tiger

SQL> select deptno, dname, loc from dept

d. Buka SQL window III

SQL> connect hr/hr

SQL> select * from scott.dept

e. Buka SQL window IV

SQL> connect system/inix2009

SQL> select * from SCOTT.dept

f. Buka SQL window V

SQL> connect sys/inix2009 as sysdba

SQL> select * from SCOTT.DEPT

g. Lihat bagaimana perintah-perintah tersebut dipandang oleh Oracle

SQL> connect sys/inix2009 as sysdba

SQL> select address, sql_text

from v$sqltext

where lower(sql_text) like ‘%dept%’;

ADDRESS SQL_TEXT

——– ———————————————

5238ABEC select * from SCOTT.dept

52305E74 where lower(sql_text) like ‘%dept%’

5237F020 select * from SCOTT.DEPT

52389C30 select * from scott.dept

523A67DC select * from dept

523A21A0 select deptno, dname, loc from dept

Terlihat bahwa Oracle memandang perintah-perintah tersebut berbeda walaupun hasilnya sama, yaitu semua isi tabel dept. Hal ini memboroskan pemakaian Shared Pool sekaligus memperlambat proses karena perintah yang ditulis dianggap berbeda.

Kesimpulan :

Setiap orang harus menggunakan perintah sama untuk sebuah hasil yang diinginkan. DBA berkewajiban membuat standardisasi perintah SQL untuk digunakan oleh programmer dan siapa pun yang berkaitan.

Baca Selengkapnya...