Blog
스터디
Tech Dive
News Feed 전수 조사
SNS 피드 Graph Database

SNS 피드 추천을 위한 데이터베이스 선택

결론

사용자 간 연관관계 기반 피드 추천 시스템에는 그래프 데이터베이스가 가장 적합합니다. 구체적으로는 다음과 같이 선택할 수 있습니다:

Neo4j 공식 문서에서 "Graph databases can identify influential users in a network, recommend new connections (friendships, favorite content) based on commonalities between users" 라고 명시되어 있음.

Meta의 TAO 시스템은 "geographically distributed graph data abstraction to power the largest social graph" 으로, MySQL 기반 스토리지에 분산 캐싱 레이어를 조합한 구조입니다.

그래프 데이터베이스가 적합한 이유

효율적인 관계 탐색

그래프 데이터베이스는 사용자 간의 관계를 노드(사용자)와 엣지(관계)로 표현하여, 복잡한 다단계 관계 쿼리를 효율적으로 처리할 수 있습니다 NebulaGraph Social Networks (opens in a new tab).

"Graph databases are ideal for social networking systems where user relationships constantly change because they can support complex multi-hop queries and real-time writes and updates" 라고 명시되어 있음.

실시간 추천 기능

관계 기반 쿼리를 실시간으로 수행할 수 있어, 사용자의 현재 행동과 관심사를 즉시 반영한 추천이 가능합니다 47Billion Recommendation System (opens in a new tab).

"Relationship-based queries in real-time can be easily performed, we can quickly capture any new movies searched by users and interests shown in their current online visit" 이라고 설명되어 있음.

데이터베이스 옵션 비교

1. 그래프 데이터베이스 (Neo4j, NebulaGraph)

장점:

"While Neo4j is more time intensive to implement, its queries are less complex and have a faster runtime than comparable queries performed in PostgreSQL" 라고 명시되어 있음.

단점:

  • 초기 구축 시간과 학습 곡선
  • 일반적인 RDBMS 대비 운영 경험 부족

적용 사례:

Wadiz는 "각 사용자들의 연관 관계 분석을 위하여 GraphDB를 도입" 했다고 설명합니다.

2. 관계형 데이터베이스 (PostgreSQL)

장점:

  • 안정적이고 검증된 기술
  • 풍부한 운영 경험과 도구
  • 일반적인 데이터 관리에 유리

단점:

  • 복잡한 다단계 관계 쿼리 시 성능 저하
  • 그래프 순회 알고리즘 구현의 복잡성

적용 사례:

"Instagram relies on PostgreSQL for storing user data, photos, and comments due to its scalability and data integrity" 라고 명시되어 있음.

3. 하이브리드 접근

많은 대규모 서비스에서는 실제 데이터는 PostgreSQL에, 관계 데이터는 Neo4j에 저장하는 방식을 사용합니다 Stack Overflow Discussion (opens in a new tab).

Stack Overflow 토론에서 "save actual data (email, name, password, etc) in Postgres and save relationships in Neo4j when building recommendation engines" 라는 패턴이 언급됨.

대규모 서비스 아키텍처: Facebook TAO

Facebook(Meta)의 TAO는 대규모 소셜 그래프를 위한 참고 아키텍처입니다 TAO Architecture Analysis (opens in a new tab).

핵심 설계

데이터 모델:

  • Objects(노드): 사용자, 게시물, 댓글 등
  • Associations(엣지): 객체 간 관계

"Every data item, such as a user, check-in, or comment, is represented by a typed object containing a dictionary of named fields" 라고 명시되어 있음.

계층 구조:

  • 스토리지 레이어: MySQL에 데이터 영구 저장
  • 캐싱 레이어: Leader-Follower 구조의 분산 캐시

"The architecture of TAO contains two layers: the storage layer and the caching layer, with the storage layer persisting graph data in MySQL" 라고 설명되어 있음.

성능:

  • 초당 10억 건 이상의 읽기 요청 처리
  • 96.4% 캐시 히트율

"TAO handles over a billion read requests and millions of write requests every second" 이며 "the overall hit rate was 96.4% for read queries" 라고 명시되어 있음.

규모별 추천 전략

스타트업/소규모 (< 100만 사용자)

  • 추천: Neo4j 또는 NebulaGraph
  • 이유: 빠른 개발, 직관적인 쿼리, 충분한 성능

중규모 (100만~1000만 사용자)

  • 추천: 그래프 DB + Redis 캐싱
  • 대안: PostgreSQL + 인메모리 그래프 구조
  • 이유: 성능과 안정성의 균형

대규모 (1000만+ 사용자)

  • 추천: 하이브리드 아키텍처 (RDBMS + 분산 캐싱)
  • 참고: Facebook TAO, WeChat 아키텍처
  • 이유: 확장성과 안정성 우선

WeChat 사례

WeChat은 그래프 데이터베이스를 메인 컴포넌트로 사용하는 아키텍처를 구축했습니다 WeChat Graph Database (opens in a new tab).

