Design Table BLOB

Okay, artikel sebelumnya kita sudah membahas tentang bagaimana keuntungan mempergunakan tipe data BLOB dan FileSystem untuk menyimpan file Binary kita. Contoh penggunaan tipe data BLOB dengan bahasa PHP juga sudah dijelaskan didalam artikel yang lalu. Nah untuk saat ini kita akan membahas bagaimana cara membuat tabel dengan tipe data BLOB yang optimal.

   Okay, artikel sebelumnya kita sudah membahas tentang bagaimana keuntungan mempergunakan tipe data BLOB dan FileSystem untuk menyimpan file Binary kita. Contoh penggunaan tipe data BLOB dengan bahasa PHP juga sudah dijelaskan didalam artikel yang lalu. Nah untuk saat ini kita akan membahas bagaimana cara membuat tabel dengan tipe data BLOB yang optimal.

Kita ambil contoh tabel profil user. Umumnya tabel profil user berisikan data pribadi user dan foto profil. Dari informasi ini, maka prakiraan tabel profil kira kira akan seperti ini :

create table profil_user

( id numeric(18,0) NOT NULL DEFAULT nextval('profile_seq'::regclass),

nama varchar(32),

alamat varchar(64),

no_telp varchar(16),

no_fax varchar(16),

foto BLOB

);

Secara umum tidak ada yang salah tabel profil user seperti diatas. Tetapi kita perlu ingat, bahwasannya tipe data BLOB ini dapat menyimpan file dalam ukuran besar hingga gigabyte. Apa yang terjadi jika kita mengirimkan perintah select * terhadap tabel ini ?

Database Administrator, terlepas dari apapun jenis database yang dipergunakan, umumnya akan membuat tablespace atau tablearea atau  spacearea dan berbagai istilah yang lainnya, untuk memisahkan data dan index. Prinsip ini sudah merupakan dasar untuk memastikan tingkat kestabilan performance database. Table akan di buat dan diletakkan di dalam tablespace DATA. Index akan dibuat dan diletakkan didalam tablespace INDEX. Akan lebih bagus lagu apabila tablespace DATA dan INDEX diletakkan didalam Harddisk yang terpisah. Mengapa demikian ? karena DATA dan INDEX memiliki cara pengaksesan yang berbeda, sehingga dengan meletakkan mereka didalam harddisk yang terpisah akan membantu Database Engine untuk bekerja lebih optimal.

Bagaimana dengan tipe data BLOB. Hampir sama dengan DATA dan INDEX, kita harus memisahkan mereka ditablespace yang terpisah dari DATA dan INDEX. Memisahkan mereka dalam tablespace yang terpisah juga sangat disarankan. Table yang berisikan BLOB sebisa mungkin memiliki sedikit tambahan atribut/kolom informasi.

Sehingga apabila prinsip diatas diterapkan di tabel profil_user, maka struktur tabelnya akan seperti ini :

create table profile_user_foto

( id numeric(18,0) NOT NULL DEFAULT nextval('profil_user_foto_seq'::regclass),

content binary,

update_date timestamp

) using tablespace BLOB;
create table profil_user

( id numeric(18,0) NOT NULL DEFAULT nextval('profil_user_seq'::regclass),

nama varchar(32),

alamat varchar(64),

no_telp varchar(16),

no_fax varchar(16),

foto_id numeric(18),

constraint foreign key profile_user_data1_fk (foto_id) references profile_user_foto (id)

) using tablespace DATA;

Ini adalah contoh dengan menggunakan database postgresql.

Bekerja dengan BLOB dan PHP

