Uygulamalarınızda Anlık Sunucu Tarafı Arama için Meilisearch

Anlık sunucu tarafı arama ne sunmalı

Sunucu tarafı arama, sorgunun tarayıcıda değil sunucunuzda (veya özel bir arama servisinde) işlendiği anlamına gelir. Uygulamanız bir arama isteği gönderir, sunucu bunu bir indeks üzerinde çalıştırır ve sıralanmış sonuçlar döner.

Bu, veri kümeniz istemciye gönderilecek kadar büyük olduğunda, platformlar arasında tutarlı alaka gerektiğinde veya erişim kontrolünün kesin olduğu durumlarda önem kazanır (örneğin, kullanıcıların yalnızca izin verilen kayıtları görmesi gereken dahili araçlar). Ayrıca analiz, kayıt ve öngörülebilir performans istediğinizde varsayılan seçimdir.

Kullanıcıların beklentileri (ve hemen fark ettikleri)

İnsanlar arama motorlarını düşünmez—deneyimi değerlendirirler. İyi bir “anlık” arama akışı genellikle şunları ifade eder:

• Hızlı geri bildirim: kullanıcı yazarken sonuçlar hızlı güncellenir, garip duraklamalar olmaz.
• Yazım hataları sorun yaratmaz: yanlış yazımlar, yer değiştiren harfler ve kısmi kelimeler yine doğru öğeleri bulur.
• Kullanışlı kontroller: filtreleme (kategori, durum, fiyat aralığı), sıralama (yeniler, en ucuz) ve fasetler (filtre başına sayımlar) doğal hissedilir.
• Alaka sırası: “en iyi” sonuçlar ilk gelir; sadece en yeni olanlar ya da anahtar kelimeyle doldurulmuşlar değil.

Bunlardan herhangi biri eksikse, kullanıcılar farklı sorgular denemek, daha fazla kaydırmak veya aramayı tamamen bırakmak suretiyle telafi eder.

Bu rehber size ne yapmanızda yardımcı olacak

Bu makale, Meilisearch ile bu deneyimi oluşturmak için pratik adım adım bir yönergedir. Güvenli kurulum, indekslenmiş verinin nasıl yapılandırılacağı ve senkronize edileceği, alaka ve sıralama kurallarının nasıl ayarlanacağı, filtreleme/sıralama/faset eklemenin yolları, güvenlik ve ölçeklendirme düşünceleri gibi konuları ele alacağız ki arama uygulamanız büyüdükçe hızlı kalsın.

Sunucu tarafı aramanın parladığı yerler

Meilisearch özellikle uygundur:

• Dokümantasyon ve bilgi tabanları (sayfaları hızlı bulun, yazım hatalarına tolerans)
• Ürün katalogları ve pazar yerleri (filtreleme ve sıralama hayati)
• Dahili araçlar (kayıtlar üzerinde izinlere duyarlı arama)
• İçerik siteleri (makaleler, rehberler, SSS içinde arama)

Amacımız: sonuçların anlık, doğru ve güvenilir hissettirmesi—aramayı büyük bir mühendislik projesine dönüştürmeden.

Meilisearch hakkında sade bir özet

Meilisearch, uygulamanızın yanında çalıştırdığınız bir arama motorudur. Ona belgeler gönderirsiniz (ürünler, makaleler, kullanıcılar veya destek talepleri gibi) ve hızlı aramaya optimize edilmiş bir indeks oluşturur. Backend’iniz (veya frontend) Meilisearch’e basit bir HTTP API ile sorgu gönderir ve milisaniyeler içinde sıralanmış sonuçlar alırsınız.

Kutudan çıktığı gibi neler sunar

Meilisearch modern aramadan beklenen özelliklere odaklanır:

• Yazım hatalarına tolerans böylece “iphnoe” yine de “iPhone”u bulur.
• Alaka denetimleri (sıralama kuralları) böylece “en iyi eşleşme”nin ne anlama geldiğini işiniz için belirleyebilirsiniz.
• Filtreler, sıralama ve fasetler kullanıcıların kategori, fiyat aralığı, stok durumu veya etiketler gibi özelliklere göre daraltma yapmasını sağlar.

Kısa, hafif hatalı veya belirsiz bir sorgu olsa bile duyarlı ve hoşgörülü hissettirecek şekilde tasarlanmıştır.

Meilisearch ne değildir

