Beberapa akses database atau salah satu akses besar?

Apa pendekatan yang lebih baik dalam hal kinerja dan pemanfaatan sumber daya yang optimal: mengakses database beberapa kali melalui AJAX untuk hanya mendapatkan informasi yang tepat saat dibutuhkan, atau melakukan satu akses untuk mengambil objek yang menyimpan semua informasi yang mungkin diperlukan , dengan probabilitas tinggi bahwa tidak semua benar - benar dibutuhkan?

Saya tahu cara membandingkan permintaan sebenarnya, tapi saya tidak tahu bagaimana menguji apa yang terbaik dalam hal kinerja database ketika ribuan pengguna mengakses database secara bersamaan dan bagaimana pooling koneksi ikut berperan.

Tidak ada jawaban yang benar untuk ini; seperti optimasi apa pun, itu sangat bergantung pada konteks / penggunaan.

Namun, pertimbangkan hal berikut sebagai aturan praktis:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

Ingat aturan optimasi pertama: mengukur, jangan menebak . Coba keduanya, instrumen mereka dengan semacam kode stopwatch, dan lihat apa yang lebih lama.

Dan juga ingat lelucon lama bahwa "hanya ada dua masalah sulit dalam ilmu komputer: pembatalan cache dan penamaan hal-hal dengan baik." Jika Anda menarik semuanya dari DB sekaligus dan menyimpannya di memori, Anda memiliki cache. Dan sekarang Anda memiliki masalah baru: kapan saja apa pun berubah di mana saja dalam sistem , itu harus membuat perubahan yang sama di dua tempat: database, dan cache. Jika Anda memiliki lebih dari satu server yang berbicara dengan DB, atau beberapa API untuk membuat server memodifikasi data, ini bisa menjadi sangat rumit dengan sangat cepat.

Tidak ada solusi peluru perak untuk pertanyaan ini. Saya kira Anda perlu MENCOBA kemungkinan trade-off dan menyempurnakan server Anda untuk mencapai yang terbaik darinya.

Poin pertama: sebelum mulai melakukan perbaikan apa pun, Anda perlu SET tolok ukur kinerja saat ini , mengukurnya , dan menjadikannya sebagai dasar perbandingan solusi yang mungkin untuk memperbaikinya.

Yang kedua adalah, penggunaan aplikasi perlu dilacak. Cara penggunaan aplikasi oleh pengguna akhir. Mengurangi nomor mentah data yang dikembalikan yang tidak diperlukan oleh pengguna akhir dapat menghemat banyak sumber daya server yang berharga . Misalnya: tidak ada gunanya mengembalikan 5.000 catatan saat pengguna tertarik pada 50 yang pertama.

Poin ketiga: Anda harus memahami frekuensi panggilan dan kemungkinan implikasinya. Misalnya: jika sebagian besar panggilan adalah kueri tabel nilai pencarian, maka Anda mungkin akan membuat infrastruktur untuk melakukan cache panggilan ini . Dengan kata lain, jika data Anda tidak sering berubah, pertimbangkan opsi caching. Dan tentu saja, meminimalkan jumlah panggilan selalu akan membantu meningkatkan kinerja.

Mendapatkan semuanya sekaligus akan memberi Anda kinerja yang lebih baik, kecuali "semuanya" mencakup hal-hal seperti Gumpalan atau objek data besar yang serupa. Kinerja overhead untuk membuat serialisasi segalanya, memindahkannya di atas kabel, lalu membatalkan deserialisasi di ujung yang lain cukup signifikan, dengan latensi jaringan menjadi bagian yang besar. Memori lebih murah daripada bandwidth jaringan, dan mungkin akan tetap demikian untuk sementara waktu. Satu-satunya jawaban Anda yang sebenarnya akan datang dari tolok ukur, tetapi jika Anda hanya mencoba mengukur satu di atas yang lain, itulah cara saya bersandar.

Jika Anda membuat keputusan arsitektur, maka REST adalah salah satu opsi. Dengan REST, Anda selalu meminta sumber daya beberapa kali, yaitu Anda tidak mengirim permintaan untuk mendapatkan 2 objek karena setiap objek memiliki url sendiri. Perhatian kinerja dengan melakukannya gaya ini mungkin akan diselesaikan ketika HTTP / 2.0 keluar. Kalau tidak, Anda hanya mengoptimalkan untuk membuatnya secepat mungkin. Banyak perusahaan melakukannya dengan cara ini.