Laravel ve PostgreSQL ile Ölçeklenebilirlik: Yüksek Performanslı SaaS İçin ‘Lateral Join’ Modeli

<p>Multi-tenant bir SaaS platformu geliştirdiyseniz, muhtemelen "Gruplar Başına En Üst N" duvarıyla karşılaşmışsınızdır. Bu genellikle şu basit gereksinimle başlar: <em>"Gösterge panelinde, her müşterinin son 3 faturasını göster."</em></p>

<p>Standart bir Laravel uygulamasında, ilk içgüdünüz Eager Loading yöntemine başvurmak olacaktır:<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code>$customers = Customer::with([
        'invoices' => function ($query) {
            $query->latest()->limit(3);
        }
    ])->get();</code></pre>
</div>

<p><strong>Problem?</strong> Eloquent’in <code>limit()</code> metodu <code>with()</code> closure içinde beklediğiniz gibi çalışmaz. Bu, tüm sonuç kümesine genel bir limit uygular, yani her müşteri için limit <em>uygulamaz</em>. Sonuç olarak, toplamda 3 fatura ile karşılaşırsınız veya <em>tüm</em> faturaları yüklemek ve bellek içinde filtrelemek zorunda kalırsınız; bu, veri büyüdüğünde <code>memory_limit</code> hatasıyla sonuçlanabilir.</p>

<p>"Naif" çözüm genellikle bir döngü içinde N+1 sorguyu veya karmaşık bir alt sorguyu gerektirir ki bu da okunması zor ve yavaş bir işlem haline gelir. Ancak PostgreSQL kullanıyorsanız, artık çok daha şık, performanslı ve ölçeklenebilir bir çözüm var: <strong>LATERAL JOIN</strong>.</p>

<p>Bu derin dalışta, geleneksel ORM desenlerinin zorluk yaşadığı karmaşık veri alma sorunlarını çözmek için Laravel'de Lateral Join deseninin nasıl uygulanacağını keşfedeceğiz.</p>

<hr/>

<h2>
    <a name="what-is-a-lateral-join" href="#what-is-a-lateral-join">
    </a>
    LATERAL JOIN Nedir?
</h2>

<p><code>LATERAL JOIN</code>'u SQL sorgunuz içinde bir <code>foreach</code> döngüsü gibi düşünün.</p>

<p>Normalde, bir <code>JOIN</code> SQL'deki "statik" bir yapıdır; yani, join'in sağ tarafı sol tarafındaki sütunları referans alamaz. Ancak <code>LATERAL</code> join bu kuralı bozarak sağdaki alt sorgunun, sol taraftaki tablodan sağ taraftaki sütunları her bir satır için referans almasına izin verir.</p>

<p>PostgreSQL, "sol" tablodaki (örneğin, <code>customers</code>) her satır için "sağ" alt sorgusunu (örneğin, <code>invoices</code>) belirli bir müşteri kimliği ile çalıştırır. Veritabanı seviyesinde hizmet verdiği için son derece hızlıdır ve sorgu planlayıcısının yürütme yolunu optimize etmesine olanak tanır.</p>

<hr/>

<h2>
    <a name="implementation-the-laravel-way" href="#implementation-the-laravel-way">
    </a>
    Uygulama: Laravel Yöntemi
</h2>

<p>Son zamanlarda Laravel'de Lateral Joins kullanmak için bir miktar <code>DB::raw()</code> kullanmanız gerekiyordu. Ancak Laravel 10.x ve 11.x ile birlikte gelen <code>joinLateral</code> ve <code>leftJoinLateral</code> ile bunu artık akıcı bir şekilde yazabiliyoruz.</p>

<h3>
    <a name="1-the-basic-top-3-pattern" href="#1-the-basic-top-3-pattern">
    </a>
    1. Temel "En Üst 3" Deseni
</h3>

<p>"Her müşteri için en son 3 fatura" sorununu akıcı arayüz kullanarak çözelim.<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code>use App\Models\Customer;

<h3>
    <a name="2-handling-jsonb-expansion" href="#2-handling-jsonb-expansion">
    </a>
    2. JSONB Genişlemesini Yönetmek
</h3>

<p>Modern SaaS'te, genellikle esnek meta verileri <code>JSONB</code> sütunlarında depolarız. Her <code>Invoice</code>'un bir <code>metadata</code> sütunu olduğunu varsayalım ve her müşteri için en son "vergilendirilebilir" faturadan "tax_rate" değerini çıkarmanız gerektiğini düşünelim.<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code>$customers = Customer::query()
->leftJoinLateral(
    Invoice::query()
        ->whereColumn('customer_id', 'customers.id')
        ->where('metadata->is_taxable', true)
        ->latest()
        ->limit(1)
        ->select(DB::raw("metadata->>'tax_rate' as current_tax_rate")),
    'tax_data'
)
->get();</code></pre>
</div>

