set 타입은 특정 key에 대해 중복되지 않고, 순서가 보장되지 않는 값의 집합을 정의합니다. 내부적으로 hash table을 사용하므로 push/pop이 아닌 add/remove 패턴의 명령어를 사용합니다.

sadd [key] [item ...]

key의 set에 item들을 추가합니다. 성공적으로 추가된 item의 수를 반환합니다.

127.0.0.1:6379> sadd a 1 2 3
(integer) 3
127.0.0.1:6379> sadd a 1 3 4
(integer) 1

srem [key] [item ...]

key의 set에 존재하는 item들을 제거합니다. 성공적으로 제거된 item의 수를 반환합니다.

127.0.0.1:6379> srem a 1 2 3
(integer) 3
127.0.0.1:6379> srem a 1 2 3 4
(integer) 1

sismember [key] [item]

key의 set에 item이 존재하는지 체크합니다. item이 존재하는 경우 1을, 존재하지 않는 경우 0을 반환합니다. Python의 'in' 키워드와 유사합니다.

127.0.0.1:6379> sadd a 1 2 3
(integer) 3
127.0.0.1:6379> sismember a 1
(integer) 1
127.0.0.1:6379> sismember a 3
(integer) 1
127.0.0.1:6379> sismember a 4
(integer) 0

scard [key]

key의 set에 존재하는 item의 갯수를 반환합니다.

127.0.0.1:6379> sadd a 1 2 3
(integer) 3
127.0.0.1:6379> scard a
(integer) 3

smembers [key]

key의 set에 존재하는 모든 item들을 반환합니다.

127.0.0.1:6379> sadd a 1 2 3
(integer) 3
127.0.0.1:6379> smembers a
1) "1"
2) "2"
3) "3"

그리고 아래의 명령들을 사용할 수 있습니다.

  • srandmember [key] [count=1] : set에 존재하는 item들을 최대 count개 랜덤 선택하여 반환합니다. count에 음수를 전달하더라도 절댓값으로 처리됩니다.
  • spop [key] : set에 존재하는 item을 랜덤하게 선택해 반환하며 제거합니다.
  • smove [source-key] [dest-key] [item] : source에 item이 존재한다면, 해당 item을 source에서 제거함과 동시에 dest로 이동시키며, 이동에 성공한 경우 해당 item을 반환합니다.
  • sdiff [key] [compare-key ...] : compare-key들의 set에 모두 존재하지 않는 item들만 반환합니다. a에 {1, 2, 3}, b에 {1, 2}, c에 {2}가 들어 있는 상태에서 sdiff a b c의 결과는 {3}입니다.
  • sinter [key] [compare-key ...] : sdiff와 반대로, compare-key들의 set에 모두 존재하는 item들만 반환합니다. a에 {1, 2, 3}, b에 {1, 2}, c에 {2}가 들어 있는 상태에서 sdiff a b c의 결과는 {2}입니다.


'데이터베이스 > Redis' 카테고리의 다른 글

[Redis] String(기본 조작)  (0) 2018.09.06
[Redis] List의 고급 커맨드들  (0) 2018.09.06
[Redis] List  (0) 2018.09.06
[Redis] select  (0) 2018.09.06
[Redis] Publish/Subscribe  (0) 2018.09.06

Redis는 0부터 시작하는 숫자 인덱스를 갖는, 논리적으로 독립되어 있는 데이터베이스 구조를 지원합니다. 서로 다른 인덱스의 데이터베이스를 사용하더라도, 이들은 동일한 파일에 함께 유지되므로 완전히 독립된 데이터베이스가 아니라 네임스페이스 개념이라고 생각하는 것이 좋습니다. 그러나 key에 대한 부분은 독립되기 때문에 여러 응용 프로그램에 서로 다른 Redis 데이터베이스를 사용하더라도 key 식별은 걱정하지 않아도 됩니다.

select [index]

데이터베이스 선택은 select를 사용합니다. 기본 인덱스는 0번이며, 0번이 아닌 인덱스가 select된 경우 콘솔에 함께 표시됩니다.

127.0.0.1:6379>
127.0.0.1:6379> select 0
OK
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> select 2
OK
127.0.0.1:6379[2]>

서로 다른 데이터베이스에서 key들은 독립되어 있습니다.

127.0.0.1:6379> set a 123
OK
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set a 456
OK
127.0.0.1:6379[1]> get a
"456"
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> get a
"123"

'데이터베이스 > Redis' 카테고리의 다른 글

[Redis] String(기본 조작)  (0) 2018.09.06
[Redis] List의 고급 커맨드들  (0) 2018.09.06
[Redis] List  (0) 2018.09.06
[Redis] Set  (0) 2018.09.06
[Redis] Publish/Subscribe  (0) 2018.09.06

