ProgramlamaBackend geliştirici

SQL'de etkili tam metin filtreleme (full-text search) nasıl uygulanır? Tam metin arama için hangi mekanizmalar vardır ve büyük hacimli metin verileri ile çalışırken nelere dikkat edilmelidir?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap.

Tarihçesi:
Başlangıçta SQL, öncelikle yapılandırılmış verilerle çalışmak için kullanılıyordu; burada metin alanlarında arama basit LIKE gibi işlemlerle sınırlıydı. Metin bilgisi miktarının artmasıyla, makaleler, mesajlar, bloglar vb. gibi büyük metinler üzerinde hızlı ve esnek arama yapabilme ihtiyacı doğdu.

Sorun:
Standart SQL araçları (LIKE/ILIKE) büyük hacimli metinlerle iyi çalışmıyor ve kelimelerin ilgili olduğu bir şekilde, morfoloji veya kelimeler arasındaki mesafeyi dikkate alarak etkili bir şekilde bulamıyor. Bu durum performans kaybına ve aramada çok uzun tepki sürelerine neden olabilir.

Çözüm:
Bu tür görevler için veritabanlarına entegre edilmiş tam metin arama mekanizmaları (Full-Text Search, FTS) kullanılır; örneğin Full-Text Index ve özel operatörler (CONTAINS, MATCH AGAINST, tsvector, tsquery). Bu tür indeksler, metinler üzerinde aramayı on kat hızlandırarak "kelime kartı" ("ters indeks") oluşturur.

Kod örneği (SQL Server):

CREATE FULLTEXT CATALOG ftCatalog AS DEFAULT; CREATE FULLTEXT INDEX ON Documents(Content) KEY INDEX PK_Documents; SELECT * FROM Documents WHERE CONTAINS(Content, '"SQL programming"');

Ana özellikler:

  • Özel tam metin indeksleri kullanılarak çalışır, normal indekslerden ayrıdır.
  • İlgililik, lemalaştırma, durak kelimeleri tanıma ve karmaşık koşullar (DEĞİL, VEYA, yakınlık) ile ilgili sorguları destekler.
  • Veri değişiklikleri sırasında indeksin sürdürülmesini gerektirir — periyodik yeniden indeksleme.

Yanlış sorular.

LIKE ile tam metin arama arasındaki fark nedir?

LIKE — kalıp ile basit karşılaştırma işlemi, metin üzerinde indeks kullanmaz, büyük hacimlerde yavaştır. Tam metin, özel bir indeks kullanır ve morfolojiyi, ilgiyi dikkate alabilir.

Örnek:

SELECT * FROM articles WHERE body LIKE '%database%'; -- yavaş, sıralama yok SELECT * FROM articles WHERE MATCH(body) AGAINST ('database'); -- hızlı, sıralamalı

Toplu eklemeler veya silmeler sırasında tam metin indeksine ne olur?

Toplu değişikliklerden sonra metin alanındaki indeks güncel olmaktan çıkar (bazı durumlarda otomatik güncelleme, bazı durumlarda manuel) ve performansı geri kazanmak için yeniden indeksleme yapılması gerekir.

-- MSSQL için ALTER FULLTEXT INDEX ON Documents START FULL POPULATION;

JSON veya XML tipindeki sütunlarda tam metin indeksleri kullanılabilir mi?

Hayır, çoğu tam metin motoru için JSON/XML yapıları için doğrudan destek yoktur; bu veriler ya bir metin alanına taşınmalı ya da özel ayrıştırıcılar/dış araçlar (örneğin, Elasticsearch) kullanılmalıdır.

Yaygın hatalar ve anti-paterner

  • Büyük tablolar üzerinde LIKE '%word%' kullanmak — felaket bir performans
  • Yeniden indeksleme yapılmıyor, arama ilgisiz hale geliyor
  • Dil özellikleri ve durak kelimeleri dikkate alınmıyor
  • Ek kaynak olmaksızın birkaç gigabayt veri indeksleniyor

Gerçek hayat örneği

Olumsuz vaka

Bir şirket, on milyonlarca makale kaydı saklıyordu. Aramada LIKE '%kelime%' kullanılıyordu. IT departmanı düzenli zaman aşımından şikayet ediyordu, kullanıcılar sonuçların gösterilmesini 10+ dakika bekliyordu.

Artılar:

  • Ek lisans veya ayar gerektirmiyor
  • Basit uygulama

Eksiler:

  • Zayıf performans, özellikle büyük hacimlerde
  • Sistemlerin yanıtlama süresinin gerçekçi olmaması
  • Yanlış arama sonuçları (kelimenin biçimi dikkate alınmıyor)

Olumlu vaka

MySQL'de Full-Text Search (FULLTEXT INDEX) uygulandı. Arama sonuçları 100 kat daha hızlı dönmeye başladı, "benzer" kelimeleri ve ifadeleri arama imkanı oldu, sıralama eklendi.

Artılar:

  • Anında arama
  • İlgili sonuçlar, morfoloji desteği
  • Ölçeklenebilirlik

Eksiler:

  • İndeksin korunması için kaynak gerekir
  • İndeks, metin alanlarında oluşturulur, iç içe yapılar için çalışmaz