Fazla Join performansı düşürür mü

[ertank]

Merhaba,

- Her bir tablonun toplam kayıt sayısı nedir?
- Her bir tablonun yıllık kayıt sayısı artışı nedir?
- Eski sipariş bilgilerinde değişiklikler oluyor mu?

[true_false]

oooo üstad sen daha ölmedin mi? Her neyse tabi Allah gecinden versin şaka sadece.
bahsettiğin 2 durumdam join olanı kaçınılmaz.
1-)yazdığın sorgunun planına bak (Explain Plan) Sorgun, joinledin tabloları full okuyorsa join fieldları indexleyerek performans artışını gözlede görebilirsin. (Explain plan için TOAD'dan yararlanabilirsin.) yani SözdeKOD

Kod: Tümünü seç

inner join tabloa on jointablo.joinfield = tabloa.id

gibi bir join yapıyorsan jaointablo daki joinfieldını indexle.

2-)zaruri olmadıkça left join kullanma

3-) Db yapını bilmiyorum. Eğer veritabanından ben genelde sorgu çekiyorum. dediğin bir db yapın varsa MySql'in MyIsam motorunu kullanabilirsin. Genelde RDBMS yapısı kullanıldığı için Mysql'de InnoDb tercih edilir ama MyIsam'ım select performansının daha iyi olduğu söylenir. InnoDb ile MyIsam arasındaki farklara ve söylentilere şuradan bakabilirsin.

tabi 3. madde tercihi oturmuş bir sistem için çok tercih edilebilir bir durum değil bu tercihi yolun başında yapılması gerekiyor. MyIsam iyidir güzeldir ama en basitinden transaction mantığı yoktur dikkatli olmak gerekir.

[csunguray]

Gerekliyse join kullanmaktan kaçınmamalısınız. Performanstan şikayetçiyseniz server'ınızı güçlendirmelisiniz. Böyle bir şey için tasarımdan ödün verilmez.

[ertank]

merhaba

- Her bir tablonun toplam kayıt sayısı nedir? 300.000
- Her bir tablonun yıllık kayıt sayısı artışı nedir? 20.000-150.000
- Eski sipariş bilgilerinde değişiklikler oluyor mu? hayır

Bu miktardaki kayıt sayıları için SQL komutu planı incelenerek yapılabilecek düzenlemelerden sonra join kullanmaya devam edebilirsiniz diye düşünüyorum. Duruma göre database sunucu RAM kullanım miktarlarını (çalışma RAM miktarı, Max RAM kullanımı, vs.) zaman içinde artırmanızda fayda olabilir. Eğer kayıt sayıları 10 milyonlar veya üzerinde olsa idi aşağıdaki yöntemi uygulamanız tavsiye edilebilirdi.

Olası tavsiye: SQL Server 2008 ve sonrası, PostgreSQL 9.3 ve sonrası, Oracle üzerinde direk desteklenen "materialized view" https://en.wikipedia.org/wiki/Materialized_view kullanmanız mümkün olabilirdi. Bildiğim kadarıyla MySQL/MariaDB desteklemiyor ancak dolaylı yollardan kullanmanız mümkün. İnternette araştırabilirsiniz.

Materialized view özetle, tablo şeklinde kullanabileceğiniz view olarak düşünebilirsiniz. Uzun sürecek birkaç kademeden oluşan join sorgunuzu materialized view olarak oluşturup çalıştırın. Oluşan view kalıcıdır. Bir sonraki view güncellemesine kadar database sunucu kapatılıp açılsa dahi sabit kalır. Buna ek olarak view üzerindeki kolonlar için indeks oluşturmanız da mümkün. Hatta oluşturacağınız indeksleri filtreli şekilde oluşturarak (PostgreSQL 7.2 (belki daha önceki sürümlerde de mevcut), SQL Server 2016 ve sonrası, Oracle destekler. MySQL bilgim dahilinde desteklemez) indeks boyutunu küçültür ve sık kullanmanız gereken bilgileri çok daha çabuk sorgulayabilirsiniz. Böylece sabit bilgilerden oluşan raporlamanız veri miktarı büyük olsa dahi çok hızlı şekilde sonuçlanacaktır.

Bu işlemlerin tamamı database sunucular üzerindeki optimizasyonlar idi. Uygulama tarafında da bir takım optimizasyonlar yapmanız mümkün olabilir.

NOT: https://en.wikipedia.org/wiki/Partial_index burada belirtildiği kadarıyla MariaDB 3.2 sürümden itibaren partial index destekliyormuş. SQLite 3.8.0 sürümden itibaren destekliyormuş. MySQL 5.7 versiyonda halen mevcut olmadığı yazılı.

[ertank]

MySQL içindeki view için "normal view" diyebiliriz. Bu view her sorgulandığı zaman view oluşturan SQL komutu çalıştırılır. Yani SQL komutunu çalıştırma ile normal view çalıştırma arasında pek bir fark yoktur.

Maretialized view oluşturulur iken bir defa çalıştırılır. Bunun dışında belirli aralıklar ile güncellenip bir önceki güncellemeden sonra eklenen kayıtları da view içine ekler. Daha önce bahsettiğim gibi materialized view bir nevi tablo gibidir.

Dolayısıyla sizin kullandığınız normal view ile önceki cevabımda bahsettiğim materialized view tamamen farklılar.

Çalışma hızı anlamında her ikisi de ilk çalıştırmada ve güncellemede (refresh) normal SQL komutu gibi zaman alır. Fark materialized view kalıcı bir tablo gibi davranır. Oluşturulan bilgileri silmez.

Aşağıdaki yerli kaynakları okumanızda fayda olabilir. Her ne kadar Oracle için hazırlanmış olsalar da konsepti anlamada yardımcı olacaktır.
http://berkeoz1.blogspot.com.tr/2013/08 ... ew-ve.html
http://www.guvenyilmaz.com/?p=1139
http://www.oganozdogan.com/2011/09/mate ... -view.html
http://serkan-yilmaz.blogspot.com.tr/20 ... -fast.html
https://eksisozluk.com/materialized-view--3630476

Yabancı kaynaklara örnek olarak aşağıdaki bağlantıları inceleyebilirsiniz.
https://docs.oracle.com/cd/B10501_01/se ... pmview.htm
https://www.postgresql.org/docs/9.6/sta ... views.html
http://www.java67.com/2012/11/what-is-d ... e-sql.html

[ertank]

Oracle Express sürümü ücretsizdir. Bir bilgisayara bir database, Max 1GB RAM kullanımı, 11GB kullanıcı verisi şeklinde limitleri vardır.
http://www.oracle.com/technetwork/datab ... index.html

Şahsen Oracle yerine PostgreSQL kullanmayı tercih ederim. Lisanslı olmasa dahi denediğim kadarıyla Oracle sistemin her türlü kaynağına çok yükleniyor.