Büyük Katalog ve Marketplace Siteleri İçin Arama Altyapısı, VPS Kaynak Planlama ve Hosting Seçimi

Büyük katalog ve marketplace aramasında asıl sorun ne?

Birkaç bin ürünlü basit bir e-ticaret sitesinde arama motoru genelde ikinci plandadır. Klasik veritabanı sorguları, basit LIKE filtreleri ve birkaç kategori filtresi çoğu zaman yeterli olur. Ancak ürün sayısı yüz binleri, hatta milyonları geçtiğinde; onlarca filtre, çoklu kategori, kampanya etiketleri, skorlamalar ve kişiselleştirme devreye girdiğinde tablo tamamen değişir. Bir anda arama, sitenin kalp atışı haline gelir.

DCHost’ta gördüğümüz büyük katalog ve marketplace projelerinin ortak noktası şu: Trafik problemleri, çoğu zaman PHP veya veritabanından önce arama katmanında patlak veriyor. Elasticsearch veya OpenSearch’e geçiş kararı tam da bu noktada gündeme geliyor; fakat asıl kritik konu, bu arama altyapısının nasıl boyutlandırılacağı ve hangi VPS/dedicated mimaride çalışacağı oluyor.

Bu yazıda, büyük katalog ve marketplace siteleri için Elasticsearch/OpenSearch tabanlı arama altyapısını hem mimari hem de VPS kaynak planlama açısından detaylandıracağız. Hangi segmentte ne kadar CPU, RAM, disk ve IOPS’e ihtiyacınız olur, arama sunucusunu uygulama ve veritabanından ne zaman ayırmalısınız, doğru hosting modelini nasıl seçmelisiniz; hepsini DCHost tarafındaki gerçek senaryolara yaslanarak adım adım konuşacağız.

Klasik veritabanı aramasının sınırları ve neden Elasticsearch/OpenSearch?

LIKE ile arama yaparken duvara tosladığınız an

Büyük katalog ve marketplace projelerinde ilk versiyon genelde şöyle başlar: Tüm ürünler SQL veritabanındadır, arama da ürün tablosunda LIKE veya basit FULLTEXT indekslerle çözülür. Başlangıçta sorun yoktur; fakat zamanla şu problemler ortaya çıkar:

• Ürün sayısı arttıkça arama sorguları gecikmeli dönmeye başlar.
• Filtreler (marka, fiyat aralığı, beden, renk, stok durumu vb.) ile aramayı birleştirince sorgular karmaşıklaşır.
• Relevans (en alakalı sonucu ilk gösterme) yönetilemez hale gelir.
• Otomatik tamamlama, öneri, benzer ürün gibi gelişmiş özellikleri eklemek zorlaşır.

Veritabanınızı ne kadar iyi ayarlarsanız ayarlayın, genel amaçlı bir SQL motorundan Google benzeri bir arama deneyimi beklemek orta-uzun vadede sürdürülebilir değildir. Arama, bambaşka bir problem setidir ve tam da bu nedenle Elasticsearch ve OpenSearch gibi arama odaklı motorlar ortaya çıkmıştır.

Elasticsearch/OpenSearch neyi farklı yapar?

Elasticsearch/OpenSearch’in temel farkı, verileri satır-sütun yapısından çıkarıp inverted index adı verilen arama dostu bir yapıya dönüştürmesidir. Bunun pratikte size sağladığı faydalar:

• Çok hızlı tam metin arama: Milyonlarca ürün içinde milisaniyeler mertebesinde sonuç.
• Relevans skoru: Hangi kelime nerede geçti, kaç defa geçti, başlıkta mı açıklamada mı geçti; hepsi skora yansır.
• Analiz ve normalizasyon: Küçük/büyük harf, accent’ler, kök bulma (stemming), eş anlamlılar kolayca yönetilir.
• Aggregrations: Filtre kutucuklarında (faceted search) anlık sayım, ortalama, min/max hesapları yapılabilir.
• Yatay ölçeklenebilirlik: Shard ve replika mantığı ile veriyi ve yükü birden fazla node’a dağıtabilirsiniz.

Bu avantajların hepsi, doğrudan kullanıcı deneyimine yansır: Daha alakalı sonuçlar, daha hızlı kategori/filtre sayfaları ve kampanyalarda çökmeden ayakta kalan bir sistem.

