Replikasi melambat setelah tabel reorganize dengan CTAS

  Teman teman pasti tahu kalau saya memakai Bucardo untuk replikasi. Nah kejadian terakhir yang saya alami dengan bucardo berhubungan dengan tabel reorganisasi. Begini ceritanya.

Saya memiliki 3 server yang saya pergunakan untuk master to master replication dan hanya salah satu server saja yang di pergunakan sebagai server transaksi utama, lainnya untuk keperluan backup dan baca data. Nah saat saya melakukan analisa terhadap server untuk keperluan backup dan data ini, saya menemukan beberapa tabel yang ukurannya 3x lebih besar dari asalnya di server transaksi utama. Saya cek apakah mungkin tabelnya ter-fragmentasi atau tidak. Ternyata benar ada fragmentasi disana.

Akhirnya tabel yang ter-fragmentasi itu saya betulkan dengan metode CTAS. Berhasil. Salah satu tabel tersebut setiap malamnya melakukan update data sekitar 150k records. Jadi kalau dengan bucardo akan menjadi 300K records. Saya berkeyakinan bahwa semuanya akan lancar.

Esoknya, hari ke 1, sewaktu saya memonitor ZABBIX, ini adalah tools di linux untuk melihat kondisi server, saya mendapati bahwa dua server dimana saya melakukan CTAS kemarin cpu-load-nya sangat tinggi. Itu selesai setelah 6 Jam process, baru load nya turun drastis. Langsung saja saya curiga, mungkin itu terjadi karena tabel yang kemarin saya CTAS. Kemudian saya coba matikan bucardo-nya dan berharap esok hari zabbix akan memberikan laporan yang lebih baik.

Esoknya, hari ke 2, pagi pagi langsung saya lihat kondisi Zabbix, ternyata benar, load selama 12 jam terakhir rendah sekali. Jadi saya berkesimpulan bahwa load yang tinggi kemarin itu karena Bucardonya. Saya remove tabel tabel yang kemarin saya CTAS dari daftar tabel yang di replikasi di bucardo. Kemudian bucardo saya start lagi untuk menyelesaikan semua data data yang belum di replikasi. Dalam 3 jam ke depan Zabbix menunjukan kalau 2 server tersebut sibuk, karena menyelesaikan transaksi bucardo. Setelah itu rendah kembali, normal seperti sedia kala.,

Nah, saya browsing mencari jawaban mengenai hal ini, tetapi masih belum juga ketemu jawabannya. Mengapa setelah tabel tersebut di CTAS, process bucardo di  tabel tersebut jadi lebih lambat. Apakah ada teman teman yang memiliki pengalaman seperti ini ? mohon info nya.

Apa itu Database OLTP ?

  OLTP adalah singkatan dari On-line Transaction Processing. Menurut Wikipedia,

Online transaction processing, or OLTP, is a class of information systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing. The term is somewhat ambiguous; some understand a “transaction” in the context of computer or database transactions, while others (such as the Transaction Processing Performance Council) define it in terms of business or commercial transactions.[1] OLTP has also been used to refer to processing in which the system responds immediately to user requests. An automatic teller machine (ATM) for a bank is an example of a commercial transaction processing application.

Jadi, OLTP adalah sistem informasi yang berbasis transaksi. Transaksi dalam konteks Applikasi OLTP adalah satu proses transaksi atau satu cyle, ada awal ada akhir. Proses transaksi di dalam applikasi sendiri bervariasi jenisnya,  antara lain :

  • Proses penyimpanan 1 form, contoh 1 Purchase Order, 1 Sales Order, 1 Material Incoming dan lain lain
  • Proses End of Month, contoh proses akhir bulan Accounting, akhir bulan Banking, dan lain lain
