Apakah pagination mengurangi beban server? (teori)

11

Saya bertanya-tanya apa alasan di balik pagination? Apakah ini digunakan karena mengurangi beban pada server karena secara teknis kami akan membatasi jumlah baris yang dikembalikan per halaman?

Saya ingin melakukan sesuatu tanpa pagination tetapi mengingat bahwa saya baru dalam hal ini (saya seorang amatir) mulai bertanya-tanya apakah secara teknis OK atau tidak.

Sam Khan
sumber
Apakah Anda benar-benar ingin menunggu peramban Anda mengunduh dan merender ribuan baris pertanyaan yang tidak Anda pedulikan ketika Anda mengklik "Pertanyaan" di situs ini?
Jeremy
3
pagination lebih untuk manusia daripada DB.
Malfist

Jawaban:

10

Ada sejumlah alasan untuk memiliki pagination, mengurangi beban server hanyalah satu. Namun, Stephen Orr memunculkan poin yang valid - Anda masih perlu menemukan jumlah data terlebih dahulu. Anda harus memastikan bahwa bahwa permintaan cepat dan tidak terlalu memuat server Anda.

Alasan lain termasuk:

  • Mengurangi jumlah data yang dikembalikan ke klien dalam sekali jalan. Jika Anda memiliki banyak data, ini bisa memakan banyak waktu dan banyak memori.
  • Pengguna sering tidak tertarik pada semua data, tetapi hanya yang terbaru (katakanlah). Dengan mengembalikan hanya beberapa halaman data yang Anda tidak mendapatkan data, pengguna tidak akan pernah melihat.

Dalam kedua kasus ini, Anda tidak ingin membuat pengguna menunggu - baik untuk data yang tidak akan mereka lihat, atau untuk semua data ketika mereka bisa mendapatkannya dengan memprosesnya.

ChrisF
sumber
2
+1 Saya sedang menulis sesuatu yang serupa, tetapi Anda terlalu cepat. Izinkan saya menambahkan bahwa konten paginasi juga (ab) digunakan sebagai cara untuk menampilkan lebih banyak add.
yannis
Anda juga dapat membuat halaman tanpa harus mencari tahu berapa banyak halaman yang ada, mengetahui ada lebih banyak data daripada yang cocok dengan halaman saat ini cukup baik.
Carlo Kuip
3

Ini bervariasi tergantung pada implementasi.

Ini akan mempercepat rendering halaman, tetapi itu tidak serta merta mengurangi beban pada server. Sebagian besar algoritma pagination yang naif perlu melakukan kueri terlebih dahulu untuk memutuskan berapa banyak halaman yang seharusnya, kemudian kueri lagi untuk mendapatkan set hasil "paged".

Steve Hill
sumber
Sebagian besar algoritma pagination yang naif perlu melakukan kueri terlebih dahulu untuk memutuskan berapa banyak halaman yang seharusnya ada : Tetapi akumulasi stres pada db dari kueri hitung dan kueri hasil paginasi hampir selalu jauh lebih sedikit daripada kueri mendapatkan segalanya dalam skenario umum (dengan database relasional terstruktur dengan baik)
yannis
@YannisRizos, tentu saja. Saya baru saja melihat sisi gelap dari ini, dengan database relasional yang sangat terstruktur (banyak pertanyaan kami GABUNG 7 atau 8 tabel berbeda untuk mendapatkan hasil).
Steve Hill
@YannisRizos: tentukan "stress on the db". Anda masih mendorong dua kueri melintasi garis. Apakah Anda membuat halaman dalam kueri (jumlah baris super-pilih), atau hasil caching di tingkat lain? Ada variabel terlalu banyak untuk mengatakan ada terlalu banyak stres db. Saya akan berpendapat bahwa dilakukan dengan benar dalam arti transaksional (apakah Anda mengizinkan hitungan kotor membaca / tidak konsisten halaman?) Meningkatkan db "stress" / load tetapi menyederhanakan pemrograman.
Jé Queue
@ Xepoch Saya tidak mengatakan terlalu banyak stres, hanya saja hitung apa pun ditambah pilih terbatas <pilih penuh. Dan itu hanya untuk skenario umum pada dbs relasional terstruktur dengan baik.
yannis
1

Nilai paling banyak yang Anda peroleh dari pagination adalah meningkatkan kecepatan aplikasi Anda dengan:

1 - Membatasi data yang dikirimkan antara klien dan server. Tidak ada gunanya membaca 10.000 pelanggan jika pengguna mencari 10 dari mereka.