Büyük katalog ve marketplace arama mimarisini nasıl kurgulamalı?

Temel bileşenler: Uygulama, veritabanı ve arama kümesi

Tipik bir büyük katalog veya marketplace mimarisinde üç ana katman bulunur:

1. Uygulama katmanı: PHP (Laravel, WooCommerce), Node.js, Java vb. ile yazılmış asıl iş mantığı.
2. Veritabanı katmanı: MySQL/MariaDB, PostgreSQL gibi ilişkisel veritabanı.
3. Arama katmanı: Elasticsearch/OpenSearch kümesi.

Küçük projelerde bu üç katman tek bir VPS üzerinde bile koşabilir; ancak ürün sayısı ve trafik arttıkça katmanların ayrışması kaçınılmaz olur. DCHost tarafında büyük katalog projelerinde genelde şu adımlı geçiş yolculuğunu görüyoruz:

• Başlangıçta: Uygulama + veritabanı + Elasticsearch aynı VPS’te.
• Orta ölçek: Veritabanı ayrı VPS/dedicated, uygulama + Elasticsearch aynı sunucuda.
• Büyük ölçek: Uygulama, veritabanı ve Elasticsearch kümesi tamamen ayrı sunucularda, hatta ayrı katmanlar halinde.

Bu ayrıştırma kararını verirken sadece arama tarafını değil, uygulama ve veritabanı için kapasite planlama gerekliliklerini de beraber düşünmek kritik.

Tek node mu, çok node’lu küme mi?

Elasticsearch/OpenSearch için mimariyi planlarken temel soru: Tek node yeter mi, yoksa küme şart mı?

• Tek node senaryosu: 100–200 bin ürün, saniyede 10–30 arama isteği, kritik olmayan SLA. Geliştirme ve erken aşama projeler için uygun.
• 3 node’lu küme: 500 bin – 5 milyon ürün, saniyede 50–200 arama isteği, yüksek erişilebilirlik ihtiyacı. Çoğu olgun marketplace için gerçekçi başlangıç.
• Daha büyük kümeler: 5 milyon+ ürün, saniyede yüzlerce istek, ağır analitik sorgular. Burada sharding stratejisi, index lifecycle ve warm/hot node ayrımı devreye girer.

Üç node’lu minimal bir küme genelde şu rollere ayrılır:

• Hepsi hem master eligible hem data node (küçük/orta ölçek için pratik çözüm).
• Büyük ölçeklerde master, data ve koordinasyon (ingest) rollerini ayırmak daha doğru olur.

VPS kaynak planlama: CPU, RAM, disk ve IOPS’i nasıl hesaplamalı?

Temel prensip: RAM aramaya, disk indexe çalışır

Elasticsearch/OpenSearch Java tabanlıdır ve heap belleğine çok bağımlıdır. Genel kabul gören kural, toplam RAM’in en fazla %50’sini JVM heap’e vermektir. Geri kalan %50 ise dosya cache ve işletim sistemi için bırakılır. Örneğin:

• 32 GB RAM’li bir node’da tipik olarak 16 GB heap, 16 GB OS cache kullanırsınız.
• 64 GB RAM’li bir node’da 32 GB heap, 32 GB OS cache mantıklıdır.

Disk tarafında ise asıl kritik olan IOPS ve gecikme değerleridir. Büyük katalog ve marketplace’lerde klasik HDD yerine NVMe depolama kullanmak neredeyse mecburi hale gelir. Bu konuyu daha geniş perspektiften görmek isterseniz, NVMe VPS hosting rehberimizde disk hızının gerçek dünyadaki etkilerini detaylı anlattık.

Ölçeklere göre örnek VPS/dedicated senaryoları

Aşağıdaki rakamlar, DCHost’ta sık gördüğümüz yaklaşık konfigürasyonlardır. Elbette ürün verinizin içeriği, mapping yapınız ve sorgu karmaşıklığına göre değişebilir; fakat planlama yaparken sağlam bir başlangıç noktası verir.

1) Küçük-orta ölçek (100k–300k ürün, saniyede 10–30 sorgu)

