AWS ElastiCache Serverless, Valkey vektör aramasını instance planlaması olmadan sunuyor

Ne değişti

Vektör araması Valkey için ElastiCache Serverless'a geldi. dev.to'daki el üstü deneyim yazısına göre AWS, bu özelliği 10 Kasım 2026'da Valkey 9 veya sonrasını çalıştıran serverless önbellekler için etkinleştirdi ve yönetilen katmana vektör araması, tam metin araması, birleşik sorgular ve sunucu tarafı agregasyonlar getirdi.

Asıl pratik değişiklik kapasite planlamasında. Daha önce ElastiCache üzerinde vektör araması, instance türlerini sizin seçtiğiniz ve belleği kendinizin boyutlandırdığı provisioned düğümlerden oluşan bir küme gerektiriyordu. Serverless bir önbellek bu işi ortadan kaldırıyor: saniyeler içinde hazırlanıyor ve kullanıma göre faturalandırılıyor. Düğüm tabanlı kümeler arama desteğini koruyor; yenilik, instance boyutlarını hiç düşünmek zorunda olmamak.

dev.to, AWS duyurusuna dayanarak vektör araması için mikro saniye düzeyinde gecikmeler ve yüzde 99'a varan recall değeri bildiriyor. Recall, yaklaşık bir aramanın gerçek en yakın komşulardan kaç tanesini bulabildiğini ölçer. Yeni yazılan kayıtlar, beklenmesi gereken bir indeksleme adımı olmadan hemen sorgulanabilir hale geliyor. Erişilebilirlik tüm ticari bölgeleri, GovCloud'u ve AWS European Sovereign Cloud'u kapsıyor; mevcut serverless önbellekler Valkey 9'a yükseltilebiliyor.

Sorgular nasıl çalışıyor

Diğer vektör depolarında olduğu gibi ElastiCache de embedding tutar: bir model tarafından üretilen, benzer anlamlı kayıtların hiç ortak kelime paylaşmasa bile birbirine yakın konumlanacağı şekilde dizilmiş sayısal metin temsilleri. Sorgu daha sonra k en yakın komşuyu, yani KNN'i arar. Bunun milyonlarca kayıt arasında hızlı kalması için Valkey, yaklaşık sonuçlar döndüren katmanlı bir graf yaklaşımı olan HNSW algoritmasını kullanır; kesin ama daha yavaş bir FLAT modu da mevcuttur.

İndeksler vektörlerle sınırlı değil. dev.to yazısı üç ek alan türü sıralıyor: tam metin eşleşmesi için TEXT, bir tür gibi kesin değerler için TAG ve yayın yılı gibi aralıklar için NUMERIC. Valkey Search sorgu dilinde önce bir filtre, sonra bir ok operatörü, ardından KNN ifadesi yazarsınız; böylece komşu araması yalnızca filtreyi sağlayan kayıtlar üzerinde çalışır.

Hibrit uyarısı

AWS'nin burada hibrit arama dediği şey bu filtre-sonra-KNN örüntüsüdür ve bu adlandırma sorgulanmayı hak ediyor. Valkey Search ayrıca metin ve vektör sıralamalarını tek bir sonuç listesinde birleştiren ayrı bir FT.HYBRID komutu tanımlar. dev.to'nun alıntıladığı ElastiCache özellik dokümantasyonuna göre Valkey 9.0 bu komutu desteklemiyor; yani müşteriler iki sıralı listenin ağırlıklı bir harmanı yerine, filtreyi takip eden bir vektör araması elde ediyor. Elasticsearch'ten gelip Reciprocal Rank Fusion bekleyenler buna göre ayar yapmalı, yine de çoğu günlük uygulama için filtre-artı-vektör yeterlidir.

Lambda'dan erişim

Ağ tarafı, aramanın kendisi kadar önemli. AWS, Valkey 9 ile ElastiCache Serverless için genel endpoint'leri geçtiğimiz Eylül'de kullanıma sunmuştu; endpoint'ler yeni değil ama arama yeteneğiyle eşleşmeleri şimdi mümkün oldu. dev.to yazarı bu kombinasyon etrafında çalışan bir örnek kurdu: hayali bir belediye kütüphanesi için kitap arama uygulaması; Amazon Bedrock'un Titan Text Embeddings V2 modelinden gelen embedding'ler, Valkey'de bir arama indeksi ve Serverless Framework ile dağıtılan bir HTTP API'nin arkasında bir Lambda fonksiyonu.

Lambda bilinçli olarak VPC olmadan çalışıyor. Bedrock'a ve önbelleğe genel internet üzerinden erişiyor; trafik TLS ile şifreleniyor ve erişim IAM ile yönetiliyor, bu da kullanıcılara NAT gateway maliyetinden kurtarıyor. İstemci, resmi Valkey istemcisi olan Valkey GLIDE: büyük ölçüde Rust ile yazılmış ve yerel bir kütüphane olarak dağıtılan bu istemci, IAM token'larını otomatik yeniliyor ve arama komutlarını专 GlideFt modülü üzerinden sunuyor.

Bellek tuzağı

Serverless'a geçmek belleği başkasının sorunu yapmıyor. dev.to yazısı belleği en büyük tuzak olarak işaretliyor: her vektör RAM'de iki kez tutuluyor, dolayısıyla maliyet tahminleri serverless katmanının bellek kullanımını gizlediğini varsaymak yerine vektör sayısı ve boyutlarından başlamalı.

Neden önemli

Bu sürüm, AWS üzerinde anlamsal aramanın eşiğini epey düşürüyor. Boyutlandırılacak instance, yönetilecek küme ve ödenek VPC ya da NAT gateway olmadığına göre, çalışan bir hibrit arama kurulumu artık kabaca bir önbellek oluşturma artı bir IAM politikası uzağında — serverless fonksiyonlarla doğal biçimde uyumlu bir mimari.

Çerçeveleme hedef kitleyi de ele veriyor. dev.to'nun belirttiği gibi duyuru, her yapay zeka ajanının, oturumun veya görevin ağ kurulumu olmayan genel bir endpoint arkasında kendi veri deposuna sahip olduğu bir örüntüye işaret ediyor — açıkça ajanlar ve onların bellek ihtiyacına göre şekillendirilmiş bir tasarım. Uyarılar gerçek ama yönetilebilir: bazılarının beklediğinden daha dar bir hibrit tanımı ve faturayı sessizce büyüten iki katına çıkmış bellek ayak izi. İkisini de baştan bilmek, ucuz bir deneyimle pahalı bir sürpriz arasındaki farkı yaratıyor.