Modül dersleri (3/4)
Bileşik ve kısmi indeksler
Önceki derslerde doğrusal DBMS sorguları (WHERE country = 'Italy') için dizinlerin kullanımını ele almıştık. Peki ya iki birleşik cephede arama yaptığımızda?
Örneğin, gerçek bir e-ticarette, belirli bir müşteri kimliğine VE ait olan ve belirli bir zaman aralığına giren siparişleri bulmak isteyebiliriz:
WHERE customer_id = 90 AND placed_at >= '2025-01-01'.
Yalnızca customer_id üzerinde bir temel dizininiz varsa, Postgres ikili ağacı kullanarak müşterinin 50 siparişini anında bulacaktır, ancak daha sonra tarihleri tembelce filtreleyerek 50 siparişin tamamını manuel ve sırayla yinelemesi gerekir.
Bileşik Dizinler
DBMS'ye "analitik sözlük" dosyalarını tek bir anahtar boyuta göre değil birden fazla boyuta göre sıralamasını söyleyebiliriz.
CREATE INDEX idx_orders_customer_date ON orders(customer_id, placed_at);Bir "bileşik" indeks, parametrelerinin sırasını çok önemli olarak ele alır: burada B-Tree düğümleri gruplanır ve customer_id'yi bir blokta katı bir şekilde kategorilere ayırır (ayrım için en ayırt edici olan); içlerinde çeşitli placed_at zaman değerleriyle mükemmel şekilde sıralanmış bir şekilde dallara ayrılan alt ağaç yaşar.
Bu yapı, birden çok iç içe yüklem içeren WHERE yan tümcelerini acımasızca yok eder.
Kısmi Dizinler (Filtrelenmiş Dizinler)
Her indeks, kullanıcı girişi akışlarında disk alanına ve CPU'ya mal olur. Ya e-ticaret sürekli olarak bir filtrenin sıralanmasını ve alınmasını gerektiriyorsa, ancak yalnızca az sayıda kayıt için? (Örneğin: okunmamış bildirimler kontrolünün hızla yoklanması.) 10.000.000 bildirimin tümü üzerinde bir "is_read" dizini oluşturmak, "Okunmamış" bildirimlerin yalnızca 5'ini temsil ediyorsa inanılmaz derecede sıkıcıdır.
CREATE INDEX idx_unread_notifs ON notifications(user_id)
WHERE is_read = false; -- Questa aggiuntiva è l'"Indice Parziale"Veritabanı, kaydın Okunmamış olması durumunda SADECE DB'ye hızlı erişim anahtarlarını saklayan, ışık hızında bir B-Tree oluşturacaktır! Disk, 10 milyonluk bir dizine değil, 5 satırlık (3 bayt) bir dizine aşık olacaktır. Hızlı SELECT'ler tam olarak fayda sağlar:
SELECT * FROM notifications WHERE user_id = 2 AND is_read = false;
Sıra sende
Geçici şifrelerin/sıfırlama belirteçlerinin aranmasını optimize etmek istiyoruz. Belirli bir ülkeden ve bilinen bir şehirden kaydolmuş tüm müşterileri aramak için sıklıkla SELECT çağrıları yapıyoruz.\n'Müşteriler'de 'idx_cust_loc' adında bir bileşik dizin oluşturun. Önce 'ülke' alanını (ki bu daha özeldir) ve ardından 'şehir' alanını iletin.
İpucu göster
Sözdizimi: CREATE INDEX name ON table(sütun1, sütun2);
3 denemeden sonra çözüm mevcut
Koşullu (Kısmi) dizinleri keşfetme
Alışveriş kullanıcısı aramasını optimize edin: kullanıcılar ön kayıt yaptırır, ancak bunları yalnızca kronolojik kayıt sırasına göre listelememiz gerekir ("müşteriler" bölümünde "signed_up_on" üzerinde bir dizin oluşturun), ancak YALNIZCA tam dize "şehir"deki müşterilerle SINIRLIDIR: "Milano".
İpucu göster
Hedef özellikte normal olarak bildirilir; sonuna sihirli anahtar kelimeyi WHERE city = 'Milano' eklersiniz.
3 denemeden sonra çözüm mevcut