[Mongodb]웹서비스컴퓨팅_11주차_(2)

1. 데이터베이스 백업

- 백업을 위한 명령어  : mongodump

• dumps the entire data of your server into the dump directory

   (서버의 전체 데이터를 덤프 디렉토리에 덤프)

• 백업 단위 선택 가능 : 컬렉션/데이터베이스/전체 데이터베이스 단위

 

ex) mongod 서버가 로컬호스트(포트# : 27017)에서 동작 중인 경우

• mongodb가 설치된 bin 폴더로 이동 후 mongodump 명령 입력

• 모든 데이터를 BSON 파일 형식으로 /bin/dump 폴더에 백업 수행

 

- mongodump와 함께 쓰는 옵션

 

Syntax	Description	Example
mongodump --host HOST_NAME --port PORT_NUMBER	This commmand will backup all databases of specified mongod instance. (지정된 mongod 인스턴스의 모든 데이터베이스를 백업)	mongodump --host tutorialspoint.com --port 27017
mongodump --dbpath DB_PATH --out BACKUP_DIRECTORY	This command will backup only specified database at specified path. ( 지정된 경로에서 지정된 데이터베이스 만 백업)	mongodump --dbpath /data/db/ --out /data/backup/
mongodump --collection COLLECTION --db DB_NAME	This command will backup only specified collection of specified database. (지정된 데이터베이스 모음만 백업)	mongodump --collection mycol --db test

 

2. 백업된 데이터 복원(restore)  명령 : mongorestore

• restores all of the data from the backup directory

 

##mongodump and mongostore are not ideal for capturing backups of larger systems.

(위 두 명령어는 큰 시스템의 백업 캡쳐에 적합하지 않다)

 

3. Relationship

• represents how various documents are logically related to each other

(다양한 문서가 서로 논리적으로 어떻게 연관되어 있는지 나타낸다)

• can be either 1:1, 1:N, N:1 or N:N

• can ne modeled via Embedded and Referenced approaches.

(embedded 및 referenced 접근 방식을 통해 모델링)

 

ex) 사용자의 주소 저장하는 경우 (여러 개의 주소 가능 -> 1:N 관계 성립)

{ "_id":ObjectId("52ffc33cd85242f436000001"),
"name": "Tom Hanks",
"contact": "987654321",
"dob": "01-01-1991" } //USER

{"_id":ObjectId("52ffc4a5d85242602e000000"),
"building": "22 A, Indiana Apt",
"pincode": 123456, "city": "Los Angeles",
"state": "California" } //Address

1) Embedded Relationships = denormalized relationship 

• maintains all the related data in a single document, which makes it easy to retrieve and maintain

(모든 관련 데이터를 단일 문서로 유지 관리하여 쉽게 사용할 수 있도록 한다(회수 하여 유지))

 

{
"_id":ObjectId("u001"),
"name": "Tom Hanks", . . .
"address": [ { "building": "22 A, Indiana Apt", . . . },
                        { "building": "170 A, Acropolis Apt", . . . } ] }
                      ]
}

•whole document can be retrieved in a single query

(전체 문서는 단일 쿼리로 검색할 수 있다)

db.users.findOne({"name":"Tom Hanks"},{"address":1})

• drawback(단점)

– if the embedded document keeps on growing too much in size, it can impact the read/write performance.

(포함된 문서의 크기가 계속 커지면 읽기 / 쓰기 성능에 영향을 미칠 수 있다)

 

 2) Referenced Relationships (참조 관계)= normalized relationship(정상화 관계)

• both the user and address documents will be maintained separately but the user document will contain a field that will reference the address document's id field.

(사용자 문서와 주소 문서는 별도로 유지되지만, 사용자 문서에는 주소 문서의 ID 필드를 참조하는 필드가 포함)

{
"_id":ObjectId("u001"),
. . .
"name": "Tom Hanks",
"address_ids": [ ObjectId("a001"), ObjectId("a002") ]
}

• need two queries: first to fetch the address_ids fields from user document and second to fetch these addresses from address collection.

(두 가지 쿼리가 필요 / 첫째는 사용자 문서에서 address_ids 필드를 가져오는 것 => 둘 째는 주소 집합에서 이 주소를 가져오는 것)

> var result = db.users.findOne({"name":"Tom Hanks"}, {"address_ids":1})

