Pemisahan baca-tulis
Ketika bisnis perusahaan terus berkembang dan jumlah pengguna meningkat secara signifikan, database asli kemungkinan tidak dapat mempertahankan dirinya sendiri. Lalu ya
- Scale-in, yang memperluas kinerja perangkat keras, tetapi kemungkinan jumlah pengguna akan terus bertambah, dan peningkatan kinerja akan segera dimakan.
- Pemisahan baca-tulis: Basis data tidak dapat bertahan, itu tidak lebih dari terlalu banyak baca dan tulis, terutama jika ada beberapa kueri kompleks seperti produk paling populer dalam 24 jam terakhir. Ini membutuhkan pernyataan SQL yang sangat kompleks, dan tentu saja lambat untuk dijalankan.
Namun, untuk memisahkan bacaan dan penulisan, database perlu dibagi menjadi pustaka master dan slave.
Database relasional utama di pasaran mendukung replikasi data, sehingga Anda dapat membagi database menjadi dua peran: Master dan Slave, operasi tulis pada master, dan menyinkronkan server master ke server slave lainnya.
Operasi offline seperti operasi baca dan analisis data dilakukan pada server Slave.
Kita tahu bahwa banyak aplikasi di Internet yang dibaca, sehingga banyak budak dapat berbagi beban dan memastikan ketersediaan dan kebenaran data.
Namun, kode aplikasi asli yang sesuai juga perlu dimodifikasi, dan harus diubah untuk menggunakan pustaka master untuk menulis data, dan menggunakan pustaka slave saat membaca data, yang setara dengan menulis ulang.
Kueri kompleks
Namun, bahkan setelah menulis ulang kode, saya menemukan bahwa kinerjanya masih belum ditingkatkan secara signifikan karena terlalu banyak kueri kompleks yang digunakan, dan kami telah mengatakan dalam komponen database bahwa gabungan sangat intensif kinerja.
Jadi bisakah kita menggunakan tabel terpisah untuk menyimpan produk populer dalam 24 jam terakhir, sehingga kita hanya perlu menggunakan SQL sederhana untuk melakukannya.
Dengan kata lain, satu set tabel database tidak sesuai untuk perilaku yang berbeda seperti laporan, pencarian, transaksi, dll.
Tabel saat ini dirancang untuk menambahkan dan memodifikasi data, dan tidak cocok untuk kueri yang kompleks.
Tetapi kita juga perlu mempertimbangkan bagaimana basis kueri ini diperbarui, atau apakah kita dapat mentolerir penundaan ini, apakah mungkin tidak diperbarui secara real time.
CQRS
Apakah penundaan dapat ditoleransi perlu dilihat dari perspektif bisnis, seperti produk terbaik yang populer dalam 24 jam terakhir, sedikit informasi yang ketinggalan zaman tidak banyak berdampak, hanya konsistensi akhir yang diperlukan.
Kita dapat menggunakan CQRS (Command Query Responsibility Segregation), yaitu pemisahan perintah untuk menambahkan atau memodifikasi perintah dari tanggung jawab kueri.
Di CQRS, penekanannya adalah pada pemisahan read (Query) dan write (Command), karena data yang dibaca oleh pengguna biasanya sudah ketinggalan zaman, jadi mengapa perlu membaca dari database, Anda dapat langsung membuat sumber data baca. Bisa berupa Cache, bisa XML, JSON, dll.
Bagaimana cara mengatasi masalah cara memperbarui yang disebutkan sebelumnya? Anda dapat menggunakan Peristiwa, yaitu peristiwa, misalnya, ketika produk dijual, Anda dapat menerbitkan peristiwa untuk memodifikasi Model Baca asli.
Dengan cara ini, sinkronisasi menjadi asinkron melalui mekanisme peristiwa.
Terakhir, metode ini paling baik digunakan hanya untuk kueri kompleks, dan kueri sederhana asli masih diambil dalam database relasional. Mengapa? Karena pengenalan teknologi baru membutuhkan harga, seperti langkah mutasi sinkron dan mekanisme peristiwa, kita tidak bisa hanya melihat keuntungan dari teknologi baru dan bukan kerugiannya.
|
Diposting pada 04/05/2020 09.58.50
|
|
|
|
