Veritabanı endeksleri eklemek için erken optimizasyon var mı?

Bugün bir meslektaşım başvurumuzdaki tüm soruları gözden geçirmemizi ve buna göre endeksleri eklememizi önerdi.

Bunun erken optimizasyon olduğunu düşünüyorum çünkü uygulamamız henüz yayınlanmadı. Canlı yayına girdikten sonra yavaş sorguları izlemeyi ve ardından buna göre indeksler eklemeyi önerdim.

Veritabanınızı tasarlarken genel fikir birliği nedir, her yeni bir sorgu yazışınızda eşleşen bir dizin eklemeniz gerekir mi? Yoksa sadece nasıl gittiğini görmek ve görmek daha mı iyi?

Erken optimizasyon, belirsiz, sezgisel bir anlamdan dolayı bir şeyi "optimize ediyor". Biliyorsunuz, muhtemelen kod okunabilirliği ve bakımının zararına bağlı olarak bu muhtemelen yavaş olacak . Performansla ilgili iyi bilinen iyi uygulamaları takip etmeyeceğimi kasten kastetmiyor.

Bazen bu çizilmesi zor bir çizgidir, ancak kesinlikle canlı yayına girmeden önce herhangi bir endeks eklememenin çok geç bir optimizasyon olduğunu söyleyebilirim ; Bu, en istekli ve en önemli kullanıcılarınız olan erken evlatçıları cezalandırır ve onlara, daha sonra incelemelerde, tartışmalarda vb. yayılacakları olumsuz bir görünüm verir. Dizin oluşturması gereken acı noktalarını bulmak için sorguları izlemek, iyi bir fikir, ancak bunu en geç beta sürümden yapacağımdan emin olabilirim.

yayınlandığında yavaş sorguları izlemek

çünkü hiçbir şey kalitenizi, kullanıcılarınızın tasarım eksikliğinden dolayı acı çektirmesi demek değildir!

Tabloları tasarlarken hangi sorguların indekslere ihtiyacı olduğunu bilmelisiniz, hangi cümleciklerin ve birleşme noktalarının hangi sütunlarda sorgulandığını bilmelisiniz. Bunların önceden indekslenmesi gerekir; çünkü canlı bir ortamda belirgin olmayan şeyler, depolanan yük veya veri arttığında hızlı bir şekilde ortaya çıkabilir. Bu olduğunda yapmak istemediğiniz şey, her 'yavaş' sorguya indeksler koymak, her şeyde bir indeksle sonuçlanacak.

“Erken optimizasyon”, aşağılayıcı anlamında, gerekmeyebilecek maliyetli optimizasyon anlamına gelir. O değil iflas önlemek için olası en geç noktasından önce uygulanan tüm optimizasyon demek!

Özellikle, uygulamanızın tamamen emmemesi için bazı makul (yaklaşık da olsa) gereklilikleri karşılayabileceğinizden emin olmak için, yayınlanmadan önce performans testlerine dayalı olarak optimize etmek meşrudur.

Mutlak bir asgari düzeyde , veritabanınıza makul miktarda test verisi yüklemeli ve uygulamanızın yanıt verebilirliğini kontrol etmelisiniz. Bu erken değil, çünkü bunun olacağını biliyorsunuz ve saçma sapan taramaları tetikleyen herhangi bir sorguyu yakalayacaktır. AE'nin dediği gibi bir yorum:

Son kullanıcının genellikle gerçek zamanlı olarak gerçekleştireceği herhangi bir sorgu için tam tablo taramasından kaçınmak için dizinleri kullanın

En azından, kullanımda büyümesi planlanan masalar için.

Daha sonra, bunun bir kısayolu olarak, veritabanı motoruyla ilgili önemli bir deneyime sahipseniz ve kodun ilk bölümünü yazarken testleri zaten planladıysanız, o zaman genellikle sorgunuzu çalıştırmadan bile bunu bileceksiniz İndeks olmadan yazı çok yavaş olacak. Tabii ki bilmiyormuş gibi davranmakta özgürsünüz ve testin geçmesi için dizini eklemeden önce başarısız olduğunu izliyorsunuz, ancak bilinen hatalı kodun (yanıt vermediğinden) yayına girmesi için bir neden yok.

Bunun erken optimizasyon olduğunu düşünüyorum çünkü uygulamamız henüz yayınlanmadı. Canlı yayına girdikten sonra yavaş sorguları izlemeyi ve ardından buna göre indeksler eklemeyi önerdim.

Son kullanıcılarınıza ve üretim ortamınıza kalite güvencesi gibi davranamazsınız. Daha fazla deyişle, üretimde çözeceğinizi söylüyorsunuz. Bunun doğru yol olduğunu sanmıyorum ve bu yaklaşımın her gün çok yanlış gittiğini görüyorum .

Bunu geniş bir fırçayla boyayamayacağınız için bir şeyi aklınızda tutmanız gerekir.