> db.address.find({"_id":{"$in":result["address_ids"] }})
//result 문서에서 address_ids 필드의 값만 추출 [ObjectId("a001"), ObjectId("a002")]

4. Database References

1)  For many use cases in MongoDB(몽고디비의 많은 사용 사례)

      • the denormalized data model where related data is stored within a single document will be optimal (embedded reltaionship)(관련 데이터가 저장되는 공식화된 데이터 모델 : 단일 문서가 최적 / 임베디드 Relationship)

      • in some cases, it makes sense to store related information in separate documents, typically in different collections or databases (normalized relationship)

            (경우에 따라 관련 정보를 별도로 저장하는 것이 타당 / 일반적으로 서로 다른 컬렉션 또는 DB 에 있는 문서(정규화된 관계))

 

2) two methods for relating documents in mongoDB applications(몽고디비 응용프로그램에서 Document와 관련된 2가지)

      • Manual references(수동 참조)

         – you save the _id field of one document in another document as a reference.
            Then your  application can run a second query to return the related data.

            (하나의 document에 id 필드를 저장하고 다른 document에서 참조하면 된다 
               / 응용프로그램에서 두 번째 쿼리를 실행하여 반환할 수 있다)

         – simple and sufficient method for most use cases.

             (대부분의 사용 사례에 대한 간단하고 충분한 방법)

      • DBRefs

      – references from one document to another using the value of the first document‟s _id field, collection name, and,             optionally, its database name

        (dbrefs를 사용하여 한 문서에서 다른 문서로 참조 /  _id 필드, 컬렉션 이름 및 데이터베이스 이름(선택 사항) 등이 있다)

      – in cases where a document contains references from different collections, we can use this method

         (document에 다른 collection이 포함되어 있다면 , 위의 방법을 사용한다)

 

3) Using DBRefs

• $ref 필드 : 참조되는 문서가 속한 컬렉션 이름↓

• $id 필드 : 참조되는 문서의 _id 필드↓

• $db 필드 : 참조되는 문서가 속한 데이터베이스 이름 (옵션)↓

아래 방향으로 필드 순서 주의 해서 사용해야한다.

 

{
"_id":ObjectId("53402597d852426020000002"),
"address": {
          "$ref": "address_home",
          "$id": ObjectId("534009e4d852427820000002"),
          "$db": "tutorialspoint"},
"contact": "987654321",
"dob": "01-01-1991",
"name": "Tom Hanks" 
}

> var user = db.users.findOne({"name":"Tom Hanks"})
> var dbRef = user.address
> db[dbRef.$ref].findOne({"_id":(dbRef.$id)})

 

 

5. Covered Queries

1) covered query

• 인덱스만 이용해서도 처리가 가능한 질의 (데이터베이스 접근 없음)

• a query that can be satisfied entirely using an index and does not have to examine any documents

(인덱스를 사용하여 완전히 만족할 수 있고, 그 어떤 document도 검토할 필요가 없는 질의)

• 질의 처리에 필요한 모든 데이터가 인덱스에 있을 때 „이 인덱스가 해당 질의를 커버 한다‟라고 함

• An index covers a query when all of the following apply:(모두 적용되면 index는 query를 다룬다)

       – all the fields in the query are part of an index, and(쿼리의 모든 필드는 index의 일부분)

       – all the fields returned in the results are in the same index(결과에 반환되는 모든 필드가 동일한 index에 있음)

       – no fields in the query are equal to null(쿼리에 null과 동일한 필드가 없음)

 

{
"_id": ObjectId("53402597d852426020000002"),
"contact": "987654321",
"dob": "01-01-1991",
"gender": "M",
"name": "Tom Benzamin",
"user_name": "tombenzamin"
}

First. create a compound index for the users collection on the fields gender and user_name using the following query 

>db.users.ensureIndex({gender:1,user_name:1})

this index will cover the following query

>db.users.find({gender:"M"},{user_name:1,_id:0}) //ID필드는 결과 문서에서 반드시 제외시켜야 함

 

 

6. Analyzing Queries

-  Analyzing queries is a very important aspect of measuring how effective the database and indexing design is.

(쿼리 분석하는 것은 효과적으로 데이터베이스와 인덱스를 디자인하는데 있어 매우 중요한 측면)

