No Comments

9 tip membina aplikasi web berprestasi tinggi – dari Perspektif seorang Arkitek DB

Big Data Talk

by , , No Comments

8-Sep-2016

Dalam peranan saya sebagai seorang Arkitek Solusi, saya telah bekerja dengan pelanggan dan SI merentangi Asia Tenggara dan India.  Mereka ini menghasilkan aplikasi era baru berlandaskan web.  Aplikasi-aplikasi ini termasuk platform jual-beli stok, gerbang bayaran, solusi perbankan mudah alih, solusi VAS telekomunikasi, sistem menjejak kesihatan/aktiviti masa nyata, platform e-perniagaan etc.  Selepas beberapa tugas, saya sedar terdapat satu pola.  Bukan sahaja sistem ini mementingkan misi atau perniagaan, ia turut berkongsi beberapa sifat yang sama.   Keperluan dan rekabentuk aplikasi-aplikasi ini ada banyak persamaan dan keserupaan.  Di bawah ini adalah beberapa persamaan ciri-ciri yang terdapat pada mana-mana aplikasi perniagaan di era kini tanpa mengira bidang dan tujuannya:-

  • Semuanya akan dihadapkan kepada umum dan boleh digunakan melalui beberapa titik sentuhan kepada pengguna.  g. aplikasi mudah alih, web etc
  • Semuanya akan bermula dengan trafik yang rendah/kenaan/permintaan pengguna dan akhirnya akan berkembang menjadi sistem yang sibuk dalam satu perniagaan
  • Sistem-sistem ini akan saling berinteraksi merentasi aplikasi sedia ada dan/atau dengan beberapa sistem lain yang dirancang untuk dibangunkan dalam tempoh satu tahun akan datang
  • Sistem-sistem ini perlu menjadi modular supaya sesetengah fungsinya dapat diganti tanpa memberi impak kepada yang lain

