> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
Bu özellik, TrustGraph'ın yapılandırılmış veri entegrasyonunun ilk uygulamasının ilk aşamalarında tespit edilen sorunları ve eksiklikleri ele almaktadır, bu da `structured-data.md`'da açıklanmıştır.
## Sorun Tanımları
### 1. İsimlendirme Tutarsızlığı: "Nesne" vs "Satır"
Mevcut uygulama, "nesne" terimini tüm alanlarda kullanmaktadır (örneğin, `ExtractedObject`, nesne çıkarma, nesne gömme). Bu isimlendirme çok genel olup kafa karışıklığına neden olmaktadır:
"Nesne" terimi, yazılımda (Python nesneleri, JSON nesneleri vb.) aşırı kullanılan bir terimdir.
İşlenen veri temelde tablolardır; tanımlı şemalara sahip satırlar.
"Satır", veri modelini daha doğru bir şekilde tanımlar ve veritabanı terminolojisiyle uyumludur.
Bu tutarsızlık, modül adlarında, sınıf adlarında, mesaj türlerinde ve belgelerde görülmektedir.
### 2. Satır Depolama Sorgu Sınırlamaları
Mevcut satır depolama uygulamasının önemli sorgu sınırlamaları bulunmaktadır:
**Doğal Dil Uyumsuzluğu**: Sorgular, gerçek dünya verilerindeki değişikliklerle başa çıkmakta zorlanmaktadır. Örneğin:
`"CHESTNUT ST"` içeren bir sokak veritabanını sorgulamak, `"Chestnut Street"` hakkında bilgi almak için zordur.
Kısaltmalar, büyük/küçük harf farklılıkları ve biçimlendirme değişiklikleri, tam eşleşme sorgularını bozmaktadır.
Kullanıcılar semantik bir anlayış beklemekte, ancak depolama literal eşleşme sağlamaktadır.
**Şema Evrimi Sorunları**: Şemaların değiştirilmesi sorunlara neden olmaktadır:
Mevcut veriler, güncellenmiş şemalara uygun olmayabilir.
Tablo yapısındaki değişiklikler, sorguları ve veri bütünlüğünü bozabilir.
Şema güncellemeleri için net bir geçiş yolu bulunmamaktadır.
### 3. Satır Gömme Gerekliliği
2. soruna bağlı olarak, sistemin satır verileri için vektör gömmelere ihtiyacı vardır, bu da şunları sağlamak için gereklidir:
Yapılandırılmış veriler arasında semantik arama (örneğin, "Chestnut Street" verisinin "CHESTNUT ST" olarak bulunduğu durumlarda)
Yapılandırılmış veri alım hattı henüz tam olarak çalışır durumda değildir:
Giriş formatlarını (CSV, JSON vb.) sınıflandırmak için tanısal istemler bulunmaktadır.
Bu istemleri kullanan alım hizmeti, sisteme entegre edilmemiştir.
Önceden yapılandırılmış verileri satır deposuna yüklemek için uçtan uca bir yol bulunmamaktadır.
## Hedefler
**Şema Esnekliği**: Mevcut verileri bozmadan veya geçişler gerektirmeden şema evrimini etkinleştirin.
**Tutarlı İsimlendirme**: Kod tabanında "satır" terimini standartlaştırın.
**Semantik Sorgulanabilirlik**: Satır gömmeleri aracılığıyla bulanık/semantik eşleştirmeyi destekleyin.
**Tam Alım Hattı**: Yapılandırılmış verileri yüklemek için uçtan uca bir yol sağlayın.
## Teknik Tasarım
### Birleşik Satır Depolama Şeması
Önceki uygulamada, her şema için ayrı bir Cassandra tablosu oluşturulmuştur. Bu, şema evrimleri sırasında tablo yapısındaki değişikliklerin geçişler gerektirmesine neden olmuştur.
Yeni tasarım, tüm satır verileri için tek birleşik bir tablo kullanmaktadır:
| `source` | `text` | Bilgi grafiğindeki kaynak bilgisine bağlanan isteğe bağlı URI. Boş bir dize veya NULL, kaynak olmadığını gösterir. |
#### İndeks Yönetimi
Her satır, şemada tanımlanan her indeks için bir kez olmak üzere birden çok kez saklanır. Birincil anahtar alanları, özel bir işaretçi olmadan bir indeks olarak kabul edilir ve bu, gelecekteki esnekliği sağlar.
**Tek alanlı indeks örneği:**
Şema, `email`'ı indeks olarak tanımlar
`index_name = "email"`
`index_value = ['foo@bar.com']`
**Bileşik indeks örneği:**
Şema, `region` ve `status` üzerinde bileşik bir indeks tanımlar
`index_name = "region,status"` (alan adları sıralanır ve virgülle birleştirilir)
`index_value = ['US', 'active']` (değerler, alan adları sırasıyla aynı sırada)
**Birincil anahtar örneği:**
Şema, `customer_id`'ı birincil anahtar olarak tanımlar
`index_name = "customer_id"`
`index_value = ['CUST001']`
#### Sorgu Desenleri
Tüm sorgular, kullanılan indeksten bağımsız olarak aynı deseni izler:
```sql
SELECT * FROM rows
WHERE collection = 'import_2024'
AND schema_name = 'customers'
AND index_name = 'email'
AND index_value = ['foo@bar.com']
```
#### Tasarım Uzlaşmaları
**Avantajları:**
Şema değişiklikleri, tablo yapısı değişiklikleri gerektirmez.
Satır verileri Cassandra için şeffaftır; alan ekleme/çıkarma işlemleri şeffaftır.
Tüm erişim yöntemleri için tutarlı sorgu kalıbı.
Cassandra'nın ikincil indeksleri (ki bunlar ölçekte yavaş olabilir).
Tüm yerel Cassandra türleri (`map`, `frozen<list>`).
**Uzlaşmalar:**
Yazma çoğaltması: her satır eklemesi = N eklemesi (dizinlenmiş alan başına bir tane).
Tekrarlanan satır verilerinden kaynaklanan depolama ek yükü.
Tür bilgisi şema yapılandırmasında saklanır, dönüşüm uygulama katmanında yapılır.
#### Tutarlılık Modeli
Bu tasarım, belirli basitleştirmeleri kabul eder:
1.**Satır güncellemeleri yok:** Sistem yalnızca eklemelerle çalışır. Bu, aynı satırın birden çok kopyasının güncellenmesiyle ilgili tutarlılık sorunlarını ortadan kaldırır.
2.**Şema değişikliği toleransı:** Şemalar değiştiğinde (örneğin, indeksler eklendi/çıkarıldı), mevcut satırlar orijinal dizinlemelerini korur. Eski satırlar, gerektiğinde kullanıcılar tutarlılığı sağlamak için bir şemayı silebilir ve yeniden oluşturabilir, ancak yeni indeksler aracılığıyla bulunamaz.
### Bölüm Takibi ve Silme
#### Sorun
Bölüm anahtarı`(collection, schema_name, index_name)` ile, verimli silme, silinecek tüm bölüm anahtarlarını bilmeyi gerektirir. Yalnızca `collection` veya `collection + schema_name` ile silmek, veriye sahip olan tüm `index_name` değerlerini bilmeyi gerektirir.
#### Bölüm Takip Tablosu
Birincil olmayan bir arama tablosu, hangi bölümlerin mevcut olduğunu izler:
Bu, silme işlemleri için bölümlerin verimli bir şekilde bulunmasını sağlar.
#### Satır Yazıcı Davranışı
Satır yazıcı, kaydedilen `(collection, schema_name)` çiftlerinin bellek içi bir önbelleğini tutar. Bir satırı işlerken:
1.`(collection, schema_name)`'ın önbellekte olup olmadığını kontrol edin.
2. Önbellekte yoksa (bu çift için ilk satır):
Tüm indeks adlarını almak için şema yapılandırmasını arayın.
Her `(collection, schema_name, index_name)` için `row_partitions`'a girişler ekleyin.
Çifti önbelleğe ekleyin.
3. Satır verilerini yazmaya devam edin.
Satır yazıcı ayrıca şema yapılandırma değişiklik olaylarını da izler. Bir şema değiştiğinde, ilgili önbellek girişleri temizlenir, böylece sonraki satır, güncellenmiş indeks adlarıyla yeniden kayda alınmasını sağlar.
Bu yaklaşım şunları sağlar:
Arama tablosu yazmaları, satır başına değil, her `(collection, schema_name)` çifti için bir kez gerçekleşir.
Arama tablosu, verilerin yazıldığı sırada aktif olan indeksleri yansıtır.
İçe aktarma sırasında yapılan şema değişiklikleri doğru şekilde algılanır.
#### Silme İşlemleri
**Koleksiyonu sil:**
```sql
-- 1. Discover all partitions
SELECT schema_name, index_name FROM row_partitions WHERE collection = 'X';
-- 2. Delete each partition from rows table
DELETE FROM rows WHERE collection = 'X' AND schema_name = '...' AND index_name = '...';
-- (repeat for each discovered partition)
-- 3. Clean up the lookup table
DELETE FROM row_partitions WHERE collection = 'X';
```
**Koleksiyonu ve şemayı sil:**
```sql
-- 1. Discover partitions for this schema
SELECT index_name FROM row_partitions WHERE collection = 'X' AND schema_name = 'Y';
-- 2. Delete each partition from rows table
DELETE FROM rows WHERE collection = 'X' AND schema_name = 'Y' AND index_name = '...';
-- (repeat for each discovered partition)
-- 3. Clean up the lookup table entries
DELETE FROM row_partitions WHERE collection = 'X' AND schema_name = 'Y';
```
### Satır Gömme İşlemleri
Satır gömme işlemleri, indeksli değerlerde semantik/bulanık eşleşme sağlayarak, doğal dil uyumsuzluğu sorununu çözer (örneğin, "Chestnut Street" için arama yaparken "CHESTNUT ST" bulmak).
#### Tasarım Genel Bakışı
Her indeksli değer gömülür ve bir vektör deposunda (Qdrant) saklanır. Sorgu zamanında, sorgu gömülür, benzer vektörler bulunur ve ilişkili meta veriler, Cassandra'daki gerçek satırları bulmak için kullanılır.
#### Qdrant Koleksiyonu Yapısı
Her `(user, collection, schema_name, dimension)` tuple'ı için bir Qdrant koleksiyonu:
İsimler temizlenir (alfanumerik olmayan karakterler `_` ile değiştirilir, küçük harfe dönüştürülür, sayısal önekler `r_` öneki alır)
**Gerekçe:** Bir `(user, collection, schema_name)` örneğini, eşleşen Qdrant koleksiyonlarını silerek temiz bir şekilde silmeyi sağlar; boyut soneki, farklı gömme modellerinin birlikte var olmasına olanak tanır.
#### Nelerin Gömüldüğü
İndeks değerlerinin metin gösterimi:
| İndeks Tipi | Örnek `index_value` | Gömülecek Metin |
WHERE collection = 'X' AND schema_name = 'customers'
AND index_name = 'email' AND index_value = ['foo@bar.com']
```
### Önemli Değişiklikler
1.**Sorgu anlamları basitleştirildi**: Yeni şema, yalnızca `index_value` üzerindeki tam eşleşmeleri desteklemektedir. Mevcut GraphQL filtreleri (`gt`, `lt`, `contains`, vb.):
Gerekliyse, döndürülen veriler üzerinde arka filtreleme olarak kullanılır.
Bulanık eşleştirme için gömülü API'nin kullanılması lehine kaldırılır.
2.**GraphQL kodu sıkı bir şekilde birleştirilmiş durumda**: Mevcut `service.py`, Strawberry türü oluşturma, filtre ayrıştırma ve Cassandra'ya özgü sorguları bir araya getirmektedir. Başka bir satır depolama arka ucunun eklenmesi, yaklaşık 400 satır GraphQL kodunun çoğaltılmasına neden olacaktır.
### Önerilen Yeniden Düzenleme
Yeniden düzenleme iki bölümden oluşmaktadır:
#### 1. GraphQL Kodunu Ayırmak
Yeniden kullanılabilir GraphQL bileşenlerini, paylaşılan bir modüle çıkarın: