[MongoDB] MongoDB 실행, 데이터베이스 생성/제거, Collection 생성/제거

MongoDB 실행, 데이터베이스 생성/제거,

Collection 생성/제거

---

오늘은 MongoDB를 실행하고, 데이터베이스와 Collection을 생성한 후 제거해보았다.

noSQL이기 때문에 기존 SQL을 사용하여 생성하던 방식과 차이가 있다.

서버 실행 및 접속

먼저 MongoDB 서버를 실행한다.

터미널을 켜서 'mongod' 명령어를 입력하여 서버를 실행한다.

서버가 실행되면서 pid, port번호, dbpath가 출력된다.

$ mongod
MongoDB starting : pid=1234 port=12345 dbpath=/data/db 64-bit host=username.local

'mongo' 명령어를 입력하여 서버에 접속한다.

url서버 url과 서버 버전이 표기된다.

$ mongo
MongoDB shell version v3.4.10
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.10

데이터베이스 생성 : use

> db
test
> use mongodb_tutorial
switched to db mongodb_tutorial
> db
mongodb_tutorial

기본적으로는 test라는 이름의 데이터베이스가 실행된다.

'use mongodb_tutorial' 명령어를 통해 mongodb_tutorial 이라는 데이터베이스를 생성했다.

이후 다시 db 명령어를 통해 생성한 데이터베이스가 실행된 것을 볼 수 있다.

> show dbs
admin  0.000GB
local  0.000GB

'show dbs' : 내가 만든 데이터베이스 리스트를 확인한다.

리스트에서 데이터베이스를 보려면 최소 한개 이상의 Document를 추가해야 한다.

아래와 같이 Document를 추가하면, 추가된 mongodb_tutorial 데이터베이스를 볼 수 있다.

> db.book.insert({"name": "MongoDB Tutorial", "autohr": "velopert"});
WriteResult({ "nInserted" : 1 })
> show dbs
admin             0.000GB
local             0.000GB
mongodb_tutorial  0.000GB

데이터베이스 제거 : delete

데이터베이스 제거에 앞서 'use' 명령어로 제거할 데이터베이스를 선택한다.

이후 db.dropDatabase(); 명령어로 데이터베이스를 제거한다.

> use mongodb_tutorial
switched to db mongodb_tutorial
> db.dropDatabase();
{ "dropped" : "mongodb_tutorial", "ok" : 1 }

Collection 생성 : db.createCollection();

Colletion을 생성하기 위해 db.createCollection() 명령어를 사용한다.

db.createCollection() 의 메소드는 name, options가 있다.

name은 생성하려는 컬렉션의 이름이며, options 변수는 필요에 따라 사용하고, 생략 가능하다.

Parameter	Type	Description
name	string	The name of the collection to create.
options	document	Optional. Configuration options for creating a capped collection, for preallocating space in a new collection, of tor creating a view/.

options 에 들어갈 수 있는 필드는 다음과 같다.

작성하려다 필드 수가 너무 많아 mongodb DOCS 에서 복붙하였다.