• Topoloji: Tek node Elasticsearch/OpenSearch, uygulama ve veritabanı ile aynı sunucuda veya ayrı küçük bir VPS’te.
• Kaynak önerisi (arama için ayrılmış VPS):
  • 4 vCPU
  • 16 GB RAM (8 GB heap, 8 GB OS cache)
  • NVMe depolama tarafında minimum 200–300 GB (index + replica + büyüme payı)
• Kullanım alanı: Niş e-ticaret, B2B kataloglar, bölgesel marketplace’ler.

2) Orta-büyük ölçek (300k–2M ürün, saniyede 30–100 sorgu)

• Topoloji: 3 node’lu Elasticsearch/OpenSearch kümesi. Uygulama ve veritabanı ayrı VPS/dedicated sunucularda.
• Node başına kaynak önerisi:
  • 4–8 vCPU
  • 32 GB RAM (16 GB heap, 16 GB OS cache)
  • NVMe depolamada node başına en az 500 GB (büyümeye göre yukarı çekilebilir)
• Sharding: Genelde index başına 3–5 primary shard, 1 replika ile başlanabilir.

3) Büyük ölçek (2M+ ürün, saniyede 100+ sorgu)

• Topoloji: En az 3–5 data node, gerekirse ayrı master node’lar ve koordinasyon node’ları.
• Node başına kaynak önerisi:
  • 8–16 vCPU
  • 64 GB RAM (32 GB heap, 32 GB OS cache)
  • NVMe depolamada node başına 1–2 TB (hot/warm mimarisine göre değişebilir)
• Ek not: Ağ bant genişliği ve latency bu ölçekte kritik hale gelir; network altyapınızın veri merkezi tarafında buna uygun tasarlandığından emin olmalısınız.

Arama sunucusunu uygulama sunucusundan ne zaman ayırmalı?

Sıklıkla gelen sorulardan biri de bu: “Elasticsearch/OpenSearch uygulama ile aynı VPS’te kalsa olur mu?” Genel deneyimimiz şu yönde:

• 100k ürün altı ve düşük trafik: Aynı VPS’te başlayabilirsiniz, maliyet avantajı sağlar.
• 100k–300k ürün ve kampanyalı trafik: Arama motoru ciddi CPU ve RAM kullanmaya başlar, uygulama ile kaynak rekabeti doğar. Bu noktada arama için ayrı bir VPS mantıklıdır.
• 300k+ ürün ve eşzamanlı 100+ kullanıcı: Aramayı ayrı VPS (veya küme) olarak ayırmak neredeyse zorunludur.

Bunu sadece performans için değil, izolasyon için de yaparsınız. Örneğin arama index yenilemesi sırasında CPU’nuz tavana vurduğunda, bunun checkout veya ödeme işlemlerini etkilememesini istersiniz.

Index tasarımı, mapping ve disk kullanımını kontrol altında tutmak

Mapping ve field türleri neden bu kadar önemli?

Büyük katalog ve marketplace projelerinde sık gördüğümüz hatalardan biri, her alanı gereksiz yere hem text hem keyword olarak indexlemektir. Örneğin:

• Ürün başlığı: text + keyword (anlaşılır)
• Ürün açıklaması: text (çoğu zaman keyword gerekmez)
• Fiyat: double (text/keyword olmamalı)
• Stok kodu: keyword (tam eşleşme için yeterli)

Yanlış mapping, gereksiz index alanına, daha yüksek RAM/disk ihtiyacına ve daha yavaş sorgulara yol açar. Katalog yapınızı iyi analiz edip, hangi alanın tam eşleşme, hangisinin tam metin arama, hangisinin sadece filtreleme için kullanılacağını netleştirmeniz gerekir.

Shard sayısı nasıl seçilir?

Her index için shard sayısını belirlerken şu noktalara bakabilirsiniz:

• Beklenen toplam index boyutu ( örn. 100 GB mı, 1 TB mı?).
• Kümedeki data node sayısı.
• Okuma/yazma dengesine göre sorgu dağılımı.

Genel yaklaşım:

• 100 GB altı index’ler için 1–3 primary shard ile başlamak çoğu zaman yeterlidir.
• 100 GB–1 TB arası index’lerde 3–5 primary shard makuldür.
• Replica sayısını genelde minimum 1 tutmak, hem yüksek erişilebilirlik hem de okuma ölçeklenebilirliği için önemlidir.