Meilisearch ana veritabanınızın yerini almaz. Veritabanınız yazmalar, işlemler ve kısıtlamalar için gerçek kaynak olmaya devam eder. Meilisearch, aranabilir, filtrelenebilir veya görüntülenebilir yapmak için seçtiğiniz alanların bir kopyasını saklar.

İyi bir zihinsel model: veritabanı veri saklar ve günceller, Meilisearch onu hızlıca bulur.

Performans beklentileri (hızı etkileyenler)

Meilisearch çok hızlı olabilir, ancak sonuçlar birkaç pratik faktöre bağlıdır:

• Veri boyutu ve yapısı (belge sayısı, alan sayısı ve indekslediğiniz metin miktarı)
• Donanım (CPU, RAM, disk)
• Yapılandırma (hangi nitelikler aranabilir/filtrelenebilir/sıralanabilir ve ne sıklıkla yeniden indeksliyorsunuz)

Küçükten orta ölçekli veri kümeleri için genellikle tek bir makinede çalıştırmak yeterlidir. İndeks büyüdükçe, neyi indekslediğinize ve nasıl güncel tuttuğunuza daha dikkatli karar vermeniz gerekir—bunları sonraki bölümlerde ele alacağız.

İndekslerinizi ve veri modelinizi planlama

Hiçbir şey yüklemeden önce, gerçekte neyi arayacağınızı belirleyin. İndeksleriniz ve belgeleriniz insanlar uygulamanızı nasıl gezdiğine uymuyorsa Meilisearch “anlık” hissettirmeyebilir.

Varlıkları indekslere eşleme

Aranabilir varlıklarınızı listeleyerek başlayın—genellikle ürünler, makaleler, kullanıcılar, yardım dokümanları, konumlar vb. Birçok uygulamada en temiz yaklaşım her varlık türü için bir indeks (ör. products, articles) kullanmaktır. Bu, sıralama kurallarını ve filtreleri öngörülebilir tutar.

UX bir kutuda birden fazla türü arıyorsa (“her şeyi ara”), ayrı indeksleri saklayıp sonuçları backend'de birleştirebilir veya daha sonra özel bir “genel” indeks oluşturabilirsiniz. Alanlar gerçekten uyumlu değilse her şeyi tek bir indekse zorlamayın.

Birincil anahtar ve belge şekli seçimi

Her belgenin sabit bir kimliği (birincil anahtar) olmalıdır. Şu özelliklere sahip bir şey seçin:

• değişmeyen (veya çok nadiren değişen)
• indeks içinde benzersiz
• veritabanınızda zaten bulunan (ör. id, sku, slug)

Belge yapısı için mümkün olduğunda düz alanları tercih edin. Düz yapılar filtreleme ve sıralama için daha kolaydır. İç içe alanlar, sıkı ve değişmeyen bir paketi temsil ediyorsa (ör. bir author nesnesi) uygundur, ancak tüm ilişkisel şemanızı yansıtan derin iç içe yapılardan kaçının—arama belgeleri okumaya optimize edilmiş olmalı, veritabanı şeklinde değil.

Alanları sınıflandırma: aranabilir, filtrelenebilir, görüntülenebilir

Belgeleri tasarlamak için pratik bir yol her alanı bir rol ile etiketlemektir:

• Aranabilir (Searchable): kullanıcıların yazdığı metin (başlık, isim, açıklama)
• Filtrelenebilir (Filterable): kısıtlama olarak kullanılan nitelikler (kategori, fiyat aralığı, durum, etiketler)
• Görüntülenebilir (Displayed): UI'ye dönecek alanlar (başlık, küçük resim URL'si, kısa özet)

Bu, yaygın bir hatayı önler: “olur ya diye” bir alanı indekslemek ve sonra neden sonuçların gürültülü veya filtrelerin yavaş olduğunu merak etmek.

Çok dilli içerik için planlama

“Dil” verinizde farklı şeyler anlamına gelebilir:

• belgenin kendi dili (her makalede lang: "en" gibi)
• kullanıcının yerel ayarı (UI dili)
• karışık dil alanları (ürün isimleri birden fazla dilde)

Erken karar verin: dil başına ayrı indeksler mi kullanacaksınız (basit ve öngörülebilir) yoksa dil alanları içeren tek bir indeks mi (daha az indeks, daha fazla mantık). Doğru cevap, kullanıcıların bir seferde tek bir dilde mi arama yaptığına ve çevirileri nasıl sakladığınıza bağlıdır.

Meilisearch kurulumu ve güvenli çalıştırma

