MySQL DB 와 분리된 DB 에는 로그 기반 사용자 데이터가 들어가는 것으로 논의했었는데요. 영오님이 이미 검토하신 것과 동일하게 로그 기반의 사용자 데이터는 admin 을 통해 입력되는 content data 에 비해 table 간 관계가 복잡하지 않고, 아래 아래 항목들이 더 중요할 것으로 보이므로 Non-Relational DB 이 더 적합하지 않을까 싶습니다.
scalability
사용자가 늘어날수록, 또 같은 사용자라도 사용 기간이 늘어날 수록 데이터 용량 증가
flexibility
쉽게 변경될 수 있는 로그 기반으로 데이터를 입력하므로, 기존과 다른 field 를 가진 record 가 쉽게 입력될 수 있어야 합니다.
performance
사용자 데이터는 content 데이터에 비해, wrtie 요청이 훨씬 더 많아 더 좋은 write performance 가 필요합니다. 대신 사용자 데이터는 content 데이터에 비해 table 간 관계가 더 단순할 것으로 보이는데요. table(collection) 구조가 단순해서 쓰기 속도가 더 빠른 Non-Relational DB 가 더 유리할 것으로 보입니다.
2004년 연말 쇼핑 시즌 동안 아마존 닷컴의 장애가 있었습니다. 대부분의 데이터베이스 시스템은 읽기가 95%이고 변경이나 삭제가 5% 정도 되기 때문에 관계형 데이터베이스(RDB)로도 충분하지만, 아마존닷컴의 장바구니는 그 반대로 쓰기가 많았기(Write-heavy) 때문에 장애가 날 수 밖에 없었죠. 당시 한 20대 인턴은 이 문제를 해결하기 위해, Dynamo라는 비관계형 키 값 데이터베이스를 만들고 장바구니에 쇼핑 아이템을 효율적으로 추가 혹은 변경해야 하는 문제를 풀 수 있었습니다. 그 이후, 많은 오픈 소스 기반 NoSQL 솔루션이 탄생하였고, 웹 2.0 붐과 아울러 쓰기 수요가 많은 소셜 네트워크 서비스 등에서 앞다투어 도입을 하기 시작했습니다.
MySQL DB 와 분리된 DB 에는 로그 기반 사용자 데이터가 들어가는 것으로 논의했었는데요. 영오님이 이미 검토하신 것과 동일하게 로그 기반의 사용자 데이터는 admin 을 통해 입력되는 content data 에 비해 table 간 관계가 복잡하지 않고, 아래 아래 항목들이 더 중요할 것으로 보이므로 Non-Relational DB 이 더 적합하지 않을까 싶습니다.
scalable 하고 MySQL-compatible 한 Vitess 는?
참고 자료
relational DB 와 non-relational DB 비교
https://www.mongodb.com/compare/relational-vs-non-relational-databases
2012년 non-relational-databases 인 AWS DynamoDB 탄생 배경
https://aws.amazon.com/ko/blogs/korea/happy-birthday-dynamodb/
https://channy.creation.net/blog/1623