Understanding database - NoSQL 한 장으로 총정리

NoSQL 은 Not only SQL, Non-SQL의 준 말이다. 다양한 종류의 NoSQL이 있으며 내가 여기서 주로 다루게 될 내용은 MongoDB이며 이는 Document-based NoSQL에 해당된다. 각 목적에 따라 다양한 툴들이 있으며 기본적인 개념에 대한 부분은 비슷하다고 생각된다. 물론 해당 툴을 제대로 다루려면 많이 읽고 많이 다뤄봐야 하는 데 사실 모든 툴을 (데이터 베이스만 가지고 놀 것도 아닌 상황에) 다 다뤄보는 건 쉽지 않을 거 같다. 하나의 언어를 선택해서 파고 들어보는 게 해당 개념을 익히는 데 큰 도움이 된다. 실제로 프로젝트를 하나 진행해보고 나서 다시 같은 내용을 읽어봤을 때 더 깊이 그리고 넓게 내용이해가 가능했다는 나의 경험담. 

Key-Value based NoSQL	Riak, Redis, Scalaris, Amazon DynamoDB	말 그대로 키-값 베이스로 한 데이터베이스 언어
Document-based NoSQL	MongoDB, CouchDB, OrientDB	다큐먼트 베이스(SQL 총정리에서 다뤘지만, SQL로 치면 tuple 정도 되는 것이 document라고 할 수 있겠다.)
Column-base NoSQL	Google BigTable, Cassandra, Hbase, Amazon DynamoDB	컬럼 베이스
Graph-based NoSQL	Neo4J, InfoGrid, FlockDB	그래프 베이스

ACID는 이미 언급되었다 시피 관계형 데이터 베이스의 골든 스탠다드라고 할 수 있다. Atomicity, Consistency, Isolation, Durability 를 모두 만족하는 데이터 베이스를 만든다면 최고라고 할 수 있겠다. 이는 보통 전통적인 데이터베이스(i.e. SQL)에서 가능한 조건들이었다. 

하지만 NoSQL의 세계에는 CAP Theorem 를 따른다. 모든 분산 데이터는 3가지 조건(CAP) 중 오직 2가지의 조건만을 충족하며 데이터를 저장할 수 있다. Consistency, Availability, Partition Tolerance 가 그 3가지 이다. 

Figure 1. CAP Theorem(cap 정리)

The BASE Property 는 다시 아래와 같이 정의된다. 

1) Basically Available : DDB(분산 데이터 베이스)는 항상 CAP theorem을 따른다. 

2) Soft state: 시스템 상태는 데이터 트랜젝션(데이터 베이스에 변화를 주는 작업들)이 수행되지 않더라도 변화할 수 있다. 

3) Eventually Constancy: 시스템은 결국은 일관성을 갖게 될 것이다.

만약 가용성과 분할 내성이 보장되는 상황이라면, 분산 데이터 베이스를 다룰 때 일시적 데이터가 불일치하는 경우(일관적이지 않는)는 허용이 된다. 언젠가는 결국 일관성을 갖게 될 것이기 때문이다. 그래서 중앙 집중적인 데이터 베이스에서는 ACID 대신 BASE Property를 따른다. (중앙 집중식 데이터는 하나의 데이터 베이스 저장소를 가지는 것이고 분산 데이터 베이스는 여러 개의 데이터 베이스 저장소를 가지는것이다 - 파티션분할, 이 부분은 마지막쯤에서 다뤄질 예정이다) 

 

MongoDB는 일반적인 목적으로 주로 사용되며 분산 데이터 베이스를 채택하여 사용이 가능하다.(클라우드)

• SSPL(Licensed under the server-side public license),
• SQL joining 대신에 lookup 이라는 것을 사용한다.
• 데이터 베이스 이름은 대소문자를 가리며 각 64 바이트를 넘길 수 없다. 
• 모든 다큐먼트들은 각각 16 MB를 넘길 수 없다. 
• JSON 파일의 binary-encoded 된 BSON이라는것이 사용되어 진다. 
• 데이터 타입이나 대소문자를 잘 구별해서 사용해야 한다. 
• 각 다큐먼드 들은 유니크한 _id가 있어야 한다(sql 의 pk와 같은 역할을한다.) -> 만약에 따로 지정하지 않는 다면 자동으로 생성 및 업데이트 되며 이를 objectID라고 한다. 보통 이는 데이터 입력되는 시간과 날짜 정보를 포함하고 있다. 

MongoDB 도 CRUD(Create Read Update Delete)를 수행할수있다. 일반적으로 많이 쓰이는 코드를 위주로 정리해보고자 한다. 

다음은 조건부여 시 많이 사용하는 코드이다. 

$eq( 같은 값 ), $gt(큰 값), $gte(크거나 같은 값), $in(뒤에 따라 오는 배열에 포함되어 있는지), $lt(less than), $lte(less than or equal), $ne(not equal), $nin(Non in an array) 

다음 은 그 박에 수정 및 데이터를 읽기 위한 코드들이다. 

데이터 입력
db.product.insertOne({"category": "fruit", "name":"Apple from Uleumgol"});
db.product.insertMany({"category": "fruit", "name":"Apple from Uleumgol"},{"category": "fruit", "name":"Banana from Ulsan"} );
데이터 찾기 
db.product.find({"pyears":{$gte:3}, {"age": {$lte:50}});
데이터 업데이트 
db.product.updateMany({"pyear": {$gte:3}}, 
					  {$set: "status.finished":1, "status.ongoing":0}}
                     );
데이터 삭제
db.product.deleteMany({"finished": 1, "ongoing":0});

그 박에 활용 많이 되는 코드 들 

$set: 값 설정하기, 만약 해당 열이 존재하지 않으면 열을 데이터에 추가하고 값을 추가한다. 기존 데이터 유형이 새로운 입력된 유형으로 바뀌기도 한다. 
$unset: 열 값 삭제
$inc: 값을 하나씩 증가시킨다. 만약 해당 열이 없다면 열을 생성하고 1로 지정한다. 
$push: 배열 값을 추가하는데 만약 해당 배열이 없다면 새로 생성한다. 
$addToSet: 배열의 구성요소를추가한다. 하지만 배열요소의 중복은 피한다. 
$pull: 배열의 요소를 제거한다. 
$pop: 순서에 따른 값을 제거한다. 예를들어 {$pop:{"key":1}} 배열값의 맨 마지막 값을 제거한다. 
{"upsert": true}: 다큐먼트가 없다면 새로 추가하고 있다면 업데이트 한다.

MongoDB 에서 쿼리만들기를 쉽게해주는 기능 중 하나는 Aggregation이다. 집계라는 그 뜻과 같이 여러 가지의 단계를 연달아서 수행할수 있도록 해주는 역할을 한다. 다시 말하면 다양한 기능을 쌓아 올리면서 원하는 결과를 도출해낼 수 있는 방법이다. 실제로 MongoDB Compass 를 사용하면 각 단계의 예상 결과값을 실시간으로 보여주기 때문에 처음 쿼리를 도전하는 사람이라면 compass로 연습해보면 좋을 거 같다. 

Aggregation에 다양한 명령어들이 있는 데 모두 중요하고 다양하게 활용해보면서 배우는 걸 추천한다. 이에 관해서는 사실 MongoDB 공홈 만큼 잘 되어 있는 곳은 없는 것 같다.

제일 많이 쓰이는 건

$project : 다큐먼트의 구성을 원하는 요소만으로 바꿀 추릴 수 있다.

$unwind: 배열 요소를 분리하여 여러 개의 다큐먼트로 보여준다. (가장 많이 사용한 듯) 

그 밖에도 많은 데 자세히 다루긴 많으므로 이 부분은 다음 기회에 코딩하는 부분만 따로 다뤄봐야 겠다. 

 

INDEX

MongoDB는 Schemaless 데이터 베이스기 때문에 이론적으로 온갖 다른 형태의 다큐먼트를 하나의 컬렉션에 다 때려 넣을 수 있다. 