Meilisearch'i çalıştırmak basittir, ancak “varsayılan olarak güvenli” olması için birkaç kasıtlı karar gerekir: nerede dağıtıldığı, verilerin nasıl kalıcı tutulduğu ve master anahtarının nasıl yönetildiği.

Dağıtım seçenekleri (işletebileceğiniz birini seçin)

• Docker (en yaygın): hızlı başlatma, yükseltme kolay, ortamlar arası tutarlı. Kalıcı bir hacimle eşleştirin.
• VM veya çıplak metal: systemd, log rotasyonu, yedeklemeler gibi standart bir Linux dağıtım hattınız varsa uygundur.
• Managed hosting: ekibi sunucu yönetmek istemiyorsa, yönetilen bir Meilisearch sağlayıcısı veya eklenti sunan bir platform arayın. Esneklik yerine daha basit operasyon alırsınız.

Ortam temelleri: depolama, bellek, yedekler, izleme

Depolama: Meilisearch indeksini diske yazar. Veri dizinini güvenilir, kalıcı depolamaya koyun (geçici konteyner depolamasına değil). Büyüme için kapasite planlayın: geniş metin alanları ve çok sayıda özellik indekslerle hızla büyüyebilir.

Bellek: Yük altında arama için yeterli RAM ayırın. Swap gözlemlerseniz performans düşer.

Yedekler: Meilisearch veri dizinini yedekleyin (veya depolama katmanında anlık görüntüler kullanın). En az bir kez geri yüklemeyi test edin; geri yükleyemediğiniz bir yedek sadece bir dosyadır.

İzleme: CPU, RAM, disk kullanımını ve disk I/O'yu izleyin. Ayrıca süreç sağlığını ve log hatalarını takip edin. En azından hizmet durduğunda veya disk alanı azaldığında uyarı verin.

Master anahtarı ayarlayıp güvenli saklama

Geliştirme dışındaki her durumda Meilisearch'i bir master key ile çalıştırın. Bu anahtarı bir gizli yönetici veya şifrelenmiş ortam değişkeni deposunda saklayın (Git'e, açık metin .env dosyasına koymayın).

Ayrıca ağ kurallarını düşünün: özel bir arayüze bağlayın veya yalnızca backend'inizin erişebildiği şekilde gelen trafiği kısıtlayın.

İlk başlatma kontrol listesi

• Bir dağıtım yöntemi seçin (Docker/VM/managed) ve kalıcı depolama yapılandırıldığından emin olun.
• MEILI_MASTER_KEY'i güvenli bir gizli depoda ayarlayın.
• Servisi başlatın ve doğru ağdan erişilebilir olduğunu doğrulayın.
• Sağlık/sürüm yanıtını doğrulayın:

curl -s http://localhost:7700/version

• Logların toplandığını ve temel uyarıların kurulu olduğunu doğrulayın (süreç durdu, düşük disk vb.).
• İlk yedeği alın (gerçek veriden önce bile) ve geri yükleme adımlarını belgeleyin.

Belgeleri indeksleme ve senkron tutma

Meilisearch indeksleme eşzamansızdır: belgeleri gönderirsiniz, Meilisearch bir görev kuyruğuna alır ve o görev başarılı olana kadar belgeler aranabilir hale gelmez. İndekslemeyi bir iş sistemi gibi ele alın, tek bir istek gibi değil.

Basit bir indeksleme akışı (ekle → bekle → doğrula)

