bu sorguları nasıl düzeltebilriz?

17-05-2013, 19:13:07

Merhaba Arkadaşlar,
büyük kayıtlı iki tabloda çekmek istediğim veriler için kullandıgım bu iki sorguyu daha performanslı(hızlı) nasıl düzeltebiliriz acaba.

SELECT videos.title,videos.id,videos.views,videos.thumb,videos.duration,users.display_name FROM videos LEFT JOIN users ON videos.user_id = users.id where videos.category ='".$channel_id."' and videos.id != '".$basic_id."' ORDER BY rand() LIMIT 0,15

SELECT videos.*, channels.cat_name,channels.yt_slug, users.display_name, users.avatar,'".$config->db->name."' dbx FROM `videos` 
LEFT JOIN channels ON videos.category =channels.cat_id
LEFT JOIN users ON videos.user_id = users.id
WHERE videos.`id` = '".$basic_id."' limit 0,1

17-05-2013, 20:07:19

#2

fatihemre

Merhaba,

Bu sorgularınız için yeni olarak ne üretirsek üretelim, siz bu sorguları nerede ve nasıl kullanıyorsunuz bilmediğimiz için yazdıklarımız hayal ürünü olmaktan öteye geçemez. Tablo yapınızı bilmiyorum, dönen sorguları nasıl php kodları arasında kullanıyorsunuz bilmiyoruz. Sorgudan dönen verileri nasıl kullanıyorsunuz, nerelerde kullanıyorsunuz ya da dönen sütunların hangilerini kullanıyorsunuz bilmiyoruz. Örneğin bir satır veriniz tahmini ne kadar bellek harcıyor bilmiyoruz, vesaire..

Bu yüzden sorgularda dikkatimi çeken tek şey join işlemleri oldu. join yerine where ile bağlama ne kadar alternatif olabilir kodlara bilemem tabi.

17-05-2013, 20:15:28

#3

BLaH

bayGaReZ adlı üyeden alıntı: mesajı görüntüle

Merhaba,

Bu sorgularınız için yeni olarak ne üretirsek üretelim, siz bu sorguları nerede ve nasıl kullanıyorsunuz bilmediğimiz için yazdıklarımız hayal ürünü olmaktan öteye geçemez. Tablo yapınızı bilmiyorum, dönen sorguları nasıl php kodları arasında kullanıyorsunuz bilmiyoruz. Sorgudan dönen verileri nasıl kullanıyorsunuz, nerelerde kullanıyorsunuz ya da dönen sütunların hangilerini kullanıyorsunuz bilmiyoruz. Örneğin bir satır veriniz tahmini ne kadar bellek harcıyor bilmiyoruz, vesaire..

Bu yüzden sorgularda dikkatimi çeken tek şey join işlemleri oldu. join yerine where ile bağlama ne kadar alternatif olabilir kodlara bilemem tabi.

sql den gelebilecek sonucları tahmin etmek güç değil bence ama,
1. sorgu da rast gele 15 kayıt çekip, ekrana yazma işlemi
diğer sorgu ise get ile gelen id ye videonun bilgilerini çekme işlemi,
ücretli bu ve benzer sistemi yoran sorguları tesip edip çözebilecek arkadaşlarda makul ücret talepleri ile iletişim bilgilerini pm atabilirler.

17-05-2013, 20:24:07

#4

fatihemre

BLaH adlı üyeden alıntı: mesajı görüntüle

sql den gelebilecek sonucları tahmin etmek güç değil bence ama,
1. sorgu da rast gele 15 kayıt çekip, ekrana yazma işlemi
diğer sorgu ise get ile gelen id ye videonun bilgilerini çekme işlemi,
ücretli bu ve benzer sistemi yoran sorguları tesip edip çözebilecek arkadaşlarda makul ücret talepleri ile iletişim bilgilerini pm atabilirler.

Uygun görürseniz sisteminizi incelemek isterim.

17-05-2013, 22:29:34

#5

digiklan

yazılım size mi ait?
bir keremysql rand() kaldıracaksınız. kayıt sayısı bir kaç binden fazla olduğunda hele hele yüzbinleri bulduğunda mysql rand intihardır. onun yerine php rand kullanacaksınız.
ayrıca bu sistemde dün konuştuğumuz api video sitesindeyse ki öyle sanıyorum join li işlemler yerine 2 sorgu yapmanız daha hızlı sonuç döndürür.
ve yine daha az kaynak harcama adına bu rastgele videoları 2-3 dakikada bir yenilenecek şekilde bir file cache e bağlarsanız anlık kullanıcı sayısı artsa bile performans açısından zaafiyet doğmaz.

18-05-2013, 01:03:50

#6

NepenTheS

digiklan adlı üyeden alıntı: mesajı görüntüle

