Graf Veritabanı Uygulaması Geliştirme: Neo4j ve Cypher'a Giriş

Graf veritabanı ne zaman gerekir?

İlişkisel veritabanları veriyi tablolarda satır ve sütun olarak tutar, ilişkileri ise yabancı anahtarlar ve JOIN işlemleriyle kurar. Bu model, ilişkilerin sayısı sınırlı ve sorgular tablo düzeyinde olduğunda çok iyi çalışır. Ancak asıl soru ilişkilerin kendisi olduğunda, örneğin "bir kişinin arkadaşlarının arkadaşları kimler", "bu işlem hangi hesap zincirinden geçti" ya da "bu ürünü alan kişiler başka ne aldı" gibi sorularda, çok sayıda JOIN gerekir. Sorgular karmaşıklaştıkça hem yazması hem çalıştırması zorlaşır.

Graf veritabanı, veriyi düğümler (nodes) ve onları bağlayan ilişkiler (relationships) olarak saklar. İlişkiler temel bir öğedir ve veritabanında doğrudan depolanır; bir düğümden ona bağlı düğümlere ulaşmak için tablo taramak gerekmez. Bu yüzden derinlemesine ilişki gezintisi, yani birkaç adım ötedeki bağlantıları bulmak, graf modelde doğal ve hızlıdır.

Tipik kullanım alanları: öneri sistemleri, sahtekarlık ve kara para aklama tespiti, sosyal ağ analizi, bilgi grafları, ağ ve altyapı bağımlılıkları, tedarik zinciri izlenebilirliği, kimlik ve erişim yönetimi. Ortak özellikleri, değerin verinin kendisinden çok bağlantılarda yatmasıdır. Neo4j, özellik grafı (property graph) modelini kullanan bir graf veritabanıdır.

Graf veri modeli: düğüm, ilişki ve özellik

Özellik grafı modelinin yapı taşları şunlardır: • Düğüm: bir varlığı temsil eder, örneğin bir kişi, ürün, hesap ya da cihaz. Düğümlere etiket verilir (Kişi, Ürün gibi). • İlişki: düğümleri birbirine bağlar, bir türü ve yönü vardır, örneğin bir kişinin bir ürünü SATIN_ALDI ilişkisiyle bağlanması. • Özellik: düğümün ya da ilişkinin üzerindeki anahtar-değer bilgisidir, örneğin kişinin adı, ilişkinin tarihi.

Modelleme, ilişkisel tasarımdan farklı düşünmeyi gerektirir. Önce cevaplanacak sorular belirlenir, sonra bu sorulara yanıt verecek düğüm ve ilişkiler çizilir. İyi bir graf modelinde isimler gündelik dille okunabilir: "Ayşe, Ürün-A'yı satın aldı" cümlesi doğrudan bir yapıya dönüşür. Yaygın bir ilke, varlıkları düğüm, varlıklar arasındaki eylem ve bağları ise ilişki yapmaktır.

Sık yapılan modelleme hatası, her şeyi özellik olarak tutmaktır. Eğer bir bilgiyi "ortak olan her şeyin" bulunması için gezinmek istiyorsanız, örneğin aynı şehirde yaşayan kişiler, o bilgiyi özellik yerine düğüm yapıp ilişkiyle bağlamak daha uygundur. Aşırı yoğun düğümler (çok sayıda ilişkisi olan, örneğin bir ülke düğümü) ise gezinti performansını etkileyebilir; modelde bu tür düğümlerden kaçınmak ya da bölmek gerekir.

Cypher sorgu dilinin mantığı

Neo4j'nin sorgu dili Cypher, graf desenlerini ASCII sanatı benzeri bir söz dizimiyle tanımlar. Düğümler parantezle, ilişkiler köşeli parantez ve okla gösterilir. Örneğin bir kişinin takip ettiği kişileri bulmak için desen şu şekilde okunur: MATCH (a:Kişi)-[:TAKIP_EDER]->(b:Kişi) WHERE a.ad = 'Ayşe' RETURN b.ad. Bu sorgu, ad özelliği Ayşe olan kişiden TAKIP_EDER ilişkisiyle bağlı kişileri döndürür.

Temel komutlar şunlardır: • MATCH: grafta bir desen arar. • WHERE: sonuçları koşullarla süzer. • RETURN: sonuç olarak ne döneceğini belirler. • CREATE ve MERGE: düğüm ve ilişki oluşturur. MERGE, varsa mevcut olanı kullanır, yoksa yaratır; veri yüklerken mükerrer kayıt oluşmasını önler. • SET ve DELETE: özellikleri günceller, düğüm ya da ilişkileri siler. • WITH: sorgunun aşamalarını birbirine bağlar; toplama ve ara sonuçlarla çalışırken gerekir.

Cypher'ı öğrenirken en büyük zihinsel geçiş, JOIN yerine desen düşünmektir. İlişkisel dilde "şu tabloyu şuna bağla" dersiniz; Cypher'da "şu şekle uyan yapıyı bul" dersiniz. Sorguyu önce kâğıtta çizip sonra desene çevirmek öğrenmeyi hızlandırır. Sorgu performansını anlamak için de komut öncesine yerleştirilen EXPLAIN ve PROFILE anahtar sözcükleri, sorgu planını ve işlem maliyetini görmeyi sağlar.

Veri alımı ve ilişkisel veritabanından göç

