프로젝트를 위한 DB선정

특정시간에 자신에게 푸쉬알람을 보내주는 서비스이다.

푸쉬 알람 항목은 자신이 화면상에서 선정 가능하다. 이 푸쉬 알람 항목들은 모듈화 되어있고, 각 모듈은 사용자가 자율적으로 등록 할 수 있다. 각 모듈에 필요한 정보는 크롤링 URI, 및 html 태그정보이다.

서버에서는 이렇게 사용자들이 모듈로 등록한 정보들을 주기적으로 크롤링해와서 DB에 저장해서 최신상태를 유지한다. 각 사용자가 설정한 시간대에 설정한 데이터들을 꺼내 사용자에게 푸쉬해준다.

RDBMS VS NoSQL

기본적으로 유저들의 정보도 포함이 되지만, 프로젝트에서 가장 크게 다루는 데이터는 게시글 등록자가 선정한 URI + 태그를 크롤링한 비정형 웹 데이터들이다.

또한 크롤링한 데이터의 write, update, select쿼리가 빈번하게 발생한다. 서비스의 확장시 다양한 종류의 데이터에서 빠르게 원하는 데이터를 찾는 쿼리의 성능도 중요하다.

비정형화된 데이터 : 크롤링한 데이터의 칼럼수가 다양하다. 데이터 칼럼의 항목수, 데이터 종류를 게시글 등록자가 설정하기 때문에 이를 한 테이블에 같은 스키마로 담기가 어렵다. -> 스키마를 정의하지 않고 데이터를 JSON형태로 저장하는 NoSQL사용 권장

이미 저장된 데이터의 가변성 : 게시글 등록자의 크롤링할 칼럼 변경, 크롤링 타겟의 구조 변경등으로 이미 저장된 row에 변경된 구조의 데이터가 update로 들어가야 하는경우 발생. -> RDBMS사용이 어려움 , NoSQL사용

한테이블에 모든 크롤링 정보가 들어감 : 모든 게시글 등록자가 선정한 정보는 같은 hierarchy의 데이터로써 RDMBS로 구현할 경우 한 테이블에 들어갈 정보이다. -> 따라서 scale-out이 용이한 NoSQL사용.

NoSQL의 단점 고려 : 복잡한 데이터 쿼리나, 데이터 일관성등의 보장은 해당 서비스에서 크게 필요한 요소가 아니기에 NoSQL를 쓰지 않아야할 이유가 없다.

결론

NoSQL을 사용한다.

서비스 특성상 가장 많이 실행될 기능인 읽기기능에 대한 성능표이다.

출처 : NoSQL Performance Benchmarks

아파치 카산드라가 전구간에서 가장 좋은 성능을 보인다. 이러한 성능 차이가 다른 글에서도 똑같이 보이고 있으므로 카산드라의 성능에 대한 신뢰도가 매우 높아보인다.

또한 write기능이 포함된 실험에서도 카산드라가 가장 높은 성능을 보여준다.

Cassandra

슈퍼칼럼의 인덱싱을 2차까지만 지원하고 그 미만은 지원하지 않는다.

HBase

트랜잭션 지원 : 데이터 일관성을 보장

MongoDB

~~데이터 write시에 데이터베이스 단위의 락을 사용함~~ 현재는 해결된 문제

데이터의 무결성이나, depth가 깊은 데이터의 저장(다중 인덱싱)이 크게중요한 서비스가 아니기때문에 이 단점을 write성능의 큰 차이로 극복하는 Cassandra 를 db로 선정하였다.

참고자료 :

Cassandra는 도커 이미지에 대한 자료도 많이 없어서 몇시간을 벌써 해멨다. 이러다가 개발도 못할상황이 발생할것 같다.

MongoDB로 먼저 빠르게 개발을 하자.