예를 들어 국어사전을 생각해보자. 국어사전에서 행복이라는 단어를 찾기 위해서 1페이지부터 마지막 페이지까지 모두 다 읽어나가는 방법이 있을 수 있겠지만, 우리는 그거보다 더 효율적인 방법을 안다. ㅎ 이라는 인덱스를 찾아서 해당 페이지를 찾고 다음 단어의 모음 자음 순서를 토대로 원하는 답을 찾아낸다. 

또 다른 예시를 찾아보자. 만약 스칼렛이라는 서울 강남구에 사는 여자를 찾고자 한다. 서울 강남구에 집들을 한 군데씩 다 들러서 스칼렛이 나타날 때까지 뒤져볼 수도 있곘지만 아~~~주 오랜 시간이 걸릴 것이다. 만약 우리가 스칼렛의 집 gps 주소를 알고 있다고 해보자. 우리는 단 숨에 스칼렛 집의 위치를 찾아낼 수 있다. 

이 처럼 검색의 속도를 효과적으로 높여주는 역할을 하는 것이 바로 INDEX(인덱스) 이다. 빨리 원하는 정보를 찾기 위한 지표와 같은 것이기 때문에 인덱스 지정을 하는 것이 효과적이기는 하지만 모든 필드를 인덱스로 지정하는 것은 오히려 역효과가 날 수도 있다. 

왜냐하면 데이터를 읽는 속도는 인덱스를 활용하면 빠를 수 있지만, 인덱스로 지정된 필드의 값을 업데이트 하거나 추가하는 것은 더 오랜 시간이 걸리기 때문이다. (인덱스 값을 매번 새로 산정하고 또 인덱스 리스트가 따로 메로리 영역을 차지한다) 그래서 메모리 측면에서도 속도 측면에서도 불필요한 필드의 인덱스를 설정하는 것은 피하는 것이 좋다. 

인덱스로 사용될 수 있는 키로는 단독 필드 뿐만 아니라 두개 이상의 키로 조합된 compound index도 설정이 가능하다. 보통 싱글 인덱스의 경우엔 순서 정렬이 중요한 의미가 없지만, compound index의 경우 얘기가 달라진다. 만약 compound key를 설정하고 정렬을 하려고 한다면 compound key 의 순서가 중요하다. 아래 예시에서 처럼 나이, 이름으로 된 인덱스를 생성하였다면 나이, 이름 순으로의 정렬을 하는 것은 가능하지만 설정의 순서를 이름, 나이로 변경할 수는 없다. 그 이유는 다음과 같다. 만약 나이-이름으로 인덱스를 설정하면 각 나이 별로 이름을 순서대로 정렬한다. (나이로 그루핑이 되는 셈) 그런데 만약 내가 이름 순서대로 먼저 정렬을 하고 싶다는 것은 이름으로 그루핑을 하겠다는 건데 그렇게는 불가능하다는 것이다. 그럴 땐 이름-나이 순으로 인덱스 지정을 해줘야 한다. 

db.users.createIndex({"age":1, "username":1}); 
db.users.find( {"age":21 }).sort({"username":1}): 
//나이 21세를 찾아(그룸 나이=21) 이름 별로 정렬(이미 index가 정렬되어 있을 것임) 

db.users.find({"age": {"$gte":21, "$lte":30}}): 
//나이가 21-30세 사이인 데이터(21세부터 30세사이의 그룹), 각 그룹 내에 이름 별로 정렬되어 있다. 

db.users.find({"age": {"$gte":21, "$lte":30}}).sort({"username":1}): 
//마찬가지로 정렬이 되지만, 전체적으로 보았을 때는 이름은 순서대로 정렬되어 있지 않다. 
//다만 각 나이 그룹 안에서는 인덱스로 인해 순서대로 정렬되어 있다.

3번 째 4번 째 쿼리의 결과 : 21세부터 29세 사이의 값이 포함되어 있으며 각 그룹안의 이름은 순서대로 정렬되어 있다.

스키마 디자인을 할 때 고려해야 할 것이 무엇이 있을까? NoSQL은 스키마리스 데이터 베이스라고 한 마당이지만 마찬가지로 데이터 베이스 모델 설계 과정은 중요하다. NoSQL에서 고려해야 할 사항들은 다음과 같다. 

1) 제한 사항: 데이터 베이스나 하드웨어적인 제한들이 있는가? 

2) 접근 패턴 : 작업량이 얼마나 될 지 어떤 것들이 있을 지를 고려하여 패턴을 결정해야 한다.

3) 관계 유형: 이는 사용하게 될 어플리케이션에서 어떤 데이터를 주로 필요로 할 지에 따라 달라진다. 읽기 위주인지 쓰기 위주인 지 등에 대해 언급될 것이다. 

4) 카디널리티: SQL과 만찬가지로 다대다, 다대일 등의 관계를 파악해야 한다. 

 

먼저 스키마 디자인 패턴에 대해서 간단하게 아래와 같이 정리했다. 

Bucket Pattern	이는 타임시리즈 데이터에 적합하다. 버켓 패턴의 경우 어떤 도큐먼트 하에 계속 데이터를 저장하다가 미리 저장해둔 양을 초과하는 경우 새로운 다큐먼트를 생성하여 계속 저장하도록 하는 역할을 한다. 예를 들어, 1 시간 동안 발생한 센서 데이터만 저장하도록 하는 경우, 1시간 내에 발생한 데이터가 모두 저장되면 새로운 도큐먼트를 만들어서 또 새로운 1시간동안의 데이터를 저장하는 방식으로 사용될 수 있다.
Outlier Pattern	어떤 데이터에 갑자기 이상치로 추정되는 대용량 데이터가 들어왔을 때 별개의 도큐먼트로 해당 데이터를 저장하도록 하는 방법이다. 이 때 has_extras: true라는 필드가 추가될 것이고 이를 통해 우리는 별개의 도큐먼트도 확인해야 된다는 걸 알 수 있게 된다. 예를 들어, 도서 판매량이 각 도서마다 추가된다고 했을 때, 1000만권을 넘어가는 값을 이상치로 설정하는 경우 도서판매량이 이상치 값을 넘는 경우 도서판매량에 대한 정보를 새로운 도큐먼트로 별개 저장을 하는 방법이다.
Computed Pattern	다른 필드의 값을 계산해서 얻어지는 평균 평점 등과 같은 값이 필요할 때 필요한 데이터를 읽을 때마다 계산하는 방법과 데이터를 업데이트 할 때 계산을 미리 해놓는 방법이 있을 수 있다. 이 패턴은 보통 후자의 경우에 해당된다. 예를 들어 후기를 작성하는 경우 보통 후기 작성률이 0.1%라고 했을 때 각 물건을 읽는 횟수가 후기데이터를 업데이트하는 횟수보다 극도로 크다. 그래서 각 물건 데이터를 읽을 때마다 계산을 하는 것이 계산 횟수가 훨씬 크다는 것을 의미한다. 그렇기에 반대로 데이터를 쓸 때 전체 후기의 갯수와 해당 물품의 후기 총합을 계산해서 가지고 있다가원하는 물건의 평균값만 읽을 때 (두 개만 불러서) 계산할 수 있는 방법을 취할 수 있다.
Extended Referencing Pattern	자주 참조하는 필드의 내용만 내재하도록 만드는 방법이다. 예를 들어 주문과 관련된 컬렉션이 있을 때 주문한 고객의 이름과 주소 정보를 매번 고객 컬렉션에 가서 가져오거나 아니면 고객 정보를 전부 복사해서 이중으로 주문에 저장하는 방법 대신 필요한 주소와 이름 필드만 주문 컬렉션에 추가로 저장하는 방법이다. 이때 이 참조되는 데이터는 되도록이면 자주 바뀌지 않는 경우에만 유용하다. 이렇게 하는 경우 일부 데이터가 중복될 수는 있으나 매번 컬렉션들을 조인하는 것을 피할 수 있다.
Approximation Pattern	많은 리소스가 필요한 계산을 해야할 때, 만약 그 결과값이 근사값으로 표현되어도 큰 문제가 되지 않는 상황에 사용될 수 있다. 에를 들어서 총 웹사이트 접속자 수 900,000과 를 계산할 때. 900,001과 900,000는 큰 차이가 없다. 그래서 100 정도(?), 혹은 매번 1%의 값이 상승했을 때 값이 업데이트 되도록 하는 방법이 있을 수 있다. 여러가지 방법이 있을 수 있지만 이는 결과값의 정확도가 크게 중요하지 않는 상황에 활용될 수 있다.

