Merhaba, Senaryomuzda 700.000’den fazla kaydın bulunduğu gönderim tablomuz korkunç bir performans sergiliyor. Tablodan veri almak için gereken maksimum süre 6 saniyeden fazla.
Sorgu oldukça basitti. Elimizde olan tek şey 4 join, birkaç where cümleciği (yaklaşık 4), order( created_at time alanında DESC), sınırlama
Sorun kaynağı çözümlemesi..
Gönderim tablomuzda karşılaştığımız büyük yavaşlamaya neden olan birkaç nokta şunlar:
Çözüm 1: Index oluşturma
İnsanlar milyonlarca satırla boğuşuyor, bizimki bunun sadece basit bir örnek, yani yanlış yaptığımız bir şeyler olmalı. Doğru indeksleme size sorgularınızda hız açısından çok yardımcı olacaktır. İlk düşüneceğimiz nokta bu.
Herhangi bir optimizasyon olmadan her şeyin çalıştırılması index ekledikten sonra ortalama 2,3 saniye‘ye düştü. (elbette bu süre yalnızca sorgunun veritabanı üzerinde çalıştırılma süresini içermez, aynı zamanda verilerin ağ üzerinden yayılması süresini de içerir)
Sütunlara indekslemeyi ekledikten sonra, sürenin kısaldığını öğrencik, ancak bu yeterli değil. Hâlâ 2 saniye civarında ve çoğu zaman bundan daha fazla sürede yanıt dönüyor.
Çözüm 2: Boş Dize (Empty string) hatası
Kullanıcı herhangi bir girişe herhangi bir şey yazmadıysa, bu çoğunlukla sayfanın ilk yüklendiği ve API çağrısının herhangi bir filtreleme olmadan yalnızca en son verileri almak için yapıldığı sırada gerçekleşir.
Yani kısacası string alan tipi içerisindeki “” değerlerini empty/null gibi tanımladığımızda sorgu süresi 2,3 saniyeden 1,3 saniyeye indi.
Tamam, doğru yönde ilerliyoruz. Tam 1 saniyeyi kısalttık ama yine de 200/150 ms’nin altına inmek zorundayız, yani daha gidecek çok yolumuz var.
Çözüm 3: Gereksiz birleştirmeler (Join)
Gönderimleri sorgularken zorunlu olmayan tablolarla birleştirmeler yapıyoruz. Bu yüzden koda tüm bunlar eklendiğinde onu kaldırdık ama bu, inceleyenlerin pek fazla dikkat etmediğini gösteriyor
Çözüm 4: ORM
TypeORM’in geliştiricilere JSON benzeri nesneleri kullanarak SQL sorguları oluşturmamızı sağladığı aktif kayıt modeli adı verilen bir şey var, bir örnek ile anlatmak gerekirse,
|
|
model.find({ select: { userName : true, firstName : true }, where: { userName : “SomeUsername” }, relations: { user : true, contest: true, problem: true }, order: { created_at : “ASC/DESC” , skip: 0, take: 10, }) |
Bu geliştirmeyi hızlı ve kolay hale getirir ve ham SQL sorguları yazma konusunda iyi olmayan bir geliştirici için çok sezgisel hissettirir, bu yöntem ile kelimenin tam anlamıyla SQL sorguları oluşturmak için JSON nesneleri oluşturuyorsunuz.
Bu yaklaşım iyi görünüyor ve çoğu zaman işe yarıyor ama bizim durumumuzda çok aptalca bir şey yapıyordu, sorguyu kendiniz görebilmeniz için ne yaptığını yazmayacağım.
Kısaca iki sorgu çalıştırıyordu, öncelikle bu durumda hiç ihtiyaç duyulmuyordu, daha sonra yazıp test ettiğim basit ve tek bir sorguyla kolaylıkla yapılabilirdi.
Yalnızca iki ayrı sorgu çalıştırmakla kalmıyordu, aynı zamanda dört tabloyu her iki sorgu için de iki kez birleştiriyor ve ardından da sıralıyordu. her ikisinde de iki kez. (Bu kelimenin tam anlamıyla hiçbir anlam ifade etmiyor)
Performansın en çok darbe aldığı yer burasıydı. Aşağıdaki sorgulara kendiniz bir göz atın.
|
|
SELECT DISTINCT `distinctAlias`.`Submission_id` AS `ids_Submission_id`, `distinctAlias`.`Submission_created_at` FROM (SELECT `Submission`.`id` AS `Submission_id`, ... more selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId` LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId`) `distinctAlias` ORDER BY `distinctAlias`.`Submission_created_at` DESC, `Submission_id` ASC LIMIT 10 |
|
|
SELECT `Submission`.`id` AS `Submission_id`, `Submission`.`language` AS `Submission_language`, `Submission`.`verdictCode` AS `Submission_verdictCode`, `Submission`.`tokens` ... shit ton of selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId` LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId` WHERE `Submission`.`id` IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ORDER BY `Submission`.`created_at` DESC |
2 ayrı sorguyla yapmaya çalışılan şeyin aynısını yapmak için basit bir tek SQL sorgusu yazıldı
|
|
SELECT Submission.id, Submission.language, Submission.verdictCode, ... FROM submission AS Submission LEFT JOIN problem ... LEFT JOIN user ... ORDER BY Submission.created_at DESC LIMIT 10 |
Ve bu sorguyu çalıştırdığımızda sadece 100 ms’de çalıştı.
Böylece 1,3 saniyeden 100 ms’ye , Genel olarak 2,3 saniyeden 100 ms’ye indik.
Bu da 23 kattan fazla performans artışı anlamına geliyor .
Okuduğunuz için teşekkür ederim.