Semua jenis transaksi tersebut diatas itulah yang disebut Proses Transaksi atau transaction processing.  Sedang yang dimaksud dengan Transaksi Database adalah proses menyimpan sebuah record dalam suatu tabel. Sehingga dengan penjelasan ini, 1 Transaksi Applikasi dapat berisikan ribuan Transaksi Database.
Database OLTP harus didesain dan di rancang untuk menangani kegiatan Transaksi Applikasi. Desain databasenya memiliki karakteristik sebagai berikut :
  • Normalisasi
    • Tabel tabel yang dimiliki selalu dalam bentuk tabel normalisasi atau 90% atau lebih dari tabel yang dimilikinya dalam bentuk normalisasi
  • Database Blok berukuran kecil, 2 kilobyte atau 4 kilobyte
    • Setiap blok penyimpanan di database umumnya memakai besaran 2kb atau 4kb
    • Ukuran blok yang kecil ini akan mempercepat proses pencarian data yang spesifik
  • Transaction Control
    • Selalu menggunakan transaction contol, yakni begin transaction, end transaction, commit dan rollback.
    • Kontrol ini dipergunakan untuk memastikan 1 Transaksi Applikasi berjalan semestinya hingga akhir dengan benar.

Dengan karakteristik seperti itu, maka Transaksi Applikasi di database OLTP haruslah transaksi yang memiliki proses penyimpanan dengan cepat. Kecepatannya harus kurang dari 60 detik. Lebih cepat lebih baik. Misal, 1 Transaksi Applikasi, menyimpan 1 Form Purchase Order, haruslah kurang dari 60 detik. Jadi semua Transaksi Applikasi jenis OLTP ini harus cepat.

Bagaimana dengan Proses Analisa ? Proses analisa umumnya melibatkan banyak tabel yang harus di join. Semakin banyak tabel yang di join akan mempengaruhi kecepatan pemrosesan data. Proses Analisa tetap dapat di lakukan dengan menggunakan database OLTP, tetapi ada keterbatasan di dalamnya, karena normalisasi, atau karena blok database. Seberapa besar batasan yang dapat diterima itu harus ditentukan. Jikalah Proses Analisa cukup tinggi pengunaannya, lebih baik proses analisa dilakukan di DATAWAREHOUSE.

5 Tips PostgreSQL dari Instagram

  Teman teman pasti tahu tentang instagram.  Instagram adalah website social networking dan berbagi photo secara online. User dapat meng-upload foto dan membagikannya ke teman teman yang lainnya. Foto yang di upload, dapat juga di modifikasi dengan penggunaan filter. Banyak sekali filter yang dimilikinya. Instagram sangat populer, mereka mengklaim sudah mendapatkan 100 juta pengguna pada february 2013.

Instagram menggunakan database PostgreSQL sebagai database backend mereka dan framework Django sebagai framework applikasi mereka. Instagram juga memiliki beberapa server postgresql yang bekerja secara shared. Saya masih tidak paham apakah mereka menggunakan clustering atau replication, selengkapnya dapat teman teman baca disini.