Normalization(Referencing-외부 참조 문서) vs Denormalization(Embedding- 내재된 문서) 

SQL과 달리 모두 정규화를 하지 않는 NoSQL은 정규화를 한 문서를 레퍼런스 문서라고 하고, 이는 데이터 간의 관계를 통해서 정의될 수 있다. 정규화가 안된 상태로 하나의 문서에 내재되어 모두 같이 표현되어 있는 경우 내재된 문서라고 한다. 하나의 필드 혹은 배열의 형태로 저장될 수 있다. 아래는 몇 가지 특징을 정리해 둔 표이다.

Embedding (내재 문서)	Referencing  (참조 문서)
빨리 읽기 가능 (하나의 쿼리로 원하는 정보 모두 취득가능) 모두 하나로 저장하니까 추가 문서 수가 적다.  데이터 내용이 자주 바뀌지 않을 때 유리(쓰기 느리므로) eventual consistency 허용가능한 경우 (항상 동기화된 데이터를 유지하기쉽지않음) 각 도큐먼트가 차지하는 공간은 많지만 데이터가 자주 추가되지않으므로 조금씩 크기가 커진다.  데이터를 가져오려고 두 번째 쿼리를 써야하는 경우 대신 사용한다.	빨리 쓰기 가능 (해당 필드만 업데이트하면 되니까)  따로 떼어내서 문서로 저장해야 하니 추가적으로 문서 수가 많아진다.  자주 변동되는 휘발성 데이터에 용이(쓰기 빠르니까) 즉시 데이터의 일관성이 요구되는 경우 크기가 조금 더 큰 크기로 커진다.  보통 결과로부터 자주 제외되는 데이터(읽어낼 필요가 별로 없는)의 경우

PyMongo

대부분의 데이터 사이언스를 공부하는 사람들은 파이썬을 기본적으로 다루는 것 같다. 그 만큼 파이썬이 호환성도 좋고 확장성도 좋다. 

MongoDB도 BSON(JSON의 이진법 형태로 쓰인 언어)를 사용해서 Python에 연결하여 이용할 수 있고 PyMongo라고 부른다.  아래와 같이 Python 인터페이스에서 사용자는 JSON를 사용하고 중간에 Python app과 PyMongo driver 가 BSON 형태로 NoSQL과 소통하여 결과를 처리하는과정이다. 

사용자 쪽  JSON 사용 (Python)

Python App  & PyMongo Driver

NoSQL BSON 사용 (MongoDB)

python -m pip install pymongo
python -m pip install dnspython
// MongoDB Atlas랑 연결하기 위해서는 이것도 설치해야 한다. 

import pymongo
from pymongo import MongoClient

conn_str="mongodb+srv"://<username>:<password>@<cluster-name>.mongodb.net/myFristDatabase"
client = MongoClient(conn_str, serverSelectionTimeoutMs=5000)

try:
     print(client.server_info())
except Exception:
     print("Unable to connect to the server.")

 

몽고 디비는 그다지 부지런하지 않다고 한다. 그래서 첫 번째 다큐먼트가 추가될 때까지 어떤 작업도 진행되지 않는다고 한다. 그래서 3개의 명령이 동시에 시행된다. (딕셔너리 스타일; [ ] 혹은 속성 스타일; db.objectname.fieldname 접근 두 가지 방법이 있다.) 

- 데이터 베이스와 컬렉션 생성, 다큐먼트 입력이 동시에 하나의 쿼리로 작성된다. 딕셔너리 타입의 경우 데이터베이스와 컬렉션 이름 같은 것들을  [ ] 안에 담아서 표현하는 반면(client["OnlineStore"]), 속성 타입은 client.OnlineStore과 같은 형식으로 표현된다. 

##Dictionary-Style Access
myDB = client["OnlineStore"]
myCollection = myDB["phones.items"]

item_1={
"_id": "ewubkjdsk244",
"name": "iphone 13"}

myCollection.insert_one(item_1)
print(myCollection.inserted_id)   //데이터 입력 여부 확인하기 위해 테스트 출력

#########################################
##Attribute-Style Access
myDB = client.OnlineStore
myCollection = myDB.phones.items

item_1={
"_id": "ewubkjdsk244",
"name": "iphone 13"}

myCollection.insert_one(item_1)
print(myCollection.inserted_id)

그리고 입력한 데이터를 읽는 건 아래와 같이 표현할 수 있다. 

##Dictionary-Style Access
import pprint                        //JSON format으로 출력해서 보여주는 역할 
myCollection = myDB["phones.items"] 
user1_items=myCollection.find()     
for item in user1_items:
	pprint.pprtin(item)

#######################################
##Attribute-Style Access
import pprint
myCollection = myDB.phones.items
user1_items=myCollection.find()
for item in user1_items:
	pprint.pprtin(item)

//Python 형태로 결과와 문자열을 혼합하여 사용 가능하다. 
myCollection = myDB.laptops.items 
user2_items = myCollection.find() 
for item in user2_items: 
print( item2["item_name"] + " is in the " + item2["category"] + " category")

--> 결과적으로 
Macbook Pro 2 is in the electronic category

//여러개의 다큐먼트 입력하기 
item_1 ={
	"_id": "hvjh399"
}

item_2 ={
	"_id": "hvjh400"
}

item_3 ={
	"_id": "hvjh401"
}


new_items=[item_1, item_2, item_3]  //item 1,2,3을 배열값으로 저장 

////

myDB = client["OnlineStore"]        //데이터베이스 생성
myCollection= myDB["phones.items"]  //컬렉션 생성
myCollection.insert_many(new_items) //여러 개의 다큐먼트 한번에 입력

Python의 장점 중 하나는 다양한 시각화를 쓸 수 있다는 저인데 마찬가지로 판다스를 연결하여 사용하는 방법을 간단하게 다뤄본다. 

import pandas as pd                  //판다스
all_items = myCollection.find()      //all_items라는 변수에 마이컬렉션에 있는 데이터 모두 추출
items_df = pd.DataFrame(all_items)   //해당 데이터를 데이터프레임으로 변환 
items_df                             //데이터 프레임으로 바뀐 결과 출력

파이썬으로 연결하여 사용하는 방법은 간단하게 이 정도로 정리한다. 

 

다음은 분산된 데이터베이스 시스템에 대해 다뤄보고자 한다(DDB). 가장 처음 이 부분에 대해서는 언급한 적이 있는 있는 데 MongoDB는 파티션이라던지 같은 기능을 활용하여 데이터 베이스의 저장 위치나 저장 방법을 다양하게 적용할 수 있다. 그로 인해서 Partition tolerance를 보장할 수 있게 된다. 다시 한번 설명하자면 Partition tolerance는 CAP theorem 의 한 요소로써 하나의 파티션이나 하나의 데이터베이스에 손상이 왔다고 하더라도 사용하는 사용자 입장에서는 해당 사실을 인지하지 못 하도록 대책이 마련되어 있는 상황이라고 할 수 있다. 

 

