How to implement DB Schema[4]

보통 2학년 2학기, 3학년즈음에 배우는 컴퓨터 네트워크 개념들에 대해 공부하고 있는 요즘이다. 

내가 만든 DB schema를 어떻게 효율적으로 운용할 수 있을지에 대해 self-study를 해보며 rough하게 작성해보라는 과제를 내주었다. network에 대해 지식이 없기에 이 곳에서 허락하는 시간을 쏟아부어서 개념 및 실무적용 기법에 대해 많은 search를 해보았다. 내가 잘 모르는 분야이다 보니  나의 workflow가 올바르게 가고 있는지 체크를 받고자 작성한 draft를 형에게 보냈고 feedback이 왔다. 

 

*draft이다 보니 매우 간략하게 기술되어있음. 구체적인 기술적용법이나 적용 알고리즘에 대해서는 차후에 공부하며 작성할 예정* 

 

 

Marking scheme: Poor/Fair/Good

CDN을 기준별로 설정하기
1. 팔로우 관계가 이루어져있거나 함께 아는 친구들의 정보를 담고 있는 user table을 물리적으로 가까운 proxy server 위에 두기.
→ fair. proxy server는 유저의 접속 지역과 밀접한 곳에 위치해야 적은 레이턴시를 보장할 수 있는데, 이를 만족시키기 위한 세부적인 알고리즘이 어떤 것이 있을지 고려할 것
 
2. 인플루언서를 포함한 셀럽들을 국적별로 카테고라이징 시켜서 그들의 user table을 해당 국가에 두기 
→ good.
 
Caching
캐싱은 영구적으로 데이터를 보관할 수 없다는 점을 이용하여 story table을 캐싱시키는 게 좋을 거 같다는 생각이 들었음. 특별한 삭제처리를 유저가 하지 않더라도 24hours가 경과하면 알아서 사라지기 때문. 
→ fair. 다만 인스타그램 구동 시 포스트를 불러오는 동작이 스토리를 불러오는 동작보다 훨씬 빈번하게 일어나는데 스토리만 캐싱시켰을 때 얻는 이점이 무엇일지 생각해 볼 필요가 있음.

오히려 cdn과 연계하여 이미지를 in-memory storage에 업로드 한 뒤, 아시아/유럽 지역으로 region을 나누어 분산배치 하는 것이 효율적이지 않을지

LFS&BLOB
이미지, 동영상 등 상대적으로 용량이 큰 파일들을 BLOB형식으로 저장 처리를 한 뒤, FEED를 보여 줄 때 POST의 미디어 파일을 끌어 올 때 LFS를 적용하는 것이 좋은 방안이 될 거 같다.
→ good. 세부적인 LFS 구현 방식 (in-memory storage 활용 및 backbone network attach 등)을 추가적으로 생각해보면 좋을 것. 

버퍼 캐시 히트율
디스크를 읽는 물리적 과정을 최대한 줄이고, 평소 user가 좋아하는 유형의 post들이나, 함께 아는 user_id들을 버퍼 캐시에 올려둔다면 곧 바로 메모리 블록에서 찾을 수 있는 비율이 올라가 효율적으로 데이터를 읽을 수 있을 것 같다. 
→ good.

데이터를 읽는 과정은 index Full scan이 효율적일 것 같다는 생각이 들었음. SNS 특성 상, 우리가 데이터를 조회할 때 000이상, 000미만 등의 조건을 붙여서 데이터를 추출할 작업이 많이 있지 않을 것 같음. 보통 특정 id를 검색하거나, 특정 post를 검색하는 등의 작업이 주를 이루기 때문. 테이블 전체를 스캔하기 보다 PK, Candidate Key를 이용하여 레코드의 대부분을 필터링 한다면 I/O 측면에서 큰 효율성을 얻을 수 있을 것 같음 .
→ good. 다만 cache organization scheduler를 어느시점에 구동할 지 생각해보면 좋을 것.

인메모리 데이터베이스 

DB전원 종료 시 휘발되어버린다는 점을 고려하였을 때, low risk를 지고 싶다면 로그인 세션 관련 정보를 올려두면 좋을 것 같다는 생각이 들었음. 하지만 수정된 정보들을 디스크 로그에 기록한다는 점과  Active - Active Clustering을 사용한다는 가정 하(전원이 종료되도 다른 서버가 작동하기 때문에)에는 로그인세션 뿐만 아니라 빠른 속도로 접근해야하는 post table(미디어 파일들에 빠른 access를 allow하기 위해 또한 post들을 수정할 때 빠르게 정보가 최신화 되어야하기 때문에), comment table에 적용시켜도 좋을 거 같음  
→ poor. active clustering(high availability) 설정 시 네트워크 상단에 load balancer가 위치하는 것이 통상적인 실무 관례이므로 네트워크 세션은 서버 단이 아닌 load balancer단에서 관리됨.
또한 단순 로그인 정보를 cache로 구동하는 것은 비용대비 효과가 적으며, 분산 배치 시 db 최신화는 in-memory caching과 무관함 (db mirroring과 관련있음)

Active - Active Clustering
돈이 많은 다국적 기업의 특성 상, 약간의 비용 risk를 감수하더라도 서비스 중단이 되지 않도록 초점을 맞출 것이라는 판단 하에 Active - Active Clustering을 사용하는 것이 좋을 것 같다는 생각이 들었음. 
→ fair. active clustering의 목적성에 부합함

테이블의 수평 분할
파티션 방법을 통해 수천만 건의 데이터가 들어있는 post table을 수평분할하면 I/O가 효율 것이라 생각함. 그 중에서도 Range 파티션을 통해 post가 작성된  날짜를 기준으로 분할함으로써 성능 개선을 보장시킬 수 있음.  
→ good.

슈퍼타입/서브타입 적용 
  이전에 구성한 DB Schema에는 슈퍼타입/서브타입을 적용시킬만한 attribute들의 중복이 없었으나, 향후 youtube DB schema 같은 복잡도가 높은 과제에서는 적용시키면 좋을 것 같음. 
→ poor. 스토리와 일반 포스트의 관계가 밀접하고, 이를 구현하는 방식이 유사함에 따라 포스트/스토리 관계를 슈퍼/서브타입으로 구분할 수 있을 것. OOP적 접근을 더 생각해 볼 것.

 

 

형이 정성스럽게 남겨준 feedback 내용들이다. 원래는 프로젝트에 관한 모든 doc들은 영어로 작성하기로 하였지만, 내가 잘 모르는 분야인 network인지라 한국어로 해준 듯 하다. 

이제 feedback 내용을 토대로 더욱 구체적으로 작성할 수 있도록 관련 내용들을 더 공부해야겠다. 

 

 

 

 

 

 

 

 

 

군대에서 이렇게 목적성을 가질 수 있게, 확실한 동기부여를 해준 형들에게 감사의 말을 전하며 끝까지 최선을 다하도록 해야겠다