1. Belgeleri ekleyin (her birinin sabit benzersiz bir id'si olduğundan emin olun, genellikle id).

curl -X POST 'http://localhost:7700/indexes/products/documents?primaryKey=id' \\
  -H 'Content-Type: application/json' \\
  -H 'Authorization: Bearer YOUR_WRITE_KEY' \\
  --data-binary @products.json

2. Görevi bekleyin. API yanıtı bir taskUid içerir. succeeded (veya failed) olana kadar sorgulayın.

curl -X GET 'http://localhost:7700/tasks/123' \\
  -H 'Authorization: Bearer YOUR_WRITE_KEY'

3. Sayaçları ve basit bir aramayı doğrulayın. İndeksin beklenen sayıda belgeye sahip olduğunu ve basit bir sorgunun sonuç döndürdüğünü onaylayın.

curl -X GET 'http://localhost:7700/indexes/products/stats' \\
  -H 'Authorization: Bearer YOUR_WRITE_KEY'

Sayım eşleşmiyorsa, tahmin yürütmeyin—önce görev hata detaylarını kontrol edin.

Sonradan sürpriz yaratmayacak toplu yükleme

Toplu yükleme, görevleri öngörülebilir ve kurtarılabilir tutmakla ilgilidir.

• 1.000–10.000 belge/parti ile başlayın veya yük boyutunu sınırlandırın (çoğu uygulama için 5–15 MB aralığı konforludur).
• Tek büyük yük yerine birçok küçük parti tercih edin; yeniden denemesi ve hatalı veriyi izole etmesi daha kolaydır.
• Sık değişiklikler varsa, her dakika gibi düzenli aralıklarla toplu indeksleyin; her şeyi yeniden oluşturmayın.

Güncellemeler vs tam yeniden indeksleme

addDocuments bir upsert gibi davranır: aynı birincil anahtara sahip belgeler güncellenir, yenileri eklenir. Normal güncellemeler için bunu kullanın.

Tam yeniden indeksleme gerektiren durumlar:

• belge yapısını önemli ölçüde değiştirdiğinizde,
• türetilmiş alanları yeniden hesaplamanız gerektiğinde,
• senkronizasyonunuz kaydıysa ve temiz bir sıfırlama istiyorsanız.

Kaldırmalar için deleteDocument(s) çağırın; aksi takdirde eski kayıtlar kalabilir.

Tekrarlanabilirlik: işler başarısız olduğunda güvenli yeniden deneme

İndeksleme yeniden denenebilir olmalıdır. Anahtar nokta sabit belge id'leridir.

• Bir toplu yükleme zaman aşımına uğrarsa aynı partiyi yeniden gönderebilirsiniz: upsert + sabit id'ler çoğaltma oluşturmaz.
• Döndürülen taskUid'yi parti/iş id'nizle birlikte saklayın ve görev durumuna göre yeniden deneyin.
• Bir kuyruğunuz varsa, işçi “en az bir kez” güvenli olmalıdır: çoğaltmalar zararsız olmalıdır.

Ön üretim için tohum verisi

Üretim verisinden önce, gerçek alanlara uyan küçük bir veri kümesi (200–500 öğe) indeksleyin. Örnek: id, name, description, category, brand, price, inStock, createdAt alanlarına sahip bir products seti. Bu, görev akışı, sayımlar ve güncelleme/silme davranışını doğrulamak için yeterlidir—büyük bir içe aktarma beklemeden.

Kontrolünüzdeki alaka ve sıralama kuralları

Arama “alakası” basitçe: ne önce gösterilir ve neden. Meilisearch bunu zorlamak zorunda bırakmadan ayarlanabilir hale getirir.

Doğru alanlarla başlayın

İki ayar Meilisearch'in içeriğinizle ne yapabileceğini şekillendirir:

• searchableAttributes: kullanıcının yazdığı sorguda aranacak alanlar (örneğin: title, summary, tags). Sıra önemlidir: ilk alanlar daha önemli sayılır.
• displayedAttributes: yanıtta döndürülecek alanlar. Bu gizlilik ve yük boyutu için önemlidir—bir alan gösterilmiyorsa gönderilmez.

Pratik bir temel: birkaç yüksek sinyal alanını aranabilir yapın (başlık, ana metin) ve görüntülenen alanları UI'nin ihtiyaçlarıyla sınırlayın.

Sıralama kuralları sonuç sırasını nasıl etkiler

Meilisearch eşleşen belgeleri sıralama kurallarıyla—bağlayıcı tiebreaker'lar hattıyla—sıralar. Kavramsal olarak tercih eder:

1. sorguyla iyi eşleşen sonuçları (yazım toleransı dahil), sonra
2. eşleşmenin daha güçlü olduğu sonuçları (daha yakın kelimeler, daha önemli alanlardaki eşleşmeler), sonra
3. iş mantığınıza uyan sonuçları (yenilik veya popülerlik gibi özel sıralama).

İçini ezberlemenize gerek yok; etkili ayarlamak için esas olarak hangi alanların daha önemli olduğunu ve ne zaman özel sıralama uygulayacağınızı seçersiniz.

Yaygın ayarlama hedefleri (örneklerle)

Amaç: “Başlık eşleşmeleri kazanmalı.” title'ı öne koyun:

{
  "searchableAttributes": ["title", "subtitle", "description", "tags"]
}

Amaç: “Daha yeni içerik önce gelsin.” Bir sıralama kuralı ekleyin ve sorgu zamanında sıralayın (veya özel sıralama ayarlayın):

{
  "sortableAttributes": ["publishedAt"],
  "rankingRules": ["sort", "typo", "words", "proximity", "attribute", "exactness"]
}

Sonra şu şekilde istekte bulunun:

{ "q": "release notes", "sort": ["publishedAt:desc"] }

Amaç: “Popüler öğeleri öne çıkar.” popularity'yi sıralanabilir yapın ve uygun olduğunda buna göre sıralayın.

Değişiklikleri basit bir önce/sonra testiyle değerlendirin

Kullanıcıların yazdığı 5–10 gerçek sorgu seçin. Değişiklikten önce en üst sonuçları kaydedin, sonra sonra karşılaştırın.

Örnek:

• Önce: sorgu "apple" → Apple Watch band, Pineapple slicer, Apple iPhone case
• Sonra (başlık-öncelikli + exactness): sorgu "apple" → Apple iPhone case, Apple Watch band, Pineapple slicer

Eğer “sonra” listesi kullanıcı niyetine daha uygunsa ayarları koruyun. Kenar durumları bozuyorsa, neyin iyileştirdiğini bilmek için bir seferde bir şey değiştirin (önce alan sırası, sonra sıralama kuralları).

Gerçek dünya için filtreler, sıralama ve fasetler

İyi bir arama kutusu sadece “kelimeleri yaz, eşleşmeleri al” değildir. İnsanlar sonuçları daraltmak ister (“sadece stoktakiler”) ve sıralamak isterler (“en ucuz ilk”). Meilisearch'te bunu filtreler, sıralama ve fasetler ile yaparsınız.

Filtreler ve fasetler (aynı fikir, farklı UI)

Bir filtre, sonuç kümesine uyguladığınız kuraldır. Bir faset, kullanıcıların bu kuralları oluşturmasına yardımcı olmak için UI'de gösterdiğiniz (genellikle onay kutuları veya sayımlar olarak) şeydir.

Teknik olmayan örnekler:

• Kategori: “Ayakkabılar”, “Ceketler”, “Aksesuarlar”
• Fiyat: “50$ altında”, “50–100$”
• Durum: “Stokta”, “Tedarikte”, “Arşivlenmiş”

Kullanıcı “running” arayıp sonra category = Shoes ve status = in_stock ile filtreleyebilir. Fasetler “Shoes (128)” ve “Jackets (42)” gibi sayımlar göstererek neyin mevcut olduğunu anlamalarına yardımcı olur.

Filtrelenebilir ve sıralanabilir alanları yapılandırma (yoksa çalışmaz)

Meilisearch, filtre ve sıralama için kullanacağınız alanları açıkça izinlendirmenizi ister.

• Filtre için kullanacağınız alanları filterable olarak işaretleyin: category, status, brand, price, created_at (zamanla filtreleme yapıyorsanız), tenant_id (müşterileri izole ediyorsanız).
• Sıralama için kullanacağınız alanları sortable yapın: price, rating, created_at, popularity.

Bu listeyi sıkı tutun. Her şeyi filtrelenebilir/sıralanabilir yapmak indeks boyutunu artırabilir ve güncellemeleri yavaşlatabilir.

Sayfalama ve sınırlar, aramayı hızlı tutmak için

50.000 eşleşmeye sahip olsanız bile kullanıcılar yalnızca ilk sayfayı görür. Küçük sayfalar kullanın (genellikle 20–50 sonuç), mantıklı limit ayarlayın ve offset ile sayfalandırın (veya tercih ederseniz daha yeni sayfalama özelliklerini kullanın). Ayrıca uygulamanızda maksimum sayfa derinliğini sınırlandırın; “sayfa 400” istekleri pahalıdır.

Eşanlamlılar ve stop kelimeler (isteğe bağlı, dikkatli kullanın)

• Eşanlamlılar (Synonyms) farklı kelimeler aynı anlama geldiğinde yardımcı olur (ör. “hoodie” ↔ “sweatshirt”). Bunları kademeli ekleyin ve arama analizini gözden geçirin—çok fazla eşanlamlı şaşırtıcı eşleşmelere yol açabilir.
• Stop kelimeler (“the”, “and” gibi) yaygın kelimeleri kaldırır. Gürültüyü azaltabilir, ancak “The Who”, “A Team” gibi tam isim aramalarına zarar verebilir. Net bir sorun yoksa stop kelimeleri özelleştirmeyin.

Meilisearch'i uygulama backend'inize entegre etme

Sunucu tarafı aramayı eklemenin temiz yolu Meilisearch'i API'nizin arkasında uzmanlaşmış bir veri servisi gibi treat etmektir. Uygulamanız bir arama isteği alır, Meilisearch'i çağırır, sonra istemciye düzenlenmiş bir yanıt döner.

Basit bir backend deseni

Çoğu ekip şu akışla çalışır:

1. İstemci endpoint'inizi çağırır (ör. GET /api/search?q=wireless+headphones&limit=20).
2. Backend girdileri doğrular, iş kurallarını uygular ve hangi indeksi sorgulayacağına karar verir.
3. Backend, kullanıcı sorgusunu filtreler/sıralama ile Meilisearch Search API'ye gönderir.
4. Backend sonuçları post-proses yapar (özel alanları gizle, DB ile birleştir, izinleri uygula).
5. Backend istemciye kararlı bir yanıt şekli döner.

Bu desen, Meilisearch'i değiştirilebilir tutar ve frontend kodunun indeks iç detaylarına bağlı kalmasını engeller.

Eğer yeni bir uygulama inşa ediyor veya iç aracı yeniden kuruyorsanız ve bu paterni hızla uygulamak istiyorsanız, Koder.ai gibi bir vibe-coding platformu React UI, Go backend ve PostgreSQL ile tam akışı iskeletleyip Meilisearch'i tek bir /api/search uç noktasının arkasına entegre edebilir—istemciyi basit, izinleri ise sunucu tarafında tutar.

Frontend vs backend sorgulama (ve neden backend daha güvenli)

Meilisearch istemci tarafı sorgulamayı destekler, ancak backend sorgulama genellikle daha güvenlidir çünkü:

• Gizli anahtarlar gizli kalır: ayrıcalıklı API anahtarlarını açığa çıkarma riski yoktur.
• Yetkilendirme tutarlı olur: backend, bu kullanıcının neleri görmeye izinli olduğunu uygulayarak sonuçları döndürebilir.
• Sorgu karmaşıklığını kontrol edersiniz: performansı korumak için filtre, sıralama ve sayfalandırma sınırları koyabilirsiniz.

Kamuya açık veriler için kısıtlı anahtarlarla istemci sorgulaması çalışabilir, ancak kullanıcıya özel görünürlük kuralları varsa aramayı sunucunuz üzerinden yönlendirin.

Alaka bozulmadan popüler sorguları önbelleğe alma

Arama trafiği genellikle tekrarlar içerir (“iphone case”, “return policy”). API katmanında önbellekleme ekleyin:

• Anonim trafik için kısa süreli (örn. 10–60 saniye) tam yanıt önbelleklemesi yapın.
• Önbellek anahtarlarını normalize edin (boşlukları kırpın, küçük harfe çevirin, filtre/sıralamayı dahil edin).
• Hızlı değişen indekslerde TTL'leri kısa tutun; agresif temizleme yerine kısa ömürlü önbellek tercih edin.

Oran sınırlama ve kötüye kullanım kontrolleri

Aramayı herkese açık bir endpoint gibi muamele edin:

• IP veya kullanıcı başına oran limitleri uygulayın.
• Maksimum limit ve maksimum sorgu uzunluğu belirleyin.
• Gerçek kullanıcıları engellemeyecek şekilde botları yumuşakça engelleme düşünebilirsiniz.

Güvenlik temelleri: anahtarlar, erişim kontrolü ve çoklu kiracı

Meilisearch genellikle uygulamanızın “arka” tarafında konumlandırılır çünkü hassas iş verilerini hızla döndürebilir. Bir veritabanı gibi davranın: kilitleyin ve sadece her çağıranın görmesi gerekeni açığa çıkarın.

API anahtarları: master vs kısıtlı (en az ayrıcalık)

Meilisearch'in tüm işlemleri yapabilen bir master key'i vardır: indeks oluşturma/silme, ayar güncelleme ve belge okuma/yazma. Bu anahtarı sadece sunucuda tutun.

Uygulamalar için sınırlı eylemler ve sınırlı indekslerle API anahtarları oluşturun. Yaygın bir desen:

• Backend işleri: belirli indekslerde yazma ve ayar güncelleme yapabilen bir anahtar.
• Uygulama sunucusu: arama için sadece okunabilir bir anahtar.
• İstemci (zorunluyse): katı filtreler içeren, sadece arama yapabilen kısıtlı bir anahtar.

En az ayrıcalık, sızan bir anahtarın veri silme veya alakasız indeksleri okuma yeteneğini kısıtlar.

Çoklu kiracı: ayrı indeksler mi yoksa tenantId ile filtre mi?

Çoklu müşteriye hizmet veriyorsanız iki ana seçenek vardır:

1) Kiracı başına bir indeks.