데이터 시스템이라고 하면 다양한 데이터 저장 기술들을 합쳐놓은 것을 의미한다. 실제로 다양한 기업들은 하나의 툴만 이용하는 것이 아니라 다양한 데이터베이스 시스템들을 조합하여 사용하고는 한다. 캐쉬나 인덱스 그리고 데이터 같은 것들도 모두 동기화되며 어플리케이션에 저장된다. API(Application programming interface)는 이런 뒤에서 일어나는 복잡한 작업들이나 구조를 가리고 사용자에 사용 편리한 화면만을 제공해주는 역할을 한다. 사용자가 API를 통해서 어떤 작업을 요청하는 경우 작업을 처리하는 방법은 크게 3가지로 나뉘어진다. 

1. In-memory cache: 먼저 캐쉬된 데이터가 있는 지 먼저 확인 한다. (만약에 이미 읽어둔 데이터가 있으면 또 전체 데이터를 훑을 필요가 없기 때문에)

2. Primary Database: 캐쉬된 데이터가 없다면 주요 데이터베이스에 일단 쓰기를 진행한다. 데이터에 변화가 생기면 이를 인덱스에 반영하고 캐쉬 메모리에도 전달한다. 

3. Full-text index: 인덱스 데이터도 따로 저장된다고 했는 데 이 인덱스 파일을 뒤져서 혹시 찾는 결과가 있는 지 확인해본다. 

만약에 예를 들어 이메일을 보내는 것과 같이 바로 결과 반영이 될 필요가 없는 경우에는 비동기 작업으로 진행되기도 한다. 

Martin Kleppmann, 2020

다음 3가지 사항은 데이터 시스템을 설계하는 데 있어서 고려할 수 있는 세가지 쥬요 요소라고 볼 수 있겠다. 신뢰성있고 확장이 가능하며 유지가 가능한 데이터베이스를 설계할 수 있어야 겠다. 

Reliability	Scalability	Maintainability
* 사용자가 예상한 대로 작동! * 사용자가 실수해도 문제 발생 x * 사용자가 원하는 사용에맞는 충분한 성능 * 인가되지 않은 접근이나 잘못 사용되는 것을 막을 수 있는 능력	* 작업량 늘어나도 커버 가능한 성능 * 부하매개 변수를 이용한 작업량 설명이 가능(예상 로드) * Fan-out(쿼리 수 확인)등을 통한 작업량 설명 가능  * 쓰루풋을 측정한 성능확인(배치별 처리) 혹은  반응 시간(online system)	* Operability: 무난하게 잘 작동되도록 유지하는 게 어렵지 않음  * Simplicity: 새로운 엔지니어가 보기에도 이해하기 어렵지 않음 * Evolvability: 수정하기 너무 어렵지 않고 예측하지 못한 상황에 대해서 변화를 적용하기 어렵지 않음

 

다음 질문은 수업 중에 실제 사례를 반영한 질문이다. 같이 생각해보면 좋을 거 같다. 

트워터의 경우 사용자가 새로운 메세지를 그들의 팔로워들한테 게시한다. 그러면 사용자는 자기가 팔로우한 사람들이 올린 트윗들을 읽을 수 있게 된다. 두 가지 디자인이 고안되어 있다. 어떤 방법이 더 효과적일 까? 

1. 팔로워 테이블, 사용자 테이블 그리고 트윗 테이블을 모두 별개로 만들고 각 테이블이 팔로우 테이블을 참조하여 원하는 데이터를 찾아내서 출력하도록 하는 방법

2. 팬아웃(fan-out)방법을 활용하여  트윗을 각 팔로워들 마다 31M까지 버케팅하여 저장하도록 하는 방법이다. 그러니까 이미 팔로워별로 트윗 리스트를 다 만들어둔 상태로 팔로워들은 본인의 트윗리스트를 확인 하는 셈이다. 

실제로 트위터에서 과거 1번의 방법을 사용하다 현재는 2번의 방법을 적용하고 있다는 것이 교수님의 대답이었다. 1번의 경우 읽는 시간과 쓰는 시간의 차이로 인해 최신 데이터를 읽어오지 못하는 경우가 발생할 수도 있다는 단점이 있고 속도가 느리다. 하지만 2번의 경우 타임라인에 따라 트윗을 이미 다 줄지어 저장해놓고 팔로워들별로 자기 결과 리스트가 있으니 앱에 접근했을 때 더 빠른 속도로 결과를 읽어올 수 있다. 

 

확장성은 NoSQL의 장점 중 하나이다. SQL의 경우 수직 확장만 가능했고 수평 확장을 하기 위해서는 데이터 구조를 새로 설계해야 하는 불편함이 있었다. 하지만 NoSQL은 수직, 수평확장이 모두 가능하다. 데이터 측면 뿐만 아니라 데이터 저장 방법 측면에서도 적용되는 부분이다. 예를 들어 수직 확장 데이터 저장을 한다는 것은 더 성능이 좋은 하드웨어를 도입하며 스케일업하는 방법인데, 요즘은 잘 사용되지 않는다고 한다. 실제로 사용되는 방법은 수평적 확장 방법이다. 이는 여러 개의 하드웨어에 데이터 인스턴스들을 나누어서 저장함으로 인해 각 하드웨어 부가되는 로드를 나누는 방법이다. 보통 예전 수직적 확장을 적용했을 때는 centralised database 구조였으며 하나의 데이터베이스 센터에 모든 데이터를 저장하고 필요한 로컬 컴퓨터에서 필요한 정보를 가져와 사용하는 방법이었지만, 언급했듯이 하드웨어의 성능을 끈임없이 높이는 데는 한계가 있고 또한 만약 저장된 기계에 문제가 생겨 데이터에 손실이 오는 경우 복구에도 문제가 있을 수 있다. 

그렇기 때문에 현재 사용되는 방법은 분산된 데이터베이스 시스템이다. 즉 하나의 데이터 저장 매체가 아닌 여러 군데에 흩어져 있는 하드웨어에 데이터를 분산하여 저장하는 방법을 택하여 성능을 보완함과 동시에 데이터 손실의 부담도 줄일 수 있다. 

 

Replication(복제)

내 개인 데이터를 저장할 때도 항상 복제본을 두는 것이 나는 습관화되어 있다. 하드웨어와 클라우드에 나누어 저장하고 버전을 나누어 관리하기도 한다. 마찬가지로 데이터 베이스를 복제본을 두어 관리하는 방법을 레플리케이션이라고 한다. 같은 데이터를 여러 개의 사본을 만들어 네트워크로 연결이 가능한 여러 대의 기계에 나누어 저장하는 방법이다. 이렇게 했을 때 나누는 방법에 따라 다음과 같은 복제의 이점이 발생한다.  1) 지역별로 사용자와 가까운 위치에 있는 데이터를 사용할 수있게 할 수 있고 2) 데이터의 가용성이 높아지고(혹시나 하나의 기계에서 실패해도 바로 다른 기계로 요청하여 결과 전달) 또 3) 읽기 속도가 빨라진다. (원래는 하나의 기계에서 전 세계인의 읽기 쓰기를 진행했다가, 이제는 각 나라별로 읽기와 쓰기를 따로 한다고 하면, 왜 당연히 속도의 향상이 있을 수 밖에 없는 지 생각해볼 수 있을 거 같다)

복제 방법은 여러가지 방법이 있다.  1) Single Leader : 리더 데이터가 하나만 있는 경우이며 리더, 마스터 혹은 프라이머리 데이터 베이스라고 부른다. 보통은 리더 데이터베이스는 쓰기(데이터 업데이트, 수정)에 쓰이고 나머지 팔로워 데이터베이스(세컨더리, hot standby, slave, read replica)들은 읽기에 쓰인다.  2) Multi-Leader : 리더가 여럿 있는 경우이다.  3) Leaderless: 리더 데이터베이스가 없이 모두 평등한 경우-2,3은 아래에 내용 추가 

복제의 과정은 1) 복제본 중 하나를 리더로 선정 2) 다른 복제본들은 팔로워 3) 읽는 건 리더나 팔로워에소 모두 가능(제약 어떻게 하냐에 따라 달라질 수 있다) 

동기화 복제와 비동기화 복제로 나눠어 지는 데 동기화 복제(Synchronous)의 경우 데이터가 항상 일관성을 유지할 수 있다. 하지만 만약에 팔로워(세컨더리) 데이터베이스가 사용자의 요청에 대하여 반응하지 않는 상황이 발생하는 경우, 데이터 입력이 안될 수도 있다. 반면에 비동기화 복제(Asynchronous)의 경우는 일관성이 항상 유지되지는 않지만 결론적으로는 결과가 모두 반영된다. 그렇기 때문에 읽기와 쓰기가 각각 작동하기에 하나의 작업이 다른 작업에 영향을 주지 않고 작동이 정상적으로 된다. 하지만 서로 다른 사용자의 읽기와 쓰기 시점에 따라 다른 결과를 출력할 수도 있다는 단점이 있다. 

비동기화 복제의 겨우 replocation lag 라는 상황을 겼을 수 있는 데 이는 리더 데이터 베이스가 수정되고 나머지 팔로워 복제본 들에 수정이 반영되는 데 걸리는 지연 이라고 볼 수 있다. 하지만 항상 데이터는 결과적으로는 일관성을 유지하도록 되어 있다.

다음과 같은 문제 사항에도 그 해결책이 같이 제시되어 있다. 복제 방법을 적용할 때에 고려해야 하는 것 중 하나로 Node Outage의 상황이 있을 수 있다. 여기서 노드라고 하면 각 복제본이 저장되어 있는 곳을 의미한다. 만약 팔로워(세컨더리)복제본에 문제가 발생하는 경우에는 "catchup recovery" 전략으로 복구한다. 문제가 있는 동안 반영되지 않은 것들이 반영되어 최종적으로 일관적인 데이터를 가질 수 있도록 한다. 만약 리더 복제본에 문제가 발생하는 경우는 "failover"(장애조치)라고 하며 다음과 같은 방법으로 일반적으로 극복한다. 1) 리더에 문제가 있음을 판단 2) 새로운 리더를 다른 복제본 중에서 선정한다(투표과정을 거침) 3) 시스템에 새로운 리더를 인지 및 활용할 수 있도록 한다.  

Replication Lag의 문제 사항을 조금 더 구체적으로 정리해 보았다. 

1. 오래된 데이터를 읽는 상황(Reading stale data solution)의 해결책 : 데이터를 사용자가 작성한 곳에서 읽어온다. (다른 복제본들은 아직 다 업데이트 안되었을 수 있으므로) 그래서 읽기와 쓰기를 모두 리더로 부터 하도록 설정할 수 있다. 비동기화복제기 때문에 다른 복제본들이 모두 업데이트되는 데 조금 지연이 있을수 있다. 

2. 과거로 가는 시간여행(Backward Time travel) 해결책: 단조적 읽기 방법, 각 사용자마다 데이터를 하나의 지정된 복제본에서만 읽도록 설정할 수 있다. (매번 다른 복사본에서 읽어오도록 하는 것 보단) 사용자 A는 복제본 1에서만, 사용자 B는 복제본 2에서만 읽도록 하는 방법이다. 그 이유는 각 복제본마다 데이터의 수정이 반영되는 시점이 조금씩 상이하니까. 

3) 관찰자데자뷰(Observer Dejavu) 해결책: 일관된 접두사 읽기, 관찰자(제 3자의 사용자 -수정 안하고 읽기만 하는)의 경우 나중에 입력된 데이터를 먼저 읽게 되는 가능성도 있다. 이를 위해 데이터를 순서대로 입려되도록 하고 항상 일관된 접두사만 보이도록 해야 한다. 그리고 모든 관련된 데이터는 같은 파티션에 저장되도록 한다. 

 

실제로 복제본을 만드는 것 외에도 물리적으로 추가 데이터 센터를 활용할 수 있다. 그리고 여기에 각각 리더 데이터베이스를 두는 multi-leader 복제 방법을 적용할 수 있다. 이렇게 하는 경우 성능 향상, 데이터센터 내성(데이터센터에 사고나거나 네트워크문제 생겨도 커버 가능), 사용자가 만약에 오프라인데이터(달력)를 사용하거나 콜라보레션 편집 작업을 할 때에 사용될 수 있다. 

하지만 리더가 둘이다보니 수정작업을 하는 데  갈등이 발생할 수 있다.(Write Conflicts) 그 해결책은 다음과 같이 5가지로 정리해보았다. 1) 갈등을 탐지하는 것을 동기식으로 만든다. 2) 특정 레코드에 대한 쓰기는 모두 같은 리더를 통해서 되도록 지정 한다. 3) 각 쓰기 작업에 유니크한 아이디를 지급하고 더 최신에 쓰인 것이 항상 선택되도록 한다. 4) 모든 정보를 보존하는 명시적인 데이터 구조에 충돌을 기록한다. 5) 먼저 갈등이 되는 걸 둘 다 저장해뒀다가 나중에 자동으로 어플리케이션이 수정하거나 사용자가 수정하도록 한다. 

Leaderless replication 은 쿼롬 읽기 쓰기를 한다.  읽기 수정(오래된 데이터). 안티 안트로피 과정(일부 데이터의 경우 자주 읽히지 않고 저장만 되어 있는 경우, 손실될 수도 있다).  보통 데이터를 쓸 때 리더에 쓰기가 완료되면 Acknowledge 라는 신호를 보내는 데, 이 경우엔 데이터의 n./2+1의 노드가 모두 반영되야지만 ok사인을 보낸다. 즉 5개 중 3개 이상의 복제본에서 read 요청에 대한 반응을 보내거나, write 요청에 대해서 확인이 와야지만 작업이 된다는 원리이다. 

 

다음으로 복제만큼 중요한 파티션(몽고디비에서는 샤딩이라고 칭한다)를 다뤄보겠다. 

Partitioning(Sharding) 은 말 그대로 구간을 나누는 것을 의미한다. 보통 복제본을 만들고 또 샤딩도 같이 하여서 데이터를 저장하는 것이 일반적이다. 샤딩을 함으로 인한 좋은 점은 여러 노드들에 대해 실패내성이 생긴다는 것이다. (하나의 복제본에서 실패해도 다른 파티션에 저장된 복제본을 참조하면 됨) 파티션을 하는 방법은 key range 방법과 hash of key방법이 있다. key range 방법은 말 그래도 키의 범위를 지정하여 특정 범위 별로 데이터를 저장하는 방법이고 hash of key 는 해쉬태그로 키의 범위를 임의로 설정하여 저장하는 나누는 방법이다. range 별로 서정하는 경우 한 영역으로의 치우침 혹은 몰림 현상 같은 것들이 발생할 수 있기 때문에 hash of key 방법을 사용한다. (예를 들어 이름을 성씨별로 나누었을 때 극도로 김씨, 박씨, 이씨 등에 몰릴 것이고 반면 황보씨에는 적은 데이터가 저장될 것이다) 단, 쿼리를 짤 때 범위별로 효과적으로 짜는 것은 어려워진다.( 임의 범위이기 때문에 임의로 모두 지정해줘야 함 ) 

 

Rebalancing. 계속 데이터를 사용하고 시간이 지나면서 쿼리 쓰루풋(처리량)이 증가하여 더 많은 CPU가 필요하게 될 것이고 데이터 크기가 커져서 더 많은 디스크와 랩이 필요하게 될 것이며 만약 특정 하드웨어에 실패가 되는 경우 다른 하드웨어가 해당 역할을 떠맡는 일이 생길 수도 있다. 이러한 경우들에 우리는 데이터가 모두 공평하게 잘 나눠서 저장되고 시스템이 다운되는 일이 없도록 하길 원한다. 이에 Rebalancing 작업을 할 수 있는 데 그 방법으로는 파티션의 숫자를 바꿔주는 것이다. 예를 들어 기존에 4개의 노드에 5개의 파티션들이 저장되어 있었다면 이를 5개의 노드에 4개의 파티션만 저장해주는 것이다. 이렇게 재분산함으로써 문제를 해결해볼 수 있다. 

 