<p>Bu yöntem, PHP'de tüm JSON nesnesini alıp ayrıştırmaktan önemli ölçüde daha hızlıdır; bu özellikle binlerce kayıt ile çalışırken geçerlidir.</p>

<hr/>

<h2>
    <a name="deepdive-why-this-beats-window-functions" href="#deepdive-why-this-beats-window-functions">
    </a>
    Derinlemesine: Neden Bu Yöntem Pencere Fonksiyonlarını Geçiyor?
</h2>

<p>Muhtemelen şöyle düşünüyorsunuz: <em>"<code>ROW_NUMBER() OVER (PARTITION BY ...)</code> kullanamaz mıyım?"</em></p>

<p>Pencere Fonksiyonları güçlüdür, ancak büyük bir dezavantajları vardır: genelde filtrelemeden önce tüm tabloyu (veya büyük bir dizin aralığını) taramak zorundadırlar.</p>

<p>Bir <code>LATERAL JOIN</code>, uygun bir bileşik dizin ile birlikte kullanıldığında, <strong>Dizin Atlama Taraması</strong> (veya benzer optimizasyonlar) gerçekleştirebilir. PostgreSQL, dizinde her müşteri kimliği için en son 3 kaydı direkt olarak atlayabilir; böylece tüm faturaları taramak zorunda kalmaz ve sonra sıralama yapmaz.</p>

<h3>
    <a name="the-performance-benchmark" href="#the-performance-benchmark">
    </a>
    Performans Ölçütleri
</h3>

<p>50.000 müşteri ve 2.000.000 fatura içeren bir üretim veritabanında:</p>

<div class="table-wrapper-paragraph">
    <table>
        <thead>
            <tr>
                <th>Yöntem</th>
                <th>Çalışma Süresi</th>
                <th>Bellek Kullanımı</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>Eager Loading (Hepsi) + PHP Filtre</td>
                <td>4.2s</td>
                <td>512MB+</td>
            </tr>
            <tr>
                <td>Pencere Fonksiyonu (<code>ROW_NUMBER</code>)</td>
                <td>850ms</td>
                <td>45MB</td>
            </tr>
            <tr>
                <td><strong>LATERAL JOIN</strong></td>
                <td><strong>120ms</strong></td>
                <td><strong>12MB</strong></td>
            </tr>
        </tbody>
    </table>
</div>

<p>Fark gökyüzü ve yer kadar, özellikle "N" değeri "Top N" arttıkça.</p>

<hr/>

<h2>
    <a name="advanced-use-case-running-totals-and-deltas" href="#advanced-use-case-running-totals-and-deltas">
    </a>
    İleri Düzey Kullanım Durumu: Sürekli Toplamlar ve Değişimler
</h2>

<p>Lateral join'lar sadece ilgili kayıtları almak için değil; "değişim" hesaplamak için de mükemmeldir (mevcut kayıt ile önceki kayıt arasındaki fark).</p>

