Forum
Aktif konular
Üyeler
Kurallar
Arama
Hacimli Tablolarda Offset Performans Sorunu Hacimli Tablolarda Offset Performans Sorunu
-
Elimde 10m kayıt olan bir tablo var. Veritabanı olarak MySQL 8 kullanıyorum ve veritabanı motoru olarak InnoDB kullanıyorum. Belirli filtrelere göre bu 10m'lik tabloda sayfalama yapmam gerekiyor. Sayfalamayı limit ve offset ile yapıyorum (limit 5 offet 1000 gibi). Offset işin içine girdiğinde veritabanı offset sayısı kadar tek tek tek satırları geziyor ve offsete ulaştıktan sonra limit değeri kadar kayıt dönüyor. Bu da demek oluyor ki offset arttıkça tabloda tek tek gezeceği satır sayısı artıyor. Offset 10000 olduğunda ilk 10000 satırı tek tek pas geçmiş oluyor. Buda offset arttıkça büyük performans kaybına sebep oluyor. Bu konuyu aşmak için nasıl yöntemler uyguluyorsunuz?
-
ID ye göre getirebilirsin hocam mesela
select kolon FROM tablo where ID < idno order by ID desc limit 0,10
Dediğinden en sondaki 10 kaydı getirir sonraki sayfaya tıkladıntan sonra en son id yi alıp o id den küçük olan 10 kayısı getir diye devam eder.
umarım anlatabilmişimdir
-
EmQceR bunu yazdı
ID ye göre getirebilirsin hocam mesela
select kolon FROM tablo where ID < idno order by ID desc limit 0,10
Dediğinden en sondaki 10 kaydı getirir sonraki sayfaya tıkladıntan sonra en son id yi alıp o id den küçük olan 10 kayısı getir diye devam eder.
umarım anlatabilmişimdir
Hocam bahsettiğin load more'da çalışabiliyor. Ancak standart sayfalamada kullanıcı istediği zaman istediği sayfayı seçebileceği için ID'den gitme olayı ne yazikki patates :/
-
-
yolbulucu bunu yazdı
Burdaki yöntemde pagination'u next, prev ile kullanabiliyoruz. ne yazikki N. sayfaya geçiş yapamıyoruz.
-
index var mı db de ? Çok uzun sürmemeli hocam bende 100m satırlı tablo var ebesinin nikahı gibi joinler var 1 saniye bile sürmüyor.
-
MhmdAlmz bunu yazdı
index var mı db de ? Çok uzun sürmemeli hocam bende 100m satırlı tablo var ebesinin nikahı gibi joinler var 1 saniye bile sürmüyor.
hocam offset işin içine girince durum değişiyor. ofset 10-20 de sorun yok offset 40000, 50000 geldiğinde ve aynı anda 40 kullanıcı bunu isteyince işler karışıyor. offset işin içine girince konu indexden çıkıyor. offseti yakalayabilecek için offset kadar rowu tek tek scan ediyor. tabiki db sunucunun ram'i yüksekse ve bu ram'e göre ayar yapıldıysa bu konu daha az sancı yaratabiliyor ancak bir noktadan sonra herkes için bir kanser oluyor. bilgin olması için ve ileride karşına gelirse diye araştırmanı öneririm.
@yolcubulucu dayının paylaştığı video'ya bakarbilirsin istersen. ses kötü ama konuyu anlayabilirsin. ayrıca https://www.slideshare.net/Eweaver/efficient-pagination-using-mysql buda dayının sunumu.
TeRRoR tarafından 16/Mar/20 17:53 tarihinde düzenlenmiştir -
@MhmdAlmz benim sorgum şu şekilde, aşağıda EXPLAIN çıktısını paylaşıyorum. Belki index tarafında benim atladığım birşey vardır.
Query:
https://paste.ubuntu.com/p/qvDGS4w4ZF/
Explain:
https://paste.ubuntu.com/p/bfmnfV27N9/
Indexler:
Products tablosunda:
category_id ve is_active için tek index.
Product_Filter tablosunda
product_id için tek index.
-
@EmQceR bahsettiği çözümün adı keyset pagination olarak geçiyor. Hem offset problemi için hemde keyset pagination implementasyonu içinde buraya bakabilirsini.
-
TeRRoR bunu yazdı
@EmQceR bahsettiği çözümün adı keyset pagination olarak geçiyor. Hem offset problemi için hemde keyset pagination implementasyonu içinde buraya bakabilirsini.
Adını bilmiyordum ama ben bu mantıkla kullanıyordum id değerini JavaScript'le alıp yapıyordum. Bilgi için teşekkürler umarım işine yaramıştır ki döküman da yaramış gözüküyor
-
EmQceR bunu yazdıTeRRoR bunu yazdı
@EmQceR bahsettiği çözümün adı keyset pagination olarak geçiyor. Hem offset problemi için hemde keyset pagination implementasyonu içinde buraya bakabilirsini.
Adını bilmiyordum ama ben bu mantıkla kullanıyordum id değerini JavaScript'le alıp yapıyordum. Bilgi için teşekkürler umarım işine yaramıştır ki döküman da yaramış gözüküyor
hocam ne yazikki keyset pagination next-prev'de işe yarıyor. 1-2-3-4....123 sayfalamada işe yarayamıyor ne yazikki. Bu arada bir iki düzeltme yapmam gerekiyor. Konuyu açarken paylaştığım sorguda select products.id yazan kısım normalde select products.* şeklindeydi ben kurcalarken yanlış olanı paylaşmışım sizinle. select products.id büyük oranda performans artışı sağladı sebebini tam olarak çözemedim ancak group by için oluşturduğu temp table'a sadece id alınca daha az memory ile işlem yaptığı için yoğun kullanımda IO kullanımıda düştü diye düşünüyorum. Bu durumda aslında yıllarca select * ile değil kullanacağınız kolonları alın sadece uyarısının güzel bir karşılığı oldu benim için. ORM'nin dezavantajları işte :/
Bu arada offset'in benim için major sorun yaratması group by ile kullanıyor olmam. Şu aşamada select products.id ile çekip dönen id listesini where in ile tekrar çekip kullanıyorum ve gözle görülür bir performans artışı var gözüküyor test ortamında ilerleyen süreçt tekrar karın ağrısı olduğunda bakıcaz duruma artık, eğer bu ekonomik durumda batmazsak tabi :)
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla