Artikel ini kami sadur dari tulisan seorang Database Solution Architects bernama Sameer Kumar. Sebagai upaya kerjasama i3 dengan Ashnik untuk memberikan konten bermanfaat kepada pembaca.
Dalam peran saya sebagai seorang Arsitek Solusi, saya telah bekerja dengan pelanggan dan SI membentang Asia Tenggara dan India. Mereka ini menghasilkan aplikasi era baru berlandaskan web. Aplikasi-aplikasi ini termasuk platform jual-beli saham, gerbang pembayaran, solusi mobile banking, solusi VAS telekomunikasi, platform e-bisnis etc.
Setelah beberapa tugas, saya sadar ada satu pola. Bukan saja sistem ini mementingkan misi atau bisnis, Ia juga berbagi beberapa sifat yang sama. Kebutuhan dan desain aplikasi-aplikasi ini ada banyak persamaan dan keserupaan. Di bawah ini adalah beberapa persamaan karakteristik yang ada pada setiap aplikasi bisnis di era ini terlepas dari bidang dan tujuannya:
- Semuanya akan dihadapkan kepada publik dan dapat digunakan melalui beberapa titik sentuhan kepada pengguna seperti aplikasi mobile, web, dan lain-lain.
- Semuanya akan dimulai dengan trafik yang rendah dan akhirnya akan berkembang menjadi sistem yang sibuk dalam satu bisnis.
- Sistem-sistem ini akan saling berinteraksi melintasi aplikasi yang ada dan/atau dengan beberapa sistem lain yang direncanakan untuk dikembangkan dalam satu tahun akan datang.
- Sistem-sistem ini harus menjadi modular sehingga beberapa fungsinya dapat diganti tanpa memberi dampak kepada yang lain.
Selama perbincangan dengan tim aplikasi dan infrastruktur, kami merumuskan beberapa fakta umum yang dapat dipergunakan dalam kebanyakan situasi saat mengembangkan sistem berlandaskan web. Saya akan sebutkan beberapa ilmu yang saya pelajari dan beberapa rekomendasi yang kami rumuskan saat berbagai tugas:
- Adalah terbaik untuk melanjutkan desain yang modular dengan ruang berkorelasi dan kontrak antara modul yang berbeda. Ruang berkorelasi dan kontrak ini akan membantu Anda meminimalkan perubahan dan dampak perubahan yang dibuat pada satu modul. Sebagai contoh, jika Anda sering menggabungkan semua interaksi database Anda sebagai API akses data, ia akan membantu Anda menghindarkan dampak perubahan database. API akses data dapat dirancang untuk mengirim data ke aplikasi sebagai JSON atau XML. Ini akan memisahkan sepenuhnya aplikasi dari perubahan pada desain database, pemulihan dan bahkan platform database. Lalu, semua titik sentuhan database Anda berada pada satu tempat di mana mudah untuk membuat ulang kode saat perubahan desain database. Pemisahan yang sama dapat dilakukan pada setiap lapisan akses data, aplikasi, web dan interaksi pengguna.
- Sementara menerima permintaan pengguna adalah lebih baik dengan membariskan permintaan menggunakan cara barisan pesan dari membiarkan pengguna menunggu selama server memproses permintaan. Sama untuk permintaan DB, balik memungkinkan aplikasi untuk membuat hubungan adalah lebih baik untuk membenarkannya membariskan permintaan. Ini juga memungkinkan penggunaan sumber yang lebih baik dan mengurangi pertukaran konteks. Dengan database PostgreSQL, Anda memiliki pilihan alat seperti pgpool dan pgBouncer untuk memfasilitasi pilihan konektivitas.
- Seringkali lebih baik untuk membagi aplikasi ke beberapa bagian yang disebut modul (sub-aplikasi kecil) atau layanan mikro yang dapat berfungsi dengan servis mikro/modul yang lain e.g. Anda dapat mengganti dan mengubah modul pendaftaran pelanggan Anda tanpa memberikan dampak kepada modul lain yang tergantung pada pendaftaran pelanggan untuk mengambil informasi pelanggan atau mendaftar pelanggan baru. Interaksi antara modul-modul ini dapat dilakukan melalui Web Service yang memfasilitasi antarmuka dan kontrak antara sub-aplikasi/layanan mikro ini.
- Apabila jumlah transaksi meningkat, secara praktis tidak mungkin untuk menambahkan dengan satu disk atau satu server. Anda harus merencanakan untuk meluncurkan arsitektur aplikasi Anda dengan cara entitas yang memiliki transaksi tulis yang tinggi, dapat dibagi apabila perlu. Postgres Plus Advanced Server EnterpriseDB memfasilitasi Hash partitioning yang dapat membantu Anda mencapai pembagian traksaksi tulis membentang disk-disk berbeda.
Pilihan lainnya adalah Anda dapat menggunakan database NoSQL seperti MongoDB untuk berbagi entitas dengan operasi tulis yang besar di beberapa server. Setelah semua, arsitektur aplikasi hibrida kini bukanlah jarang, di mana beberapa entitas didistribusikan ke dalam penyimpanan NoSQL dan sebagian disimpan dalam basis data relasional. - Banyak kebutuhan yang rumit atau kebutuhan yang tidak jelas butuhkan desain skema yang normal. Ini memungkinkan adaptasi yang mudah untuk mengubah hierarki hubungan atau untuk memperkenalkan konsep baru nanti. Contoh khas dari ini adalah aturan aplikasi. Anda mungkin akhirnya menyimpan aturan informasi metadata membentang 3-4 “tables” dan menghubungkannya pada waktu nyata, dapat mengakibatkan masalah besar, meskipun pada skala kecil.
Pendekatan yang lebih baik adalah menggunakan mesin aturan yang berlandaskan aplikasi di mana aturan dapat dispesifikasikan dalam dokumen XML atau JSON dan disimpan sementara di server aplikasi. Sama juga dengan hubungan rinci dalam entitas lain yang telah banyak berubah sejak beberapa tahun belakangan ini dan pasti akan terus berubah. Untuk menyimpan informasi seperti ini, lebih baik simpan di dalam database NoSQL atau jenis data rata e.g. JSON atau Array. PostgreSQL memiliki banyak jenis data, konektivitas dan indek untuk memungkinkan Anda menyimpan data Anda dengan cara yang terbaik. - Simpan sementara data Anda dalam server aplikasi. Tidak ada yang baru tentang “caching”, Anda mungkin telah menyimpan sementara data statis. Namun masih ada banyak data yang Anda tidak simpan sementara. Sebenarnya Anda dapat menyimpan sementara data operasi yang diperbarui dalam waktu nyata. Dalam kondisi kecelakaan, data ini dapat dibangun kembali dari transaksi atau log aktivitas. Saya akan jelaskan lebih lanjut tentang ini dalam salah satu blog saya nanti.
- Di balik menggunakan cara tradisional yaitu “SELECT FOR UPDATE”, capai paralel tinggi dengan kunci optimistic.
- Pada hari ini, dalam kebanyakan aplikasi, data awalnya dibaca kemudian diperbarui. Jadi sementara ada beban membaca karena pertanyaan dan pencarian, semua operasi tulis juga menghasilkan permintaan baca pada database. Sebelum mendaftar pengguna baru, Anda akan memeriksa jika pengguna itu telah ada.
Dengan membuat replika baca dan menyeimbangkan beban, permintaan bacaan membentang beberapa replika bisa sangat berguna. PostgreSQL menyediakan replikasi “steaming” sebagai cara mudah untuk membuat replika bacaan. Menggunakan fitur yang sama, Anda juga dapat membangun cluster berskala dan keberadaan tinggi dengan PostgreSQL. Fitur replikasi yang sama turut ada dalam MongoDB, ia fleksibel untuk menspesifikasikan pilihan baca dari mana untuk mendapatkan data. - Sering saat merancang sistem yang melibatkan transaksi keuangan atau manajemen persediaan e.g. situs bisnis, mobile banking, pembayaran tagihan ponsel atau aplikasi dompet mobile yang singkat, Anda akan menghadapi masalah besar pada liability atau manajemen persediaan. Tipikalnya ada rincian pada satu baris atau satu baris untuk akun internal. Ini sering menjadi pusat pertelagahan dan pencerutan. Lihat jika ini dapat dihindarkan dengan beberapa proxy atau entity palsu.
Sumber: Ashnik.