JK
>読み込み中 // 読み込み中
ビューを初期化中
完了goneo4jmemgraphtigergraphdocker
グラフデータベース性能ベンチマーク
グラフDBとRDBMS間における探索速度、メモリ消費、クエリ効率を多角的に検証した分析基盤。
課題と解決策
多層ソーシャルグラフや推薦機能において、どのデータストアが最適であるかを客観的データに基づき選定すること。
機能
- 深さごとの探索自動ベンチマークスイート
- レイテンシパーセンタイル（p50, p95, p99）の詳細比較
- メモリ使用量およびCPU負荷の可視化
- Dockerによる完全再現可能な検証環境
技術スタック
| 技術 | バージョン | 目的 | 採用理由 |
|---|---|---|---|
| Go | 1.25.1 | Primary language | Strong concurrency primitives, fast compilation, good driver ecosystem |
| neo4j-go-driver/v6 | v6.2.0 | Bolt protocol client for CognoDB, Neo4j, Memgraph | Official driver, supports Bolt 5.x, parameterized queries |
| go-echarts/v2 | v2.7.2 | HTML chart generation | Go-native, generates standalone HTML |
| godotenv | v1.5.1 | Environment configuration | Standard .env loading |
| net/http | stdlib | REST client for TigerGraph | No external dependency needed |
アーキテクチャ
Benchmark Engine
- Adapter pattern with common GraphDatabase interface (16 methods)
- 5 database adapters (4 active, FalkorDB disabled due to OOM)
- Sequential workload executor with warm-up and measured iterations
- Concurrent workload executor with N goroutines and sync.WaitGroup
- Factory function for adapter creation from configuration
CLI Pipeline
- 10 CLI entry points: benchmark, captest, charts, cleanup, dataset, load, runall, summary, verify, verify-load
- JSONL append-only result output for crash resilience
- CSV summary aggregation with percentile calculation
- HTML chart generation via go-echarts
- Pipeline automation via runall (verify → load → benchmark → report)
プロジェクト構成
cmd
benchmark
captest
charts
cleanup
dataset
load
runall
summary
verify
verify-load
internal
benchmark
concurrent.go
measurement.go
runner.go
safe.go
database
cognodb
memgraph
neo4j
tigergraph
types
factory.go
dataset
parser.go
APIエンドポイント
Query Workloads （ポート 0）
| メソッド | ルート | 目的 |
|---|---|---|
| Cypher | MATCH (n:Person {id: $id}) RETURN n.id AS id | Point lookup — single node by ID |
| Cypher | MATCH (n:Person {region: $val}) RETURN n.id AS id LIMIT 10 | Indexed lookup — nodes by region |
| Cypher | MATCH (n:Person {id: $id})-[:FRIEND]->(m:Person) RETURN collect(m.id) | 1-hop traversal — direct friends |
| Cypher | MATCH (n:Person {id: $id})-[:FRIEND]->()-[:FRIEND]->(m:Person) RETURN collect(DISTINCT m.id) | 2-hop traversal — friends of friends |
| Cypher | MATCH (n:Person {id: $id})-[:FRIEND]->()-[:FRIEND]->()-[:FRIEND]->(m:Person) RETURN collect(DISTINCT m.id) | 3-hop traversal — extended network |
| Cypher | MATCH (n:Person) RETURN n.region AS region, count(n) AS cnt ORDER BY cnt DESC LIMIT 10 | Aggregation — region distribution |
| Cypher | CREATE (n:Person {id: $id, region: $region, ...}) | Write — create new node |
データベース設計
Person (node label)
| カラム | 型 | 備考 |
|---|---|---|
| idPK | STRING | Unique constraint, indexed |
| region | STRING | Indexed |
| gender | STRING | Not indexed |
| age | STRING | Indexed (CognoDB, Neo4j, Memgraph only) |
| completion_percentage | STRING | Not indexed |
49,683 nodes extracted from SNAP soc-Pokec dataset. All properties are strings.
FRIEND (relationship type)
| カラム | 型 | 備考 |
|---|---|---|
| source_id | STRING | Person.id (from) |
| target_id | STRING | Person.id (to) |
100,000 directed relationships. No properties on edges. Many-to-many cardinality.
Directed graph: Person --[FRIEND]--> Person. Many-to-many via graph relationships (no junction table). Relationships are first-class citizens in the graph model.
主要な設計判断
Single Bolt Driver for 3 Databases
判断: Use neo4j-go-driver/v6 for CognoDB, Neo4j, and Memgraph
理由: All three support Bolt protocol; Cypher is logically equivalent
利点: Code reuse, consistent behavior across databases, adapter pattern isolates DB-specific behavior
トレードオフ: Cannot test database-specific optimizations; Memgraph has its own Go driver
MaxPoolSize = 1
判断: Single connection per benchmark run despite constant defining 10
理由: Measure single-connection latency; avoid connection pool effects
利点: Clean latency measurement without pool contention
トレードオフ: Doesn't test connection pooling behavior
JSONL for Raw Results
判断: One JSON object per line, append-only output
理由: Stream results without loading all into memory; easy to append across runs
利点: Resilient to crashes (partial results preserved)
トレードオフ: Requires full file scan for aggregation
No Retries on Measured Queries
判断: Zero retries for benchmark queries to capture true latency
理由: Network blips and failures are part of real-world performance
利点: Honest performance measurement including failure modes
トレードオフ: Network blips cause false negatives
Goroutine-Per-Client Concurrency
判断: Each concurrent client creates its own database connection
理由: Simulates real-world multi-client scenarios; avoids shared connection contention
利点: Realistic concurrency testing with independent connections
トレードオフ: Higher resource usage; connection limits become the bottleneck
MERGE for Idempotent Node Loading
判断: Use MERGE (upsert) instead of CREATE for node loading
理由: Makes loading idempotent — running multiple times doesn't create duplicates
利点: Safe re-runs, consistent dataset state
トレードオフ: MERGE is slightly slower than CREATE due to existence checks
テスト
None (no _test.go files)•ユニットテスト 0 件
テスト内容
- Capability test matrix (cmd/captest/) — tests all 8 workload types against all databases with small 10-node graph
- Connection verification (cmd/verify/) — tests basic connectivity and parameterized queries
- Data integrity verification (cmd/verify-load/) — verifies node/relationship counts (49,683 nodes, 100,000 relationships)
不足しているカバレッジ
- No unit tests for individual functions (_test.go files do not exist)
- No tests for statistical functions (percentile, mean, stddev calculation)
- No tests for CSV parsing edge cases (empty datasets, malformed CSVs)
- No tests for concurrent behavior
- No tests for chart generation correctness
- No test framework installed (no testify, gomock)
主な課題
- 異なるデータモデル間で公平かつ同一な負荷条件を再現すること
- 深層探索時におけるメモリ枯渇の防止
学んだこと
- ネイティブグラフエンジンとRDBMSの長所短所の実測比較
- 高負荷下におけるレイテンシパーセンタイルの測定手法