Shard sayısını çok yüksek tutmak, yönetim yükünü ve bellek tüketimini gereksiz arttırır; dolayısıyla “ne kadar çok shard o kadar iyi” yaklaşımı doğru değildir.

Hot/warm mimarisi ile maliyetleri dengelemek

Belli bir ölçeğin üzerinde, tüm index’lerinizi en pahalı ve en hızlı NVMe disklerde tutmak zorunda değilsiniz. Sık sorgulanan son dönem verilerini hot node’larda, daha eski ve seyrek kullanılan verileri warm node’larda tutarak maliyet/performans dengesini sağlayabilirsiniz. Bu yaklaşım, özellikle büyük log index’lerine ek olarak katalog geçmişi tutan sistemlerde işe yarar.

Genel hosting bütçenizi planlarken bu tür stratejilerin etkisini anlamak için, hosting maliyetlerini düşürme rehberimize de mutlaka göz atmanızı öneririm.

Arama altyapısını uygulama mimarisiyle birlikte düşünmek

Uygulama, veritabanı ve arama yükünü birlikte planlamak

Sadece Elasticsearch/OpenSearch tarafını doğru boyutlandırmak yetmez; uygulama ve veritabanı hesaplarını da beraber yapmalısınız. Örneğin WooCommerce, Laravel veya Node.js tabanlı bir marketplace geliştiriyorsanız:

• Uygulama için CPU ve RAM ihtiyacı (PHP-FPM worker sayısı, Node.js worker’ları vb.).
• Veritabanı için buffer pool, connection pool ve disk IOPS ihtiyacı.
• Arama için shard, replika ve heap planlaması.

Bu üçlüyü beraber düşünmek için hazırlanmış detaylı bir rehber arıyorsanız, WooCommerce, Laravel ve Node.js için doğru VPS kaynaklarını seçme rehberimize göz atmanızı özellikle tavsiye ederim.

Arama güncellemeleri, senkronizasyon ve kuyruk yapısı

Marketplace veya büyük katalog sitelerinde arama index’ini güncel tutmak başlı başına bir konudur. Temel akış şöyle çalışır:

1. Ürün verisi asıl veritabanına yazılır veya güncellenir.
2. Bu değişikliği bir kuyruk sistemine (ör. job queue) gönderirsiniz.
3. Kuyruktaki iş, Elasticsearch/OpenSearch index’ini günceller.

Yoğun kataloglarda, toplu index yenilemeleri (reindex) sırasında arama kümenizi kilitlememek için şu pratikleri kullanabilirsiniz:

• Blue/green index stratejisi: Yeni index’i arka planda hazırlayıp alias ile canlıya almak.
• Batch boyutlarını dikkatli ayarlamak (örneğin 500–1000 dokümanlık parçalar halinde indexlemek).
• Index işlemlerini trafiğin nispeten düşük olduğu saatlere kaydırmak.

Veritabanı ve önbellek katmanını da unutmamak

Arama motoru ne kadar iyi olursa olsun, kategori sayfalarınızda ve ürün detay sayfalarınızda önbellek kullanmıyorsanız, gereksiz yük üretirsiniz. Büyük katalog ve marketplace mimarilerinde genelde şu yapı tercih edilir:

• Elasticsearch/OpenSearch sadece arama ve filtreler için kullanılır.
• Ürün detayları, fiyat ve stok bilgisi asıl veritabanından (veya önbellekten) çekilir.
• Hot sayfalar (ana kategori, kampanya sayfaları) tam sayfa önbellekle hızlandırılır.

Benzer bir ayrıştırmayı e-ticaret tarafında da görebilirsiniz. Örneğin, WooCommerce için ayrı veritabanı ve önbellek sunucusunun ne zaman mantıklı olduğuna dair yazımızda, uygulama-veritabanı-önbellek ayrımını ayrıntılı şekilde anlatıyoruz. Aynı prensipleri arama altyapısı için de düşünebilirsiniz.

Hosting modeli seçimi: paylaşımlı hosting, VPS, dedicated ve colocation

Paylaşımlı hosting nereye kadar yeter?