yazılım size mi ait?
bir keremysql rand() kaldıracaksınız. kayıt sayısı bir kaç binden fazla olduğunda hele hele yüzbinleri bulduğunda mysql rand intihardır. onun yerine php rand kullanacaksınız.
ayrıca bu sistemde dün konuştuğumuz api video sitesindeyse ki öyle sanıyorum join li işlemler yerine 2 sorgu yapmanız daha hızlı sonuç döndürür.
ve yine daha az kaynak harcama adına bu rastgele videoları 2-3 dakikada bir yenilenecek şekilde bir file cache e bağlarsanız anlık kullanıcı sayısı artsa bile performans açısından zaafiyet doğmaz.

Hocam şu aralar herkeste bir join kullanma hastalığı görüyorum. Fakat okuduğum 2 3 makale de join ile tablo ilişkilendirme işlemlerinin büyük verilerde daha fazla sıkıntı yaratacağı yönünde görüşler var bunun doğruluğu nedir acaba ?

18-05-2013, 01:33:51

#7

digiklan

NepenTheS adlı üyeden alıntı: mesajı görüntüle

Hocam şu aralar herkeste bir join kullanma hastalığı görüyorum. Fakat okuduğum 2 3 makale de join ile tablo ilişkilendirme işlemlerinin büyük verilerde daha fazla sıkıntı yaratacağı yönünde görüşler var bunun doğruluğu nedir acaba ?

join işi kolaylaştırır. ama mysql kararsız bir database. eğer 50 satır kategori 100 satır kayıt ve 30 satır user varsa problem yok.
ama 50 satır kategori 1 milyon satır kayıt ve 250.000 user varsa geçmiş olsun.
cevap süreleri uzuyor işlemci kullanımı tavan yapıyor.
muhtemelen sebebi veritabanının ilişkiyi kurabilmek için kendi içinde gerçekleştirmek zorunda olduğu geçişler.

bunun yerine sayısal primary id üzerinden sorgulanan bir sistem ile, doğru index alanları eklenmiş tablolar arasında php yi gezzdirmek daha doğru. bir sorgu yap 1 milyon kayıt içinden tek satır iste primary sayısal id ile milisaniye düzeyinde yanıt geliyor. bu gelen satırdan user_id ve category_id al 2 sorgu ile user bilgisi çek, kategori bilgisi çek. 3 işlem de milisaniye düzeyinde ve 1 saniyeyi bulmaz.

ama sen join yaptığında veritabanı bir kaç saniyede yanıt veriyor. muhtemelen sebebi join dediğinde satırları bir birine bağlayabilmek için 2 tabloyu birleştirmek için aynı anda kullanıyor. join yapılan tablo sayısı ve bu tablolardaki kayıtlar arttıkça yanıt süresi çok kararsız hale geliyor, işlemci %100 üzerine vuruyor.

19-05-2013, 18:36:33

#8

BLaH

digiklan adlı üyeden alıntı: mesajı görüntüle

join işi kolaylaştırır. ama mysql kararsız bir database. eğer 50 satır kategori 100 satır kayıt ve 30 satır user varsa problem yok.
ama 50 satır kategori 1 milyon satır kayıt ve 250.000 user varsa geçmiş olsun.
cevap süreleri uzuyor işlemci kullanımı tavan yapıyor.
muhtemelen sebebi veritabanının ilişkiyi kurabilmek için kendi içinde gerçekleştirmek zorunda olduğu geçişler.

bunun yerine sayısal primary id üzerinden sorgulanan bir sistem ile, doğru index alanları eklenmiş tablolar arasında php yi gezzdirmek daha doğru. bir sorgu yap 1 milyon kayıt içinden tek satır iste primary sayısal id ile milisaniye düzeyinde yanıt geliyor. bu gelen satırdan user_id ve category_id al 2 sorgu ile user bilgisi çek, kategori bilgisi çek. 3 işlem de milisaniye düzeyinde ve 1 saniyeyi bulmaz.

ama sen join yaptığında veritabanı bir kaç saniyede yanıt veriyor. muhtemelen sebebi join dediğinde satırları bir birine bağlayabilmek için 2 tabloyu birleştirmek için aynı anda kullanıyor. join yapılan tablo sayısı ve bu tablolardaki kayıtlar arttıkça yanıt süresi çok kararsız hale geliyor, işlemci %100 üzerine vuruyor.

peki bana daha önce anlattığınız gibi rand'dan kurtulabiliyorum ama join yapısından nasıl kurtarabilrim. rica etsem bu sorguları değiştirebilmeniz mümkünmüdür? görmüş ve öğrenmiş olurum.

19-05-2013, 18:48:21

#9

Byturkx

Join kullanabileceğin yerlerde sub query'de kullanabilirsiniz.