Çapraz-kiracı erişim riskini azaltır ve mantığı basit tutar. Dezavantaj: daha fazla indeks yönetimi gerekir.

2) Paylaşılan indeks + tenant filter.

Her belgeye tenantId alanı koyun ve tüm aramalarda tenantId = "t_123" gibi bir filtre zorunlu kılın. Bu iyi ölçeklenebilir, ancak her isteğin filtreyi uyguladığından emin olmalısınız (en iyisi, çağıranların bunu kaldıramayacağı şekilde scoped key kullanmak).

Veri sızıntılarını önleme: ne dönebileceğini kontrol edin

Arama doğru olsa bile sonuçlar istemeden gizli alanları sızdırabilir (e-posta, dahili notlar, maliyet fiyatları). Döndürülebilecekleri yapılandırın:

• Görüntülenebilir/erişilebilir alanları güvenli bir allowlist ile sınırlayın.
• Hassas alanları yalnızca gerekli ise indeksleyin—ve sonuçlarda geri göndermekten kaçının.

Kötü senaryo testi yapın: yaygın bir terim aratın ve özel alanların görünmediğini doğrulayın.

Temel operasyonel güvenlik

• Ağ erişimini kısıtlayın: localhost veya özel bir ağ arayüzüne bağlayın; gelen trafiği yalnızca uygulama sunucularından izin verin.
• TLS ve oran sınırlama gerekiyorsa Meilisearch'i bir reverse proxy arkasına koyun.
• Anahtarları gizli yönetimlerde saklayın ve periyodik döndürme planlayın.