Jikalau anda memutuskan untuk menggunakan tipe data BLOB di database untuk menyimpan file binary anda, maka dibawah ini adalah beberapa hal yang harus anda perhatikan pada saat bekerja dengan tipe data BLOB dan PHP

  Jikalau anda memutuskan untuk menggunakan tipe data BLOB di database untuk menyimpan file binary anda, maka dibawah ini adalah beberapa hal yang harus anda perhatikan pada saat bekerja dengan tipe data BLOB dan PHP :

  1. Submit file binary dengan HTML File :
    • Pastikan anda menggunakan parameter enctype di dalam form submit. Parameter ini dipergunakan untuk mengirimkan file binary anda.
      
      <form action='add_blob.php' method='post' enctype='multipart/form-data'>
          <input id='userfile' type='file' name='userfile' value='' />
      </form>
      
      
  2. Menangkap file binary
    • File Binary yang telah di submit, akan diterima oleh PHP dalam array $_FILES[“userfile”]
    • Isi dari variabel $_FILES[“userfile”] adalah sebagai berikut :
      
      $_FILES['userfile']['tmp_name'] = File binary
      $_FILES['userfile']['name'] = Nama file binary
      $_FILES['userfile']['type'] = Tipe ekstensi file
      $_FILES['userfile']['size'] = ukuran file dalam byte
      
      
    • Untuk mendapatkan lebar dan tinggi dari image gunakan perintah berikut ini :
      
      list ($file_width, $file_height, $type, $attr) = getimagesize($_FILES['userfile']['tmp_name']);
      
      
  3. Untuk menyimpan file binary ke database dengan kohana, php framework.
    • Disini kita menggunakan function fopen dan filesize dari php.
      
      $image = ORM::factory('table_image');
      $image->file_content = fread (fopen ($_FILES['userfile']['tmp_name'], 'r'),
      filesize ($_FILES['userfile']['tmp_name']));
      $image->last_update = new DATE();
      $image->save();
      
      
  4. Untuk membaca file dari BLOB dan menampilkannya ke browser terdapat 2 cara :
    • Tanpa Kompresi, file langsung dibaca dari database dan dikirim ke browser.
      
      $result = ORM::factory('table_image')->find($id);
      if ($result->id)
      {  header ('Content-type: '.$result->file_type);
         echo $result->file_content;
      };
      
      
    • Dengan Kompresi, file dibaca dari database dan di quality di turunkan ke 75%.
      
      $result = ORM::factory('table_image')->find($id);
      if ($result->id)
      {  header ('Content-type: '.$result->file_type);
         echo imagejpeg(imagecreatefromstring($result->file_content), '', 75);
      };
      
      

Demikanlah tutorial cara menggunakan tipe data BLOB dengan PHP.
Semoga bermanfaat.

BLOB atau FileSystem ?

Pertanyaan yang umum diajukan oleh para designer database adalah apakah akan menggunakan BLOB atau FileSystem untuk menyimpan suatu file binary ?, disimpan di BLOB bisa, disimpan di Filesystem juga bisa. Manakah yang terbaik ?

  BLOB adalah tipe data untuk menyimpan file binary. Image, video, music, document, semuanya bisa disimpan di dalam tipe data ini. Pertanyaan yang umum diajukan oleh para designer database adalah apakah akan menggunakan BLOB atau FileSystem untuk menyimpan suatu file binary ?, disimpan di BLOB bisa, disimpan di Filesystem juga bisa. Manakah yang terbaik ?

Jawaban saya :  Sesuaikan dengan jenis applikasi anda !.

Keuntungan File System :

  • Mudah untuk di rawat.
  • bisa diperlakukan seperti file pada umumnya.
  • process READ sangat cepat.
Keuntungan BLOB :
  • Diamankan dengan Referential Integrity, sehingga tidak mudah untuk  terhapus secara tidak sengaja.
  • Dapat di replikasi ke beberapa server database
  • Bisa masuk dalam skema Point-in-time Backup.

Keuntungan FileSystem adalah kekurangan BLOB dan sebaliknya, keuntungan BLOB adalah kekurangan FileSystem. Sehingga dari sini kita dapat menentukan file binary akan disimpan dimana ?