"The WeChat team has come up with an architecture where a graph database is the main component of the solution" 이며, "The team generated SST files offline via scheduling Spark tasks, and storage nodes pull the data required and ingest the data to the graph database" 라고 설명되어 있음.

Neo4j 성능 및 확장성

QPS 및 성능 벤치마크

Neo4j의 성능은 하드웨어 구성, 쿼리 복잡도, 데이터 크기에 따라 크게 달라집니다 Neo4j Performance Tuning (opens in a new tab).

쓰기 성능:

  • 노드 생성: 약 37,497 nodes/second
  • 관계 생성: 약 37,488 relationships/second
  • 속성 생성: 약 120,345 properties/second

내부 클러스터 테스트에서 "achieved 37,497 nodes per second, 37,488 relationships per second, and 120,345 properties per second when loading data" 라고 명시되어 있음.

벌크 임포트:

"Neo4j 2.2's write performance delivered up to 100x higher transactional throughput with concurrent load, and bulk data import at over 1M records/second" 라고 명시되어 있음.

읽기 성능:

  • 단순 쿼리: 수백~수천 QPS (하드웨어 의존적)
  • 복잡한 그래프 순회: 수십~수백 QPS

Causal Clustering 아키텍처

Neo4j Enterprise는 Causal Clustering을 통해 고가용성과 확장성을 제공합니다 Neo4j Clustering Introduction (opens in a new tab).

핵심 구조:

  • Primary 서버: 읽기/쓰기 가능
  • Secondary 서버: 읽기 전용
  • Raft 프로토콜을 통한 트랜잭션 복제

"Database primaries achieve high availability by replicating all transactions using the Raft protocol" 라고 명시되어 있음.

확장 특성:

읽기 확장 (Scale-Out 가능):

  • Secondary 서버를 추가하여 읽기 워크로드 분산
  • 소수의 Primary에서 다수의 Secondary로 데이터 전파

"Database secondaries scale out read workloads, and many secondaries can be fed data from a relatively small number of primaries, allowing for a large fan out of the query workload for scale" 라고 명시되어 있음.

쓰기 확장 (수직 확장만 가능):

  • Raft에서 선출된 리더만 쓰기 가능
  • 쓰기 성능 향상을 위해서는 서버 스펙 업그레이드 필요

"Write scaling is vertical only, as only one node at a time (the elected leader) is allowed to write" 라고 명시되어 있음.

샤딩 제약 사항

전통적 샤딩 미지원:

  • 클러스터의 모든 노드가 전체 그래프 데이터를 보유해야 함
  • 그래프 데이터베이스에서 샤딩은 안티패턴으로 간주됨

"All nodes participating in the cluster must contain the entire graph" 이며 "Sharding is considered an anti-pattern for graph databases, as the best performance occurs when all data is available in memory on a single instance" 라고 명시되어 있음.

Neo4j Fabric (4.0+):

"Neo4j Fabric was introduced in January 2020 with Neo4j 4.0, allowing sharding of data across multiple shards (databases or clusters)" 라고 명시되어 있음.

최소 클러스터 구성

고가용성을 위한 최소 구성은 3개의 Core 서버입니다 Neo4j Cluster Sizing (opens in a new tab).

"At minimum, an application will use three core servers to be considered fault-tolerant - if one of the three servers fails, the cluster is still operable for updates" 라고 명시되어 있음.

NebulaGraph 성능 및 확장성

QPS 및 성능 벤치마크

NebulaGraph는 대규모 분산 환경에 최적화된 고성능 그래프 데이터베이스입니다 NebulaGraph Overview (opens in a new tab).

쓰기 성능 (Meituan 벤치마크):

  • Vertex 삽입: 84,000 QPS
  • Edge 삽입: 76,000 QPS

Meituan 벤치마크에서 "NebulaGraph achieved 84,000 QPS for inserting vertices and 76,000 QPS for inserting edges, significantly outperforming competitors (Dgraph: 10,138/9,600 QPS; HugeGraph: 410/457 QPS)" 라고 명시되어 있음.

읽기 성능:

"In throughput tests for one-hop queries, the largest throughput of Dgraph was only 11% of that of NebulaGraph" 라고 명시되어 있음.

최신 성능 개선 (v3.5.0):

"The performance of FIND ALL PATH queries improved approximately 50-500% across varying depths, with around 600% increase for 1 to 5 hops" 라고 명시되어 있음.

프로덕션 환경 성능

Snapchat 사례:

"NebulaGraph's sharded architecture allowed ingestion of 12TB graphs and real-time queries at p90 <20ms" 라고 명시되어 있음.

Meituan 프로덕션:

"Knowledge graph data size at Meituan can reach hundreds of billions of vertices and edges with throughput reaching tens of thousands of QPS" 라고 명시되어 있음.

Shared-Nothing 분산 아키텍처

NebulaGraph는 선형 확장성을 제공하는 완전 분산 아키텍처를 가지고 있습니다 NebulaGraph Architecture (opens in a new tab).

아키텍처 계층:

  • Graph Service: 쿼리 처리 및 최적화
  • Storage Service: 분산 데이터 저장 및 복제
  • Meta Service: 메타데이터 및 클러스터 관리