Senin ne ortak iş yükü ?

Bu çok açık veya donuk gelebilir, ancak pratikte önemlidir. İş yükünüzün% 98'ini oluşturan 10 sorunuz varsa (oldukça yaygındır, ister inanın ister inanmayın), tavsiyem üretim öncesi zor bir analiz olacaktır . Gerçekçi ve temsili verilerle, bu 10 sorgunun olabildiğince iyi olduğundan emin olun ( mükemmel , değerli zaman kaybıdır ve neredeyse elde edilemez).

İçin iş yükü% 2 oluşturan diğer 200 sorguları , o büyük olasılıkla çaba bir ton değerinde değildir ve üretimde sorun giderme tuhaflıklar perf köşe dava yapacak olanlardır. Bu aynı zamanda bir gerçeklik ve çok da kötü bir şey değil. Ancak bu, en iyi uygulamaların endekslenmesini göz ardı etmek veya veri alımı konusunda tahmini varsayımlarda bulunmak anlamına gelmez.

Üretimden önce veri tabanı performansını belirlemek yaygın ve iyi bir uygulamadır. Aslında, bu gelişme DBA adı verilen bu tür bir şey için nispeten ortak bir konum var .

Fakat...

Bazıları bunu çok ileri götürür ve "sadece durumda" diye endeksler ekleyerek çıldırır. Birisi bunun eksik bir indeks olduğunu öneriyor? Ve diğer dört varyasyon ekleyin. Aynı zamanda kötü bir fikir. Sadece veri almayı düşünmek zorunda değilsiniz, peki ya veri modifikasyonu? Tabloda ne kadar fazla indeks varsa, genellikle veriyi değiştirdiğinizde o kadar fazla ek yük demektir.

Çoğu şey gibi, sağlıklı bir denge var.

Eğlenceli küçük bir not olarak ... "Index" çoğullaştırması

"Endeksler" finansal insanlar içindir

"Dizinler" bizim için

Hayır, erken optimizasyon değil, ancak herhangi bir optimizasyonun gerektiği gibi yapılması gerekiyor.

İşte ne yapardım:

1. Bir üretim yükünü taklit etmek için veritabanını yeterli test verisiyle yükleyin. Bu% 100 kesinliği elde edemezsiniz ancak sorun değil: sadece yeterince veri koyun. Bir tabloda sabit miktarda veri var mı? Yükle. Çok fazla veri içeren bir tablonuz var mı, örneğin, bu sitedeki soruları içeren tablo ne? Yalnızca sahte veriler olsa bile birkaç milyon kaydı yükleyin.
2. Veritabanı sunucunuzdaki profili açın .
3. Otomatikleştirilmiş komut dosyaları (ses sağlar) ve gerçek kullanıcılar (bir şeyleri nasıl kıracaklarını biliyorlar) kombinasyonunu kullanarak uygulamadan uzak durun.
4. Profil verilerini gözden geçirin. Belirli sorgular yavaş mı? Açıklama planlarını kontrol edin ve veritabanı sunucusunun bir dizin istediğini ancak var olmadığını söyleyip söylemediğini kontrol edin .

Veritabanı sunucuları karmaşık ve akıllı yazılım parçalarıdır. Nasıl dinleyeceğinizi biliyorsanız, nasıl optimize edeceğinizi söyleyebilirler.

Anahtarlar, optimizasyondan önce ve sonra performansı ölçmek ve veritabanının neye ihtiyacı olduğunu size bildirmesini sağlamaktır .

Bilinen sorunlar için kanıtlanmış kalıpları takip etmek (kimliğine göre bir kayıt bulmak gibi) erken bir şey değildir. Sadece mantıklı.

