MongoDB

MongoDB 기본 데이터 베이스 Collection 특징동적 스키마를 갖고 있어서 스키마를 수정하려면 필드 값을 추가 / 삭제하면 된다. \* index,Shard를 생성할 때 Collection 안의 특정 필드를 기준으로 하기 때문에 너무 동적인 것 보다 어느정도

맥북에 mongo cli를 설치 하고싶다. 그러나 구글에 검색해서 나오는 방법들로는 설치가 되지 않는다. 누군가는 10분만에 설치하는 간단한 것이지만, 그 간단한 것을 난 한시간이나 걸렸다. 이 글은 "두번 다시 삽질하지 말자" 라는 간절함을 현재의 내가 미래에 내게

Modeling이란? 어플리케이션의 요구사항과 데이터베이스 성능의 균형을 맞추는 것 -> 공략법이다 키포인트 내장시킬것인가 vs 참조할 것인가 정규화 vs 역정규화 조인 vs 조인 안하기 내장: 하나의 컬렉션만 읽어 모든 값을 가져올 수 있다 -> read가 빠

회원이 많은 OLTP성 카페의 요구사항을 구현하고 모델링을 진행 해보자. 1. 카페 컬렉션에 유저 정보를 Embedding 카페라는 컬렉션에 members라는 배열 필드를 만들어 유저가 카페에 가입할 때마다 배열에 유저를 추가한다. id가 2번인 카페에 유저를

회원이 많은 OLTP성 카페의 요구사항을 구현하고 모델링을 진행 해보자. 2.멤버 컬렉션에 멤베가 가입한 카페를 Embedding 카페라는 컬렉션에 members라는 배열 필드를 만들어 유저가 카페에 가입할 때마다 배열에 유저를 추가한다. id가 2번인 카페에

회원이 많은 OLTP성 카페의 요구사항을 구현하고 모델링을 진행 해보자.3\. 도큐먼트가 16메가바이트를 넘는 문제 + 카페에 대한 데이터가 수정될 때, 작업시간이 선형적으로 증가하는 문제 해결 하기 위해 컬렉션을 분리한다.cafe와 members 컬렉션을 각각 생성한

