디지털이 아닌 부분은 문서로 가득합니다. 책상은 문서로 가득 차 있습니다. 그중에는 정형화된 문서(송장, 명함)도 있고, 덜 정형화된 문서(메모, 스케치)도 있으며, 그 중간 형태이거나 두 가지를 모두 모은 문서(노트, 스케치패드)도 있습니다.
대부분의 데이터베이스 기술은 이러한 일반적인 경험을 깨뜨렸습니다. 일반적으로 그 원인은 자연스러운 개념을 부자연스러운 디지털 구멍에 억지로 집어넣었기 때문입니다. 예를 들어 관계형 데이터베이스의 탄생은 당시 기술의 공간 제약으로 인한 중복을 피하기 위해 데이터를 한 번만 저장하는 방식으로 추진되었습니다.
관계형 및 기타 기술 중심의 추상화 방식은 그 자체로는 좋지만, 문서와 같은 자연스러운 개념에서 소프트웨어 구축으로 전환할 때 사고와 작업 방식을 바꿀 필요가 없다면 어떨까요?
Couchbase용 문서를 디자인할 때 얼마나 자연스러울 수 있는지 살펴봅시다.
맥주 데이터 열기
우리가 살펴볼 데이터 세트는 원래 다음과 같습니다. OpenBeerDB.com 오픈 데이터베이스 라이선스에 따라 라이선스가 부여됩니다. 원래 데이터는 관계형 데이터였으며, 사이트에서 다운로드하는 데이터에는 원본 데이터베이스의 SQL 덤프가 포함되어 있습니다.
다행히도 데이터를 보다 자연스러운 형태로 다시 조립하는 것은 충분히 쉽습니다. 다음에서 데이터 마이그레이션에 대해 자세히 알아보겠습니다. SQL에서 NoSQL로 나중에 "Couchbase로 마이그레이션하기" 게시물에서 설명합니다.
먼저 두 가지 유형의 문서를 살펴보겠습니다.
맥주(물론)
"_id": "beer_1554_Enlightened_Black_Ale",
"_rev": “1-191ae52a6c773fd7749b65ffd9ae8044”,
"양조장": "뉴 벨기에 브루잉",
"name": "1554 인라이튼드 블랙 에일",
"abv": “5.5”,
"설명": "홍수와 수백 년 된 벨기에 문헌에서 탄생한 1554 인라이튼드 블랙 에일은 라이트 라거 효모 균주와 다크 초콜릿 몰트를 사용하여 흑맥주의 정의를 새롭게 정립했습니다. 1997년 포트 콜린스 홍수로 인해 연구원 필 벤스타인이 도서관에서 발견한 오리지널 레시피가 파괴되었습니다. 그래서 필과 브루마스터인 피터 부커트는 오랜 세월 동안 사라진 이 독특한 스타일을 되찾기 위해 벨기에로 떠났습니다. 그들의 첫 번째 과제는 오래된 스크립트와 오래된 측정 단위를 해독하는 것이었지만, 시행착오와 수개월간의 사내 샘플링을 통해 적당한 바디감과 입맛을 지닌 1554년 흑맥주를 완성했습니다.",
"category": "벨기에 및 프렌치 에일",
"style": "기타 벨기에 스타일 에일",
"업데이트됨": “2010-07-22 20:00:20”
}
다음은 뉴 벨기에 브루잉의 1554 인라이튼티드 블랙 에일을 설명하는 문서입니다. 물론 문서를 읽어보셨기 때문에 이미 알고 계실 수도 있습니다. (다행히도!) 이런 내용을 읽을 필요는 없습니다:
| id | 이름 | brewery_id | abv | style_id |
| 1 | 1554 인라이튼티드 블랙 에일 | 2 | 5.5 | 3 |
이는 고도로 정규화되고 관계형이지만 그 자체로는 큰 정보를 제공하지는 않습니다. 이 관계에 다른 두 개의 테이블을 추가하더라도 여전히 읽고 정신적으로 재조합하는 것이 다소 번거롭습니다.
맥주 이름과 이 맥주를 만든 사람 외에도 ABV, 설명, 카테고리와 스타일도 확인할 수 있습니다. 문서에 언급된 유일한 'ID'는 맥주 자체에 대한 자연스럽고 구성된 ID입니다. 여기에 언급된 관계는 사람이 읽을 수 있고, 나중에 살펴보겠지만 여전히 검색할 수 있습니다.
이제 뉴 벨기에 브루잉의 자체 문서를 살펴 보겠습니다...
양조장
"_id": "brewery_New_Belgium_Brewing",
"_rev": “1-e405d6f86ec028a4fe0d18be0a6d4fa1”,
"name": "뉴 벨기에 브루잉",
"주소": [
"500 린든 스트리트"
],
"city": "포트 콜린스",
"state": "콜로라도",
"code": “80524”,
"country": "미국",
"전화": “1-888-622-4044”,
"웹사이트": "http://www.newbelgium.com/",
"설명": "장면을 설정하겠습니다: 1989. 벨기에. 자전거를 탄 소년(32세의 청년으로 설정). 야심찬 젊은 홈브루어 청년이 펑퍼짐한 타이어가 달린 산악자전거를 타고 맥주로 유명한 유럽 마을을 달릴 때, 뉴 벨기에 브루잉 컴퍼니는 그의 눈에 희미하게 비쳤을 뿐이었습니다. 아니면 지하실. 제프 레베쉬는 몇 가지 재료와 상상력으로 가득 찬 레시피를 들고 포트 콜린스로 돌아왔습니다. 그리고 맥주가 있었습니다. 제프가 지하실에서 처음 양조한 두 가지 맥주는? 흙빛이 감도는 갈색 더벨 맥주는 Abbey, 균형이 잘 잡힌 앰버 맥주는 Fat Tire라고 명명했습니다. 나머지는 역사라고 말하는 것은 그의 아내의 개입을 간과하는 것입니다. 킴 조던은 뉴 벨기에 최초의 보틀러이자 영업 담당자, 유통업자, 마케터, 재무 기획자였습니다. 그리고 이제 그녀는 우리의 CEO가 되었습니다.",
"geo": {
"loc": [
“-105.07”,
“40.5929”
],
"정확도": "범위_보간"
},
"업데이트됨": “2010-07-22 20:00:20”
}
이 문서의 ID가 비슷하다는 것을 알 수 있지만 이제는 "brewery_" 접두사를 사용하고 있습니다. 이 두 문서 ID의 접두사는 이름 기반 ID와 마찬가지로 사람이 문서를 다시 찾는 데 도움이 됩니다. UUID, 숫자 또는 날짜 기반 ID를 사용할 수 있습니다. 그러나 데이터베이스에서 원하는 것을 찾기 위해 항상 보기 쿼리의 결과를 로드해야 하는 것보다 조회용 ID를 '직접' 만들 수 있는 것이 더 유용할 수 있습니다.
이 문서는 일반적인 명함의 구조화된 버전과 크게 다르지 않습니다. 사실, 대신 사용할 수 있는 JSON 기반 연락처 형식이 있을 수 있습니다.
결론
카우치베이스는 스키마가 없으므로 이 두 문서를 데이터베이스에 넣는 데는 입력해서 데이터베이스에 추가하는 것보다 더 많은 시간이 걸리지 않습니다. 구조, 값, 키 이름의 진정한 가치는 우리가 무엇을 구축할지 확실히 알기도 전에 필요한 것이 아니라 프로세스 후반부에 나타납니다.
다음 편에서는 데이터 모음에 하나의 문서를 사용할 때와 여러 문서를 사용할 때를 결정할 때 고려해야 할 몇 가지 사항에 대해 살펴보겠습니다.