Jika applikasi kita bekerja dengan banyak process READ terhadap file binary ini, maka FileSystem jawabannya. Apalagi kalau jenis applikasinya adalah Web-based dan diakses melalui Proxy-Server, maka user akan dapat menerima file binary nya yang diinginkannya dengan cepat . Flickr dan Google Picasa bisa menjadi contoh, mereka melayani banyak user yang ingin “melihat picture” yang dishare. Arsitektur Flickr dapat anda lihat di tautan berikut ini.

Jika applikasi kita tidak terlalu banyak process READ dan lebih kearah Replikasi maka BLOB adalah solusinya. File binary akan disimpan ke dalam database. Database dapat di replikasikan ke beberapa server di lain lokasi. User pun masih bisa menerima delay yang terjadi saat process READ.

Database saat ini sudah memiliki algoritma yang sangat bagus dalam menangani tipe data BLOB. Bahkan ada yang menggunakan Database Firebird untuk melakukan testing antara Firebird dan FileSystem, dan mengklaim kalau Firebird lebih cepat daripada FileSystem dalam menangani tipe data BLOB. Anda dapat membacanya blog ini dan hasil diskusinya di reddit.com. Bagaimana dengan database yang lain ?

Dalam kasus saya, kita memakai BLOB. Data file binary disimpan di dalam database. Ada beberapa pertimbangan yang mendasari keputusan ini, yaitu :

  • Database harus dapat di replikasi.
  • Size file binary yang di upload dibatasin max 5 MB.
  • Applikasi dalam bentuk Web-Based.
  • Process READ terhadap file binary dalam konteks “Download File“, artinya user harus mendownload dulu file binary tersebut.
  • Process READ tidak terlalu banyak dan low traffic.
Bagaimana dengan anda ?

Facebook, MySQL, dan 4000 Horisontal Partisi

4000 shard Instance of MySQL, wow cool

  Michael Stonebraker menulis dalam artikelnya yang berjudul Facebook trapped in MySQL ‘fate worse than death’ tentang bagaimana database MySQL dipergunakan oleh FaceBook. Saya sangat salut dengan para engineernya Facebook dalam menggunakan database MySQL. Bayangkan 4000 Shard Instance database MySQL dipergunakan bersama sama dan 9000 Instance MemCache.

Wow, 4000 shard instance ? apa itu shard ? shard itu dalam arti lain adalah “horisontal partition”, artinya data yang dimiliki dipisah kedalam 4000 Instance MySQL. Nah pemisahannya ini dilakukan secara logika,developer Facebook yang menentukan data A pergi ke Instance MySQL yang mana, data B pergi ke instance MySQL yang mana. Proses pemisahaan ini sangatlah rumit, parameter yang dipergunakan mungkin juga sangat banyak dan beragam. Pekerjaan besar untuk developernya.

Bayangkan pula, 4000 mesin itu bisa terletak di belahan dunia yang lain, mungkin saja ada yang di amerika, singapura, eropa, china dan sebagainya. Tentu saja mereka memiliki cara untuk menyatukan kembali data tersebut, detailnya saya juga kurang tahu.Tapi saya yakin prosesnya juga rumit.

Di artikel tersebut juga disebutkan, menurut informasi terakhir tahun 2008, Facebook memiliki 1800 server khusus hanya untuk MySQL dan 805 server untuk MemCache. Wow, menakjubkan. Tentu saja DBAnya akan bekerja keras untuk memaintain database server dengan jumlah sebanyak itu.

Kembali ke artikel yang di tulis pak michael, dia mengatakan, dengan jumlah database MySQL yang sangat banyak dan hanya bisa melakukan “horisontal partition” untuk scalabilitasnya, maka Facebook akan mengalami kesulitan jika arsitektur seperti ini di pertahankan. Mengapa ? karena untuk melakukan ini semua itu sangat kompleks, ribet, dan memusingkan.