데이터베이스는 항상 백업과 복구를 할 일이 생기기 마련입니다. MongoDB에서는 dump와 restore를 위해 mongodumpmongorestore를 사용합니다.

mongodump

MongoDB path가 환경 변수로 등록되어 있거나, 아니라면 MongoDB가 설치된 bin 디렉토리에 가서 mongodump 명령어를 사용해 MongoDB 전체나 특정 DB, 또는 컬렉션을 BSON 형태로 덤프받을 수 있습니다.

> mongodump -h localhost
2018-03-23T10:53:19.338+0900    writing admin.system.version to
2018-03-23T10:53:19.339+0900    done dumping admin.system.version (1 document)

...

2018-03-23T10:53:19.351+0900    done dumping dms.refresh_token (2232 documents)

위처럼 mongodump 명령어를 사용하면 MongoDB에 접속해서 데이터베이스의 덤프를 dump라는 폴더 아래에 내려받게 됩니다. DB별로 디렉토리가 하나씩 생기고, 그 아래에 컬렉션 별로 BSON 파일이 생성됩니다. -d 또는 --db, -c 또는 --collection 옵션을 통해 특정 데이터베이스, 또는 특정 데이터베이스의 컬렉션만 덤프받을 수도 있습니다.

> mongodump -h localhost -d test_db
2018-03-23T10:53:53.715+0900    writing dms.refresh_token to
2018-03-23T10:53:53.715+0900    writing dms.notice to

...

2018-03-23T10:53:53.725+0900    done dumping dms.refresh_token (2232 documents)
> mongodump -d dms -c refresh_token
2018-03-23T10:54:33.638+0900    writing dms.refresh_token to
2018-03-23T10:54:33.648+0900    done dumping dms.refresh_token (2232 documents)

다른 옵션들은 mongodump 매뉴얼이나 mongodump --help 커맨드를 이용해 알아볼 수 있습니다.

mongorestore

mongodump를 이용하여 BSON 파일을 얻어냈다면 같은 디렉토리의 mongorestore를 이용해 데이터베이스를 복구할 수 있습니다.

> mongorestore -h localhost ~/dump/

이 경우 mongorestore는 /dump 디렉토리 하위에 있는 데이터베이스별 디렉토리를 순회하며, BSON 파일을 통해 데이터베이스를 복구합니다. 특정 데이터베이스만 복구하려면 -d 옵션과 함께 mongorestore를 수행합니다.

> mongorestore -h localhost -d dms ~/dump/dms/

백업 디렉토리의 하위에 있는 해당 데이터베이스의 백업 디렉토리를 기입하여야 합니다. mongorestore는 단순히 insert만 있기 때문에, 겹치는 데이터가 있더라도 해당 값을 덮어쓰지 않습니다. 복구 전에 존재하는 컬렉션을 없애고 싶다면 --drop 옵션을 사용합니다.

> mongorestore -h localhost -d dms --drop ~/dump/dms/

다른 옵션들은 mongodump 매뉴얼이나 mongorestore --help 커맨드를 이용해 알아볼 수 있습니다.

'데이터베이스 > MongoDB' 카테고리의 다른 글

[MongoDB] 인증(authorization) 추가하기  (0) 2018.09.06

일반적인 RDB의 경우, 설치와 동시에 root 비밀번호를 생성하고 즉시 인증 체계를 생성합니다. 그러나 mongod 커맨드를 입력하여 켤 수 있는 MongoDB Server는 기본적으로 보안 모델이 없이 실행됩니다. 따라서 별도의 인증 절차를 가지고 있지 않습니다. 이 때문에 2017년 1월에는 이런 약점을 노린 랜섬웨어가 발생하기도 했습니다. MongoDB는 되도록이면 외부로부터의 신뢰되지 않은 접속을 허용하지 않는, 보안에 문제가 되지 않는 환경에서 보안 모델 없이 실행하는 것을 지향하고 있으나, 어쨌든 MongoDB도 ID와 비밀번호로 접근하는 기본적인 보안 모델을 가지고 있으니 이를 통해 MongoDB Server에 인증 과정을 추가해 보도록 합시다.

관리자 계정 생성하기

mongod로 별도의 보안 모델이 없는 MongoDB Server를 실행하고, MongoDB Shell에 접속합니다.

> mongo
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.6.3

MongoDB에는 admin이라는 데이터베이스가 존재하며, 해당 데이터베이스에 사용자를 추가합니다.

> use admin
> db.createUser({
    user: 'username',
    pwd: 'password',
    roles: ['userAdminAnyDatabase']
})