Elasticsearch/OpenSearch gibi servisler, doğası gereği uzun süreli çalışan, yüksek RAM ve disk IOPS tüketen süreçlerdir. Paylaşımlı hosting ortamlarında:

• Genelde kendi Elasticsearch/OpenSearch sürecinizi çalıştırmanıza izin verilmez.
• CPU, RAM ve disk I/O limitleri sıkıdır, yoğun kampanyalarda arama performansı düşer.
• Gelişmiş network ve güvenlik yapılandırmalarını esnek yönetemezsiniz.

Bu nedenle büyük katalog ve marketplace sitelerinde ciddi arama altyapısı konuşmaya başladığımız anda, pratikte seçenekler VPS, dedicated sunucu veya colocation tarafına kayar.

VPS ne zaman doğru seçim?

VPS (sanal sunucu), büyük katalog ve marketplace projelerinin çok büyük kısmı için ideal başlangıç noktasıdır. Neden?

• İlk aşamada 1–3 VPS ile uygulama + veritabanı + arama katmanlarınızı esnek şekilde ayırabilirsiniz.
• Dikey ölçekleme ile CPU/RAM arttırmak nispeten hızlı ve kolaydır.
• NVMe disk gibi performans bileşenlerini uygun maliyetle kullanabilirsiniz.

DCHost tarafında, özellikle Elasticsearch/OpenSearch için yüksek IOPS ve düşük gecikmeli disk ihtiyacı olan müşterilerde NVMe VPS’ler oldukça yaygın. Eğer “hangi disk tipinin arama performansına etkisi ne olur” sorusu aklınızı kurcalıyorsa, tekrar hatırlatayım: NVMe VPS hosting rehberindeki test ve örnekler bu konuda oldukça net bir resim çiziyor.

Dedicated ve colocation ne zaman gündeme gelir?

Belli bir ölçeğin üstünde VPS yerine fiziksel (dedicated) sunucuya geçmek daha mantıklı hale gelir. Özellikle:

• Node başına 64 GB+ RAM ve 8–16 gerçek (fiziksel) çekirdek ihtiyacı varsa.
• 1–2 TB NVMe disk alanını sadece arama index’leri için kullanmak istiyorsanız.
• Ağ tarafında özel routing, VLAN, firewall veya gelişmiş DDoS koruması gibi ihtiyaçlarınız artıyorsa.

Daha da ileri seviyede, kendi donanımınızı getirip veri merkezinde barındırmak (colocation) da seçenekler arasına girer. Bu durumda Elasticsearch/OpenSearch kümenizi tamamen kendi donanımınız üzerinde, DCHost veri merkezinin enerji, soğutma ve network altyapısından faydalanarak çalıştırabilirsiniz.

İzleme, loglama, yedek ve felaket senaryoları

Arama kümesini nasıl izlemeniz gerekir?

Elasticsearch/OpenSearch kümenizin sağlığını sadece CPU ve RAM üzerinden okumak yeterli değildir. İzlemeniz gereken başlıca metrikler:

• Heap kullanım oranı ve GC (Garbage Collection) süreleri.
• Disk doluluk oranı ve I/O gecikmesi.
• Shard sayısı, relocating/initializing shard’lar.
• Arama ve index isteği gecikme süreleri (latency).

Bu metrikleri Prometheus, Grafana gibi araçlarla toplayıp grafikleştirmek ve eşik değerler aşıldığında alarm üretmek uzun vadede hayat kurtarır. Aynı yaklaşımı zaten VPS izleme tarafında da kullanmanızı öneriyoruz; detaylı bir başlangıç noktası arıyorsanız, DCHost blogunda yer alan izleme ve alarm kurulum rehberlerimiz size yol gösterecektir.

Yedekleme ve felaket kurtarma

Elasticsearch/OpenSearch verisi genelde “yeniden oluşturulabilir” kabul edilir; çünkü asıl kaynağınız veritabanınızdır. Yine de şu pratikleri atlamamak gerekir:

• Kritik index ve ayarları (template, ILM policy, role, user vb.) düzenli olarak snapshot almak.
• Snapshot’ları ayrı bir depolama alanında veya farklı bir bölgedeki sunucuda saklamak.
• Felaket senaryosunda index yeniden kurulum süresini (RTO) ve veri kaybı toleransınızı (RPO) önceden test etmek.

