Ad Alanı (Namespace)

Ad alanı (namespace), paylaşılan bir sistem içinde bir veri grubunu diğerinden izole eden mantıksal bir bölümdür ve aynı tanımlayıcıların, anahtarların veya kaynak adlarının farklı ad alanlarında çakışmadan bağımsız olarak var olmasına izin verir. Bu kavram, yazılım altyapısının birçok katmanında tekrarlanır - programlama dilleri fonksiyon adı çakışmalarını önlemek için ad alanları kullanır, Kubernetes bir küme içindeki kaynak gruplarını izole etmek için ad alanları kullanır - ancak özellikle AI/veri altyapısı bağlamında en sık, birlikte hiç aranmaması gereken farklı vektör alt kümelerini ayırmak için kullanılan bir vektör veritabanı indeksi içindeki mantıksal bölümleri ifade eder. AI/SaaS kurucuları için neden önemli: ad alanları, bir vektör deposunda çok kiracılı veri izolasyonu için standart, düşük yüklü mekanizmadır. Müşteri başına ayrı, tamamen bağımsız bir vektör indeksi sağlamak yerine (operasyonel olarak pahalı ve başlatması yavaş) veya tüm müşterilerin vektörlerini tek büyük, bölünmemiş bir indekste karıştırıp onları ayrı tutmak için tamamen metadata filtrelemeye güvenmek yerine (bu işe yarar, ama her sorguya filtreleme yükü ekler ve eksik bir filtre cümlesinin kiracılar arasında veri sızdırması gibi gerçek bir risk yaratır), çoğu vektör veritabanı tek bir indeks içinde kiracı başına bir ad alanı oluşturmanıza izin verir - sorgular API düzeyinde bir ad alanına sınırlandırılır, bu yüzden uygulama kodunda başka bir yerde bir hata olsa bile yanlışlıkla kiracı sınırları arasında arama yapmanın hiçbir yolu yoktur. Nasıl çalışır: özellikle Pinecone'da, her sorgu ve upsert işlemi bir `namespace` parametresi alır; `namespace="tenant_A"`a upsert edilen vektörler, her ikisi de aynı fiziksel indekste yaşasa ve hatta aynı vektör kimliklerine sahip olsa bile, `namespace="tenant_B"`a karşı çalıştırılan bir sorgu için tamamen görünmezdir. Bu, mimari olarak tamamen ayrı indekslerden daha ucuzdur, çünkü bir indeks içindeki ad alanları genellikle aynı temel altyapıyı ve yapılandırmayı (boyutsallık, metrik) paylaşırken, sorgular için yine de katı izolasyon sağlar. Diğer vektör veritabanları aynı kavramı farklı adlar altında uygular - Weaviate "sınıflar" (classes) kullanır, Qdrant kiracı başına desenler için "koleksiyonlar" (collections) kullanır, Chroma "koleksiyonlar" kullanır. Somut örnek: 500 B2B müşteriye hizmet veren bir AI bilgi tabanı SaaS'ı, her müşterinin dahili dokümanlarını tek bir Pinecone indeksinde depolar, ama her upsert ve sorgu için `namespace = f"tenant_{customer_id}"` kullanır. Kiracı A'nın bir çalışanı dahili wiki'sinde arama yaptığında, sorgu `index.query(vector=q, namespace="tenant_4471", top_k=5)` şeklindedir - yapısal olarak Kiracı B'ye ait tek bir vektörü bile döndürmesi imkansızdır, çünkü ad alanı sınırı gelecekteki bir kod değişikliğinin yanlışlıkla atlayabileceği bir uygulama düzeyinde filtre tarafından değil, Pinecone'un kendisi tarafından zorlanır. Bu, güvenlik bilincine sahip ekiplerin ad alanı izolasyonunu, sonradan eklenen bir düşünce değil, mimari incelemede birinci sınıf bir tasarım kararı olarak ele almasını gerektirecek kadar önemlidir - ilk kurumsal müşteri, tedarik durum tespiti sırasında veri izolasyonu hakkında keskin bir soru sorduğunda değil.