Recommended
More Related Content
Similar to MongoDB 이해하기
Similar to MongoDB 이해하기 (20)
More from 선협 이
More from 선협 이 (16)
Recently uploaded
Recently uploaded (20)
MongoDB 이해하기
- 2. 오늘의 목표 MongoDB 분산 시스템 모델링 패턴
- 3. MongoDB 분산 시스템 모델링 패턴 오늘의 목표
- 4. NoSQL이란?
- 5. Not Only SQL 관계형 DB가 아닌 DB
- 6. •분산 시스템을 위해 탄생 •RDBMS에서 하기 힘든 것을 지원 •Schema-less •MongoDB, Redis, HBase... NoSQL
- 8. RDBMS NoSQL 장점 • 데이터의 무결성을 보장한다. • 정규화를 통해 필요한 부분만 수정이 가능하 다. • 기본적으로 일관성을 유지한다. • 스키마가 없어 유연하게 데이터를 저장할 수 있다. • 분산 시스템에서 가용성이 뛰어나다. • 읽기 성능이 뛰어나다. • 수직, 수평 확장이 가능하다. 단점 • 관계가 많을수록 복잡한 쿼리를 사용해야한다. • 수평적 확장이 어렵다. 따라서 성장 한계가 존 재한다. • 관계가 없기 때문에 사실상 정규화가 불가능 하다. 때문에 연관된 데이터가 있을 경우 여러 컬렉션에서 데이터를 수정해야한다. • 무결성이 보장되지 않아 사용자의 실수가 그 대로 반영될 수 있다.
- 10. MongoDB
- 11. MongoDB - Document Document의 구조
- 12. MongoDB - Document Document 스키마 타입
- 14. MongoDB - Document 조작 방법
- 15. MongoDB - BASE •Basically Available •Soft state •Eventually consistent •ACID를 포기하고 성능과 가용성을 우선
- 16. MongoDB - BASE Basically Available •기본적으로 언제든지 사용할 수 있다. •가용성이 필요하다는 의미
- 17. MongoDB - BASE Soft state •외부의 개입이 없어도 정보가 변경될 수 있다. •네트워크 파티션 등 문제가 발생되어 일관성이 유지되지 않는 경우 일관성을 위해 데이터를 자동으로 수정한다.
- 18. MongoDB - BASE Eventually consistent •일시적으로 일관적이지 않은 상태가 되어도 일정 시간 후 일관적인 상태가 되어야한다. •장애 발생시 일관성을 유지를 위한 이벤트를 발생시킨다.
- 19. MongoDB - BASE
- 20. MongoDB - ACID? •Single-Document Transaction •Multi-Document Transaction (4.0) •Shard Cluster Transaction (4.2)
- 21. MongoDB 분산 시스템 모델링 패턴 오늘의 목표
- 22. 🤔 대규모 데이터를 처리해야하는데 RDBMS는 성장 한계가 있구나 일관성과 무결성을 버리고 더 빠른 읽기 성능과 수평 확장이 가능한 DB가 필요해
- 24. •Consistency (일관성) •Availability (가용성) •Partition tolerance (분할내성) CAP Theorem
- 25. •모든 노드가 같은 시간에 같은 데이터를 볼 수 있다. Consistency
- 26. •모든 요청에 성공 혹은 실패 결과를 반환 할 수 있다. Availability
- 27. •통신에 실패해도 시스템이 계속 동작해야한다. Partition tolerance
- 28. MongoDB는 일관성과 분할내성을 지닌 데이터베이스다
- 30. •완벽한 CP, AP 시스템은 구리다. •CA는 네트워크 장애가 절대 발생하지 않아야 하기 때문에 사실상 불가능하다. •따라서 P는 무조건 인정하고 들어가야한다. •대부분의 분산 시스템은 상황에 따라 일관성과 가용성의 우선순위를 다르게 설정한다. CAP 이론의 한계
- 32. PACELC Theorem
- 34. P-S-S
- 35. P-S-A
- 36. MongoDB 분산 시스템 모델링 패턴 오늘의 목표
- 37. Not Only SQL 관계형 DB가 아닌 DB
- 38. •Parent References •Child References •Array of Ancestors •Materialized Paths •Nested Sets Model Tree Structures
- 39. Model Tree Structures Parent References
- 40. Model Tree Structures Child References
- 41. Model Tree Structures Array of Ancestors
- 42. Model Tree Structures Materialized Paths
- 43. Model Tree Structures Nested Sets
- 45. Model Relationships Link vs Embed
- 46. Model Relationships 1:1 •Document의 크기가 엄청 크지 않다면 Sub Document로 Embed하는 것이 좋다. •너무 크다면 Link 관계로 유지하고 필요한 경우 Setset 패턴을 사용한다.
- 47. Model Relationships 1:N •Embed vs Link를 참고하여 선택한다. •필요한 경우 Setset 패턴을 사용한다.
- 48. Model Relationships N:M •Array를 사용하여 Link할 수 있다. •단방향, 양방향을 정한다. •어떤 Collection에서 쿼리가 자주 발생하는지에 따라 모델링 해야한다.
- 50. Modeling Patterns Attribute •동일한 필드를 묶는 패턴 •인덱싱 수를 줄일 수 있다.
- 52. Modeling Patterns Extended Reference •관계가 있는 Document에서 자주 사용되는 데이터를 저장해두는 패턴 •쿼리 호출 횟수를 줄일 수 있다. •데이터 수정이 있는 경우 양쪽을 모두 수정해야한다.
- 54. Modeling Patterns Subset •관계가 있는 Document 사이에 자주 쓰이는 데이터를 부분적으로 Embed하는 패턴 •쿼리 호출 횟수를 줄일 수 있다. •데이터 수정이 있는 경우 양쪽을 모두 수정해야한다.
- 56. Modeling Patterns Computed •Document write시 통계값을 저장하는 패턴 •read 성능 낭비를 막을 수 있다. •오차가 있을 수 있다.
- 58. Modeling Patterns Bucket •하나의 필드를 기준으로 Document들을 묶는 패턴 •실시간으로 데이터가 들어오는 시계열 데이터에 적합 •필드 추가, 인덱스 크기 절약, 쿼리 단순화에 좋다 •최대 BSON 사이즈를 넘지 않도록 조심해야한다.
- 60. Modeling Patterns Schema Versioning •Document에 버전 정보를 기록하는 패턴 •서비스가 발전하면서 스키마가 변경될 수 있다. 이 때 Schema Versioning 패턴을 사용하면 기존 데이터를 수정하지 않아도 괜찮다. •Document가 너무 많은 경우 유용하다.