Itulah sebabnya, pak michael menyarankan Facebook untuk memindahkan databaseny dari MySQL ke database yang lain yang dapat melakukan scalabilitas dengan benar. Beliau menyarankan untuk berpindah ke database dengan konsep NewSQL seperti database VoltDB, NimbusDB, dan GenieDB. Konsep ini berbeda dengan konsep NoSQL yang menurut beliau masih merupakan database MySQL dalam bentuk yang lain.

Sudah beberapa hari ini pendapat dari pak michael ini mengundang perdebatan diantara para developer database. Slashdot, salah satu website rujukan para developer, ikut pula menjadi ramai. Topik ini pun berkembang menjadi ajang membahas solusi apa yang tepat untuk Facebook. Menariknya para developer ini juga menyarankan untuk memakai PostgreSQL.

Apapun solusi yang ditawarkan, bagaimana bentuk pelaksanaannya, semua developer setuju dengan pendapat pak michael, Facebook harus segera “menulis ulang” applikasinya dan menggunakan database yang baru

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.

Pgfouine menganalisa PostgreSQL Log

  Setelah kita mengaktifkan fasilitas log dari database Postgresql, maka di dalam direktori log akan muncul file *.log. File *.log ini jika kita dapat kita baca dengan menggunakan text editor, isinya bisa bermacam macam bergantung setting parameter yang kita lakukan pada file postgresql.conf. Untuk DBA yang sudah berpengalaman, mereka dapat membaca isi file log ini dengan cepat untuk mendapatkan gambaran mengenai isi file log tersebut. Tetapi apabila file log tersebut sudah berukuran cukup besar, tentu saja mereka akan kesulitan untuk membaca dan memahami file log tersebut.

Umumnya logging di PostgreSQL tidak dilakukan dalam waktu yang lama. Waktu selama 3 jam sudah cukup lama untuk ukuran database yang aktif. Karena proses logging ini dapat membuat sistem database menjadi lambat, sehingga mengaktifkan fasilitas logging harus dilakukan dengan hati hati dan dengan penuh pertimbangan.

Komunitas Postgresql telah menyediakan suatu tools untuk menganalisa file log yang dihasilkan, namanya pgfouine. Tools ini akan membantu menganalisa isi file log yang telah dihasilkan. Tools ini dibuat melalui bahasa pemrograman php, sehingga anda perlu menginstall php sebelum menggunakan file ini.

Berikut adalah step untuk melakukan analisa file log postgresql di sistem saya, Ubuntu 11.04 :

    1. aktifkan fasilitas log di postgresql
    2. edit file postgresql.conf

      $ sudo vim /etc/postgresql/postgresql.conf

      Dan ubah parameter parameter berikut ini :

      1. log_destination = 'stderr'
      2. silent_mode = on
      3. log_min_duration = 0
      4. log_duration = on
      5. log_statement = 'all'
      6. log_line_prefix = '%t [%p]: [%l-1] '
      7. lc_messages = 'en_GB.utf8'
    3. restart database postgresql

$ sudo /etc/init.d/postgresql restart

    1. download tools pgfouine dari website pgfouine, ambil file yang tarball (*tar.gz)
    2. extract pgfouine di direktory anda, dan berpindahlah ke direktory tersebut


1. $ tar -xfs pgfouine.tar.gz
2. $ cd pgfouine

  1. jalankan pgfouine

    sudo ./pg_fouine.php -logtype stderr -file /var/log/postgresql/pgsql.log > report.html
  2. buka file report.html melalui browser anda

Didalam file report tersebut, anda bisa melihat query mana saja yang lambat, query mana saja yang dieksekusi berulang ulang dan seterusnya. Untuk query yang lambat tersebut anda harus mencari solusinya dengan cara melakukan tuning. Umumnya solusi untuk tuning 1 query akan berbeda untuk query yang lainnya. Kita akan mempelajari tuningnya dilain kesempatan.

Thank you.

