회원 데이터베이스를 어떻게 짜볼까?

하나의 서비스를 만들때 빼놓을 수 없는것은 바로 '데이터베이스'이다. 데이터베이스가 없다면 우리는 정보를 어떻게 저장하고 유지하고 분석할 수 있을까? 

 

이번 글에서는 어떤 서비스든 빼놓을 수 없는 '회원' 데이터베이스에 대해서 어떻게 짜는게 좋을지에 대해 글을 써보겠다.

그리고 겸해서 RDB와 NOSQL중에 어느 상황에서 선택하면 좋을지도 써보겠다.

 

Member Table

내가 보통 회원 데이터베이스를 설계할 때는 이러한 정보는 주로 넣는다. 

• Primary Key 용 id
• 로그인 아이디 (요새는 이메일을 로그인용 아이디로 쓴다.)
• 비밀번호
• 닉네임
• 권한 (ROLE)
• 생년월일
• 성별
• 핸드폰번호
• 가입일

 

어떤 테이블을 만들던 가장 고민하는 것은 "PK를 auto_increment로 두는게 가장 좋은 방식일까?" 이다. 

요즘은 auto_increment 대신 uuid 함수를 이용해 유저의 고유 식별 코드를 생성하는 경우도 있다고 하니 머릿속에 잠시 넣어보는것도 좋은거같다.

 

회원 데이터베이스 설계에 있어서 이 글을 읽어보는걸 강력히 추천한다. 데이터베이스 설계를 너무나도 잘해놨으며 로컬에서 간단하게 테이블 설계하는거와는 차원이 다르다. 많은 생각이 드는 글인거같다. 👍👍

 

 

RDB VS NoSQL

 

요즘은 NoSQL을 참 써보고싶은데 대체 어떤 상황에 적용해야하는지 잘 모르겠어서 결국 그나마 친숙한 RDB를 선택하고 말았는데 이 글을 빌미로 NoSQL을 적재적소에 사용할 수 있게 학습해야겠다.

 

RDB 란?

RDB는 관계형 데이터베이스로 RDBMS(데이터베이스 관리)로 생성하고 수정하고 관리한다. RDBMS는 SQL을 통해 관리된다.

관계형 데이터베이스는 사전에 엄격하게 정의된 DB Schema를 요구하는 table 기반 데이터 구조를 갖는다. 이러한 특징으로 인해 데이터 중복이 없다. 또한 중복이 없기 때문에 update가 많을 때 유리하다.

 

RDB 장점

• 명확한 데이터 구조 보장
• 데이터 중복 없이 한번만 저장 (무결성)
• 데이터 중복이 없기 때문에 UPDATE에 용이

RDB 단점

• 시스템이 커질경우 JOIN문이 많은 복잡한 Query를 작성
• 수평적 확장이 까다롭기에 비용이 큰 수직적 확장(Scale up)이 주로 사용된다.
  • 수직적 확장 : 서버의 사양을 올리는 확장
• 스키마 변경이 어렵다.

RDB 를 사용할 때

• 데이터 구조가 변경될 여지 없이 명확한 경우
• 데이터 UPDATE가 잦은 시스템

 

NoSQL 이란?

NoSQL은 비관계형 데이터베이스이다. RDB와 달리 table 형식이 아닌 비정형 데이터를 저장할 수 있도록 지원한다. 또한 NoSQL은 데이터 중복이 있을 수 있기에 update시에 여러 컬렉션에서 수정이 필요할 수 있기 때문에 update가 적고 조회가 많을 때 유리하다.

 

NoSQL의 다양한 데이터 표현 방식

Document 모델

• Document 모델은 레코드 하나를 오브젝트(도큐먼트) 형식으로 표현한다. 자유로운 스키마 구조를 가지며 구조가 확정되지 않은 데이터를 밀어넣고, 자유롭게 작업하기 좋다. MongoDB가 대표적 예시이다.

Graph 모델

• Graph 모델은 데이터를 Vertex와 Edge로 그래프에 표현하는 방식이다. 데이터 사이의 유기적인 관계를 표현하기에 적합하다. 

Key-Value 모델

• Key-Value 모델은 하나의 키에 값을 맵핑하는 해시 구조의 데이터 모델이다. 빠르게 데이터에 접근할 수 있는 장점이 있다. 대표적인 예로 Redis가 있다.

Wide-column 모델

• Wide-column 모델은 테이블 형태를 취하지만 행마다 갖는 컬럼의 형태가 고정되어 있지 않은 데이터 모델이다.

 

NoSQL 장점

• 유연하고 자유로운 데이터 구조
• 새로운 필드 추가 자유로움
• 수평적 확장 (Scale out) 용이
  • 수평적 확장 : 여러 대의 서버를 두어 성능을 올리는 확장

NoSQL 단점

• 데이터 중복 발생 가능
• 중복 데이터가 많기 때문에 데이터 변경 시 모든 컬렉션에서 수정 필요
• 명확한 데이터 구조 보장안함

NoSQL 사용할 때

• 정확한 데이터 구조가 정해지지 않은 경우
• UPDATE가 자주 이뤄지지 않는 경우
• 데이터 양이 매우 많은 경우

 

채팅 프로그램의 경우 채팅 목록, 친구 목록 등을 RDB로, 채팅 내역의 경우는 NoSQL을 사용하는 경우도 꽤 있다고 한다. 그러니 채팅 프로그램을 한번 만들어보는게 어떤지?! 지난 학기에 소켓 프로그래밍도 배웠는데....