Field	Type	Description
capped	boolean	Optional. To create a capped collection, specify true. If you specify true, you must also set a maximum size in the size field.
autoIndexId	boolean	Optional. Specify false to disable the automatic creation of an index on the _id field. IMPORTANT For replica sets, do not set autoIndexId to false. Deprecated since version 3.2.
size	number	Optional. Specify a maximum size in bytes for a capped collection. Once a capped collection reaches its maximum size, MongoDB removes the older documents to make space for the new documents. The size field is required for capped collections and ignored for other collections.
max	number	Optional. The maximum number of documents allowed in the capped collection. The size limit takes precedence over this limit. If a capped collection reaches the size limit before it reaches the maximum number of documents, MongoDB removes old documents. If you prefer to use the max limit, ensure that the size limit, which is required for a capped collection, is sufficient to contain the maximum number of documents.
usePowerOf2Sizes	boolean	Optional. Available for the MMAPv1 storage engine only. Deprecated since version 3.0: For the MMAPv1 storage engine, all collections use the power of 2 sizes allocation unless the noPadding option is true. The usePowerOf2Sizes option does not affect the allocation strategy.
noPadding	boolean	Optional. Available for the MMAPv1 storage engine only. New in version 3.0: noPadding flag disables the power of 2 sizes allocation for the collection. With noPadding flag set to true, the allocation strategy does not include additional space to accommodate document growth, as such, document growth will result in new allocation. Use for collections with workloads that are insert-only or in-place updates (such as incrementing counters). Defaults to false. WARNING Do not set noPadding if the workload includes removes or any updates that may cause documents to grow. For more information, see No Padding Allocation Strategy.
storageEngine	document	Optional. Available for the WiredTiger storage engine only. New in version 3.0. Allows users to specify configuration to the storage engine on a per-collection basis when creating a collection. The value of the storageEngine option should take the following form: { <storage-engine-name>: <options> } Storage engine configuration specified when creating collections are validated and logged to the oplogduring replication to support replica sets with members that use different storage engines.
validator	document	Optional. Allows users to specify validation rules or expressions for the collection. For more information, see Document Validation. New in version 3.2. The validator option takes a document that specifies the validation rules or expressions. You can specify the expressions using the same operators as the query operators with the exception of $geoNear, $near, $nearSphere, $text, and $where. NOTE Validation occurs during updates and inserts. Existing documents do not undergo validation checks until modification. You cannot specify a validator for collections in the admin, local, and config databases. You cannot specify a validator for system.* collections.
validationLevel	string	Optional. Determines how strictly MongoDB applies the validation rules to existing documents during an update. New in version 3.2. validationLevel Description "off" No validation for inserts or updates. "strict" Default Apply validation rules to all inserts and all updates. "moderate" Apply validation rules to inserts and to updates on existing validdocuments. Do not apply rules to updates on existing invaliddocuments.
validationAction	string	Optional. Determines whether to error on invalid documents or just warn about the violations but allow invalid documents to be inserted. New in version 3.2. IMPORTANT Validation of documents only applies to those documents as determined by the validationLevel. validationAction Description "error" Default Documents must pass validation before the write occurs. Otherwise, the write operation fails. "warn" Documents do not have to pass validation. If the document fails validation, the write operation logs the validation failure.
indexOptionDefaults	document	Optional. Allows users to specify a default configuration for indexes when creating a collection. The indexOptionDefaults option accepts a storageEngine document, which should take the following form: { <storage-engine-name>: <options> } Storage engine configuration specified when creating indexes are validated and logged to the oplog during replication to support replica sets with members that use different storage engines. New in version 3.2.
viewOn	string	The name of the source collection or view from which to create the view. The name is not the full namespace of the collection or view; i.e. does not include the database name and implies the same database as the view to create. See also db.createView(). New in version 3.4.
pipeline	array	An array that consists of the aggregation pipeline stage. db.createView creates the view by applying the specified pipeline to the viewOn collection or view. The view definition is public; i.e. db.getCollectionInfos() and explainoperations on the view will include the pipeline that defines the view. As such, avoid referring directly to sensitive fields and values in view definitions. See also db.createView(). New in version 3.4.
collation	document	Specifies the default collation for the collection. Collation allows users to specify language-specific rules for string comparison, such as rules for lettercase and accent marks. The collation option has the following syntax: collation: { locale: <string>, caseLevel: <boolean>, caseFirst: <string>, strength: <int>, numericOrdering: <boolean>, alternate: <string>, maxVariable: <string>, backwards: <boolean> } When specifying collation, the locale field is mandatory; all other collation fields are optional. For descriptions of the fields, see Collation Document. If you specify a collation at the collection level: Indexes on that collection will be created with that collation unless the index creation operation explictly specify a different collation. Operations on that collection use the collection’s default collation unless they explictly specify a different collation. You cannot specify multiple collations for an operation. For example, you cannot specify different collations per field, or if performing a find with a sort, you cannot use one collation for the find and another for the sort. If no collation is specified for the collection or for the operations, MongoDB uses the simple binary comparison used in prior versions for string comparisons. For a collection, you can only specify the collation during the collection creation. Once set, you cannot modify the collection’s default collation. For an example, see Specify Collation. New in version 3.4.