Pemrosesan transaksi online (OLTP)

  • Artikel

Pengelolaan data transaksional dengan menggunakan sistem komputer disebut dengan Pemrosesan Transaksi Online (OLTP). Sistem OLTP merekam interaksi bisnis saat mereka terjadi di dalam operasi organisasi sehari-hari, dan mendukung pengambilan kueri data ini untuk membuat kesimpulan.

Data Transaksional

Data transaksional adalah informasi yang melacak interaksi yang terkait dengan aktivitas organisasi. Interaksi ini biasanya merupakan transaksi bisnis, seperti pembayaran yang diterima dari pelanggan, pembayaran yang dilakukan kepada pemasok, produk yang bergerak melalui inventaris, pesanan yang diambil, atau layanan yang dikirimkan. Peristiwa transaksional, yang mewakili transaksi itu sendiri, biasanya berisi dimensi waktu, beberapa nilai numerik, dan referensi ke data lain.

Transaksi biasanya harus atomik dan konsisten. Atomisitas berarti bahwa seluruh transaksi selalu sukses atau gagal sebagai satu unit kerja, dan tidak pernah dibiarkan dalam kondisi setengah selesai. Jika suatu transaksi tidak dapat diselesaikan, sistem database harus memutar kembali langkah-langkah yang telah dilakukan sebagai bagian dari transaksi tersebut. Dalam RDBMS tradisional, puter kembali ini terjadi secara otomatis jika transaksi tidak dapat diselesaikan. Konsistensi berarti bahwa transaksi selalu meninggalkan data dalam kondisi yang valid. (Ini adalah deskripsi atomitas dan konsistensi yang sangat informal. Ada definisi yang lebih formal dari properti ini, seperti ACID.)

Database transaksional dapat mendukung konsistensi yang kuat untuk transaksi menggunakan berbagai strategi penguncian, seperti penguncian pesimistis, untuk memastikan bahwa semua data sangat konsisten dalam konteks perusahaan, untuk semua pengguna dan proses.

Arsitektur penyebaran paling umum yang menggunakan data transaksional adalah tingkat penyimpanan data dalam arsitektur 3 tingkat. Arsitektur 3 tingkat biasanya terdiri dari tingkat presentasi, tingkat logika bisnis, dan tingkat penyimpanan data. Arsitektur penerapan terkait adalah arsitektur N-tier, yang mungkin memiliki beberapa tingkat menengah yang menangani logika bisnis.

Ciri khas data transaksional

Data transaksional cenderung memiliki ciri-ciri sebagai berikut:

Persyaratan Deskripsi
Normalisasi kasus Sangat dinormalisasi
Skema Skema pada tulis, diterapkan dengan ketat
Konsistensi Konsistensi yang kuat, jaminan ACID
Integritas Integritas tinggi
Menggunakan transaksi Ya
Strategi Penguncian Pesimistis atau optimis
Dapat diperbarui Ya
Dapat ditambahkan Ya
Beban kerja Penulisan berat, pembacaan sedang
Pengindeksan Indeks primer dan sekunder
Ukuran datum Berukuran kecil hingga sedang
Model Relasional
Bentuk data Tabular
Fleksibilitas kueri Sangat fleksibel
Sisik Kecil (MB) hingga Besar (beberapa TB)

Kapan menggunakan solusi ini

Pilih OLTP saat Anda perlu memproses dan menyimpan transaksi bisnis secara efisien dan segera membuatnya tersedia untuk aplikasi klien dengan cara yang konsisten. Gunakan arsitektur ini ketika penundaan nyata dalam pemrosesan akan berdampak negatif pada operasi bisnis sehari-hari.

Sistem OLTP didesain untuk memproses dan menyimpan transaksi secara efisien, serta mengkueri data transaksional. Tujuan pemrosesan dan penyimpanan transaksi individual secara efisien oleh sistem OLTP sebagian dicapai dengan normalisasi data — yaitu, memecah data menjadi potongan kecil yang tidak terlalu berlebihan. Ini mendukung efisiensi karena memungkinkan sistem OLTP untuk memproses sejumlah besar transaksi secara independen, dan menghindari pemrosesan tambahan yang diperlukan untuk menjaga integritas data dengan adanya data yang berlebihan.

Tantangan

Mengimplementasikan dan menggunakan sistem OLTP dapat menimbulkan beberapa tantangan:

  • Sistem OLTP tidak selalu baik untuk menangani agregat sejumlah besar data, meskipun ada pengecualian, seperti solusi berbasis SQL Server yang terencana dengan baik. Analitik terhadap data, yang mengandalkan perhitungan agregat atas jutaan transaksi individual, sangat intensif sumber daya untuk sistem OLTP. Mereka bisa lambat untuk dieksekusi dan dapat menyebabkan perlambatan dengan memblokir transaksi lain dalam database.
  • Saat melakukan analitik dan pelaporan pada data yang sangat dinormalisasi, kueri cenderung rumit, karena sebagian besar kueri perlu mendenormalisasi data dengan menggunakan gabungan. Juga, konvensi penamaan untuk objek database dalam sistem OLTP cenderung singkat dan ringkas. Peningkatan normalisasi ditambah dengan konvensi penamaan singkat membuat sistem OLTP sulit bagi pengguna bisnis untuk mengkueri, tanpa bantuan DBA atau pengembang data.
  • Menyimpan riwayat transaksi tanpa batas waktu dan menyimpan terlalu banyak data dalam satu tabel dapat menyebabkan performa kueri yang lambat, tergantung pada jumlah transaksi yang disimpan. Solusi umum adalah mempertahankan jendela waktu yang relevan (seperti tahun fiskal saat ini) dalam sistem OLTP dan membongkar data historis ke sistem lain, seperti data mart atau gudang data.

