최근 NoSQL 관련 소식이 많이 들려서 나름 정리를 해보았다.

NoSQL이란?

• 정의: NoSQL은 비관계형 데이터 저장소로 고정된 테이블 스키마나 조인을 지원하지 않고 수평적 확장에 강하다. 학계에서는 구조적 저장소로 부르기도 한다.  구현 제품으로는 구글의 BigTable, 아마존의 Dynamo가 있고, 아파치 HBase, 페이스북의Cassandra등의 오픈소스 제품도 있다. ( NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees. These data stores may not require fixed table schemas, usually avoid join  operations and typically scale horizontally. Academics and papers typically refer to these databases as structured storage. Notable production implementations include Google’s BigTable and Amazon’s Dynamo, however there are also many publicly available open source variants including Apache HBase and Facebook’s Cassandra.) from 위키피디어
• NoSQL은 수평확장에 강하다. (strong network partition tolerance)
• 이미 많은 대형 사이트 솔루션이 ‘MySQL + Memcached’에서 NoSQL로 변화 중이다.

NoSQL 선택 기준

(참고: Visual Guide to NoSQL Systems)

CAP 선택

Visual Guide to NoSQL Systems from Nathan Hurst’s Blog

• Consistency: each client always has the same view of the data
• Availability: all clients can always read and write
• Partition tolerance: the system works well across physical network partitions

(참고: Brewer’s CAP Theorem CAP 중에서 2개만 얻을 수 있고 하나는 포기해야 한다는 이론)
ex) RDM (MySQL) = C + A, NoSQL (Cassandra) = A + P, BigTable = C + P

Data Model 선택

• Relational: RDBMS, support ACIDity
• Key-value: 키 기반의 get, put, delete 기능 제공
• Column-oriented: 테이블 기반이지만 조인 미지원, 컬럼기반 (not like row-oriented databases)
• Document-oriented: JSON, XML 형태의 구조적 문서 저장, 조인 미지원

NoSQL 적용 사례

Digg.com

• LAMP 기반에서 NoSQL 기반으로 구조 개편 (참고: Saying Yes to NoSQL; Going Steady with Cassandra)
• 상황
  • 끝이 안보이게 빠르게 증가하는 데이터 때문에 고성능, 쓰기 중심의 어플리케이션 구축이 어려움
  • 수평적, 수직적 확장 전략이 필요함
  • CAP에서 Consistency를 포기할 수 있는 상황 (digg 서비스 특징)
  • consistency는 어플리케이션 레벨에서 구현 가능
  • 복수의 데이터 센터 지원, 수정 작업 시 다운타임 없어야 함
• 오픈소스 Cassandra 선택
  • Cassandra? Dynamo 인프라 위에 BigTable 데이터 모델을 가지고 있는 분산 DB
  • 컬럼기반, 구조적 문서 저장 가능
  • 모든 노드가 개별적(identical)이고 데이터가 여러 노드와 데이터 센터간에 복제되어 안전
  • 수평확장할 경우 읽기, 쓰기 성능이 선형적으로 증가
  • 현재상황
    • full text 인덱싱, relational and graph 인덱싱 추가
    • Cassandra 성능 향상 (오픈소스 프로젝트 참가)
    • atomic counter 기능 추가 (Zookeeper 기반)
  • 그 이후의 자세한 내용 Looking to the future with Cassandra

digg.com 이외 대형 사이트

(참고: Building Scalable Databases: Are Relational Databases Compatible with Large Scale Websites?)

• Google: BigTable
• Amazon: Dynamo
• Linkedin: Project Voldemort
• 트위터도 Cassandra 사용 검토

Digg.com에서는 친구가 추천(digg)한 글을 표시해주기 위해 Cassandra를 선택한 것으로 판단된다.

대량의 데이터를 가공하여 개인화된 정보를 표시해줄 때 기존의 RDB + 캐싱 기법이 한계를 갖고 있는데, 이를 비정규화된 데이터를 분산된 서버에 저장하는 방식으로 해결한 것으로 보인다.

즉, 내가 어떤 글을 추천했을 때 내 친구들의 모든 리스트에 내 추천 기록을 저장해서 해당 글이 친구에 의해 추천받았다는 것을 각각의 사용자에게 보여줄 수 있게 되는 것이다.

이는 Daum view에서 내가 구독하는 사용자가 발행한 최신글, 인기글을 보여주거나, 추천 LIVE, 추천평 LIVE를 보여주는 것과 유사하다고 할 수 있는데,

재미있는 사실은 view에서는 전혀 다른 방식으로 이를 해결했다는 것이다.

view에서는 기존 MySQL 기반의 데이터 영역을 Lucene 기반의 검색엔진으로 상당부분 대체했고 서비스가 검색을 기반으로 발전하고 있다.

내가 5명의 블로거를 구독하고 있을 때 이들이 추천한 정보를 가져오기 위해서 SQL 쿼리를 MySQL로 요청하는 것이 아니라,

검색 쿼리를 Lucene으로 요청하게 된다.

예를 들어 RDB 쿼리가 다음과 같다면,

SELECT * FROM recommend_table r

JOIN user_mapping_table um ON r.userid = um.userid

ORDER BY r.id desc;

검색 쿼리가 다음과 같이 만들어 질 수 있다.

(daumid:id1 OR daumid:id2 OR daumid:id3 OR daumid:id4 OR daumid:id5) type:recent

만일 구독 글 안에서 검색을 하고 싶으면 검색엔진의 이점은 더욱 분명히 드러나게 된다.