Gerçek bir uygulamada veri çoğu zaman başka bir kaynaktan gelir: ilişkisel veritabanı, CSV dosyaları, API'ler ya da olay akışları. Veri aktarımı iyi planlanmazsa en çok zaman burada kaybedilir. Genel akış, kaynak tabloları düğüm ve ilişkilere eşlemekle başlar. Bir tablo satırı çoğunlukla bir düğüm olur; yabancı anahtar ise bir ilişkiye dönüşür. Bağlantı tabloları (çoktan çoğa ilişkiler) doğrudan ilişki olur ve ek özellikler taşıyabilir.

Yükleme sırasında dikkat edilecekler: • Önce düğümleri, sonra ilişkileri yüklemek. İlişki kurarken uç düğümlerin zaten var olması gerekir. • Benzersizlik kısıtları ve indeksler tanımlamak. MERGE ve MATCH ile düğüm bulma işlemleri, indeks olmadan tüm düğümleri taramak zorunda kalır ve yükleme çok yavaşlar. • Büyük hacimde veriyi partiler halinde yüklemek. • Veri kalitesini baştan denetlemek: boş değerler, tekrar eden kayıtlar ve tutarsız biçimler. • Aktarım sonrası kayıt sayılarını kaynakla karşılaştırarak doğrulamak.

Kaynak sistemden tamamen geçiş yapılacaksa, ilişkisel yapıdaki sorguların graf karşılığı yeniden yazılır. Bazı projelerde ise graf veritabanı mevcut sistemin yerine değil yanında, ilişki sorgularını hızlandırmak için kullanılır ve veri sistemler arasında senkron tutulur.

Yol analizi ve Graph Data Science

Grafın gücü, yol ve bağlantı sorularında ortaya çıkar. Değişken uzunluklu yol desenleriyle, birden fazla adım ötedeki bağlantılar tek ifadeyle bulunur. Cypher'da en kısa yol fonksiyonu düğümler arasındaki en az adımlı yolu verir. Bu, "bu hesaplar birbirine nasıl bağlı" ya da "bu servis çökerse hangi servisler etkilenir" sorularının cevabıdır.

Bir adım daha ileri gidilince Graph Data Science (GDS) yaklaşımı devreye girer. Bu kütüphane, graf algoritmalarını büyük veri üzerinde çalıştırır: • Merkezilik algoritmaları, ağda en etkili ya da kritik düğümleri bulur. • Topluluk tespiti, yoğun bağlı grupları ortaya çıkarır; örneğin şüpheli hesap kümeleri ya da müşteri segmentleri. • Benzerlik algoritmaları, benzer davranan düğümleri bulur; öneri sistemlerinin temelidir. • Yol bulma algoritmaları, ağırlıklı en kısa yolu ve rotaları hesaplar. • Düğüm gömmeleri ve bağlantı tahmini, grafı makine öğrenmesi modellerine girdi olarak hazırlar.

Uygulama senaryolarında öneri motoru için ortak satın alma davranışları, sahtekarlık tespiti için ortak cihaz ya da adres paylaşan hesap kümeleri, altyapı yönetiminde bağımlılık analizi öne çıkar. Algoritma çıktıları düğümlere özellik olarak yazılıp sorgularda kullanılabilir.

Performans, güvenlik ve üretim

Üretime geçerken grafın nasıl çalıştığı kadar nasıl işletildiği de önemlidir. Performans için ilk bakılacak yer indeks ve kısıtlardır: sorguların başlangıç düğümlerini hızlı bulabilmesi gerekir. Sonra sorgu planlarına PROFILE ile bakılır; gereksiz taramalar, sınırsız yol desenleri ve çok yoğun düğümlerden geçen sorgular yavaşlığın yaygın nedenleridir. Derinliği sınırlamak, desenleri sıkılaştırmak ve yoğun düğümlerden kaçınmak sorgu sorunlarını sıklıkla çözer. Bellek ayarları da önem taşır; sayfa önbelleği, sıcak veri kümesini tutacak kadar büyük olmalıdır.

Güvenlik tarafında kimlik doğrulama, rol bazlı yetkilendirme ve bağlantı şifrelemesi temel gereksinimlerdir. Hassas verilerde düğüm ya da özellik düzeyinde erişim sınırlamak da değerlendirilir. Yedekleme ve geri yükleme prosedürleri test edilmeli, kümeleme ile yüksek erişilebilirlik gereksinimine göre planlanmalıdır.

Uygulama geliştirme tarafında sürücü kütüphaneleriyle uygulamadan sorgu çalıştırılır; parametreli sorgular hem güvenlik (enjeksiyon önleme) hem performans (sorgu planı önbelleği) için tercih edilir. Şema değişiklikleri, veri modelleme kararlarının sonradan değiştirilebilmesi için ortama göre sürümlenir ve test edilir. İzleme, yavaş sorgu kayıtları ve kapasite planı, üretime çıkıştan önce hazır olmalıdır.

Mindset programında bu beceri

Mindset kataloğundaki "Graph Veritabanları ile Uygulama Geliştirme (Neo4j)" eğitiminin modül başlıkları bu konuları sırasıyla işliyor: graf veri modeli temelleri, Cypher sorgu dili, veri alımı ve göç, ileri sorgulama ve yol analizi, Graph Data Science ve uygulama senaryoları, performans, güvenlik ve üretim.

İlişkisel sorgulama tarafında temeli güçlendirmek isteyenler için SQL becerisi iyi bir başlangıç noktasıdır; graf modelleme ise ilişkisel tasarımla kıyaslandığında daha iyi anlaşılır.