langchain-azure-cosmosdb: Tek Veritabanıyla Agentic Uygulamalar
Şahsen, Bir AI agent uygulaması kurmaya kalkıştığınızda — özellikle prodüksiyona çıkacak ciddi bir şeyse — kafanızın karıştığı an genelde mimarı diyagramı çizdiğiniz andır. Vector DB bir tarafta, chat history için ayrı bir Redis ya da Postgres, agent state için bir checkpointer, semantic cache için başka bir servis, uzun vadeli hafıza için yine ayrı bir yapı… Sonra bakıyorsunuz, tek bir agent için altı tane farklı servis ayağa kaldırmışsınız. İlginç, değil mi? Her birinin SLA’i başka, ölçeklenmesi başka, faturası da başka (bizzat test ettim)
📋 İçindekiler
-
Evet, doğru duydunuz.
Eski mimariyi kabaca aylık maliyetle düşünürsek şöyle oluyor:
- Pinecone Standard: ~$70 (bu kritik)
- Redis Cache (Premium tier): ~$250
- PostgreSQL (chat history için): ~$120
- Cosmos DB (metadata): ~$80
- Toplam: ~$520/ay
Yeni mimarı işe tek Cosmos DB serverless ya da autoscale üstüne oturuyor:
- Cosmos DB autoscale (4000 RU max): ~$280-350/ay
Bence, Kabaca %35-40 maliyet düşüşü gibi dürüyor. Ama bence daha önemlisi operasyonel taraf; dört farklı servisi izleyen ekibi sadeleştiriyorsunuz, bazı durumlarda yarıya indiriyorsunuz bile.
💡 Bilgi: Cosmos DB serverless modunda düşük trafikli POC’ler için aylık maliyet 20-30 dolara kadar inebiliyor. Demo ya da iç araç geliştiriyorsanız serverless ile başlamak baya iş görüyor. Üretime geçince autoscale’e dönersiniz.Pratik Senaryo: Kimler İçin Mantıklı, Kimler İçin Değil?
Startup ve Küçük Ekipler
Bir şey dikkatimi çekti: Eğer 2-5 kişilik bir ekipseniz. Hâlâ ürün-pazar uyumunu arıyorsanız, bu paket — itiraz edebilirsiniz tabi — size uyuyor gibi dürüyor. Mimariyi sadeleştirmek hız kazandırıyor. Kendi tecrübemden söyleyeyim: 2023’te yaptığım bir prototipte sadece vector DB seçimine iki hafta harcamıştık; şimdi olsa Cosmos DB’ye geçer, prototipi üç günde çıkarırdım.
Kurumsal Yapılar
Büyük kurumsal yapılarda biraz daha dikkat lazım. Eğer şirketinizde. Elasticsearch veya Pinecone kullanan başka ekipler varsa, “tek teknolojide birleşelim” demek kolay olmuyor. Bu durumda yeni paketi sadece yeni projelere uygulamak, eskileri olduğu gibi bırakmak daha akıllıca olabilir.
Bir de şu var: Cosmos DB’nın RU bazlı fiyatlandırması bazı yöneticileri ürkütüyor. “RU nedir, neden bu kadar tutuyor?” sorularına cevap vermekle uğraşmak istemeyebilirsiniz. Bunun yerine gerçekçi kapasite planlaması yapıp finans ekibine düzgün bir sunum vermek daha mantıklı olur.
Hangi Durumda Tercih Etmeyin?
Açık konuşayım — eğer sadece vektör araması yapıyorsanız ve agent state, chat history gibi şeylere ihtiyacınız yoksa Cosmos DB biraz fazla gelebilir. Bu durumda Azure AI Search veya open-source bir çözüm (mesela Qdrant) daha ekonomik olabilir. Paketin asıl gücü bütün bileşenleri birlikte kullanacağınız senaryolarda ortaya çıkıyor.
Karşılaştığım Bir Sorun ve Çözümü
İlk denememde — geçen Salı küçük bir test container’ı üzerinde — LangGraph checkpointer ile çalışırken garip bir
partition keyhatası aldım. Mesaj şuna benziyordu: “PartitionKey extracted from document doesn’t match the öne specified in the header.”Bir dakika — bununla bitmedi.
Şöyle söyleyeyim, Nerede hata yaptığımı bulmam yarım saat sürdü. Container’ı oluştururken partition key’i
/userIdyapmıştım (inanın bana). Checkpointer thread_id bazlı yazıyor; doğru partition key/thread_id‘ olmalıydı. Mantıklı değil mi? Dokümantasyon bu konuda biraz eksik kalıyor; dikkat etmek lazım yanı.
Container’ları her bileşen için ayrı oluşturup her birinin kendi partition stratejisini doğru kurmak gerekiyor.AI Agent’larda Sohbet Geçmişi: Nerede Saklamalı? yazımda chat history için partition stratejilerini detaylı tartışmıştım; yeni paketle birlikte oradaki önerilerin çoğu hâlâ geçerli.
İlk Adım Olarak Ne Yapmalı?
Eğer mevcut bir RAG uygulamanız varsa ve bu pakete geçmeyi düşünüyorsanız şu sırayı öneririm:
- Önce dev ortamda, küçük bir Cosmos DB hesabıyla başlayın (serverless). Aylık 10-15 dolar yeter.
- Zaten sonra
Vector store ‘u taşıyın demek istiyorum ama düzenli gidelim; ilk olarak vector store’u taşıyın.
Embedding’leri yeniden hesaplamak gerekecek — bu süreyi planlayın. - Daha sonra
chat history ‘yi geçirin.
Eski verileri taşımak istiyorsanız basit bir Python script yeterli olur.
İki hafta sürecek iş iki ayı buldu, üstüne canlıda da sıkıntılar çıktı. Neyse uzatmayalım, böyle işlerde sakın gitmek lazım.{“}”
Sıkça Sorulan Sorular
langchain-azure-cosmosdb paketi production-ready mi?
Aslında, Microsoft destekliyor ve PyPI’da resmî olarak yayında. Ama aslında çok yeni bir paket, o yüzden bence kritik prodüksiyon yüklerinde önce bir-iki ay dev/staging ortamında test etmek mantıklı. Erken adopter avantajı var, yanı fırsatı kaçırmamak için takipte olmakta fayda var — ama henüz battle-tested sayılmaz.
Cosmos DB hibrit araması Pinecone veya Weaviate’e göre nasıl?
Saf vektör araması performansında çok yakın sonuçlar alıyorsunuz. Hibrit arama tarafında, yanı vektör + BM25 kombinasyonunda, Cosmos DB son güncellemelerle bayağı iyi bir noktaya geldi (ciddiyim). Tecrübeme göre test ettiğim senaryoda recall@10 değeri Pinecone ile sadece %3 fark ediyordu — pratikte fark etmezsiniz yanı.
Mevcut LangChain Cosmos DB MongoDB vCore entegrasyonum var, geçmeli mıyım?
Hemen geçmek zorunda değilsiniz. Yeni paket NoSQL API üzerine kurulu ve daha derin özellikler sunuyor. Açıkçası yeni projelerde bunu tercih etmenizi öneririm,. Mevcut projelerde acil bir ihtiyaç yoksa beklemenizde hiç sakınca yok.
KVKK ve veri yerelleştirme açısından Cosmos DB Türkiye’de uygun mu?
Cosmos DB’nın Türkiye bölgesi (Turkey Central) mevcut, yanı verilerinizi burada tutmak mümkün. KVKK uyumluluğu için bu iyi bir başlangıç noktası. Ama şöyle bir durum var: Azure OpenAI servisi Türkiye’de henüz büyük çoğunluk modelleri sunmuyor, bu yüzden embedding ve LLM çağrıları için genelde en yakın bölge olan West Europe tercih ediliyor. Bu durumda veri akışını düzgün dokümante etmek gerekiyor — bence bu kısmı atlamayın.
Maliyeti nasıl tahmin edebilirim?
Şöyle ki, Azure Cosmos DB Capacity Calculator iyi bir başlangıç noktası. Ama gerçekçi bir tahmin için aslında bir hafta dev ortamında gerçek trafiği simüle edip RU tüketimini ölçmek en sağlıklısı. Mesela POC’lerde serverless modla başlayın, üretimde autoscale’e geçin — tecrübeme göre bu geçiş çok şey değiştiriyor.
Kaynaklar ve İleri Okuma
Microsoft Cosmos DB Blog: Introducing langchain-azure-cosmosdb (yanlış duymadınız)
PyPI: langchain-azure-cosmosdb Paket Sayfası
Şöyle söyleyeyim, Azure Cosmos DB for NoSQL Vector Search Resmî Dokümantasyonu
Araya gireyim: GitHub: langchain-azure Repository
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
Python AI Uygulamalarında Azure App Service: Hız Kazandıran Sessiz Değişim27 May 2026SharePoint RER Emekliye Ayrılıyor: 1 Temmuz 2027 Son Tarih6 Tem 2026Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek5 May 2026GitHub Issues Araması Değişti: Artık Anlamla Buluyor4 Nis 2026
İlginizi Çekebilir
Pınar H.
Agentic mimarilerde servis sayısı arttıkça debugging cehenneme dönüyor, bunu yaşayarak biliyorum. CosmosDB ile her şeyi tek çatı altında toplamak mantıklı geliyor ama maliyet tarafı nasıl, yoğun workload’larda RU tüketimi patlar mı acaba? Bu arada şu yazınız da güzeldi: Kubernetes v1.36 Pod-Level Resource Managers: Sidecar Derdi Bitiyor — https://www.askinkilic.com.tr/kubernetes-v136-pod-level-resource-managers-sidecar-derdi-bi/
Uğur H.
Tam da bu sorunu yaşıyordum, farklı servisler arasında veri tutarlılığını sağlamak gerçekten baş ağrısı. CosmosDB’yi sadece klasik bir NoSQL olarak düşünürdüm ama bu kadar bileşeni tek çatıda topladığını bilmiyordum, denemeye değer görünüyor.
Yorumlar kapalı.
2 comments