Request Routing. 그 밖에도 사용자가 노드를 접근하는 방법에 차이를 줄 수 있다. 1) 사용자가 랜덤으로 하나의 노드를 선택하고, 선택된 노드가 해당되는 노드의 정보를 전달받아 출력하는 방법(노드가 위치를 알고 있음) 2) 사용자가 rounting tier에 모든 요청을 보내고 해당 routing tier에서 해당되는 노드로 정보를 요청하는 방법(라우터가 위치를 알고 있음) 3) 고객이 어떤 파티션에 어떤 노드인지 알고 해당 노드에 요청을 보내느 방법이 있다.(고객이 위치를 알고 있음)

Martin Kleppmann (2020)

 

데이터 모델링 (RDBMS vs MongoDB) 

전통적 관계형 데이터 베이스 관리 시스템은 스키마를 정의하고 어플리케이션과 쿼리를 개발하는 역할을 하지만 다음과 같은 문제사항이 있다. ;  하나의 정확한 해결책/ 수정x, 중복 x, 사용하면서 스키마 구조 변화가 필요->성능저하

 

그렇다면 MongoDB의 데이터 모델링 순서를 살펴보자

1) 데이터 모델을 개발하고 정의한다. 2) 데이터 모델을 재정의한다 3) 어플리케이션을 발전시킨다 4) 데이터 모델을 발전시킨다 5) 3-4번을 반복하며 더 나은 방향으로 개선한다. 

이런 방법으로 인해 다음과 같은 이점이 있다 ; 다중의 디자인 선택권이 있고 사용패턴에 따로 수정이 가능하고 디자인 개선이 쉽고 직관적이다(시스템 다운 없이 가능) 

※고려할 사항: 데이터 모델은 어플리케이션 단계에서 정의된다. 디자인은 어플리케이션 수명에 필수적인 부분이고, 앱의 데이터 필요 및 일기 쓰기 데이터 사용의 변화에 따라 영향을 받는다. 

 

데이터 모델링 방법 - MongoDB

1) 어플리케이션 작업량을 평가한다.

2) 엔티티랑 그 관계를 확인한다

3) 각 컬렌션별로 데이터 모델을 마무리 짓는다. 

Evaluate Application workload	Map out entities and their relationships	Finalize data model for each collection	Outcome
- by a business domain expert - 비즈니스 도메인 전문가가 해야함! - consider the current, predicted and future scenarios - 현재 그리고 미래에 어떻게 될 지를 모두 고려해서 - consider production logs and matrix - 생산기록과 매트릭스 같은 걸 모두 고려하여  - consider the data size  - 데이터 크기도 고려하기 - consider the operations lists ranked by importance(speed, accuracy, etc) - 속도나 정확도와 같은 작업 목록의 순위를 고려하기	- Link or Embedded?  (by Collection Relationship Diagram- CRD) - 참조로 할 건지 내재하는 거로 할건지	- considering data size -데이터 크기 고려해서 - considering database queries and indexes - 데이터베이스 쿼리랑 인덱스 고려해서 - considering current operations and assumptions - 현재 수행하고 싶은 작업들과 가정들을 고려해서 - identify and apply relevant design patterns - 관련된 디자인 패턴을 정의하고 적용해서	- Data size  - 데이터 크기 - Collection with fields and shapes  - 컬렉션 필드와 구조 - queries and index - 쿼리들과 인덱스 - assumptions and future/growth projections -가정들, 그리고 미래 성장 예측
** Operations? ** Cardinality?	** How often the embedded info be accessed? 내재된 문서를 얼마나 자주 찾아 쓸건가 ** embedded info changes often? 내재된 문서에 정보를 얼마나 자주 변경할 건가 ** queries used embedded data? 내재된 데이터를 쿼리에 이용할 건가? ** embedded data to be used together? 내재된 데이터가 문서의 다른 데이터와 같이 쓰일 것인가?	** Schema versioning 스키마 버전 활용 ** Bucket Pattern 버켓 패턴 ** Computed pattern 계산된 패턴

마지막 데이터 모델을 마무리하는 데 있어서 고려해야 할 것 중에 스키마 버저닝이라는 것이 있다. 이는 스키마에 버전 번호를 붙여서 활용하는 것이다. 알다시피 몽고디비는 스키마리스이기 때문에 중간에 언제든 구조가 변경될 수 있다. (추가 열이 생길 수 있다) 이럴 때 스키마를 계속 수정하는 대신 새로운 스키마 번호를 부여하고 기존의 데이터는 중복으로 적지 않고 새로 추가된 필드들만 버전 번호와 함께 표시하는 방법이다. 기존에 _id, name, mobile, work_phone으로만 되어 있던 스키마에서(버전 1.0) 에 새로운 구조인 _id, name, contacts [ ]의 형태로 변경되었다. 이 때 schema_version:2.0으로 표기하고 수정된 필드를 표시해주는 방법을 채택하고 있다. 자세한 사항은 몽고디비 공싸 유튜브에서 굉장한 강의를 들을 수 있다. 

다음으로 버킷 패턴과 컴퓨티드 패턴은 이미 앞서 설명한 바에 있기 때문에 다시 설명할 필요가 있을까 싶지만 사실 그만큼 중요하긴 하다. 

버킷 패턴은 인덱스의 크기를 크게 줄이고, 관련 데이터의 검색 속도를 높여준다. 아래 그림에서 'valcount'가 200에 도달하면 새 문서가 생성되고 새 문서에 저장되기 시작한다. 

computed pattern 은 문서에서 매번 계산된 결과를 읽을 때마다 계속 계산하는 대신 데이터를 쓸 때 총 수와 수량(요약기록)을 남겨두는 방법을 채택한다. 쓰기에 대한 계산은 읽기에 대한 계산보다 빠르다. 일종의 캐싱 패턴의 종류라고 한다.

 

 

데이터베이스 어플리케이션 시스템 (Database Application system)

# 3-Tier Architecture (3층 구조)

아래와 같이 3개의 층으로 구성되어 있다. 

Client(사용자 층): 정보를 표시하는 것을 다룬다.  GUI, Web interface, display of info [i.e. HTML, CSS, JS]

Application server or Web server(어플리케이션 서버/웹서버): 비즈니스 로직을 실현한다. Application programs, web pages - stores biz rules, implement logic [i.e. divided by NodeJS, Python, Java, PHP, C; host language + SQL, NoSQL;  Data sub-language]

Database server(데이터베이스 서버): 데이터베이스 쿼리를 응용 프로그램으로 부터 실행한다. Database Management System - hosts DBMS (accept and process queries and commands) [i.e. MySQL, MongoDB]

데이터 베이스 프로그래밍에 대화형 인터페이스는 SQL/NoSQL 명령 실행을 위해서 모니터에 직접 입력할 수 있는 인터페이스를 의미한다. 

대화형 인터페이스를 통해서 만들어진 파일들은 Oracle RDBMS 에서 @<fillename> 혹은 PHPMyAdim에서 "import tool"과 같은 것을 이용해서 실행할 수 있다. 응용 프로그램은(어플리케이션 프로그램)은 데이터베이스에 사용자가 쿼리하기 위해서 사용하는 만들어진 데이터 트랜젝션 작업과 같은 것이 사용되거나 데이터 베이스 트랜젝션을 실행하기 위한 웹 인터페이스로써 시행된다. (항공사 예약)

• Interactive interface: interface where SQL/NoSQL commands can be typed directly into a monitor for execution
• Execute file of command: file created through an interactive interface (import tool; PHPMyAdmin, typing @<filename> in oracle)
• Application program: used as canned transactions by end users to query DB or execute transactions on DB (making airline reservations)

