Graf ma’lumotlar bazasi nima va Neo4j qachon kerak

Qisqa javob

Graf ma’lumotlar bazasi ma’lumotlarni jadvallarda emas, graf ko‘rinishida saqlaydi:

• tugunlar (nodes) — obyektlar: foydalanuvchi, mahsulot, kompaniya, karta;
• bog‘lanishlar (edges, relationships) — tugunlar orasidagi yo‘naltirilgan munosabatlar: «do‘sti», «sotib oldi», «bo‘ysunadi», «foydalandi»;
• xususiyatlar (properties) — tugunlarda ham, bog‘lanishlarda ham kalit-qiymat juftliklari: ism, sana, summa.

Tugunlar belgilar (:User, :Product) bilan belgilanadi, bog‘lanishlarning esa turi (:BOUGHT) bor. Eng mashhur graf MBBT — Neo4j, uning so‘rov tili Cypher deb ataladi.

Asosiy farq: bog‘lanish hisoblanadigan JOIN emas, balki saqlangan obyekt. Tugundan butun jadval bo‘ylab kalit qidirmasdan darhol qo‘shnilarga o‘tish mumkin.

Nega bog‘lanish zanjirlari SQL uchun og‘ir

Relyatsion bazada bog‘lanish — tashqi kalit, graf bo‘ylab har bir qadam esa yana bitta JOIN. Bir-ikki qadamgacha hammasi yaxshi. Muammolar quyidagi hollarda boshlanadi:

• chuqurlik oldindan noma’lum — «shu akkaunt bilan istalgan sondagi o‘tkazmalar orqali bog‘langan hammani topish»;
• qadamlar ko‘p — «do‘stlarning do‘stlarining do‘stlari»;
• bog‘lanishlar har xil turda — foydalanuvchi, qurilma, telefon, karta va manzil bitta zanjirda.

SQLda bunday so‘rovlar rekursiv CTE (WITH RECURSIVE) bilan yoziladi. Ular ishlaydi, lekin o‘qish qiyin, oraliq qatorlar soni keskin o‘sib ketishi mumkin, optimizator esa ularning narxini yomon baholaydi. Graf bazasida bog‘lanishlar bo‘ylab yurish asosiy amal, so‘rov esa yo‘l shabloni sifatida yoziladi.

Graflar qayerda tabiiy

Cypherda misol

«Hali tanish bo‘lmagan do‘stlarning do‘stlari» tavsiyasi:

MATCH (me:User {id: 42})-[:FRIEND]->(friend)-[:FRIEND]->(candidate)
WHERE candidate <> me
  AND NOT EXISTS { (me)-[:FRIEND]->(candidate) }
RETURN candidate.name, count(friend) AS mutual
ORDER BY mutual DESC
LIMIT 10

So‘rov deyarli rasmdek o‘qiladi: mendan do‘st orqali nomzodga. Endi istalgan umumiy obyekt orqali to‘rt qadamgacha bog‘langan akkauntlarni qidirish:

MATCH (a:Account {id: 'A-1'})-[*1..4]-(linked:Account)
RETURN DISTINCT linked.id

SQLda xuddi shu narsa sikllardan qo‘lda himoyalangan rekursiv so‘rovni talab qiladi.

Qachon baribir PostgreSQL yaxshiroq

Graf bazasi — ixtisoslashgan vosita. Quyidagi hollarda PostgreSQLda qoling:

• asosiy ma’lumotlar jadvalli: buyurtmalar, to‘lovlar, qoldiqlar, hisob-fakturalar;
• agregatlar va hisobotlar kerak: summalar, guruhlash, buxgalteriya uchun eksport;
• bog‘lanishlar sayoz va oldindan ma’lum — indeksli bir-ikki JOIN tez ishlaydi;
• ierarxiya kichik — bir necha yuz xodimli tuzilmani WITH RECURSIVE bemalol bosib o‘tadi;
• jamoada graf bazalari bilan tajriba yo‘q, ikkinchi MBBTni esa qo‘llab-quvvatlash, zaxiralash va sinxronlash kerak bo‘ladi.

Ko‘p uchraydigan ishchi variant — gibrid: PostgreSQL asosiy baza bo‘lib qoladi, graf bazasi esa tavsiyalar yoki antifrod uchun kerakli bog‘lanishlar nusxasini oladi.

Qanday qaror qilish kerak

1. Mahsulotingizning eng muhim 3–5 ta so‘rovini yozib chiqing.
2. Ularning ko‘pchiligi summa, filtr va ro‘yxatlar haqida bo‘lsa — relyatsion baza kerak.
3. Asosiy so‘rovlar yo‘llar, qo‘shnilar va o‘zgaruvchan uzunlikdagi zanjirlar haqida bo‘lsa — grafda prototip qilib ko‘ring.
4. Prodakshenni ko‘chirishdan oldin real hajmdagi ma’lumotlarda sinab ko‘ring.

Ko‘p uchraydigan xatolar

• Butun tizimni, jumladan to‘lovlar va hisobotlarni grafga ko‘chirish.
• Hamma narsani tugun xususiyati sifatida modellashtirib, bog‘lanishlarni unutish — graf sekin jadvalga aylanadi.
• Katta graflarda chuqurlik cheklovisiz ([*]) so‘rovlar yozish.
• Graf asosiy bazaning nusxasi bo‘lganda sinxronlashni o‘ylab ko‘rmaslik.