Anahtarın istemci tarafında olup olmaması konusunda emin değilseniz, varsayılan olarak “hayır” kabul edin ve aramayı sunucu tarafında tutun.

Tahmin yapmadan performans ve ölçeklendirme

Meilisearch iki işi ayırt eder: indeksleme (yazma) ve arama sorguları (okuma). Çoğu “bilinmeyen yavaşlık”, bu iki işin CPU, RAM veya disk için rekabet etmesinden kaynaklanır.

Performans genellikle nerede tıkanır

İndeksleme yükü büyük toplu içe aktarmalar, sık güncellemeler veya çok sayıda aranabilir alan eklendiğinde artar. İndeksleme arka planda olsa da CPU ve disk bant genişliği kullanır. Görev kuyruğu büyürse, sorgu trafiği değişmese bile aramalar yavaşlayabilir.

Sorgu yükü trafikle artar; ancak filtreler, fasetler, daha büyük sonuç setleri ve yazım toleransı da istekte yapılan işi artırır.

Disk I/O sessiz suçludur. Yavaş diskler (veya paylaşılan hacimde gürültülü komşular) “anlık”ı “nihayetinde” haline getirebilir. Üretim için NVMe/SSD tipik tabandır.

Pratik ölçeklendirme adımları

Başlangıç olarak Meilisearch'e indeksleri sıcak tutacak kadar RAM ve tepe QPS'i karşılayacak kadar CPU verin. Sonra kaygıları ayırın:

