Elasticsearch Mapping’lerini Azure Cosmos DB’ye Taşımak
Elasticsearch’ten Azure Cosmos DB’ye geçişte ilk tasarım kararı, mevcut mapping tanımının yeni platformda neye karşılık geleceğidir. Elasticsearch’te mapping tek bir yapıdır; alanların nasıl saklandığı ve indekslendiği orada tanımlanır. Azure Cosmos DB şema bağımsız çalıştığı için birebir çevrilecek bir karşılık sunmaz, mapping’in yaptığı iş dört ayrı yere dağılır: indexing policy, full-text policy, vector policy ve computed properties. Aşağıda, kaynak makaledeki yaklaşım izlenerek bu dört yeteneğin mapping’in hangi bölümünü üstlendiği ve geçişin hangi sırayla yapılmasının önerildiği var.
Hedef, mapping’i satır satır dönüştürmek değil. Uygulamanın bağımlı olduğu sorgulama, filtreleme, sıralama (ranking) ve veri getirme davranışı korunurken Azure Cosmos DB’nin container düzeyindeki modeline geçiliyor.
Mapping karşılıklarına genel bakış
Kaynak makale, Elasticsearch tarafındaki yapıları Azure Cosmos DB karşılıklarıyla şöyle eşleştiriyor:
| Elasticsearch | Azure Cosmos DB karşılığı |
|---|---|
Tam eşleşme sorguları, filtreler, sıralama ve aggregation için kullanılan mapped field’lar, index ayarı ve alan tipleri |
Indexing policy: included/excluded path’ler, range index’ler, composite index’ler ve spatial index’ler |
text alanları ve analyzer’lar |
Full-text policy ve indexing policy içindeki full-text index |
dense_vector alanları ve vector index seçenekleri |
Container vector policy ve indexing policy içindeki vector index |
| Runtime field’lar veya arama için materyalize edilmiş değerler | Computed properties |
Çeviriye başlamadan önce her alanın yalnızca tipini değil, nasıl kullanıldığını envanterlemek gerekiyor. Filtreleme ve sıralamada kullanılan bir alan, relevance sıralaması için kullanılan bir alandan farklı karşılanır, ikisi de string tutsa bile. Tek bir Elasticsearch alanı Azure Cosmos DB tarafında birden fazla yeteneğe karşılık gelebilir.
Yeteneğe göre çeviri
1. Tam eşleşme, filtre, sıralama ve aralık davranışı
Elasticsearch tarafında:
"properties": {
"category": { "type": "keyword" },
"price": { "type": "double" },
"description": { "type": "text" }
}Azure Cosmos DB tarafında:
"indexingPolicy": {
"includedPaths": [
{ "path": "/category/?" },
{ "path": "/price/?" }
],
"excludedPaths": [
{ "path": "/description/?" }
]
}JSON değerleri olduğu gibi korunur, yalnızca sorguların kullandığı path’ler indekslenir. Composite index’i ancak tekrar eden bir sorgu category ile filtreleyip price ile sıralıyorsa eklersiniz. Partition key ayrı bir tasarım kararıdır, bu yapılandırmadan bağımsız olarak belirlenir.
2. Full-text alanlar ve analyzer’lar
Elasticsearch tarafında:
"properties": {
"description": {
"type": "text",
"analyzer": "english"
},
"sku": { "type": "keyword" }
}Azure Cosmos DB tarafında:
"fullTextPolicy": {
"defaultLanguage": "en-US",
"fullTextPaths": [
{ "path": "/description",
"language": "en-US" }
]
}
"fullTextIndexes": [
{ "path": "/description" }
]Burada özel bir analiz zincirini kopyalamaya çalışmak yerine analyzer’ın amacını çevirmek gerekir: dile duyarlı tokenization, stemming ve stop-word işleme. Tam eşleşme için kullanılan sku alanı ise normal indexing policy içinde kalmaya devam eder.
3. Vector alanları
Elasticsearch tarafında:
"content_vector": {
"type": "dense_vector",
"dims": 384,
"similarity": "cosine",
"index": true
}Azure Cosmos DB tarafında:
"vectorEmbeddingPolicy": {
"vectorEmbeddings": [{
"path": "/contentVector",
"dataType": "float32",
"distanceFunction": "cosine",
"dimensions": 384
}]
}
"vectorIndexes": [{
"path": "/contentVector",
"type": "quantizedFlat"
}]Embedding modelinin boyut (dimensions) ve benzerlik fonksiyonu bilgisi aynen korunmalı. Azure Cosmos DB tarafındaki vector index tipini ise veri boyutu, filtreler, gecikme ve recall beklentisi belirler.
4. Türetilmiş ve runtime değerler
Elasticsearch tarafında:
"runtime": {
"discountedPrice": {
"type": "double",
"script": {
"source": "emit(doc['price'].value * 0.9)"
}
}
}Azure Cosmos DB tarafında:
"computedProperties": [{
"name": "discountedPrice",
"query": "SELECT VALUE c.price * 0.9 FROM c"
}]Kararlı ve deterministik bir türetmeyi computed property olarak yeniden yazabilirsiniz. Desteklenmeyen ya da dış duruma (external state) bağlı mantık ise ya veri alım (ingestion) aşamasında ya da uygulama katmanında hesaplanır.
Önerilen geçiş sırası
Kaynak makale geçişi beş adımlı bir akışla tarif ediyor:
- Mapping ve iş yükünü envanterleyin; mapping’leri, template’leri, analyzer’ları, vector ayarlarını, runtime field’ları ve bunları kullanan sorguları dışa aktarın.
- Her alanı davranışına göre sınıflandırın. Path’leri tam eşleşmeli filtreleme/sıralama, full-text arama, vector arama, geospatial sorgular veya türetilmiş değer olarak işaretleyin.
- Container politikalarını birlikte tasarlayın ve örtüşmeleri çözün; bir
descriptionalanı aynı anda normal sorgulara, full-text aramaya ve vector tabanlı veri getirmeye açık olabilir. - Temsili veri ve sorgularla doğrulayın. Sonuç doğruluğunu, relevance sıralamasını, gecikmeyi, RU tüketimini ve yazma maliyetini karşılaştırın.
- Kontrollü yayına alın. Politika değişikliklerini bağımlı sorgulardan önce uygulayın, uygulanabilir olduğu yerde index dönüşümünü izleyin, bir geri dönüş (rollback) yolu bırakın.
Çıkarılacak ders
Bir Elasticsearch mapping’ini yeniden üretilmesi gereken bir şema olarak değil, arama niyetinin beyanı olarak ele almak daha doğru. Azure Cosmos DB’de bu niyet, birbiriyle uyumlu çalışan container politikaları üzerinden ifade edilir: indexing policy standart sorgu erişim yollarını, full-text policy analiz edilen metni, vector policy embedding’leri, computed properties ise yeniden kullanılabilir türetilmiş değerleri üstlenir. İş yüküne göre çeviri yapmak davranışı korur, gereksiz index’lerden ve geçiş dönemine özgü varsayımlardan da uzak tutar.
Bu yazı, kaynak makalenin bir serinin ikinci bölümü olduğunu belirtiyor. İlk bölümde Elasticsearch kullanıcıları için genel geçiş yolu ve full-text search desteğinin temel kavramları ele alınmıştı. Üçüncü bölümün ise sorgu çevirisini, yani bir Elasticsearch Search Request’in Azure Cosmos DB sorgusuna nasıl dönüştürüleceğini kapsayacağı belirtiliyor.
Kaynaklar ve İleri Okuma
- Migrating Elasticsearch Mappings to Azure Cosmos DB — Madeline Egan, Azure Cosmos DB Blog
- Azure Cosmos DB Blog
- Azure Cosmos DB’ye Elasticsearch’ten Geçiş Rehberi
- Elasticsearch Sorgularını Azure Cosmos DB’ye Çevirmek
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder