پایگاه داده گراف؛ مدل‌سازی، انتخاب و مقیاس

یک بازارگاه ایرانی می‌خواهد حساب‌هایی را پیدا کند که با چند شماره، کارت، دستگاه و نشانی مشترک در چند دقیقه سفارش می‌سازند. در SQL، تیم یک Query قابل قبول برای عمق دو می‌نویسد؛ بعد Risk می‌خواهد «تا چهار Hop، با مسیر و دلیل» را ببیند. Query سخت‌تر می‌شود، اما این هنوز اثبات نمی‌کند که SQL شکست خورده یا Graph database سریع‌تر است. سؤال درست این است: آیا Relationship و Path، بخش اصلی مدل و Workload ماست و آیا یک موتور گراف روی Dataset و Query واقعی، SLO و هزینه بهتری می‌دهد؟

پایگاه داده گراف برای داده‌های متصل ابزار قدرتمندی است، نه جایگزین عمومی دیتابیس رابطه‌ای. این راهنما Property graph و RDF را تفکیک می‌کند، از Query و Integrity به مدل می‌رسد، Cypher/GQL/Gremlin/SPARQL را مرزبندی می‌کند و انتخاب، Pilot، عملیات و مهاجرت را مرحله‌به‌مرحله می‌سازد. برای مقایسه کل خانواده‌های SQL، Document، Key-value، Distributed و Vector ابتدا مقاله انتخاب پایگاه داده وب را ببینید؛ این صفحه مالک Graph workload است.

پایگاه داده گراف چیست؟

Graph database داده و رابطه را در مدلی ذخیره و Query می‌کند که Path، Neighborhood و Pattern مفاهیم درجه‌اول‌اند. دو خانواده مهم:

این دو قابل تقلیل به «نود و یال» هستند اما Semantics، Identity، Schema، Reasoning، Query و ابزار متفاوت دارند. موتور یا سرویس خاص ممکن است یکی یا هر دو را پشتیبانی کند؛ Dataset آن‌ها لزوماً با زبان دیگر قابل Query نیست. مستند Amazon Neptune مثلاً صریح می‌گوید داده Property graph بارگذاری‌شده برای openCypher با RDF/SPARQL یک مدل واحد قابل‌تعویض نیست.

Graph database، GraphQL و Graph analytics یکی نیستند

• Graph database: موتور ذخیره/Query/Transaction داده گراف.
• GraphQL: زبان و Runtime API برای درخواست Shape داده؛ Backend می‌تواند SQL یا هر Storage باشد.
• Graph analytics: الگوریتم‌هایی مثل centrality، community یا path روی Graph؛ ممکن است Batch/OLAP باشد.
• Knowledge graph: مدل Entity/Relation با Governance و گاهی Ontology؛ الزاماً محصول خاصی نیست.
• Graph visualization: نمایش تعاملی؛ Storage یا Query engine نیست.

API GraphQL به این دلیل Graph database نمی‌خواهد که نام هر دو «Graph» است. همچنین داشتن Graph DB به‌تنهایی Knowledge graph معتبر یا GraphRAG grounded نمی‌سازد.

چه زمانی Graph fit قوی است؟

از Query portfolio آغاز کنید. Graph fit زمانی قوی‌تر می‌شود که چند ویژگی هم‌زمان حاضر باشند:

• Relationship و Path پاسخ اصلی‌اند، نه فقط فیلتر جانبی؛
• Traversal چندمرحله‌ای یا Pattern ترکیبی پرتکرار و متغیر است؛
• مدل Relationshipها سریع‌تر از Schema جدولی تغییر می‌کند؛
• Explainability مسیر—این حساب از طریق کدام دستگاه متصل است—لازم است؛
• Latency تعاملی برای Neighborhood/Path روی Graph واقعی اهمیت دارد؛
• تیم می‌تواند Integrity، Security و عملیات موتور دوم را مالک شود.

چه زمانی SQL انتخاب بهتری است؟

دیتابیس رابطه‌ای برای Transaction، Constraint، Aggregate، گزارش و Joinهای خوب‌مدل‌شده بسیار قوی است. PostgreSQL جاری با WITH RECURSIVE hierarchy/graph traversal، ترتیب Depth/Breadth و Cycle detection را پشتیبانی می‌کند. اگر Path کم‌عمق و ثابت، Dataset کوچک/متوسط، Aggregate غالب یا تیم/عملیات SQL بالغ است، Graph engine ممکن است فقط پیچیدگی اضافه کند.

Join عمیق الزاماً «نمایی» نیست و Graph traversal نیز ثابت نمی‌ماند. Selectivity، Degree، Path explosion، Index، Cache، Distribution و Query plan تعیین‌کننده‌اند.

Index-free adjacency؛ ویژگی همگانی یا تضمین O(۱) نیست

برخی Native graph engines رابطه را طوری نگه می‌دارند که از Node به Relationship مجاور حرکت مستقیم باشد؛ اصطلاح Index-free adjacency به این ایده اشاره دارد. اما پیاده‌سازی Vendor، Storage layout، Partition، Remote hop و Index متفاوت است. حتی اگر هر Hop محلی ارزان باشد، تعداد مسیرهای ممکن می‌تواند با Branching factor رشد شدیدی کند.

Approximate traversal work ≈ visited nodes + traversed relationships
Path candidates can grow with degree^depth unless bounded/pruned

عبارت «میلیون‌ها نود در میلی‌ثانیه» یا «سرعت ثابت با رشد حجم» بدون Dataset، Query، Hardware، Cache و Percentile بی‌معناست.

از Query contract به مدل گراف برسید

ابتدا پنج تا ده Query بحرانی، SLO و Output توضیح‌پذیر را ثبت کنید:

Decision: آیا سفارش برای بررسی دستی نگه داشته شود؟
Pattern: Customer→Device←Customer→Card←Customer
Depth: max 4 hops
Window: edges active in last 30 days
Filter: verified device, exclude shared corporate NAT
Output: risk score + path + reason codes
SLO: p95 under 150 ms at 80 QPS
Freshness: under 2 minutes
Guardrail: false-positive review rate

مدل باید به این Queryها پاسخ دهد؛ «هر اسم را Node و هر فعل را Edge کنیم» طراحی نیست.

Property graph: Node، Relationship، Label و Property

در بازارگاه فرضی:

• Nodeها: Customer، Order، Device، CardToken، Address، Seller؛
• Relationshipها: PLACED، USED_DEVICE، PAID_WITH، SHIPPED_TO، SOLD_BY؛
• Propertyهای رابطه: first_seen، last_seen، count، source، confidence.

Direction را بر اساس خوانایی Query و Semantics تعریف کنید؛ داده را بی‌دلیل در هر دو جهت Duplicate نکنید. Entityهای حساس مانند کارت را Tokenize کنید و Raw PAN، رمز یا PII غیرضروری وارد Graph نکنید.

Identity و Edge provenance؛ رابطه هم یک ادعاست

«دو حساب یک دستگاه دارند» ممکن است از Login معتبر، Cookie، IP مشترک یا Fingerprint احتمالی آمده باشد؛ این‌ها یک Confidence و Purpose ندارند. Edge باید Source، Method، Timestamp، Confidence، Expiry و Policy داشته باشد.

Edge احتمالی را به Fact قطعی تبدیل نکنید. مسیر توضیح باید Provenance را برگرداند و تصمیم پرریسک Human review/Appeal داشته باشد.

Constraints و Indexes؛ Schema-less یعنی Rule-less نیست

Graph انعطاف‌پذیر می‌تواند Label، Type و Property تازه بپذیرد، اما Production به Contract نیاز دارد: Unique ID، existence/type، cardinality، allowed relationship، temporal rule و ownership. مستند Neo4j نیز استفاده از Constraint و Index را در مدل با Schema باز توصیه می‌کند و انواع Range، Text، Full-text، Point، Lookup و Vector index را جدا می‌سازد.

// Example Cypher-style constraints/indexes; verify syntax for your engine/version
CREATE CONSTRAINT customer_id_unique
FOR (c:Customer) REQUIRE c.id IS UNIQUE;

CREATE INDEX order_created_at
FOR (o:Order) ON (o.created_at);

Index برای Anchor کردن Traversal و فیلتر Property مهم است؛ Edge traversal جای همه Indexها را نمی‌گیرد.

Cypher و GQL؛ از Pattern به Query اعلامی

GQL با استاندارد ISO/IEC ۳۹۰۷۵:۲۰۲۴ نخستین زبان استاندارد ISO برای Property graph است. Cypher از Semantics الگوی MATCH/RETURN سهم زیادی با GQL دارد، اما یکسان فرض‌کردن آن‌ها خطاست. مستند جاری Neo4j در ۲۰۲۶ اعلام می‌کند Cypher ۲۵ بیشتر Mandatory featureهای GQL را پشتیبانی می‌کند و هم‌زمان فهرست تفاوت‌ها/موارد پشتیبانی‌نشده را منتشر کرده است.

MATCH p = (c:Customer {id: $customerId})
          -[:USED_DEVICE|PAID_WITH*1..4]-(related:Customer)
WHERE related.id  c.id
RETURN related.id, p
LIMIT 50;

این مثال آموزشی است: Variable-length pattern بدون Bound، Selective anchor و Limit می‌تواند Path explosion بسازد. Parameter استفاده کنید؛ Query string را از ورودی کاربر Concatenate نکنید.

Gremlin؛ Traversal قابل ترکیب با تفاوت Provider

Gremlin زبان Traversal پروژه Apache TinkerPop برای Graphهای Property است و روی OLTP/OLAP استفاده می‌شود. مستند TinkerPop ۳.۸.۱ جاری تأکید می‌کند Syntax کلی قابل حمل است، اما Capability و محدودیت Providerها متفاوت می‌ماند. عبارت «Gremlin را بلدیم، پس موتور قابل تعویض است» بدون Compatibility test درست نیست.

g.V().has('Customer','id',customerId)
 .repeat(both('USED_DEVICE','PAID_WITH').simplePath())
 .times(4)
 .hasLabel('Customer')
 .dedup()
 .limit(50)

Step support، Transaction، Cardinality، ID، Lambda، Index و Serialization را برای Provider منتخب بسنجید.

RDF و SPARQL؛ وقتی Semantics و Linked data مهم‌اند

RDF گزاره را به Triple/Quad تبدیل می‌کند و URIها Identity مشترک می‌سازند. SPARQL برای Pattern query روی RDF dataset است. Ontology/Reasoning و Named graph می‌توانند Provenance و دانش بین‌سامانه‌ای را مدل کنند، اما هزینه Modeling، Vocabulary governance و Query tuning دارند.

PREFIX ex: <https://example.ir/schema/>
SELECT ?product ?category WHERE {
  ?product ex:belongsTo+ ?category .
  ?category a ex:Category .
}
LIMIT 100

برای Knowledge graph، ابتدا Entity identity، Vocabulary، Source و Update policy را حل کنید. «Graph برای SEO معنایی» به‌تنهایی رتبه یا Knowledge Panel نمی‌سازد؛ Structured data عمومی باید با محتوای قابل مشاهده و سیاست Search سازگار باشد.

چهار Use case با معیار پذیرش

Fraud ring و Entity network

ارزش: کشف مسیرهای Device/Card/Address و Explainability. معیار: Precision/recall در Gold set، p95 Query، review load و false decline. IP مشترک به‌تنهایی Edge هویتی قوی نیست.

Recommendation و Similarity

Graph می‌تواند Candidateهای رابطه‌ای بسازد؛ Ranker ممکن است قواعد، Feature و مدل دیگر داشته باشد. معیار: Eligible coverage، latency، diversity، incremental contribution و return guardrail. مقاله بیگ دیتا در فروشگاه اینترنتی Data Product و Experiment پیشنهاد را پوشش می‌دهد.

Authorization و Entitlement

مدل User→Group→Role→Resource می‌تواند «چرا این دسترسی وجود دارد؟» را پاسخ دهد. اما Authorization درخواستی نباید با Graph قدیمی یا Fail-open اجرا شود. معیار: freshness، deny precedence، cycle policy، p99 و audit explain path.

Dependency و Impact analysis

Service→API→Queue→Database→Owner برای Blast radius و Change impact مفید است. Graph باید از Discovery/CMDB/Deployment feed به‌روز شود؛ نقشه دستی کهنه برای Incident خطرناک است. معیار: coverage، staleness، owner completeness و incident usefulness.

Supernode و Path explosion را طراحی کنید

Node پرDegree مانند IP اپراتور موبایل، Category عمومی یا حساب بانکی واسط می‌تواند Traversal را منفجر و False association بسازد. راهکار تابع Semantics است:

• Bound روی Depth، Time window و Relationship type؛
• Selective Anchor و Predicate pushdown؛
• Degree cap یا Hub classification با دلیل؛
• Precomputed projection/materialized relationship برای Query داغ؛
• Timeout، memory/result budget و pagination؛
• جداکردن OLTP lookup از OLAP graph algorithm.

حذف همه Hubها نیز می‌تواند Signal واقعی را از بین ببرد؛ Policy باید Test و Version شود.

Transaction و Consistency؛ واژه ACID کافی نیست

بررسی کنید Transaction چه Scopeای دارد، Cluster چه Consistency می‌دهد، Read-your-writes چگونه است، Conflict/Retry چه Semanticsی دارد و Constraint چه زمانی اعمال می‌شود. برای Fraud تصمیم لحظه‌ای، Edge با تأخیر می‌تواند نتیجه را عوض کند؛ برای Recommendation شاید Eventual consistency قابل قبول باشد.

Consistency contract:
source event time | ingest time | graph commit time | query as-of time
duplicate policy | ordering | retry/idempotency | late-event handling
read consistency | stale tolerance | reconciliation cadence

Polyglot persistence؛ Source of truth را دو بار نسازید

معمولاً Order، Payment و Ledger در Relational source باقی می‌مانند و Graph Projection برای Relationship query ساخته می‌شود. Dual write مستقیم از Application به دو Database احتمال Drift می‌سازد. Outbox/CDC/Event pipeline با Idempotent consumer و Reconciliation قابل کنترل‌تر است.

Relational transaction + outbox
        ↓ CDC/event bus
Graph projector (idempotent, versioned)
        ↓
Graph read model
        ↓
lag/completeness/reconciliation monitoring

برای Outbox، Ordering، Retry، Saga و عملیات، مقاله معماری Event-Driven مرجع مکمل است.

Backfill، Rebuild و Schema evolution

Graph Projection باید از Source قابل بازسازی باشد. Pipeline را برای Snapshot+CDC gap، Resume، Duplicate، Tombstone، Relationship rename و Version هم‌زمان طراحی کنید. Migration گراف معمولاً فقط Import CSV نیست؛ Query و Consumerها نیز به Label/Type وابسته‌اند.

API و Query safety

کاربر نباید Traversal نامحدود اجرا کند. Queryهای محصول را Allowlist/Template کنید؛ Parameter، Max depth، Result limit، Timeout، Cost budget و Rate limit داشته باشید. Authorization باید پیش از Return و برای Node/Edge/Property حساس اعمال شود. Error نباید Query، Secret یا Topology را افشا کند.

Graph endpoint نیز API است: Authentication، authorization، injection، pagination، version، audit و abuse controls می‌خواهد. راهنمای امنیت API با OWASP، OAuth و JWT لایه عمومی کنترل را تکمیل می‌کند.

امنیت و Privacy؛ Relationshipها می‌توانند حساس‌تر از Node باشند

رابطه «این فرد از این کلینیک خدمت گرفته» یا «این حساب با آن آدرس/دستگاه مرتبط است» حتی بدون Property زیاد حساس است. Threat model باید inference، enumeration، graph scraping، path leakage، insider access و re-identification را ببیند.

• Purpose و حداقل Edge/Property لازم؛
• Role/attribute-based access و Tenant isolation؛
• Encryption، Secret rotation و private network؛
• Query/security log بدون PII اضافی؛
• Retention/expiry برای Edgeهای احتمالی؛
• Deletion/Correction در Projection و Backup؛
• Human review و Appeal برای تصمیم پراثر.

Benchmark؛ موتور را با Query واقعی مقایسه کنید