예측할 수 없는 행동로그 분석하기: 게임과 같은 서비스에서 사용자들의 패턴을 분석하고, 모든 행동을 기록한다.초기 모델링유저의 대한 데이터를 생성하고 유저의 로그를 배열로 저장한다위와 같은 모델링은 하나의 컬렉션에 너무 큰 데이터가 들어가게 된다. (로그가 많아지게 되

배달 어플 주문 리뷰 서비스 가게를 만들고 800개의 리뷰를 생성. 리뷰는 배열 혈태로 삽입 문제점여러 음식점을 클릭해서 리뷰를 확인할 때 음식점 클릭 -> find -> 내부적으로 캐시의 있는지 확인 후(없다면 캐시에 적재) 도큐먼트 반환따라서 캐시에 올라가는 데

회사의 결제선 상품 카테고리등을 트리패턴을 통해 모델링 해보자 회사 결재선 작성 테스트 데이터 삽입 트리구조로 데이터 표현하기 (데이터간 관계가 표현된다. 순서보장 x)

스마트 사옥에서 각 층별로 온도에 대한 데이터를 수집하여 MongoDB에 저장한다반복문과 날짜를 조합하여 1분단위의 30일치분 테스트 데이터를 삽입한다.(데이터는 864000개 이고, 데이터의 총 크기는 약 60MB이다)문제점컬렉션의 도큐먼트수가 너무 많다. (온도

(지금부터 서술하는 글은 모든 해당사항에 적용되지 않는다)lookup을 사용하기 전에 sort나 limit을 먼저 진행하자.MongoDB의 쿼리 성능을 최적화하는 데 있어 sort나 limit 같은 연산을 $lookup 이전에 수행하는 것이 성능에 이점을 줄 수 있다.

cursor.explain() 함수를 통해 실행 계획을 출력할 수 있다.explain(): 기본적인 queryPlannder 모드explain('executionStats'): queryPlannder의 모든 항목과 winning plan의 세부 정보를 보여준다expl

자주사용하는 쿼리의 응답이 빠른 이유 처음 쿼리를 실행했을 때 보다 두 번쨰 쿼리 실행 응답이 빠른 이유는 뭘까? 그림을 통해 알아보자. 쿼리 최초 실행: 캐쉬에서 매칭되는 엔트리 확인(캐쉬에 존재하지 않음) -> 실행 계획 후보 생성 -> 후보 실행 계획 수행 -

Change Stream을 사용하면 데이터베이스 변경사항에 대하여 실시간으로 알람을 받을 수 있다.나의 경우 파이썬을 이용하여 기본적인 파이프라인만 구축해 알람을 받아 보았고, 더 자세한 내용은 공식문서에서 확인할 수 있다.(Change Stream 공식문서로 이동하기

추출MongoDB 홈페이지에 접속하여 mongodb-database-tool 다운로드다운로드 링크다운 받은 파일의 bin 디렉토리 내부에서 명령어를 실행한다../mongoexport --uri="mongodb+srv://cluster0.texal2d.mongodb.ne

1\. Background Option4.2버전 이전까지는 Background Option을 설정하지 않으면 인덱스를 생성하기 까지 데이터베이스에 락이 걸린다. Version >= 4.2: Background Option이 default2\. Rolling Index

TTL Index: 시간을 기준으로 자동으로 생성된 도큐먼트를 삭제한다. 날짜를 기준으로 하는, 또는 날짜를 가지고 있는 배열을 포함하는 싱글필드 인덱스만 생성 가능하다.

Multikey Index: 배열필드거나 배열안의 내장된 필드에 인덱스를 생성하는 인덱스왼쪽은 두개의 도큐먼트, 오른쪽은 총 네개의 도큐먼트지만 addr에 인덱스를 설정하면 인덱스의 수는 같다.(왼쪽은 멀티키인덱스, 오른쪽은 싱글인덱스로 적용된다)Multikey Ind

Compound Index는 여러 필드로 구성된 인덱스다. 여러 필드로 생성되기 때문에 필드의 순서에 따라 정렬을 하게 된다. \-> 필드의 순서가 중요하고, Compound Index만의 중요한 특성이 존재한다.인덱스의 선행필드(일부필드만) 사용해도 Compound

4.0부터 지원하는 기능이다.Transaction을 사용하겠다는 것은 컬렉션을 정규화 하겠다는 의미이다. 그렇기에 굳이 사용을 권장하지 않는다. 몽고디비의 특성과 맞지 않기 때문이다. (정규화를 할 것이면 처음부터 RDBMS를 고려하자)Transaction을 사용하는이

Causal Consisitency시간을 기준으로 데이터 응답을 대기시킨다. 즉 완벽한 일관성을 보장한다.주로 사용되는 사용되는 기술은 아니다. 몽고디비의 특성상 일관성 보다는 빠른 속도와 유연한 도큐먼트를 활용하는 것이 주 목적이기 때문이다.몽고디비 3.6부터 지원한

Write Concern: Replica Set의 동기화 정도를 제어한다. (몇개 까지 복제를 완료하고 멤버에게 데이터를 반환할 것인가)

Reflica Set으로 구성된 몽고디비 서버에서 Read에 대한 요청을 어떤 멤버가 처리하게 할 것인지에 대한 옵션이다.Read Preference의 종류는 다음과 같다.Secondary 옵션의 문제점? Secondary의 경우 복제가 완료되지 않아서 지연된 데이터를

AggregationCollection 데이터를 변환하거나 분석하기 위해 사용하는 집계 Framework.Aggregation은 Find 함수로 처리할 수 없는, SQL의 Group By와 Join 구문 같은 복잡한 데이터 분석 기능들을 제공한다.Aggregation

git clone https://github.com/ylake/mongodb-cluster-docker-compose.gitclone한 디렉토리로 이동하여 docker-compose up -d(필요한 이미지들을 받아 컨테이너를 실행한다.)config serve

링크에 접속하여 다운로드를 진행한다.데이터 베이스로 사용할 dir 생성1번에서 다운받은 Community Server 파일의 bin 경로로 들어가 옵션을 실행한다.새로운 터미널을 1번에서 다운받은 shell 파일의 bin 경로로 들어가 몽고 쉘에 접속한다.rs.stat

장점용량의 한계를 극복할 수 있다. 데이터 규모와 부하가 크더라도 처리량이 좋다.고가용성을 보장한다(모든 샤드는 Replica Set으로 구성되어 있기 떄문)하드웨어에 대한 제약을 해결할 수 있다.단점관리가 비교적 복잡하다.Replica Set과 비교해서 쿼리가 느리다

Replica Set Election(Fail-Over):Primary가 정지되면 쓰기요청이 불가능 하다. 이때 새로운 Primary를 선출해야 하는데, Replica Set에서는 서버간 HeartBeat 요청을 통해 작동 유무를 확인하고 있다가 Primart가 반응이