Bagikan melalui

Pemrosesan transaksi online (OLTP)

Pengelolaan data transaksi dengan menggunakan sistem komputer disebut sebagai 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 transaksi tidak dapat diselesaikan, sistem database harus mengembalikan langkah apa pun yang sudah dilakukan sebagai bagian dari transaksi tersebut. Dalam sistem manajemen database relasional tradisional (RDBMS), pembatalan ini terjadi secara otomatis ketika transaksi tidak dapat diselesaikan. Konsistensi berarti bahwa transaksi selalu meninggalkan data dalam kondisi yang valid. Transaksi ini adalah deskripsi informal tentang atomitas dan konsistensi. Ada definisi yang lebih formal dari properti ini, seperti atom, konsisten, terisolasi, dan tahan lama (ACID).

Database transaksi dapat mendukung konsistensi yang kuat dalam transaksi dengan menerapkan berbagai strategi penguncian, seperti penguncian pesimis. Strategi ini membantu memastikan bahwa semua data tetap konsisten dalam konteks beban kerja, untuk semua pengguna dan proses.

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

Ciri khas data transaksional

Data transaksi cenderung memiliki sifat-sifat berikut.

Persyaratan Deskripsi
Normalisasi Sangat ternormalisasi
Skema Skema saat menulis, diberlakukan
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 intensif, pembacaan moderat
Pengindeksan Indeks primer dan sekunder
Ukuran datum Berukuran kecil hingga sedang
Fleksibilitas pengajuan Sangat fleksibel
Skala 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 keterlambatan pemrosesan yang nyata memiliki efek negatif pada operasi bisnis sehari-hari.

Sistem OLTP dirancang untuk memproses dan menyimpan transaksi secara efisien, dan mengkueri data transaksional. Tujuan pemrosesan dan penyimpanan transaksi individu secara efisien oleh sistem OLTP sebagian dicapai melalui normalisasi data, yang memecah data menjadi potongan yang lebih kecil dan kurang berlebihan. Langkah ini memungkinkan sistem OLTP memproses sejumlah besar transaksi secara independen. Ini juga menghindari proses tambahan yang diperlukan untuk menjaga integritas data dengan adanya data redundan.

Tantangan

Sistem OLTP dapat menciptakan beberapa tantangan:

  • Saat Anda menjalankan analisis terhadap data yang mengandalkan perhitungan agregat dari jutaan transaksi individual, itu sangat membebani sumber daya untuk sistem OLTP. Mereka dapat berjalan lambat dan menyebabkan pelambatan dengan memblokir transaksi lain dalam database. Akibatnya, sistem OLTP tidak selalu ideal untuk menangani agregat melalui sejumlah besar data terdistribusi. Tetapi ada pengecualian, seperti skema yang direncanakan dengan baik.

  • Saat Anda melakukan analitik dan pelaporan pada data yang sangat dinormalisasi, kueri cenderung kompleks, karena sebagian besar kueri perlu melakukan denormalisasi data dengan menggunakan join. Peningkatan normalisasi dapat menyulitkan pengguna bisnis untuk mengkueri tanpa bantuan administrator database (DBA) atau pengembang data.

  • Ketika Anda menyimpan riwayat transaksi tanpa batas waktu atau menyimpan terlalu banyak data dalam satu tabel, itu dapat menyebabkan performa kueri yang lambat, tergantung pada jumlah transaksi yang Anda simpan. Solusi umumnya 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, dan aplikasi seluler atau desktop biasanya berkomunikasi dengan sistem OLTP melalui perantara REST API.

Dalam praktiknya, sebagian besar beban kerja tidak sepenuhnya OLTP. Mereka sering menyertakan komponen analitik juga dan memerlukan pelaporan real-time, seperti menjalankan laporan terhadap sistem operasional. Beban kerja ini disebut sebagai pemrosesan transaksional dan analitik hibrid (HTAP). Untuk informasi selengkapnya, lihat Pemrosesan analitik online (OLAP).

Di Azure, penyimpanan data berikut memenuhi persyaratan inti untuk OLTP dan manajemen data transaksi:

Kriteria pilihan utama

Untuk mempersempit pilihan, mulailah dengan menjawab pertanyaan berikut:

  • 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 mungkin membatasi penyimpanan data yang dapat Anda pilih berdasarkan driver yang didukungnya untuk berkomunikasi dengan penyimpanan data, atau asumsi yang dihasilkannya tentang database mana yang digunakan.

  • Apakah persyaratan throughput tulis Anda tinggi? Jika ya, pilih opsi yang menyediakan tabel dalam memori atau kemampuan distribusi global seperti Azure Cosmos DB.

  • Apakah solusi Anda multitenant? Jika demikian, pertimbangkan opsi yang mendukung kumpulan kapasitas. Beberapa instans database mengambil dari kumpulan sumber daya elastis, daripada sumber daya tetap untuk setiap database. Kumpulan Elastis dapat membantu Anda mendistribusikan kapasitas dengan lebih baik di semua instans database dan membuat solusi Anda lebih hemat biaya. Azure Cosmos DB menawarkan beberapa model isolasi untuk skenario multipenyewa.

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

  • 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 beban kerja Anda memerlukan transaksi ACID terjamin? Jika Anda bekerja dengan data nonrelasional, pertimbangkan Azure Cosmos DB, yang memberikan jaminan ACID melalui operasi batch transaksional dalam partisi logis.

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

  • Apakah solusi Anda memerlukan transaksi terdistribusi? Jika ya, pertimbangkan transaksi elastis dalam Azure SQL Database dan SQL Managed Instance. SQL Managed Instance juga mendukung panggilan tradisional melalui Koordinator Transaksi Terdistribusi Microsoft (MSDTC).

Langkah berikutnya

  • Last updated on