SELECT * FROM recommend_table r

JOIN user_mapping_table um ON r.userid = um.userid

JOIN news_table n ON r.news_id = n.id

WHERE n.title like ‘%검색어%’ OR n.summary like ‘%검색어%’

ORDER BY r.id desc;

(daumid:id1 OR daumid:id2 OR daumid:id3 OR daumid:id4 OR daumid:id5) type:recent 검색어

물론 Lucene 기반의 데이터 영역이 가지는 구조적 단점이 있겠지만

현재까지는 이런 변화가 기존에 생각하지 못했던 서비스들을 만들어낼 수 있는 기술적 기반이 되었다고 할 수 있다.

그리고 view 서비스는 사용자의 추천 행위를 검색 랭킹에 반영할 수 있는 소셜 검색의 새로운 도전 무대라고 생각한다.

기존에 서비스 기획과 검색 기획이 별도로 진행됐다면 검색이 바로 서비스인 새로운 모습이 구현되고 있는 것이다.

사용자가 참여하는 서비스가 검색의 품질에 직접 기여하게 되고, 검색 랭킹의 영향으로 다시 사용자 참여를 이끌어내는 새로운 생태계가 만들어지기를 기대해 본다.

설날에 집안 정리를 하면서 소셜 검색에 대한 생각도 정리해 보았다.

최근 소셜 검색은 다시 새롭게 정의되고 있으며 한마디로 정의하기 힘든 영역이라 할 수 있다. 하지만 구글에서 시도한 실험들을 따라가다 보면 소셜검색의 실체가 드러난다.

1. 사용자가 컨텐츠를 평가

구글이 Digg.com을 인수하려는 시도를 하다 결국 자체적으로 구글 검색 결과에 대해 사용자가 직접 평가를 하는 시스템을 도입했다. 하지만 서비스 컨셉의 충돌로 의미있는 결과를 만들어내지 못한 것으로 알고 있다. 이를 통해 알 수 있는 것은 사용자 추천이 검색 결과에 잘  융합되지 못한다면 오히려 별도의 서비스로 사용자 추천을 수집하는 방식이 효과적이라는 것이다.

사용자 평가를 활용하면 범용적인 PageRank보다 더 의미있는 개인화된 랭킹, 그리고 사회적 환경에 따라 변하는 동적 랭킹을 제공하는 것이 가능할 것이다.  이를 위해서는 해당 컨텐츠를 누가 추천했는지 추천자를 분류하는 것이 중요하고 내가 신뢰할 수 있는 추천자의 역할이 중요해진다.

2. 소셜 네트워크 내에서의 검색

최근에 구글에서 발표한 소셜검색은 자신의 소셜 네트워크 안에서 검색을 해주는 기술이다. 내 친구가 작성한 블로그, 사진, 트위터 등을 모두 검색해주기 때문에 나름 의미가 있지만 이것만으로는 의미있는 가치를 만들어주지는 못할 것이다.

Daum과 같은 포털에서는 포털 내의 사용자가 생산한 컨텐츠 검색을 제공해 줄 수 있으나 오픈 플랫폼을 기반으로 외부 네트워크를 확장하고 컨텐츠를 확보해야만 진정한 소셜 검색이 될 수 있다고 생각한다.

3. 아이덴티티 통합

구글 버즈가 새로 오픈했는데 버즈의 가장 강력한 기능은 사용자의 아이덴티티를 묶어 주는데 있다. 구글은 이미 전세계의 모든 웹페이지를 인덱싱하고 있지만 각각의 글이 누구의 소유인지 추측만 할 뿐 정확히 알지 못한다. 그런데 구글 버즈를 통해 사용자들이 스스로 자신들의 트위터, 블로그, 플리커와 같은 웹에 흩어져 있는 자신의 아이덴티티를 묶어 주고 있는 상황이 되었다.

물론 구글은 이미 url 기반으로 모든 정보를 수집하고 있기 때문에 이런 통합된 아이덴티티를 기준으로 내 버즈를 쉽게 생성할 수 있고, 이 방식은 API를 활용한 FriendsFeed와는 전혀 다른 방식이며 비동기적으로 수집이 수행된다.

4. 관심별로 사용자 그룹핑

소셜 검색에서 사용자별로 개인화된 검색 결과를 보여주는 것은 기술적으로 불가능해 보일 수 있다. 하지만 이는 사용자 클러스터로 해결이 가능하다. Daum view에서는 이미 키워드 기반으로 사용자를 묶어주는 서비스를 준비하고 있으며, 사용자의 아이덴티티를 통합할 수 있다면 그 데이터를 기반으로 사용자의 관심을 알 수 있고, 이 관심을 기반으로 사용자를 분류할 수 있다.

또한 추천자도 이와 동일한 관심에 따라 분류됐을 때 개인에게 의미있는 컨텐츠를 찾아줄 수 있는 가능성이 커진다.  이런 세분화된 추천은 소셜 랭킹에 반영될 수 있는 중요한 요소이다. 즉, 내가 관계를 맺고 있는 사람들의 추천, 좀 더 넓은 의미로 내가 생성한 글들, 내가 구독하는 글들로 판단된 관심과 동일한 관심을 갖고 있는 사람들의 추천을 통해 그 사람이 원하는 정보를 찾아줄 수 있다면 이것이 새롭게 가치를 창조하는 미래의 소셜 검색이라고 할 수 있다.

참고: 소셜 검색 알고리듬 찾기