데이터베이스 프로그램에서는 상호 작용 순서는 다음과 같다. 1) 사용자 프로그램을 열거나 데이터베이스 서버에 연결을 한다. (host address, username, password, DB name을 사용해서) 2) 사용자 프로그램에 쿼리를 제출하거나 데이터베이스를 업데이트한다 (SQL statements을 사용해서) 3) 더이상 DB 필요 없으면 프로그램 종료 하거나 연결을 종결한다. (Programming command) 

 

데이터 프로그래밍을 하기 위한 단계에 있어서 응용프로그램 단계에서는 1) 데이터베이스 기능(function)의 라이브러리를 사용하거나 데이터 베이스 연결을 위한 클래스를 사용한다. 쿼리를 준비하고 실행하고 수정하고 쿼리 결과를 반복하는 등의 작업을 한다. 2) DBMS에 의한 처리를 위해 데이터 베이스 statement를 추출하고 식별하는 범용프로그래밍 언어에 데이터베이스 명령어들(사전에 컴파일러가 소스 코드를 스캔한다) 을 포함하고 있다. 3) 처음부터 새로운 언어를 설계하는 것은 데이터 베이스 모델이랑 쿼리 언어(일반적으로 데이터 베이스 프로그래밍 언어라고 불리는) 과 호환된다. 

 

1-1) 데이터 베이스 프로그래밍에 Function 라이브러리를 사용하는 순서 - 다음에 나오는 예시도 아래 순서를 따른다

1. 라이브러리 function을 API로 불러온다. - API(Application Programming Interface)
2. DB랑 연결 
3. SQL/NoSQL 코드 준비하고 파라미터도(매개변수)도 준비
4. 코드 시행 
5. 쿼리 결과 처리
6. 쿼리결과로 부터 결과값 추출하기
7. 결과 출력하기 

1-2) 파이썬이나 노드 JS의 예시("Cursor", 커서를 사용하는)

커서는 DB의 레코드에 대한 반복을 가능하게 하는 제어 구조이다. (쿼리 결과에 대한 루프, 한 번에 하나의 레코드)

Lecture materials

1. 커서가 해당되는 데이터 베이스를 가르키도록 한다. ; 7번 
2. 커서를 사용해서 쿼리문을 시행한다. ; 8번 (SELECT ~~)
3. 커서로부터 데이터를 로컬 변수로 패치한다.(한번에 튜플 하나씩- 행 하나) ; 9번 (mycursor.fetchall() )
4. 계속 반복한다. ; 10, 11 번 (for 문)
5. 모든 행이 다 패치 완료되면 커서 종겨; 12번 (mycursor.close())

Lecture materials

2) 이미 SQL파트에서 언급한 바 있지만 Stored Procedure라는 내재된 명령어를 사용하여서 쿼리가 시행되도록 할 수 있다. 이는 영구 저장 모듈(persistent stored module)이라고도 하는 데 데이터 베이스 서버의 DBMS에 저장되어 있다가 실행되는 방법이다. 다른 2개의 방법은 어플리케이션 서버에 저장되는 것을 생각한다면 이게 차이점이라고 할 수 있다. 만약 여러개의 응용 프로그램에서 필요한 경우, 데이터 전송의 감소가 필요한 경우 유용하고 뷰(View) 생성 과정에도 유용하다. 

 

데이터 베이스 프로그래밍 기술의 문제점 

1) 임피던스 불일치는 호스트 프로그래밍 언어 모델과 데이터베이스 모델 간의 비호환성 결과로 발생한다. (프로그래밍 언어 데이터 타입은 속성 데이터 타입과 다르다)- 데이터 유형이 다름으로 인한 비호환성 문제

2) 그렇기 때문에 각 프로그래밍 언어와 DBMS 간에 연결할 수 있는 것(바인딩)이 필요하다(다른 데이터 유형에 따라 사용가능한)

3) 바인딩(연결할 수 있는 무언가)은 쿼리 결과의 데이터 구조(테이블)를 프로그램 언어의 적절한 데이터 구조로 매핑하는 데 필요하다.  

4) 튜플(행)에서 개별 값을 추출하기 위해 쿼리 결과(한 번에 하나의 튜플)을 반복하는 매커니즘이 필요하다. 

 

Web Database Programming (NodeJS)

일반적인 사용자 - 서버 요청 - 반응 오는 과정의 순서는 아래 그림과 같다. 

자바 스크립트는 단순한 프로그래밍 언어로 HTML페이지랑 상호호환이 가능하다. 또 흔히 게임이나 모바일 어플리케이션 개발에 사용되기도 한다. 스크립팅으로 해석되기 때문에 인터넷 브라우저에서만 실행될 수 있다. 브라우저 외부에서 코드를 실행하고 사용하려면 Node JS를 활용해야 한다.

 

Node JS 는 오픈 소스이며 자바 스크립트를 다른 플랫폼과 호환해주는 역할을 한다.비동기 이벤트 기반 자바스크립트 런타임이며, 확장 가능한 네트워크 어플리케이션 구축이 가능하도록 설계되어 있다. 

 

<html>
<head><title> JAVASCRIPT </title></head>
<body>
<script type="text/javascript">
   //아래와 같이 헬로우월드 출력! 
   document.write("hello world")
   console.log("Hellow World")
   alert("Hello World")
   
   //아래와 같이 변수를 입력 받아서 합계를 계산해서 출력할 수도 있다.
   var num1, num2, sum
   num1=prompt("Enter first number")
   num2=prompt("Enter second number")
   sum=parseInt(num1)+parseInt(num2)
   alert("Sum ="+sum)
</script>
</body>
</html>

이렇게 자바스크립트에 바로 시행할 코드를 입력할 수도 있고 다음과 같이 hello.js 에 저장된 내용을 불러올 수도 있다. 

<html>
<head><title>JAVASCRIPT</title></head>
<body>
<script type="text/javascript" src="hello.js"></script>
</body>
</html>

//hello.js file
document.write("hello world");
console.log("hello worlds");
alert("hello world");

자바스크립트에서 사용할 수 있는 변수이름은 아래의 규칙을 따라야 한다.

알파벳, 숫자, $ 그리고 _ (언더바)만 사용이 가능하다.  공백이라던지 다른 기호는 허용되지 않는다. 변수 이름의 첫 글자로는 숫자는 올 수 없다.  변수 이름들은 대소문자에 따라 달라진다. 따로 길이의 제한은 없다.    

 

자바스크립트에 사용가능한 연산자들은 거의 다른 언어를 사용해본 사람들이라면 모두 알 것 같다. 아래와 같이 구글 검색으로 쉽게 검색이 가능하다. 자바나 파이썬을 사용해본 사람들은 아마 익숙할 것 같다. 조금 헷갈리는 건 == , ++, -- 같은 표현, === (데이터 타입까지 같다) !==(같은 타입이지만 다른 값) 등이 있겠다. 

 

자바스크립트에서도 문자열 연결하는 것이 가능한데 변수 선언을 하여 변수들과 문자열과의 연결도 가능하다. 변수 선언은 "let"을 사용한다. 

//Example 1) 
let firstname = 'Bella';
let lastname = 'Kim';

let fullname = firstname + ' '+ latname; 
//결과: Bella Kim

console.log(fullname);

//문자 하나만 출력 
console.log(fullname[2]);

//몇 글자인지 길이 출력 
console.log(fullname.length);

//Example 2)
console.log(fullname,toUpperCase()); //대문자로 변환

let result = fullname.toLocaleLowerCase(); //소문자로 변환 
console.log(result);

let index= email.indexOf('@');   //@의 위치 
console.log('index of the @ sign:', index);

다음은 const 를 활용하여 변수 선언을 하는 데, let과 달리 const로 선언된 변수는 수정이 불가하다. 

const title='javascript test';
const author='me myself';
const likes=100; 