• İndeksleme okumaları etkiliyorsa, toplu içe aktarımları düşük trafikli saatlere planlayın ve çok küçük güncellemeler yerine daha büyük partileri tercih edin.
• Yüksek erişilebilirlik ve okuma kapasitesi için replika ekleyin (uygulama arama isteklerini replika arasında dengeleyebilir).
• Sharding: Meilisearch otomatik dağıtık sharding yapmaz. Tek düğümü aştıysanız veriyi uygulama seviyesinde (ör. kiracı, bölge veya zaman aralığına göre) ayırarak birden fazla indeks veya küme kullanabilirsiniz.

Tahmin etmemeniz için izlemeniz gerekenler

Küçük bir sinyal setini izleyin:

• Arama gecikmesi (p50/p95) ve throughput
• Görev kuyruğu uzunluğu / görev işleme süresi (kuyruk yükseliyorsa indeksleme yetişemiyor demektir)
• CPU, RAM, disk kullanımı ve disk I/O bekleme
• Hata oranları (time-out, 4xx/5xx, başarısız görevler)

Yedekleme ve yükseltme planlama

Yedeklemeler rutin olmalı. Meilisearch'in snapshot özelliğini düzenli kullanın, snapshot'ları kutu dışına saklayın ve ara sıra geri yüklemeyi test edin. Yükseltmelerde sürüm notlarını okuyun, yükseltmeyi non-prod ortamda aşamalayın ve bir sürüm değişikliği indeks davranışını etkiliyorsa yeniden indeksleme zamanını planlayın.