Nah, team engineering instagram membagikan 5 tips Postgresql yang sangat membantu database mereka :

  • Partial Indexes
    • Partial index ini adalah index yang dibuat berdasarkan karakteristik query yang kita buat. Dan dalam proses pencariannya memakan waktu yang lama. Karakteristiknya juga selalu tetap dan tidak pernah berubah.
    • Contoh karakteristik query selalu memakai where item_name ilike ‘software%’.
    • Maka partial indexnya adalah … Create Index idx1 on mytable where item_name ilike ‘software%’;
    • Saya sendiri belum pernah memakai partial index ini, karena karakteristik query saya lebih banyak memakai ‘%software%’ dibandingkan dengan ‘software%’; Jadi walaupun saya pakai partial index untuk kolom tersebut, tetap saja tidak akan terpakai indexnya, mengapa ? karena saya memakai  ilike ‘%…%’, yang mana akan melakukan pencarian sequential dari awal tabel hingga akhir tabel.
  • Functional Indexes
    • Index yang dibuat dengan menggunakan fungsi, contohnya substr, lower, upper, concatenate dan seterusnya.
    • Karakter query yang di pergunakan juga bersifat tetap dan tidak pernah berubah.
    • Contoh karakter query yang selalu memakai where … substr(item_name, 0, 8 ) = ‘software’
    • Maka functional indexnya adalah … Create index idx1 on mytable (substr(item_name,0,8))
    • Saya sendiri jarang memakai functional index, saya pernah pakai untuk concatenate, penggabungan dua kolom.
  • pg_reorg For Compaction
    • Seperti yang pernah saya tulis, database postgresql juga pasti akan mengalami fragmentasi suatu saat nanti, demikian juga database postgresql yang dipakai di instagram.
    • Team instagram memakai pg_reorg untuk melakukan defrag.
    • Saya sendiri masih memakai cara manual, tetapi prinsipnya sama dengan yang dipakai pg_reorg, yakni dengan metode CTAS.
  • WAL-E for WAL archiving and backups
    • WAL-E adalah program untuk membackup file postgresql WAL archive file yang dapat melakukan archive secara terus menerus.
    • Saya sendiri belum pernah menggunakannya. Karena karakteristik backup saya beda.
  • Autocommit mode and async mode in psycopg2
    • Tips ini dipergunakan jika kita menggunakan psycopg2.
    • Saya tidak memakai psycopg2, jadi belum bisa berkomentar.

Berdasarkan tips tips tersebut, team instagram mampu membuat PostgreSQL mereka melaju dengan sangat cepat. Secepat apa ? terus terang saya juga tidak tahu. Yang pasti, tips seperti partial index dan functional index itu sangat membantu sekali, walaupun saya belum pernah menggunakannya. Tetapi dari simulasi yang saya lakukan, hasilnya memang menggembirakan.

Bagaimana pendapat teman teman ?

RAID bukan untuk BACKUP Data

  Woa, apa tidak salah itu ? Menurut pengalaman saya, tidak, itu benar adanya. Tetapi setiap orang pasti memiliki pendapat masing masing. Jadi pendapat saya ini pun bisa di sanggah juga.

Mari kita lihat apa tujuan backup tersebut. Menurut Wikipedia, Backup adalah ” a backup, or the process of backing up, refers to the copying and archiving of computer data so it may be used to restore the original after a data loss event.”.

Jadi backup adalah proses untuk menduplikasi data dan menyimpannya sehingga data tersebut dapat dipergunakan untuk proses restore atau mengembalikan data setelah terjadinya kejadian kehilangan data.

Proses kehilangan data dapat disebabkan oleh berbagai hal, antara lain :

  • Kesalahan Manusia (Human Error)
    • salah delete data
    • pencurian
  • Kegagalan Perangkat Keras (Hardware Failure)
    • komputer rusak
    • kontroller media penyimpanan rusak
  • Kejadian Alam ( Catastropic Damage)
    • banjir
    • puting beliung
    • gempa bumi
  • Virus Komputer (Computer Virus)
  • Kesalahan Perangkat Lunak (Software Bugs)
  • dan sebagainya.

Sistem RAID tidak dapat menangani semua penyebab kehilangan data, hanya sebagian kecil dari bagian kegagalan perangkat keras saja. Sehingga RAID tidak seharusnya dipergunakan untuk BACKUP DATA.

RAID adalah teknologi yang dirancang untuk meningkatkan performa media penyimpanan dengan cara menggabungkan beberapa media penyimpanan dalan satu unit yang besar. RAID sekarang adalah teknologi yang murah dan mudah di dapat. RAID arti lengkapnya adalah Redundant Array of Independent Disks. Kata kata Redundant inilah yang sering disalah artikan sebagai BACKUP.

Jadi BACKUP lebih luas artinya daripada RAID. Saya tetap memerlukan RAID, tetapi RAID bukan untuk BACKUP.