1) $explain( ) 연산자

    • provides information on the query, indexes used in a query and other statistics

    (쿼리에 대한 정보, 쿼리에 사용된 인덱스 및 기타 통계 제공)

    • very useful when analyzing how well your indexes are optimized

    (인덱스가 얼마나 최적화 되어있는지 분석할 때 유용)

    • 사용 예)

> db.users.find({gender:"M"},{name:1, _id:0}).explain()
결과 
>{ "cursor" : "BtreeCursor gender_1_user_name_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 0, "nscanned" : 1, "nscannedObjectsAllPlans" : 0, "nscannedAllPlans" : 1, "scanAndOrder" : false, "indexOnly" : true, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "gender" : [ [ "M", "M" ] ], "user_name" : [ [ { "$minElement" : 1 }, { "$maxElement" : 1 } ] ] } }

2) $hint( ) 연산자

    • forces the query optimizer to use the specified index to run a query

       (쿼리 최적화가 지정된 인덱스를 사용하여 쿼리를 실행하도록 강제 적용)

    • particularly useful when you want to test performance of a query with different indexes

       (다른 인덱스로 쿼리 성능을 테스트하는데 유용)

    • 사용 예)

>db.users.find({gender:"M"},{user_name:1,_id:0}).hint({gender:1,user_name:1})

 

7. Atomic Operations

1) MongoDB provides atomic operations on only a single document

(몽고디비는 단일 document)에서만 atomic operations 을 제공

2) The recommended approach to maintain atomicity(원자성 유지하기 위한 권장하는 접근법)

    • keep all the related information, which is frequently updated together in a single document using embedded     documents(임베디드 문서를 사용하여 단일 문서로 자주 업데이트 되는 모든 관련 정보를 보관)

 =>  all the updates for a single document are atomic.(단일 document 에 대한 모든 업데이트는 원자적)

     • findAndModify 명령의 활용 예)

{ "_id":1,
             "product_name": "Samsung S3",
             "product_available": 3,
             "product_bought_by": [{ "customer": "john", "date": "7-Jan-2014"}, { "customer": "mark", "date": "8-Jan-2014"} ] }

> db.products.findAndModify({
            query:{_id:2,product_available:{$gt:0}},
            update:{ $inc:{product_available:-1},
                             $push:{product_bought_by:{customer:"rob",date:"9-Jan-2014"}} }
})

8. Advanced Indexing

{
"address": {
            "city": "Los Angeles",
            "state": "California",
             "pincode": "123"
            },
"tags": [
            "music",
            "cricket",
            "blogs"
            ],
"name": "Tom Benzamin"
}

1) 배열을 필드 값으로 가지는 인덱싱 : multikey index 로 구성

multikey index 

– 배열의 각 요소 마다 인덱스 엔트리 유지

    =>  같은 배열에서 생성된 여러 엔트리들은 동일한 문서를 참조(포인트)

–  user tag를 기반으로 user document를 검색한다 가정 / collection의 tag 배열에 index를 생성

– 배열에 index 작성 시 , 각 필드에 대한 별도 index 항목이 작성 

==> 태그 배열에서 index 생성 시, music/ cricket / blogs 값에 대해 별도의 index 생성

 

> db.users.createIndex({"tags":1})
//태그 배열에 index 생성 

> db.users.find({"tags":"cricket"})
//index 생성 후 컬렉션의 태그 필드 검색 

> db.users.find({"tags":"cricket"}).explain()
//적절하게 사용되었는지 확인하려면 explain 명령 사용
"cursor": "BtreeCursor tags_1"//결과

 

2) 서브 문서를 필드 값으로 갖는 인덱싱

– 서브 문서의 모든 필드들에 대한 인덱스 생성 =>  compound index로 구성

– 도시 , 주 및 핀코드 필드 기반 문서 검색 / 

   => 모든 필드는 주소, 하위 문서 필드의 일부 이므로 -> 하위 문서의 모든 필드에 대한 index 생성

db.users.createIndex({"addr.city":1},{"addr.state":1}, {"addr.pincode":1})
//하위 문서의 세 필드 모두에 대한 index 

db.users.find({"addr.city":"LA"})
//index을 사용하는 하위 문서 필드 검색 가능 

db.users.find({"addr.city":"LA", "addr.state":1})
//쿼리 식은 지정된 index 순서를 따라야함 

db.users.find({"addr.city":"LA", "addr.state":1, "addr.pincode":1})