2- Mempercepat kinerja kueri secara signifikan dengan mengambil hanya baris yang dapat ditampung dalam tampilan pengguna. Tidak ada gunanya membaca 10.000 pelanggan jika pengguna akan melihat 10 pelanggan pertama.

3 - Pagination membantu dengan menyediakan lebih banyak data segar. Jika aplikasi Anda menunjukkan banyak baris data dan domain aplikasi Anda memerlukan banyak pembaruan untuk baris data dalam tabel yang ditampilkan, kemungkinannya adalah pada saat Anda pergi ke halaman 20 dari daftar halaman, data pada beberapa baris akan berubah. Pikirkan aplikasi yang membaca harga saham atau kamar yang tersedia di hotel. Mengambil data lama dan menempatkannya di klien tidak ada gunanya.

Pagination adalah salah satu strategi yang dikombinasikan dengan pemfilteran dan pemahaman Anda tentang bagaimana kebutuhan pengguna akhir dari skenario tertentu (yang diharapkan mengarah pada desain yang baik untuk melayani kebutuhan ini) akan sangat meningkatkan aplikasi khususnya ketika beberapa pengguna memukul database. secara bersamaan.

Pagination tidak selalu sepele untuk diprogram. Dalam beberapa kasus itu sederhana tetapi kadang-kadang sangat kompleks untuk ditulis sehingga query SQL dijalankan tanpa melakukan pemindaian tabel penuh. Ini tentu saja tergantung pada indeks Anda, kondisi filter dan pernyataan Where Anda.

Tidak mungkin
sumber
-4

Pagination, menurut saya, adalah ibu dari semua optimisasi prematur. Benar-benar oke untuk menulis situs Anda tanpa pagination.

Jika Anda menemukan, setelah rilis, bahwa Anda memuat terlalu banyak data dalam satu panggilan, atau bahwa pengguna Anda harus menunggu informasi yang mereka inginkan karena sibuk memuat data yang tidak mereka inginkan, silakan menulis solusi Ajax yang hanya memuat halaman saat orang gulir ke bawah (lihat: Twitter, Tumblr, pencarian gambar Google).

Sunting: Paragraf kedua di atas ditulis dengan asumsi bahwa respons umum adalah "tetapi jika Anda tahu Anda akan membuat pagination pada beberapa titik, Anda mungkin melakukannya lebih awal, daripada membuang waktu mengembangkan sesuatu yang akan Anda buang jauh."

Selain menjadi ibu dari semua optimisasi prematur, saya pikir pagination adalah mimpi buruk UX dan bahwa ada solusi yang lebih baik yang tidak memerlukan banyak pengembangan tambahan di atas halaman lengkap.

Terlepas dari jumlah downvotes, saya meninggalkan jawaban ini di sini karena saya berdiri dengan sentimen, meskipun itu mungkin bukan tulisan terbaik saya.

pdr
sumber
5
Saya sangat tidak setuju dengan pernyataan ini, pagination bukan untuk mengoptimalkan DB, ini tentang menyediakan data dalam potongan yang dikelola untuk manusia. Apakah Anda dapat membaca Harry Potter jika semuanya ada di satu halaman? Apakah Anda dapat mengajukan pajak jika Kode Pajak semuanya ada di satu halaman?
Malfist
@Malfist: Satu-satunya alasan Anda tidak bisa menangani hal-hal itu pada satu halaman adalah karena halaman itu sendiri akan terlalu besar. Ini bukan masalah di halaman web. Oleh karena itu situs yang saya kutip telah menemukan solusi yang lebih baik untuk pagination, sementara Lolcats saat ini memiliki hampir 2000 halaman yang tidak mungkin untuk pagination dengan cara yang masuk akal. Tapi, ini downvote Anda, gunakan sesuka Anda.
pdr
1
@Malfist: Juga, memecah hal-hal menjadi potongan yang dikelola cukup adil jika potongan itu tidak bergeser. Jika saya membaca halaman 1-4 maka saya ingin kembali lagi lain kali dan membaca halaman 5. Tetapi dalam BANYAK kasus, situs web yang dihubungi adalah daftar item, yang terbaru adalah yang terbaru. Jadi ketika saya kembali ke halaman 5 nanti, itu sebenarnya menunjukkan setengah dari halaman 3 dan setengah dari halaman 4 dari terakhir kali saya berada di sana karena ada 1,5 halaman baru dalam daftar.
pdr
2
-1 Karena saya sangat tidak setuju dengan ini juga. Saya bahkan tidak yakin harus mulai menjelaskan alasannya.
Craige
@Craige: Baiklah, kalau begitu. Saya tentu saja tidak dapat mengajukan banyak argumen tentang itu.
pdr