사용사례: 삼성전자
Big Data Assistant
첫번째 사진의 비전을 가지고, 세번째 사진의 프로세스를 수행하는 AI 기반의 데이터 질의 서비스 구축 여정을 발표해주셨다.
계기는 데이터팀에 들어오는 요청 분석 결과 데이터 추출 요청 및 단순 질의를 포함한 단순 작업이 65%를 차지하고, 20일 이상 소요되는 일감(2번째 사진 참고)들도 요구사항 ↔︎ 결과 커뮤니케이션 미스로 여러 번 재작업하면서 소모되는 리소스 문제를 해결하고자하는 이유도 포함되어 있었다.
백엔드 입장에서 구축 여정의 기술적인 부분은 모르는 부분이 많았지만, 올해 운영 대응과 그에 따른 단순 스크립트 작업을 많이하여 난이도 별 분석 요청 그래프가 크게 공감되었고, 미리 손 쓰지 못해 반복되는 단순 작업에 대한 리소스 낭비가 아쉬웠던터라 문제를 해결하려는 해당 프로젝트가 감명 깊었다.
MongoDB 8.0
- resharding 50배 이상 빨라짐
- shard key를 변경하지 않아도 됨
- 추가 비용 없이 샤딩 가능
동시 통역을 해주셨지만 예,,? 잘 못 들었슴돠,,?
🔗 공식 문서를 첨부합니다..
모델링 원리와 방법론
모델링에 정답은 없다지만, 그래서 어려운 모델링이라 들어본 세션.
도큐먼트 필드 유형에서 배열과 Nested의 성능 차이가 궁금했었는데 큰 차이는 없다는 것을 알게되어 좋았고,
설계 전에 워크로드를 파악하여 읽기/쓰기의 빈도는 물론이고 데이터의 수명과 내구성도 고려할 수 있도록 공부를 더 해야겠다고 생각했다.
우리는 빅쿼리를 사용하고 있어 고려 대상은 아니겠지만, 빅쿼리를 사용하지 않는다면 분석용 DB로 Hidden Secondary를 활용할 수 있겠다는 생각도 해볼 수 있었다.
NoSQL인 mongoDB에서 Embedding vs Reference는 항상 고민되는 주제일 것인데 비교하여 고민 포인트와 가이드를 제시해주어 추후 설계 시 참고하면 좋을 것 같은 내용이 있었고, 기본적인 디자인 패턴을 크게 분류하여 예시해주었다.
예시된 패턴에서 Computed Pattern은 애플리케이션이 아닌 데이터베이스에서 연산하는 것이 그래도 되나,,? 미심쩍긴하지만 마켓에서도 활용 가능해보였고, Schema Versioning Pattern은 chat-service에서 폴이 사용한 것을 보고 따라하고는 있지만, 사용 및 관리 방식이 담당자에 따라 다른듯하여 내부적으로 컨벤션이 맞춰지면 좋을 것 같다고 생각했다.