Aktivasi PostgreSQL Log

  Setelah sekian lama menggunakan postgresql, saya masih penasaran dengan bagaimana cara postgresql melakukan log terhadap semua sql statement yang di jalankannya. Akhirnya saya coba untuk mengaktifkan feature loggind di database postgresql 9 di local komputer saya untuk memastikan apakah semua applikasi yang saya pakai memakai prepared statement.

Berikut adalah langkah langkah setting postgresql.conf untuk menaktifkan log :

  • Edit file postgresql.conf, di ubuntu saya lokasinya seperti ini :

    sudo vim /etc/postgresql/9.0/main/postgresql.conf
  • Setelah itu ubah nilai parameter parameter berikut :

    log_destination = 'stderr'
    logging_collection = 'on'
    log_directory = '/var/log/postgresql'
    log_filename = 'pgsql-%Y-%m-%d_%H%M%S.log'
    log_connections = on
    log_disconnections = on
    log_error_verbositu = verbose
    log_statement = on
  • setelah itu restart database postgresql kita:

    sudo /etc/init.d/postgresql restart
  • perhatikan direktory /var/log/postgresql, akan muncul 1 file baru dengan awalan pgsql-XXX.log, nah file inilah yang akan kita pergunakan untuk melihat isi file log yang di hasilkan oleh postgres, :

    sudo tail -f /var/log/postgresql/pgsql-XXX.log
  • Kemudian jalankan applikasi kita yang menggunakan database, dan amati perubahan yang terjadi di dalam file log tersebut. Berikut adalah hal-hal yang biasanya saya amati didalam file log :
    • error message
    • warning message
    • prepare statement
    • client connection / disconnection
  • Thank you

Postgresql 9 Stream Replication

  Stream Replication adalah feature terbaru dari Postgresql 9. Stream Replication termasuk dalam kategory Standby Database, yang artinya database replikasi ini berada dalam mode standby, read-only, tidak dipergunakan untuk transaksi.

Stream Replication di postgresql melakukan sinkronisasi data background prosess yang sebut walsender dan walreceiver. Background process inilah yang bertanggung jawab mengirimkan perubahan data melalui network port.
Perubahan yang terjadi di master server akan dengan cepat diimplementasikan di slave server.

Jadi, transaksi database tetap dilakukan di server master, seperti insert, delete, update dan seterusnya. Server
slave dipergunakan untuk transaksi read-only, seperti query, export data dan seterusnya. Apabila terjadi suatu hal terhadap server master, misalnya terjadi kerusakan sistem, maka server slave bisa disetting untuk menggantikan master server.

Persiapan :

  1. Siapkan 2 server linux ubuntu. Saya menggunakan IP address 192.168.0.1 untuk master dan 192.168.0.2 untuk slave servernya. Stream Replication hanya bisa berjalan apabila versi postgresql sama dan menggunakan operating system dengan versi yang sama pula.
  2. Matikan postgresql yang sedang berjalan, baik di master maupun di slave, agar tidak ada user yang melakukan transaksi ke database :

    $ sudo /etc/init.d/postgresql stop
  3. pastikan versi linux anda berjalan pada arsitektur yang sama, 32 bit atau 64 bit :

    $ sudo uname -m

    jika yang keluar adalah x86_64 berarti 64 bit, jika yang keluar adalah i386 / i686 berarti 32 bit.

