세상의 모든 Software 지식을 정리

* Index를 사용하는 이유 - 거대한 컬렉션에 대해 Read Operation이 느릴때 Read Operation시 Table scan(정보전체에 대한 읽기)이 일어남 거대한 컬렉션에 대해 Table scan이 일어난다면 서버는 Table scan이 일어나지 않도록 해야함 * Index의 효과 - 인덱스는 DB 테이블에 대한 동작속도를 높여주는 자료구조로, 저장된 자료에 대한 빠른조회를 위해 생성 (Index <-> Full Table Scan) - 인덱스는 키-필드 형태를 가지며, Scan을 거치지 않고 , 원하는 문서 위치주소로 바로 이동함 Document의 필드(들)에 index를 걸면, 데이터의 설정한 키 값을 가지고 document들을 가르키는 포인터 값으로 이뤄진 B-Tree를 만듭니다. * Index 생성시 알아둘 점 - 각 Index 는 8KB의 데이터 공간을 필요로 함 - Index생성시 write 및 update operation 성능을 떨어뜨림 - Index는 system.indexes 컬렉션에 저장됨 * 오름차순/내림차순에 대한 색인 - 키가 하나 일때는 키 방향이 무의미, 키가 하나 이상일 경우 고려함   - 단일키에서 특정 M키는 방향과 관계없이 명확함 - 최적화시 정렬방향을 고려함 {"username":1, "age": -1} 내림차순 최적화 {"username":1, "age": 1} 오름차순 최적화 {"comments.date":1} 내장문서 comments에 있는 date 키에 대한 색인 * Index의 종류 모든 MongoDB의 컬렉션은 기본적으로 _id필드에 인덱스가 존재합니다. 만약에 컬렉션을 만들때 _id필드를 따로 지정하지 않으면 mongod 드라이버가 _id필드 값을 ObjectId로 설정해줍니다. _id인덱스

기본브랜치 -master : 최종 릴리즈한 안정된 버전 -develop : 다음 릴리즈를 위한 개발 중인 최신 빌드 위 두 브랜치는 계속 존재한다. 아래 브랜치는 필요할 때 생성했다 master 나 develop 브랜치로 머지하고 삭제하는, 이벤트 성격의 브랜치이다. -featrue : 특정한 기능을 위한 브랜치  -develop 브랜치에서부터 가져오며, 다시 develop 브랜치로 머지한다.  -develop 브랜치 이외의 브랜치와는 머지하지 않는다.  -일반적으로 개발자의 로컬에서만 유지하고 origin에 푸시하지 않는다.  -develop 브랜치에 머지하면 feature 브랜치는 삭제한다. -release : 릴리즈 점검을 위한 브랜치  -develop 브랜치에서 가져오며, develop 과 master 브랜치로 머지한다.  -release-* 형태로 이름을 짓는다. 예를들어, 다음 릴리즈 버전이 1.2라면, release-1.2라고 한다.   - 다음 릴리즈까지 개발이 최종 완료되었다고 판단하는 시점에서 브랜치를 생성한다.  - 릴리즈 대상이 되는 feature 는 미리 develop에 머지되어 있어야 하고,       다음에 릴리즈할 feature 라면 develop에 머지되어 있으면 안된다.  - release 브랜치를 생성한 이후의 버그 픽스는, develop 이 아닌 release 브랜치에서 진행한다.  - 릴리즈가 모두 준비되었다고 생각하면, release 브랜치를 master에 머지한다.  - release 브랜치에서 버그 픽스한 것들을 develop 브랜치로 머지한다.  - release가 종료되면, release 브랜치를 삭제한다. -hotfix : 긴급 버그 픽스를 위한 브랜치   -master에서 가져오며, master와 develop 브랜치로 머지한다.  -hotfix-* 형태로 이름을 지음  -release 브랜치와  사용 방법은 동일하지만, 예상치 못

git 을 사용하다보면 원격저장소에서 저장소를 clone받아오는 것이 가장 많이 하는 일일것입니다.  보통 활발히 진행되고 있는 저장소라면 브랜치가 있기 마련인데 clone을 받아왔을때 이 branch들은 로컬로 가져오지 않습니다. 왠지 Subversion적인 사고로는 땡기면 다같이 와야할것 같은 생각이 드는데 git은 그렇게 동작하지 않습니다.  어쨌든 공동작업을 하거나 다른 사람의 소스를 볼때 원격의 브랜치도 가져와야 할 일이 있습니다. 일단 clone 받아온 곳에서 git branch를 하면 로컬저장소의 브랜치 목록을 볼 수 있는데 git branch -r을 하면 원격저장소의 브랜치 리스트를 볼 수 있고 git branch -a를 하면 모든 브랜치의 리스트를 볼수 있다. checkout은 브랜치나 태그로 작업트리를 변경하는 명령어 입니다. git checkout origin/autoconf처럼 명령어를 origin/autoconf처럼 원격저장소에 사용하면 원격저장소의 브랜치로 작업트리가 변경이 됩니다. detached HEAD상태이고 소스를 보고 변경도 해볼수 있지만 이곳에서 변경한 것은 잠시 확인해 보는 용도로만 사용될뿐 저장되지 않습니다. 다른 브랜치로 checkout을 하면 사라집니다. 잠시 테스트를 해보거나 확인 용도라면 이렇게 하는 것이 많지만 원하는 액션은 아닙니다. 브랜치를 추적하고 싶다면  git checkout -b 생성할브랜치이름 원격브랜치이름 처럼 해주어야 합니다. -b 옵션은 브랜치를 만들면서 해당 작업트리로 checkout까지 하라는 옵션입니다. 이제 branch명령어를 사용해보면 로컬에 새로운 브랜치가 생긴것을 볼 수 있습니다. 이렇게 하는 이유는 Subversion과는 다르게 git같은 경우는 여러개의 원격저장소를 연결할 수 있고 그중에는 브랜치명이 겹칠 수도 있기 때문으로 보입니다.  일반적으로는 로컬에서도 같은 브랜치명을 사용하게 되는데 위처럼 이름을 적어주는게 귀찮다면  git checkout -t ori

*수집 및 저장된 데이터로부터 빠른 읽기를 통한 데이터의 분석 및 가공 처리를위한 3가지 기능을 제공하고있따. 1) Aggregation Framework 2) MongoDB의 MapReduce 3) 하둡의 맵리듀스와 몽고디비를 연동 =================================================== 1) Aggregation Framework 이 함수는 $project, $match, $ group, $sort, $limit, $skip 6개가 존재한다. $project는 SQL문의 SELECT $match 는 SQL문의 WHERE절 $group 는 GROUP BY절이다 <SQL문> SELECT COUNT(*) AS count FROM order <MongoDB> db.order.aggregate([ {$group : { _id :null,               count:{$sum:1} } }]) <SQL문> SELECT SUM(price) AS total_price FROM order GROUP BY cust_id <MongoDB> db.order.aggregate([  {$group:  {_id:null,