Semasa perbinncangan dengan pasukan aplikasi dan infrastruktur, kami merumuskan beberapa fakta umum yang boleh digunapakai dalam kebanyakan situasi semasa membangunkan sistem berlandaskan web yang menghadap pengguna.   Saya akan nyatakan beberapa ilmu yang saya pelajari dan beberapa cadangan yang kami rumuskan semasa pelbagai tugasan:-

  • Adalah terbaik untuk meneruskan rekabentuk yang modular dengan ruang hubung kait dan kontrak antara modul yang berbeza. Ruang hubung kait dan kontrak ini akan membantu anda meminimakan perubahan dan impak perubahan yang dibuat pada satu modul.  Sebagai contoh, jika anda sering menggabungkan semua interaksi pangkalan data anda sebagai API capaian data, ia akan membantu anda menghindarkan impak perubahan pangkalan data.  API capaian data boleh direkabentuk untuk menghantar data ke aplikasi sebagai JSON  atau XML.  Ini akan memisahkan sepenuhnya aplikasi daripada perubahan pada rekabentuk pangkalan data, pemulihan dan malah platform pangkalan data.  Lagipun, semua titik sentuhan pangkalan data anda berada pada satu tempat di mana mudah untuk membuat pemfaktoran semula kod semasa perubahan rekabentuk pangkalan data.  Pemisahan yang sama boleh dilakukan pada setiap lapisan capaian data, aplikasi, web dan interaksi pengguna.
  • Sementara menerima permintaan pengguna adalah lebih baik untuk membariskan permintaan menggunakan cara barisan mesej daripada membiarkan pengguna menunggu semasa pelayan memproses permintaan. Sama untuk permintaan DB, sebalik membenarkan aplikasi untuk membuat hubungan, adalah lebih baik untuk membenarkannya membariskan permintaan.  Ini juga membolehkan penggunaan sumber yang lebih baik dan mengurangkan pertukaran konteks.  Dengan pangkalan data PostgreSQL, anda mempunyai pilihan alatan seperti pgpool dan pgBouncer untuk memudahkan barisan penyambungan.
  • Selalunya adalah lebih baik untuk membahagikan aplikasi kepada beberapa bahagian yang dipanggil modul (sub-aplikasi kecil) atau servis mikro yang boleh berfungsi dengan servis mikro/modul yang lain e.g. anda boleh mengganti dan mengubah modul pendaftaran pelanggan anda tanpa memberi impak kepada modul lain yang bergantung pada pendaftaran pelanggan untuk mengambil maklumat pelanggan atau mendaftar pelanggan baru. Interaksi antara modul-modul ini boleh dilakukan melalui Web Service yang memudahkan antara muka dan kontrak antara sub-aplikasi/servis mikro ini.
  • Banyak keperluan yang rumit atau keperluan yang tidak jelas perlukan rekabentuk skema yang normal. Ini membenarkan adaptasi yang mudah untuk mengubah hierarki hubungan atau untuk memperkenalkan konsep baru nanti.  Contoh tipikal bagi ini ialah peraturan aplikasi.  Anda mungkin akhirnya menyimpan peraturan maklumat metadata merentangi 3-4 “tables” dan menghubungkannya pada masa nyata, boleh mengakibatkan masalah besar, walaupun pada skala kecil.  Pendekatan yang lebih baik ialah menggunakan enjin peraturan yang berlandaskan aplikasi di mana peraturan boleh dispesifikasikan dalam dokumen XML atau JSON dan disimpan sementara dalam pelayan aplikasi.  Sama juga dengan hubungan terperinci dalam entiti lain yang telah banyak berubah sejak beberapa tahun kebelakangan ini dan pasti akan terus berubah.  Adalah lebih baik untuk menyimpan maklumat sebegini di dalam pangkalan data noSQL atau jenis data rata e.g. JSON atau Array.  PostgreSQL menawarkan banyak jenis data yang berlainan, penyambungan dan indek untuk membolehkan anda menyimpan data anda dengan cara yang terbaik.
  • Simpan sementara data anda dalam pelayan aplikasi. Tiada apa yang baru mengenai “caching”, anda mungkin telah menyimpan sementara data statik.  Tetapi masih terdapat banyak data yang anda tidak simpan sementara.  Sebenarnya anda boleh menyimpan sementara data operasi yang dikemaskini dalam masa nyata.  Dalam keadaan nahas, data ini boleh dibina semula daripada transaksi atau log aktiviti.  Saya akan jelaskan lebih lanjut mengenai ini dalam salah satu blog saya nanti.
  • Di sebalik menggunakan cara tradisional iaitu “SELECT FOR UPDATE”, capai keselarian tinggi dengan kunci optimistic.
  • Kerap semasa merekabentuk sistem yang melibatkan transaksi kewangan atau pengurusan inventori e.g. laman perniagaan, perbankan mudah alih, pembayaran bil mudah alih atau aplikasi dompet mudah alih yang ringkas, anda akan menghadapi masalah besar pada liability atau pengurusan inventori. Tipikalnya terdapat satu butiran pada satu baris atau satu baris untuk akaun dalaman.  Ini sering menjadi pusat pertelagahan dan pencerutan.  Lihat jika ini boleh dihindarkan dengan beberapa proksi atau entity palsu.  Saya akan terangkan lebih lanjut mengenai ini dalam salah satu blog saya nanti.

Anda boleh menulis kepada kami di success@ashnik.com jika anda mencari perunding dan cadangan pembangunan dalam membangun dan melancarkan sebuah sistem dengan keperluan pemprosesan yang tinggi.  Sementara itu jangan ke mana-mana, saya akan kembali pada tahun 2016 dengan blog yang lebih terperinci mengenai cadangan-cadangan di atas.

 Sameer Kumar | Senior Database Solution Architect, Singapore 


Sameer Kumar seorang Arkitek Pangkalan Data bekerja dengan Ashnik.  Beliau telah menyelesaikan banyak penyediaan sistem yang rumit dan tugas-tugas migrasi untuk beberapa pelanggan utama daripada sektor perniagaan runcit, industri perbankan dan telekomunikasi.  Sameer ialah PostgreSQL dan EDB Postgre Plus Advanced Server profesional yang berkelayakan.  Beliau juga seorang tenaga pengajar Postgres yang berkelayakan dan telah banyak memberi latihan kepada umum dan kumpulan korporat.  Beliau amat arif dengan RDBMS yang lain seperti DB2, Oracle dan SQL Server.  Juga berpengalaman di dalam teknologi bukan SQL iaitu MongoDB.  Beliau telah bekerja rapat dengan pelanggan dan membantu mereka membina platform analisis pada pangkalan data bukan SQL dan migrasi daripada RDBMS ke MongoDB.  Di waktu lapang, beliau gemar menunggang basikal di sekitar Singapura.


0
0

More from  Sameer Kumar :
8-Sep-2016