Benchmark Vendor یا Dataset کوچک نتیجه شما نیست. دو Implementation حداقلی—SQL baseline و Graph candidate—را با داده Shape واقعی بسازید:

Query plan، cardinality estimate و Index hit را ذخیره کنید. Average latency Tail و timeout را پنهان می‌کند. Failure injection و Recovery نیز بخشی از Benchmark است.

مقیاس‌پذیری: Partition کردن Graph رایگان نیست

Graphهای متصل Boundary طبیعی کمی دارند؛ Cross-partition traversal می‌تواند Network hop و Coordination ایجاد کند. Vendor ممکن است Read replica، sharding، fabric/federation یا distributed analytics ارائه کند، اما Semantics و Limit متفاوت‌اند. Query locality، tenant/region partition، supernode، write hotspot و resharding را در Pilot بسنجید.

«میلیارد رابطه با latency میلی‌ثانیه» در مستند یک سرویس Claim همان سرویس و Configuration است؛ جای Acceptance test شما نیست.

Observability: از Query تا Projection lag

Service: request rate, p95/p99, timeout, error, saturation
Database: active tx, lock/conflict, heap/GC, page cache, disk, replication
Query: fingerprint, plan change, rows/paths expanded, memory, retries
Pipeline: source lag, consumer lag, DLQ, duplicate, reconciliation gap
Data: node/edge count, orphan, invalid type, supernode, stale edge
Business: review precision, recommendation outcome, access decision

Alert باید Materiality و Runbook داشته باشد. مقاله Observability و مانیتورینگ Signal، SLO و Incident workflow را شرح می‌دهد.

Backup، Restore و Disaster recovery

Backup موفق مساوی Restore موفق نیست. RPO/RTO، Consistent backup، encryption، retention، cross-region/account copy، نسخه موتور، extension و schema/index را ثبت کنید. Restore drill باید Queryهای Golden، Node/edge count، Constraint، Permission و Projection offset را تأیید کند.

DR acceptance:
restore target version → apply config/security → verify constraints/indexes
→ reconcile source watermark → replay missing events → golden-query diff
→ switch read traffic → observe → rollback path

تست: Query correctness تا End-to-End

• Model/unit: fixture کوچک با Path/Direction/Cycle/Temporal edge؛
• Property-based: invariant مانند نبود duplicate canonical ID؛
• Integration: driver، transaction، retry، timeout، auth؛
• Contract: event→projection و API response؛
• Golden query: مسیر و Reason code مورد انتظار؛
• Performance: degree skew، supernode، concurrent read/write؛
• Failure: network cut، leader change، DLQ، restore؛
• Security: injection، tenant escape، enumeration و audit.

راهنمای استراتژی تست وب‌اپلیکیشن Portfolio و Release gate را تکمیل می‌کند.

Snapshot ابزار و زبان‌ها در ۱۲ اوت ۲۰۲۶

این جدول رتبه‌بندی «بهترین» نیست. Edition، License، Region، SLA، Query compatibility، Backup، Security، Support، Cost و دسترسی ایران باید با Snapshot قرارداد و Pilot بررسی شوند. استاندارد GQL نیز به معنی Portability کامل Productها در امروز نیست.

نقشه مهاجرت ۳۰روزه

روزهای ۱ تا ۷: تصمیم و Baseline

• Query portfolio، SLO، Dataset shape و Decision owner؛
• SQL/سیستم فعلی Baseline با Plan و Cost؛
• Data classification، source of truth و Threat model؛
• Knockoutهای Consistency، Region، License، Export و Skill.

روزهای ۸ تا ۱۸: Vertical slice

• مدل کوچک بر اساس Query؛ Constraint/Index؛
• Snapshot+CDC projector با Idempotency؛
• سه Golden query و API محدود؛
• Benchmark cold/warm/scale/skew و Failure test.

روزهای ۱۹ تا ۳۰: Shadow و Go/No-go

• Shadow read و Diff نتیجه/Latency؛
• Reconciliation، Privacy/Security و DR drill؛
• TCO شامل تیم، Infra، License، Egress و On-call؛
• Go، Conditional go، Simplify یا No-go با Evidence.

چک‌لیست Production readiness