Daha geniş perspektiften bakmak isterseniz, özellikle veritabanı tarafındaki yedekleme stratejileri için MySQL/MariaDB yedekleme stratejileri yazımızı inceleyebilir, oradaki RTO/RPO mantığını arama altyapınıza da uyarlayabilirsiniz.

Performans testleri, kapasite tahmini ve iteratif ölçekleme

Canlıya çıkmadan önce mutlaka sentetik test yapın

Büyük katalog ve marketplace projelerinde en büyük hata, arama kümesini doğrudan canlı trafiğin insafına bırakmaktır. Bunun yerine şu adımları öneriyoruz:

• Üretime yakın bir staging ortamında (aynı index boyutu ve mapping ile) test kümesi kurun.
• Gerçek kullanıcı sorgularına benzeyen bir sorgu listesi çıkarın.
• Bu sorguları yük test araçları ile (örneğin saniyede 50–100 istek) kümenize ateşleyin.
• Heap, GC, I/O, latency metriklerini inceleyin ve dar boğazları belirleyin.

Ardından, gerekiyorsa shard sayısını, replika sayısını, heap boyutunu veya VPS kaynaklarını arttırarak yeniden test edin. Bu iteratif süreç, “kervan yolda düzülür” yerine “kervanı düzeltip öyle yola çıkma” fırsatı verir.

Kapasite tahmini için pratik bir yaklaşım

Elinizde geçmiş trafik verisi yoksa, kabaca şu hesabı yapabilirsiniz:

• Sayfa görüntülemenin %30–50’si arama + filtreli kategori sayfalarından gelir.
• Eşzamanlı kullanıcı sayısını tahmin edin (örneğin kampanyada 500 eşzamanlı kullanıcı).
• Bunların yarısının aynı anda arama yaptığını varsayın (250 aktif arama kullanıcısı).
• Her kullanıcının 3 saniyede bir yeni sorgu yaptığını kabul edin.

Bu durumda saniyede ortalama ~80–90 sorgu gibi bir değere ulaşırsınız. Elasticsearch/OpenSearch kümenizi, bu yükü kaldırabilecek şekilde planlayıp bir miktar da güvenlik payı bırakırsanız, hem normal günlerde hem kampanyalarda rahat edersiniz.

Özet ve yol haritası: DCHost altyapısında arama kümenizi nasıl konumlandırabilirsiniz?

Büyük katalog ve marketplace projelerinde güçlü bir arama deneyimi sunmak için Elasticsearch/OpenSearch kullanmak artık neredeyse standart. Asıl farkı yaratan, bu altyapının doğru VPS/dedicated mimaride ve doğru boyutlandırma ile kurulması. Tek node’lu basit bir kurulumla başlayıp, ürün sayınız ve trafiğiniz arttıkça 3 node’lu bir kümeye, oradan da daha gelişmiş hot/warm yapılarına geçmek mümkün.

Planlama yaparken şu adımları izleyebilirsiniz:

• Ürün sayınızı, beklenen trafiği ve SLA beklentilerinizi netleştirin.
• Uygulama, veritabanı ve arama katmanını birlikte ele alın; sadece aramaya odaklanıp diğerlerini ihmal etmeyin.
• Elasticsearch/OpenSearch için CPU, RAM, NVMe disk ve IOPS ihtiyacını kabaca hesaplayın.
• Önce staging ortamında test edin, sonra canlıya alın; gerekiyorsa dikey/yatay ölçekleyin.

DCHost olarak, ister NVMe VPS, ister dedicated, ister colocation tarafında olun; büyük katalog ve marketplace projelerinizde arama kümenizi konumlandırırken bu yazıdaki prensipleri referans alabilirsiniz. Mevcut sitenizi paylaşımlı hosting’ten VPS’e taşımak veya halihazırdaki VPS’inizi arama odaklı bir mimariye dönüştürmek istiyorsanız, blogumuzdaki paylaşımlı hosting’ten VPS’e geçiş kontrol listesine de mutlaka göz atın. Sonrasında, kendi iş yükünüzü ve arama gereksinimlerinizi birlikte değerlendirip hem performanslı hem de maliyetini kontrol edebildiğiniz bir altyapı kurmak mümkün.