Master Server :

  1. buat direktori archive di dalam data_directory untuk menampung file wal. Default data_directory postgresql 9 di ubuntu adalah di direktori /var/lib/postgresql/9.0/main.

    $ sudo mkdir /var/lib/postgresl/9.0/main/archive
    $ sudo chown postgres:postgres /var/lib/postgresl/9.0/main/archive
     
  2. buka file postgresql.conf yang menyimpan informasi parameter inisialisasi :

    $ sudo nano /etc/postgresql/9.0/main/postgresql.conf
     
  3. ubah parameter yang ada menjadi seperti ini dan save filenya :
                     listen_address = '*'
                     wal_level = hot_standby
                     checkpoint_segment = 16                 
                     archive_mode = on
                     archive_command = 'cp -i %p /var/lib/postgresql/9.0/main/archive/%f <dev/null'
                     max_wal_senders = 3
                     wal_keep_segments = 32
    
                
  4. buka file pg_hba.conf, yang menyimpan konfigurasi koneksi ke database :

    $ sudo nano /etc/postgresql/9.0/main/pg_hba.conf
     
  5. tambahkan baris konfigurasi seperti ini, untuk memastikan agar slave dapat terkoneksi ke master server, dan save filenya :

    host replication all 192.168.0.2/32 trust 

Slave Server :

  1. buka file postgresql.conf yang menyimpan informasi parameter inisialisasi :

    $ sudo nano /etc/postgresql/9.0/main/postgresql.conf
     
  2. ubah parameter yang ada menjadi seperti ini dan save filenya :

    listen_address = '*'
    hot_standby = on
     
  3. buat file recovery.conf di direktory data_directory. Default data_directory postgresql 9 di ubuntu adalah di direktori /var/lib/postgresql/9.0/main. :

    $ sudo nano /var/lib/postgresql/9.0/main/recovery.conf
     
  4. tambahkan parameter berikut ini dan save filenya:

    standby_mode = 'on'
    primary_conninfo = 'host=192.168.0.1 port=5432 user=postgres password=postgres'
    restore_command = 'cp /path/for/backups/%f %p'
     

Sinkronisasi :

  1. Setelah master dan slave server selesai di konfigurasi, maka langkah berikutnya adalah melakukan sinkronisasi data. Lakukan step step berikut ini dengan cepat.
  2. Start database postgresql di MASTER SERVER :

    $ sudo /etc/init.d/postgresql start
     
  3. Login ke postgresql di MASTER SERVER :

    $ sudo psql -U postgres
     
  4. Jalankan perintah backup di MASTER SERVER :

    postgres# select pg_start_backup('clone', true);
     
  5. copy file database di MASTER SERVER ke SLAVE SERVER :

    postgres# \! rsync -av --exclude pg_xlog --exclude postgresql.conf --exclude postgresql.pid /var/lib/postgresql/9.0/main/* 192.168.0.2:/var/lib/postgresql/9.0/main/
     
  6. stop backup database di MASTER SERVER :

    postgres# select pg_stop_backup();
     
  7. copy direktory pg_xlog di MASTER SERVER ke SLAVE SERVER:

    postgres# \! rsync -av /var/lib/postgresql/9.0/main/pg_xlog 192.168.0.2:/var/lib/postgresql/9.0/main/
     
  8. Start database postgresql di SLAVE SERVER :

    $ sudo /etc/init.d/postgresql start
     
  9. Nah sekarang anda dapat melakukan testing melalui master server, buatlah tabel kosong dan lakukan semua perintah insert, delete, update ke dalam tabel tersebut, dan insert kan beberapa record kedalamnya, dan lihat hasilnya di slave server.

Thank you.

Install postgresql 9 di Ubuntu 10.10

  Postgresql telah melepas postgresql 9. Saatnya kita mencoba kemampuannya. Berikut cara instalasi postgresql di ubuntu 10.10.

Tutorial :

  1. Kita perlu menambahkan repository postgres 9.0, maka edit file source.list

    $ sudo vim /etc/apt/source.list
  2. Tambahkan baris perintah berikut, dan kemudian simpan :

    deb http://ppa.launchpad.net/pitti/postgresql/ubuntu maverick main
    deb-src http://ppa.launchpad.net/pitti/postgresql/ubuntu maverick main
  3. Kemudian update repository anda :

    $ sudo apt-get update
  4. Kemudian install postgres database :

    $ sudo apt-get install postgresql-9.0 libpq-dev postgresql-contrib-9.0
  5. Done.