Bununla birlikte, endeksler her zaman basit bir iş değildir. Tasarım aşamasında, trafiğinizi hangi endekse bağlı olduğunu ve hangi yazma işlemlerini azaltacağını bilmek genellikle zordur. Bu yüzden, bazı "bariz" şema tasarımı en iyi uygulamalarından yararlanmayı savunuyorum (tasarlanmış okuma / yazma modellerine uygun PK'ları kullanın ve FK endeksini kullanın); ancak, stres testiniz talep edene kadar başka hiçbir şeye endeks koymayın.

Başvurunuz serbest bırakıldığında, çok geç.

Ancak herhangi bir uygun geliştirme süreci performans testlerini içermelidir.

Hangi endekslerin ekleneceğine karar vermek için performans testlerinizin sonuçlarını kullanın ve performans testlerini tekrarlayarak etkinliklerini doğrulayın.

Her sorgunun optimize edilmesi gerektiğini düşünmeme rağmen, indeksler RDBMS'nin bir parçası, yayınlanmadan önce dikkate alınması gerekenler. Bir sorgu yürüttüğünüzde, diğer programlama türlerinin aksine sisteme nasıl çalıştırılacağını anlatmazsınız. Kendi planları geliştiriyorlar ve neredeyse her zaman bir endeks kullanılabilirliğine dayanıyorlar. Verilerin yapısı ve hacmi daha sonraki zamanlarda da dikkate alınacaktır.

İşte göz önünde bulundurmam gereken bazı şeyler:

1. Erken gelişiminizde sıkça kullanılacağını bildiğiniz bazı tanımlamalar yapmalısınız. Onlara odaklan.
2. Yavaş sorgular olacak. Önce bunları dizine ekleyerek, performansın hala yeterince hızlı olup olmadığını belirleyebilir ve ardından yeniden tasarlamayı düşünebilirsiniz (Denormalizasyon erken olabilir). Serbest bırakılmadan önce bunu yapmayı tercih ederim. Hiç kimse envanterde bir şey bulmanın 10 dakika süreceği bir sistem istemez.
3. Dizinler, sorgu performansını iyileştirebilir, ancak verilerin değiştirilmesini engellemez.
4. Pek çok sistemde sorgularınızı analiz etmek için araçlar vardır, bu yüzden kullanmaktan korkmayın.

İlk incelemenizden sonra, bunu tekrar ne zaman gözden geçirmeniz gerektiği ve bunun için bilgileri nasıl toplayacağınız (kullanımı izlemek, müşteri verilerinin kopyalarını almak, vb.) İle ilgili bazı hususları dikkate almalısınız.

Erken optimizasyon yapmak istemediğinizi biliyorum, ancak veritabanınızı endekslemeden performansınızın düşük olacağı kesin. Bunu ortadan kaldırarak, performans sorunlarına neden olan başka alanlar olup olmadığını belirleyebilirsiniz.

Ayrıca, kaç tane kullanıcı beklediğinize de bağlıdır. Kesinlikle bazı yükleme testleri yapmalı ve veritabanınızın 10 - 100s ile 1000s arasındaki eşzamanlı istekleri karşılayabileceğinden emin olmalısınız. Yine, ne kadar trafik beklediğinize ve diğerlerinden daha çok hangi alanlarda kullanılmasını beklediğinize bağlıdır.

Genelde, kullanıcının en çok isabet etmesini beklediğim bölgelere ince ayar yapardım. Sonra kullanıcı deneyimi açısından yavaş olan her şeyi ayarlayabilirim. Kullanıcı ne zaman bir şey beklemek zorundaysa, kötü bir deneyim yaşar ve geri tepebilir. İyi değil!

Öncelikli bir analizle hangi sütunların kesinlikle bir endekse ihtiyaç duyduğunu belirlemek iyi bir uygulamadır. Kesinlikle endeksiniz yoksa veri tabanı büyüklüğü arttıkça üretimde kademeli veya beklenmedik performans düşme riski vardır. Kaçınılması gereken durum, yaygın olarak çalışan bir sorgunun çok sayıda tablo satırı taramasını gerektirdiği durumdur. Kritik sütunlara indeksler eklemek erken optimizasyon değildir, çünkü gerekli bilgilerin birçoğuna sahipsiniz ve potansiyel performans farkları önemlidir (büyüklük dereceleri). Endekslerin yararının verilere daha az net veya daha fazla bağımlı olduğu durumlar da vardır - muhtemelen bu vakaların bazıları için karar vermeyi erteleyebilirsiniz.

Sormanız gereken bazı sorular:

• Her bir tablonun büyüklüğü için tasarım sınırları neler olacak?

Tablolar her zaman küçük olacaksa (<100 satır der), veritabanının tüm tabloyu taraması gerekiyorsa, felaket değildir. Bir dizin eklemek faydalı olabilir, ancak bu belirlemek için biraz daha uzmanlık veya ölçüm gerektirir.

• Her sorgu ne sıklıkta çalıştırılacak ve gereken yanıt süresi nedir?

Sorgu nadiren çalıştırılıyorsa ve katı yanıt süresi gereksinimlerine sahip değilse (örneğin rapor oluşturma) ve satır sayısı çok büyük değilse, endeks eklemeyi ertelemek muhtemelen oldukça güvenlidir. Yine, uzmanlık veya ölçüm yararlı olup olmayacağını söylemeye yardımcı olabilir.

• Sorgu, masanın birincil anahtardan başka bir şey tarafından aranmasını gerektiriyor mu? Örneğin tarih aralığına göre filtreleme, yabancı bir anahtara katılma?

Bu sorgular sık ​​sık çalıştırılıyorsa ve birçok satıra sahip tablolara dokunduysanız, o zaman ciddiyetle bir dizin eklemeyi düşünmelisiniz. Bunun bir sorgu için geçerli olup olmadığından emin değilseniz, veritabanını gerçekçi miktarda veriyle doldurabilirsiniz, ardından sorgu planına bakın.