როგორ აკეთებთ შედეგების გვერდებად დაყოფას Django-ში და DRF-ში?

Question

Accepted Answer

**გვერდებად დაყოფა** დიდი რაოდენობის შედეგებს დელებს დისკრეტულ გვერდებად, ასე რომ არ ჩატვირთავთ ათასობით ჩანაწერს ერთდროულად. ეს აუცილებელია შესრულების და გამოყენებადობისთვის. Django უზრუნველყოფს `Paginator` კლასს შაბლონებისა და ხედებისთვის, ხოლო DRF გთავაზობს ჩაშენებულ გვერდებად დაყოფას API-ებისთვის. ## პრობლემა, რომელსაც გვერდებად დაყოფა აჭრს ```python # ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows articles = Article.objects.all() # could be 100,000 records ``` ## Django-ს Paginator (ტრადიციული ხედებისა და შაბლონებისთვის) ```python from django.core.paginator import Paginator def article_list(request): articles = Article.objects.all().order_by("-created_at") # ORDER matters for consistent pages paginator = Paginator(articles, 20) # 20 items per page page_number = request.GET.get("page") # ?page=2 page_obj = paginator.get_page(page_number) # the requested page return render(request, "list.html", {"page_obj": page_obj}) ``` ```html {% for article in page_obj %}

{% endfor %} {% if page_obj.has_previous %}Prev{% endif %} Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }} {% if page_obj.has_next %}Next{% endif %} ``` `Paginator` ჰაკს queryset-ს გვერდებად და `get_page()` აბრუნებს გვერდის ობიექტს ნავიგაციის დამხმარე ფუნქციებით (`has_next`, `next_page_number` და ა.შ.) — გაითვალისწინეთ, რომ ის ამატებს `LIMIT`/`OFFSET` მოთხოვნას, ამიტომ მხოლოდ ერთი გვერდი ჩამოიტვირთება მონაცემთა ბაზიდან. ## DRF გვერდებად დაყოფა (API-ებისთვის) ```python # global default in settings.py REST_FRAMEWORK = { "DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination", "PAGE_SIZE": 20, } # now list endpoints are automatically paginated, returning: # { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] } ``` DRF აკეთებს სიაში დაჯამებული ბოლო წერტილების გვერდებად დაყოფას ავტომატურად, როდესაც კონფიგურირებულია, აბრუნებს გვერდის მეტა-მონაცემებს (რაოდენობა, შემდეგი/წინა ბმულები) შედეგების გვერდზე — კლიენტები ნავიგაციას ახორციელებენ მოწოდებული URL-ების მეშვეობით. ## DRF გვერდებად დაყოფის სტილები ```text PageNumberPagination → ?page=2 (simple page numbers) LimitOffsetPagination → ?limit=20&offset=40 (flexible offsets) CursorPagination → opaque cursor; consistent & performant for large/changing data (avoids OFFSET performance issues on huge datasets) ``` ## შესრულების დახვეწილი მომენტი ```text ⚠️ OFFSET-based pagination (page/offset) gets SLOWER on deep pages of huge tables (the DB must skip OFFSET rows). For very large datasets, CURSOR pagination (keyset, using a WHERE on an indexed column) is far more efficient. ⚠️ Always ORDER BY a stable field, or pages can be inconsistent/repeat items. ``` ## რატომ არის ეს მნიშვნელოვანი გვერდებად დაყოფა აუცილებელია შესრულებული, გამოსაყენებელი აპლიკაციების აგებისთვის, რომელიც თავს ჯდება რეალური მონაცემების მოცულობებთან — მის გარეშე, ჩამონათლელი ბოლო წერტილები და გვერდები, რომელიც ჩატვირთავს მთელი ცხრილებს (შესაძლოა ათასობით ან მილიონი რიგი), ნელი, მეხსიერებით დატვირთული და გამოუყენებელი ხდებიან, როგორც მონაცემთა ბაზას ზეწოლას აღება, ისე მომხმარებელი და კლიენტების დასაკმაყოფილებელი. გვერდებად დაყოფის გაგება ყოველდღიური პრაქტიკული ცოდნაა: Django-ს **Paginator** ამუშავებს ტრადიციულ ხედებსა და შაბლონებს (ჰაკებს querysets-ს გვერდებად ნავიგაციის დამხმარე ფუნქციებით, ეფექტურად ჩამოიტვირთება მხოლოდ ერთი გვერდი LIMIT/OFFSET მეშვეობით), და DRF-ის **ჩაშენებული გვერდებად დაყოფა** ამუშავებს API-ებს (ავტომატურად აკეთებს სიაში დაჯამებული ბოლო წერტილების გვერდებად დაყოფას მეტა-მონაცემებით და ნავიგაციის ბმულებით, როდესაც კონფიგურირებულია) — ორივე საჭიროა იმისდა მიხედვით, აგებთ თუ სერვერით გამოტანილ გვერდებს ან API-ებს. მკაფიო აგებული გვერდებად დაყოფის ცოდნა ორივე კონტექსტში აუცილებელია თითქმის ნებისმიერი მონაცემების ჩამონათლელი ფუნქციისთვის. **შესრულების დახვეწილი მომენტი** განსაკუთრებით ღირებული უფროსი დონის ცოდნაა: სტანდარტული OFFSET-ზე დაფუძნებული გვერდებად დაყოფა დეგრადირდება ძალიან დიდი ცხრილის ღრმა გვერდებზე (მონაცემთა ბაზამ უნდა გაახალი ყველა წინამორბე რიგი), ამიტომ **კურსორი (keyset) გვერდებად დაყოფა** ეფექტური არჩევანია უზარმაზარი ან სწრაფად განაკვეთი მონაცემთა ბაზებისთვის, და ყოველთვის **რიგი მდგომარეობის სტაბილური ველით** აუცილებელია თავიდან აცილებელი არაკონსიქტენტური ან დუპლიცირებული შედეგების გვერდზე. ორივე ძირეული მექანიკის გაგება (Paginator, DRF გვერდებად დაყოფის კლასები) და ამ შესრულების მოსაზრებები (OFFSET vs კურსორი გვერდებად დაყოფა, კონსისტენტური რიგი) მნიშვნელოვანია აპლიკაციების აგებისთვის, რომელიც დარჩება სწრაფი და სწორი, როდესაც მონაცემი იზრდება — გვერდებად დაყოფა უსაზღვროდ საჭირო მოთხოვნაა, და ის კარგად, განსაკუთრებით მასშტაბით, პრაქტიკული უნარი, რომელიც პირდაპირ გავლენას ახდენს აპლიკაციის შესრულებაზე და მომხმარებლის გამოცდილებაზე.