db.createUser()현재 사용하고 있는 데이터베이스(여기서는 admin)에 사용자를 추가합니다. 여기에는 사용자 이름, 비밀번호와 함께 권한(roles)을 array로 정의합니다. MongoDB에서 빌트인으로 제공하고 있는 권한은 MongoDB Built-In Roles에서 확인할 수 있습니다.

위에서 정의한 userAdminAnyDatabase어느 데이터베이스든 사용자를 생성하고 제거할 수 있다는 것을 의미합니다. 모든 권한을 가지게 하려면 root를 사용하면 되고, MongoDB 2.4 이하의 경우 db.addUser()를 통해 사용자를 추가합니다.

MongoDB Server 재시작하기

이제 MongoDB shell에서 빠져나와, 별도의 보안 모델을 가진 MongoDB Server를 실행하도록 합시다.

> mongod --auth

Ubuntu와 같은 리눅스 시스템에서 service mongod start처럼 service를 이용할 경우, config 파일을 통해 실행됩니다. 이 경우 /etc/mongod.conf를 다음처럼 수정하고 재시작(service mongod restart)하면 됩니다.

MongoDB 2.x

auth=true

MongoDB 3.x

security:
    authorization: enabled

admin 데이터베이스에 관리자 인증하기

두 가지 방법으로 데이터베이스에 인증을 진행할 수 있습니다. 첫 번째 방법은 쉘에 접속하여 db.auth()를 사용하는 것입니다.

> mongo
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.6.3
...
> use admin
> db.auth('username', 'password')
1
>

위처럼 1이 나오면 성공입니다. 두 번째 방법은, 쉘에 접속하는 것과 동시에 인증을 거치는 것입니다.

> mongo -u username -p password --authenticationDatabase admin

test 데이터베이스로 접속되나, admin 데이터베이스에는 인증이 완료된 상태일 것입니다. 인증과 함께 admin 데이터베이스로 접근하려면, 명령어에 명시만 해 주면 됩니다.

> mongo admin -u username -p password --authenticationDatabase admin

일반 사용자 만들기

성공적으로 관리자 계정을 만들고 인증을 완료했으면, 일반 사용자를 만들도록 합시다. 관리자 계정을 만들었던 것처럼 계정을 만들고자 하는 데이터베이스를 use한 다음 db.createUser()를 실행하면 됩니다.

> use test_db
> db.createUser({
    user: 'username',
    pwd: 'password',
    roles: ['dbOwner']
})

dbOwner라는 권한은 해당 데이터베이스에 대한 모든 수정/삭제 권한을 가진다는 것을 의미합니다. 이번에도 db.auth()를 통해 인증을 진행해 봅시다.

> db.auth('username', 'password')
1
>

MongoDB 공식 매뉴얼의 'enable authentication' 문서가 많은 도움이 되었습니다.

'데이터베이스 > MongoDB' 카테고리의 다른 글

[MongoDB] Dump와 Resotre  (0) 2018.09.06

Request body search에서 모든 leaf query는 context가 존재하며, 이는 query context 또는 filter context로 나뉩니다.

  • Query context : '이 document가 쿼리와 얼마나 잘 일치하는가?'에 대해 응답합니다. 일치하는 정도를 결정하는 것 외에도, 다른 document에 비해 document가 얼마나 잘 일치하는지를 나타내는 _score도 함께 계산합니다.
  • Filter context : '이 document가 쿼리와 일치하는가?'에 대해 응답합니다. Query context의 결과물이 _score였다면, 여기서는 bool(true/false)이 결과물입니다. SQL에서의 WHERE 절과 유사하다고 볼 수 있습니다. '타임스탬프가 2015년과 2016년 사이의 범위인가?', '상태가 "published"인가?' 등과 같은 쿼리가 filter context에 속합니다. 자주 사용되는 필터는 성능을 높이기 위해 ElasticSearch에 의해 자동으로 캐싱됩니다.

아래는 query context와 filter context에 사용되는 쿼리의 예입니다.

위의 쿼리를 해석하면, 아래와 같습니다.

  • "title"이 "Search"라는 단어를 포함하고,
  • "content"가 "ElasticSearch"라는 단어를 포함하고 있어야 하며,
  • "status"가 정확히 "published"이고,
  • "publish_date"가 2015년 1월 1일과 같거나 그 미래여야 합니다.

위 두개의 쿼리는 query context에 속하고, 아래 두개의 쿼리는 filter context에 속합니다. 그리고 위 쿼리에서 사용한 bool, must, filter는 모두 compound query기 때문에 별도의 context가 없습니다.

+ Recent posts