Eğer platformunuz (örneğin Koder.ai) ortam snapshot'ları ve rollback kullanıyorsa, arama dağıtımınızı aynı disipline göre yapın: değişiklik öncesi snapshot, sağlık kontrollerini doğrulama ve hızlı geri dönüş yolu tutun.

Sorun giderme ve pratik bir rollout kontrol listesi

Temiz bir entegrasyon olsa bile arama sorunları birkaç tekrarlayan kategoride toplanır. İyi haber: Meilisearch size yeterli görünürlük sağlar (görevler, loglar, deterministik ayarlar) — sistematik yaklaşırsanız hızlıca hata ayıklayabilirsiniz.

Sık görülen sorunlar (ve genellikle ne anlama gelir)

• “Filtrelerim çalışmıyor”: alan filterableAttributes'a eklenmemiş veya belgeler beklenmeyen bir şekilde depolanmış (string vs dizi vs iç içe nesne).
• “Sonuçlar garip sıralanıyor”: sıralama kuralları, eşanlamlılar, stop kelimeler veya eksik sortableAttributes/rankingRules ayarı yanlış öğeleri öne çıkarıyor.
• “Arama eski verileri gösteriyor”: indeksleme görevleri hâlâ işleniyor, bir farklı indekse yazıyor ya da senkronizasyon hattınız güncelleme/silme işlemlerini düşürdü.

Akılcı bir hata ayıklama iş akışı

Önce Meilisearch'in son değişikliğinizi başarılı uygulayıp uygulamadığını kontrol edin.

1. Görev durumunu inceleyin: her ayar değişikliği ve belge güncellemesi bir async görev oluşturur. Bir görev başarısız olduysa, önce onu düzeltin (hatalı payload, yanlış alan tipi, aşırı büyük belgeler).
2. Logları bir soru ile kullanın: “Sunucu isteğimi kabul etti mi?” sonra “İşlemeyi tamamladı mı?” Hepsini aynı anda taramayın.
3. Minimal yeniden üretilebilir sorgu oluşturun:
   • Bir indeks seçin.
   • Küçük, stabil bir sonuç kümesi döndüren bir sorgu kullanın.
   • Kısıtlamaları tek tek ekleyin: önce filter, sonra sort, sonra facets.

Açıklayamadığınız bir sonuç varsa, geçici olarak yapılandırmanızı indirgedin: eşanlamlıları kaldırın, sıralama kanca ayarlarını azaltın ve küçük bir veri kümesiyle test edin. Karmaşık alaka sorunları 50 belge üzerinde 5 milyon üzerinde olmaktan çok daha kolay görülür.

Yayılma stratejisi: etki alanını azaltın

• Test indeksi oluşturun: your_index_v2 gibi paralel bir indeks kurun, ayarları uygulayın ve üretim sorgularından örnekleri tekrar oynatın.
• Canary rollout: arama trafiğinin küçük bir yüzdesini yeni indekse veya yeni ayarlara yönlendirin, tıklama oranı ve “sonuç yok” oranlarını karşılaştırın.
• Geri dönüş davranışı: arama yavaş veya kullanılamazsa kullanıcıların ne göreceğine karar verin—önbelleğe alınmış sonuçlar, basitleştirilmiş sorgu veya nazik bir “tekrar deneyin” durumu. Arama hatalarının tüm sayfayı bozmamasını sağlayın.

Sonraki adımlar kontrol listesi

• filterableAttributes ve sortableAttributes'ın UI gereksinimlerinizle eşleştiğini doğrulayın.
• Her dağıtımdan sonra indeksleme görevlerinin başarılı tamamlandığını doğrulayın.
• Küçük bir “arama sağlığı” monitörü ekleyin (gecikme + görev hataları).
• Geri alma pratiği yapın: trafiği önceki indekse geri yönlendirin.

Related guides: /blog (search reliability, indexing patterns, and production rollout tips).