<p>Bir SaaS, sunucu metriklerini takip ettiğini varsayalım. Sunucuların listesini ve son iki ölçüm arasındaki CPU kullanım yüzdesi değişikliğini göstermek istiyorsunuz.<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code>$servers = Server::query()
->leftJoinLateral(
    Metric::query()
        ->whereColumn('server_id', 'servers.id')
        ->latest()
        ->limit(2)
        ->select('cpu_usage', 'created_at'),
    'recent_metrics'
)
->select('servers.name')
->addSelect(DB::raw("
    ((recent_metrics.cpu_usage - LEAD(recent_metrics.cpu_usage) OVER (PARTITION BY servers.id ORDER BY recent_metrics.created_at DESC)) 
    / NULLIF(LEAD(recent_metrics.cpu_usage) OVER (PARTITION BY servers.id ORDER BY recent_metrics.created_at DESC), 0)) * 100 as cpu_delta
"))
->get();</code></pre>
</div>

<p>Bekleyin, bu karmaşık görünüyor. Bunu basitleştirelim: <em>iki</em> lateral join kullanarak—birisi mevcut okuma, diğeri ise önceki için.<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code>$servers = Server::query()
->leftJoinLateral(
    Metric::query()
        ->whereColumn('server_id', 'servers.id')
        ->latest()
        ->limit(1)
        ->select('cpu_usage as current_cpu'),
    'current'
)
->leftJoinLateral(
    Metric::query()
        ->whereColumn('server_id', 'servers.id')
        ->latest()
        ->offset(1)
        ->limit(1)
        ->select('cpu_usage as prev_cpu'),
    'previous'
)
->select('servers.name', 'current.current_cpu', 'previous.prev_cpu')
->get();</code></pre>
</div>

<p>Bu çok daha okunabilir ve hesaplamaları doğrudan Blade şablonlarınızda veya API kaynaklarınızda gerçekleştirmenize olanak tanır.</p>

<hr/>

<h2>
    <a name="common-pitfalls-amp-edge-cases" href="#common-pitfalls-amp-edge-cases">
    </a>
    Yaygın Tuzaklar &amp; Kenar Durumları
</h2>

<h3>
    <a name="1-the-indexing-requirement" href="#1-the-indexing-requirement">
    </a>
    1. Dizine Alma Gereksinimi
</h3>

<p>Lateral Join, dizinlerinize göre hızlıdır. Eğer <code>invoices</code> tablosunu <code>customer_id</code> üzerinde birleştiriyorsanız ve <code>created_at</code> üzerinde sıralıyorsanız, <strong>mutlaka</strong> bir bileşik dizine sahip olmalısınız:<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight sql"><code>CREATE INDEX idx_invoices_customer_latest ON invoices (customer_id, created_at DESC);</code></pre>
</div>

<p>Bunu yapmazsanız, PostgreSQL her müşteriyi kontrol etmek için bir sekans taraması yapacaktır; bu da standart bir join'le karşılaştırıldığında daha yavaş olacaktır.</p>

<h3>
    <a name="2-column-name-collisions" href="#2-column-name-collisions">
    </a>
    2. Sütun İsim Çatışmaları
</h3>

<p><code>select('customers.*', 'latest_invoices.*')</code> kullanırken, her iki tabloda da <code>id</code> veya <code>created_at</code> sütununun bulunması gibi sorunlarla karşılaşabilirsiniz. Lütfen lateral sütunlarınızı her zaman takma adlandırarak kullanın:<br/></p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code>->select('id as invoice_id', 'amount as invoice_amount')</code></pre>
</div>

<h3>
    <a name="3-memory-limits-on-large-result-sets" href="#3-memory-limits-on-large-result-sets">
    </a>
    3. Büyük Sonuç Kümesindeki Bellek Limitleri
</h3>

<p>Lateral Joins verimli olsa da, 1.000 müşteri ve her birinin 10 ilişkili kaydı döndürmek 10.000 satırı PHP belleğinizde oluşturacaktır. Özellikle büyük veri kümesi işleyişinde <code>chunk()</code> veya <code>cursor()</code> kullanmalısınız.</p>

<hr/>

<h2>
    <a name="conclusion" href="#conclusion">
    </a>
    Sonuç
</h2>

<p><code>LATERAL JOIN</code>, PostgreSQL ile çalışan Laravel geliştiricileri için gizli bir silah gibidir. Eloquent'in kolaylığını ve ilişkisel cebirin ham gücünü birleştirir. "En Üst N" mantığını veritabanına taşıyarak, gecikmeyi azaltır, bellek tüketimini düşürür ve kullanıcılarınız için daha hızlı bir deneyim sunarsınız.</p>

<p><strong>Önemli Notlar:</strong></p>

<ul>
    <li><code>leftJoinLateral</code> kullanarak "Gruplar Başına En Üst N" sorunlarını N+1 sorgular olmadan çözün.</li>
    <li>Lateral join'larınızı her zaman bileşik dizinlerle destekleyin.</li>
    <li>Lateral join'lar, belirli kayıt alma işlemleri için genellikle Pencere Fonksiyonlarından daha performanslıdır.</li>
    <li>Aynı zamanda büyük ölçekli JSONB sütunlarından veri çıkartmak için mükemmeldir.</li>
</ul>

<hr/>

<h2>
    <a name="discussion-prompt" href="#discussion-prompt">
    </a>
    Tartışma Başlatıcı
</h2>

<p>Laravel'de karmaşık "En Üst N" sorgularını yönetme yaklaşımınız nedir? Standart Eager Loading veya Pencere Fonksiyonları ile performans darboğazları ile mi karşılaştınız? Düşüncelerinizi ve karşılaştığınız PostgreSQL "tuzaqlarını" aşağıdaki yorumlarda paylaşın!</p>

<hr/>

<p><strong>Yazar Hakkında:</strong> Ameer Hamza, SaaS platformları, e-ticaret çözümleri ve AI destekli uygulamalar geliştirme konusunda 7+ yıllık deneyime sahip, çok yüksek dereceli bir Full-Stack Geliştiricisidir. Laravel, Vue.js, React, Next.js ve AI entegrasyonlarında uzmanlaşmıştır; 50+ proje teslimatına ve %100 iş başarı oranına sahiptir. En son çalışmalarını görmek için portföyüne <a href="https://ameer.pk" target="_blank" rel="noopener noreferrer">ameer.pk</a> adresinden ulaşabilir veya sonraki geliştirme projeniz için ona ulaşabilirsiniz.</p>

<hr/>