• Graph fit با Query/Path/SLO واقعی، نه Demo، ثبت شده است.
• Property graph یا RDF و Semantics انتخاب روشن است.
• Node/Edge/Direction/Property و Identity/Provenance Version دارند.
• Constraint، Index، Cardinality و Supernode policy آزموده شده‌اند.
• Source of truth، CDC/Outbox، Idempotency و Rebuild تعریف شده‌اند.
• Consistency/freshness/late event و read semantics قرارداد دارند.
• Queryها Parameterized و دارای depth/result/time/cost budget هستند.
• Tenant/role/property/path access و Privacy lifecycle تست شده‌اند.
• p50/p95/p99، throughput، skew، cache و cost در Benchmark ثبت شده‌اند.
• Metrics/alerts/runbook، Backup/Restore، RPO/RTO و rollback عملی‌اند.

منابع معتبر برای ادامه مطالعه

• ISO/IEC 39075:2024 — GQL — استاندارد بین‌المللی زبان Query گراف.
• Neo4j Cypher Manual: GQL conformance — Snapshot جاری پشتیبانی و تفاوت Cypher/GQL.
• Apache TinkerPop Reference — Gremlin و تفاوت Capability Providerها.
• Amazon Neptune: Graph database concepts — Property graph/RDF و زبان‌های پشتیبانی‌شده در یک سرویس Managed.
• PostgreSQL 18: Recursive WITH — Baseline رسمی Recursive query، Search و Cycle detection در SQL.

سؤالات متداول

تفاوت اصلی Graph database و SQL چیست؟

Graph، Pattern/Path/Relationship را درجه‌اول مدل و Query می‌کند؛ Relational داده را در Relation/Table با Constraint و Join نگه می‌دارد. هر دو می‌توانند رابطه را پاسخ دهند. انتخاب به Query shape، SLO، Integrity، عملیات و Benchmark بستگی دارد.

آیا پایگاه داده گراف همیشه NoSQL است؟

Graph databaseها معمولاً در دسته NoSQL قرار می‌گیرند، اما GQL اکنون استاندارد ISO برای Property graph است و برخی دیتابیس‌های رابطه‌ای نیز قابلیت Graph/recursive query دارند. برچسب NoSQL برای انتخاب فنی کافی نیست.

Cypher، GQL، Gremlin و SPARQL چه تفاوتی دارند؟

GQL استاندارد ISO Property graph است؛ Cypher زبان اعلامی Patternمحور با هم‌پوشانی زیاد اما نه کامل با GQL؛ Gremlin زبان Traversal اکوسیستم TinkerPop؛ و SPARQL زبان Query برای RDF dataset است. Support دقیق را در نسخه/Provider منتخب بررسی کنید.

بهترین پایگاه داده گراف کدام است؟

بهترین عمومی وجود ندارد. مدل Property/RDF، Query/language، Consistency، Scale، Region، Security، Backup، License، Skill، هزینه و Portability را Knockout کنید و دو گزینه را با Vertical slice و Dataset واقعی مقایسه کنید.

چه زمانی نباید Graph database اضافه کنیم؟

وقتی Queryهای رابطه‌ای کم‌عمق و ثابت‌اند، Aggregate/Transaction غالب است، SQL baseline SLO را پاس می‌کند، داده و تیم کوچک‌اند یا سازمان توان اداره Storage دوم و Sync را ندارد. Graph visualization زیبا به‌تنهایی Use case نیست.

جمع‌بندی

پایگاه داده گراف زمانی می‌درخشد که سؤال محصول درباره Path، Pattern و Neighborhood باشد و مسیر پاسخ نیز بخشی از Evidence تصمیم شود. اما مزیت را باید با Query contract، Dataset shape و Benchmark نشان داد؛ نه با دشمن‌سازی SQL یا وعده سرعت ثابت. مدل Property/RDF، Identity و Provenance را روشن کنید، Constraint/Index و Query budget بگذارید، Source of truth را با Projection قابل بازسازی حفظ کنید و Security/DR/Observability را پیش از Cutover بسازید. اگر Graph candidate نتیجه و اقتصاد بهتری نداد، No-go یک تصمیم مهندسی موفق است.