let result = `The test , ${title}, written by ${author} has ${likes} likes`;  
//backticks 이 사용되어야 한다!! 여기에서 싱글 따옴표 아님 주의!!!!!
console.log(result);

다음은 try-catch 문 활용 예시이다. 

try
{
request = new XMLTTTPRequest()
}
catch(err)
{
//뭔가 출력하거나 함
}
finally
{
alert("The 'try' clause was encountered")
}

몽고디비 서버에 연결하면서 try-catch 문을 활용한 예이다. 

const {MongoClient} = require('monogdb');

async function main(){          //async: 결과 나올 때까지 기다리지 않고 계속 진행 
    const uri = const uri = "mongodb+srv://<username>:<password>@<clsuter-uri>/blahblah~~";
    const client = new MongoClient(uri); 

    try {
    await client.connet(); 
    }
    catch(e){
    console.error(e)
    }
    finally{
    await client.close();
    }
}
main().catch(console.error);

그 밖에도 여러 조건문을 사용해 볼 수 있다. 예시로 만나보자. 

const age = 25;

if(age>30){
	console.log('over 30');
}
//조건문이 true일때만 출력 

if(age>30){
	console.log('over 30');
}else {
	console.log('You are ${age}')
}
//조건이 두개로 나뉩 

if(age>30){
	document.write('over 30');
}else if(age<30) {
	document.write('You are a still baby')
} else {
	document.write('you are 30 years old');
}

for 구문과 while-do while 구문도 사용될 수 있다. 

const pname=['bella', 'brian', 'david', 'star']

for (let i =0; i <pname.length; i++){
	console.log('item in box ${i} is ${pname[i]}'); 
}

let i=0;
while (i<5){
	console.log('item in box ${i} is ${pname[i]}'); 
    i++; //i 갯수 증가 
}

let i=0; 
do {
    console.log('item in box ${i} is ${pname[i]}'); 
    i++; 
} while(i<5);

논리적 연산자를 사용한 예도 한 번 살펴보자. 

if (age <18 || gender==="male"){           
	alert("You are still too young")
}
//나이가 18세 보다 어리거나 혹은 남자면 (둘 중 하나만 true면 실행)


if(continent === "Europe" && language === "German"){
	alert("You are from Germany");
}else {
	alert("You are not from Germany"); 
} 
//유럽이고 독일어를 쓸 때, 둘 다 true여야 if 시행, 아니면 else 시행

 Breaking and Continue도 활용될 수 있다. 만약 break를 만나뭔 쿼리문이 바로 종결되고 continue는 계속 다음 쿼리가 진행된다. 그래서 아래 코드에서도 j 가 17이되는 순간 break 가 시행되면 쿼리가 종결된다. 그 다음 코드에서 보면 반복문이 끝날 때까지 쿼리가 모두 진행된다(j가 19가 될 때까지) 

자바스크립트에 배열은 똑같이 [ ]를 사용할 수 있다. 그리고 배열 접근은 인덱스 활용하는 것 처럼 위치를 숫자로 넣어서 접근이 가능하다. 그렇게 업데이트도 된다. 예를 들어 mylist[0]은 mylist 배열의 첫 항목을 반환할 것이고, mylist[0]='replace' 는 첫 항목을 replace라는 단어로 교체할 것이다. 

 

자바스크립트 function은 활용도가 많은 데 기본적으로 아래와 같은 형태로 구성되어 있다. 

function fullname(firstname, lastname){
	alert(firstname+ " "+lastname); 
}
//fullname이라는 function은 두개의 변수를 받는다. 
//이 변수는 function 안에서 순서대로 firstname, lastname으로 지칭되어 사용된다. 

let firstname= prompt("fistname?");
let lastname= prompt("lastname?");
//팝업으로 사용자에게 단어를 받음 

fullname("bella", "kim"); 
//function이름(변수 1, 변수 2)의 형태로 이용

function add(x,y){
	return x+y;
}

let result = add(8, 12);   //바로 add function으로 계산된 값이 변수에 저장 
let result2 = add(result, 5) //result 변수값이랑 5가 add function으로 계산되어 result2에 저장

function getFullname(firstname, lastname){
	let fullname = fistname + " " + lastname;
    return fullname; 
}

let userFullname = getFullname("Bella", "Kim");    //getFullname function으로 변수에 저장 
alert(userFullname);   //Bella Kim, 변수 출력

alert(getFullname("test", "name")); // test name, 아예 출력할 때 getFullname function 사용

const people = ['bella', 'luna', 'stella', 'bob', 'sasimi'] 

people.forEach(function(person) {   //function 을 변수로 받아서 각 배열에 요소들 하나씩 반영 
	console.log(person);
});

people.forEach(person) => {         //여기서는 function따로 선언 x 
	console.log(person);
});

people.forEach((person, index)=>{    //여기서는 function따로 선언 x 
	console.log(index, person);
});

let user = new Object()
let user = {}            //object는 { }를 쓴다. 

let student={
    firstname: "bella",
    lastname:"kim",
}; 

alert(student.firstname);   //bella 
alert(student["lastname"]); //kim

let anotherstudent={
    firstname: "stella",
    lastname:"lee",
    male:false,
    greet: function(){     //function을 포함하고 있는 변수 
        alert('hey'); 
    }
};

let user= {
    firstname: "bella",
    lastname:"kim",
    gender: 'female'
}; 

for (let prop in user){
	alert(prop);       //key;  firstname, lastname, gender
    alert(user[prop]); //value; 'bella', 'kim', 'female'
}

//object 두 개가 배열로 저장되어 있음 
let users=[
{
    firstname: "bella",
    lastname:"kim",
    gender: 'female'
},
{
    firstname: "bella2",
    lastname:"kim2",
    gender: 'female'
}
]; 

user.forEach(function(user, index){
	for (let prop in user){
    	alert(prop+"is"+user[prop]);
    }
});

 

const {MongoClient} = require('monogdb');

async function main(){          //async: 결과 나올 때까지 기다리지 않고 계속 진행 
    const uri = const uri = "mongodb+srv://<username>:<password>@<clsuter-uri>/blahblah~~";
    const client = new MongoClient(uri); 

    try {
    await client.connect(); 
    await listDatabases(client)   //아래에 추가로 나와 있는 function 소환! client전달 
    }
    catch(e){
    console.error(e)
    }
    finally{
    await client.close();
    }
}

main().catch(console.error);

asysnc function listDatabase (client) {
	const databaseList = await client.db().admin().listDatabase(); // db, collection, list all the db 를 변수에 저장 
    console.log('Databases:');
    databaseList.databases.forEach(db => {          //databaselist objest구조에 database라는 속성이 있습니다. 
    	console.log(`-${db.name}`);
        });
};

const {MongoClient} = require('monogdb');

async function main(){          //async: 결과 나올 때까지 기다리지 않고 계속 진행 
    const uri = const uri = "mongodb+srv://<username>:<password>@<clsuter-uri>/blahblah~~";
    const client = new MongoClient(uri); 

    try {
    await client.connect(); 
    await createListing(client, {    //client는 위에서 받은 db 위치
    	name:'bella'
        })
    }
    catch(e){
    console.error(e)
    }
    finally{
    await client.close();
    }
}

main().catch(console.error);

asysnc function createListing (client, newListing) {
	const result = await client.dbname("sample").collection("listingsAndReview").insertOne(newListing);
    console.log(`New listing created: ${result.insertedId}`);
};

그 밖에도 update, insert 등이 모두 구현 가능하다.

https://www.mongodb.com/developer/languages/javascript/node-crud-tutorial 

MongoDB and Node.js Tutorial - CRUD Operations | MongoDB

 

몽고디비 공홈을 잘 뒤져보면 정말 웬만한 사용방법은 모두 제공되는 것 같다. 그리고 추가로 해결되지 않는 것들은 커뮤니티에서 질의응답으로도 해결이 가능하고 어떤 기능에 대한 사용방법이 없다면 요청도 가능한 것 같다. 

 

이상 끝 !