"NebulaGraph has a shared-nothing distributed architecture that offers linear scalability, allowing you to add more nodes or services to the cluster without affecting performance" 라고 명시되어 있음.

레이어 분리의 장점:

  • Graph Service와 Storage Service를 독립적으로 확장 가능
  • 워크로드에 따라 각 레이어를 유연하게 스케일링

"The separated structure makes both the Graph Service and the Storage Service flexible and easy to scale in or out" 라고 명시되어 있음.

Scale-Out 메커니즘

Multi Group Raft 프로토콜:

  • Raft 프로토콜에 따라 Multi Group Raft 구현
  • 각 파티션의 모든 복제본을 하나의 Raft 그룹에 저장
  • Leader 1개와 여러 Follower로 구성되어 강력한 일관성 보장 NebulaGraph Storage Service (opens in a new tab)

"The Storage Service supports a distributed cluster architecture, implementing Multi Group Raft according to Raft protocol" 라고 명시되어 있음.

수평 확장 방법:

  • BALANCE DATA: 기존 서버에서 신규 서버로 데이터 마이그레이션
  • BALANCE LEADER: 리더 파티션만 재분배 (데이터 이동 없음)

"The storage service can be scaled in or out horizontally using BALANCE commands - BALANCE DATA migrates data from old machines to new machines, while BALANCE LEADER only changes the distribution of leader partitions" 라고 명시되어 있음.

데이터 마이그레이션:

"Data migration can take hours or even days, but NebulaGraph online services are not affected during migration" 라고 명시되어 있음.

데이터 샤딩 전략

정적 Hash 샤딩:

"NebulaGraph uses a static Hash strategy to shard data through a modulo operation on vertex ID, placing all out-keys, in-keys, and tag data in the same partition to increase query efficiency dramatically" 라고 명시되어 있음.

파티션 설계 시 주의사항:

  • 파티션 수는 그래프 스페이스 생성 시 결정되며 변경 불가
  • 향후 확장을 고려한 충분한 파티션 수 설정 필요

"The partition number must meet the need to scale-out in the future. However, the number of partitions needs to be determined when creating a graph space and cannot be changed afterward" 라고 명시되어 있음.

확장성 목표

NebulaGraph는 수조 개의 엣지와 버텍스를 저장하고 처리할 수 있는 유일한 오픈소스 그래프 데이터베이스입니다 NebulaGraph Homepage (opens in a new tab).

"NebulaGraph is the only open source graph database that can store and process graphs with trillions of edges and vertices" 라고 명시되어 있음.

성능 비교 요약

학술 연구 결과 (2023)

Applied Sciences 저널에 발표된 연구에서는 Neo4j가 전반적으로 가장 우수한 성능을 보였습니다 Academic Comparison Study (opens in a new tab).

"Neo4j was the graph database with the best performance across all metrics, including query execution time, node loading time, and RAM/CPU usage" 라고 명시되어 있음.

대규모 벤치마크 결과

소규모 데이터셋:

  • Neo4j가 데이터 임포트에서 NebulaGraph보다 빠름

대규모 데이터셋:

"NebulaGraph is a bit slower than Neo4j when the data size is small, however, when the data size is large, NebulaGraph is much faster than the other two" 라고 명시되어 있음.

그래프 쿼리 성능:

  • 3가지 그래프 쿼리 테스트에서 NebulaGraph가 Neo4j와 HugeGraph 대비 명확히 우수한 성능

"For the three graph queries tested, Nebula Graph shows clearly better performance compared to Neo4j and HugeGraph" 라고 명시되어 있음.

선택 기준

기준Neo4jNebulaGraph
소규모 데이터더 나은 전반적 성능약간 느린 임포트
대규모 데이터확장성 제한훨씬 빠른 처리
읽기 확장Secondary 서버로 가능완전한 수평 확장
쓰기 확장수직 확장만 가능수평 확장 가능
샤딩Fabric 필요 (4.0+)네이티브 지원
클러스터 구성전체 데이터 복제파티션별 복제
운영 성숙도높음 (오래된 기술)중간 (비교적 신생)

실제 대규모 참고 사례

LinkedIn LIquid:

"LinkedIn built LIquid, a graph database serving a ~15TB graph at ~2M QPS (2 million queries per second)" 라고 명시되어 있음.

이는 대규모 소셜 그래프 시스템이 도달할 수 있는 성능 벤치마크를 보여줍니다.

대안: PostgreSQL 그래프 확장

PostgreSQL을 계속 사용하고 싶다면 다음 옵션을 고려할 수 있습니다:

  • Recursive CTE: 관계 탐색 쿼리 작성 가능 (성능 제한 있음)
  • Apache AGE: PostgreSQL용 그래프 확장
  • ltree 확장: 계층적 데이터 처리

다만 전용 그래프 DB 대비 성능과 개발 편의성이 떨어질 수 있습니다 PostgreSQL vs Neo4j Performance (opens in a new tab).

출처

기본 정보

Neo4j 성능 및 확장성

NebulaGraph 성능 및 확장성

성능 비교

SNS 피드 인프라 아키텍처Facebook TAO Graph