OLTP di Azure

Aplikasi seperti situs web yang dihosting di App Service Web Apps, REST API yang berjalan di App Service, atau aplikasi seluler atau desktop berkomunikasi dengan sistem OLTP, biasanya melalui perantara REST API.

Dalam praktiknya, sebagian besar beban kerja tidak murni OLTP. Ada juga yang cenderung menjadi komponen analitik. Selain itu, ada peningkatan permintaan untuk pelaporan real time, seperti menjalankan laporan terhadap sistem operasional. Ini juga disebut sebagai HTAP (Hybrid Transactional and Analytical Processing). Untuk informasi lebih lanjut, lihat Pemrosesan Analitik Daring (OLAP).

Di Azure, semua penyimpanan data berikut akan memenuhi persyaratan inti untuk OLTP dan pengelolaan data transaksi:

Kriteria pilihan utama

Untuk mempersempit pilihan, mulailah dengan menjawab pertanyaan-pertanyaan ini:

  • Apakah Anda menginginkan layanan terkelola dan tidak mengelola server Anda sendiri?

  • Apakah solusi Anda memiliki dependensi khusus untuk kompatibilitas Microsoft SQL Server, MySQL, atau PostgreSQL? Aplikasi Anda dapat membatasi penyimpanan data yang dapat Anda pilih berdasarkan driver yang didukungnya untuk berkomunikasi dengan penyimpanan data, atau asumsi yang dibuatnya tentang database mana yang digunakan.

  • Apakah persyaratan throughput tulis Anda sangat tinggi? Jika ya, pilih opsi yang menyediakan tabel dalam memori.

  • Apakah solusi Anda multitenant? Jika demikian, pertimbangkan opsi yang mendukung kumpulan kapasitas, di mana beberapa instans DB mengambil dari kumpulan elastis sumber daya, bukan sumber daya tetap per database. Ini dapat membantu Anda mendistribusikan kapasitas dengan lebih baik di semua instans DB, dan dapat membuat solusi Anda lebih hemat biaya.

  • Apakah data Anda harus dapat dibaca dengan latensi rendah di beberapa wilayah? Jika ya, pilih opsi yang mendukung replika sekunder yang dapat dibaca.

  • Apakah database Anda harus sangat tersedia di seluruh wilayah geografis? Jika ya, pilih opsi yang mendukung replikasi geografis. Pertimbangkan juga opsi yang mendukung failover otomatis dari replika utama ke replika sekunder.

  • Apakah database Anda memiliki kebutuhan keamanan khusus? Jika ya, periksa opsi yang menyediakan kemampuan seperti keamanan tingkat baris, masking data, dan enkripsi data transparan.

Matriks kemampuan

Tabel berikut merangkum perbedaan utama kemampuan.

Kemampuan secara umum

Kemampuan Database Azure SQL Microsoft SQL Server pada komputer virtual (VM) Azure Azure Database untuk MySQL Azure Database untuk PostgreSQL
Adalah Layanan Terkelola Ya No Ya Ya
Berjalan di Platform T/A Windows, Linux, Docker T/A T/A
Keterprograman 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[1] Tidak termasuk dukungan driver klien, yang memungkinkan banyak bahasa pemrogram terhubung ke dan menggunakan penyimpanan data OLTP.

Kemampuan skalabilitas

Kemampuan Database Azure SQL Microsoft SQL Server pada komputer virtual (VM) Azure Azure Database untuk MySQL Azure Database untuk PostgreSQL
Ukuran instans DB maksimum 4 TB 256 TB 16 TB 16 TB
Mendukung kumpulan kapasitas Ya Ya No Tidak
Mendukung skala turun kluster Tidak Ya No Tidak
Skalabilitas dinamis (peningkatan skala) Ya No Ya Ya

Kemampuan beban kerja analitik

Kemampuan Database Azure SQL Microsoft SQL Server pada komputer virtual (VM) Azure Azure Database untuk MySQL Azure Database untuk PostgreSQL
Tabel temporal Ya Ya No Tidak
Tabel dalam memori (dioptimalkan memori) Ya Ya No Tidak
Dukungan penyimpan kolom Ya Ya No Tidak
Pemrosesan kueri adaptif Ya Ya No Tidak

Kapabilitas ketersediaan

Kemampuan Database Azure SQL Microsoft SQL Server pada komputer virtual (VM) Azure Azure Database untuk MySQL Azure Database untuk PostgreSQL
Sekunder yang dapat dibaca Ya Ya Ya Ya
Replikasi geografis Ya Ya Ya Ya
Failover otomatis ke sekunder Ya No No Tidak
Pemulihan titik waktu Ya Ya Ya Ya

Kemampuan keamanan

Kemampuan Database Azure SQL Microsoft SQL Server pada komputer virtual (VM) Azure Azure Database untuk MySQL Azure Database untuk PostgreSQL
Keamanan tingkat baris Ya Ya Ya Ya
Masking data Ya Ya No Tidak
Enkripsi data transparan Ya Ya Ya Ya
Membatasi akses ke alamat IP tertentu Ya Ya Ya Ya
Pembatasan akses untuk mengizinkan akses VNet saja Ya Ya Ya Ya
Autentikasi Microsoft Entra Ya No Ya Ya
Autentikasi Active Directory Domain Services Tidak Ya No Tidak
Autentikasi multifaktor Ya No Ya Ya
Mendukung Always Encrypted Ya Ya No Tidak
IP Privat Tidak Ya No Tidak

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Langkah berikutnya