Cassandra db - 데이터 모델링 - Query 정의

 이 호텔 도메인을 위해 Query 우선 접근 방법으로 데이터 모델링을 해보자. Application 을 위한 UI 디자인은 쿼리를 추출해내기 위한 좋은 결과물이다. 당신이 프로젝트 Stakeholder 와 UX 디자이너와 논의한다고 가정해보자. 그 대화를 통해 아래오 같은 Query 들을 추출해낼 수 있을 것이다.

• Q1. 호텔 근처의 관광지는?
• Q2. 주어진 호텔의 이름과 위치와 같은 정보는?
• Q3. 관광지 근처의 호텔은?
• Q4. 주어진 기간동안 이용 가능한 객실은?
• Q5. 객실의 별점과 어메니티는?

 이와 같이 쿼리를 속기헤보는 것은 전체를 설명하는 것보다 도움이될 때가 종종 있다. 여기에 리스트된 Query 들은 Q1, Q2, 등등 으로 넘더링되어있다.

 

 이제 Application 이 성공하여 고객이 호텔을 객실을 예약할 수 있도록 하고자 한다. 이는 예약 가능한 객실을 검색하고 고객의 정보를 입력하는 것과 같은 단계들이 필요하다. 그래서 너는 명백히 고객과 주소를 입력할 수 있는 Query 가 필요하다. 그러나 고객 관점에서 데이터가 어떻게 쓰여질지 뿐만아니라 Downstream 유즈케이스에 따라서 어떻게 조회돌지도 알고자 한다.

 

 당신이 예약 정보, 고객 정보를 어떻게 저장할지를 처음으로 집중하는 것은 자연스러운 현상이다. 그 후에 쿼리를 어떻게 작성할지를 생각하게 될 것이다. 이전에 Shopping Query 를 논의할때 비슷한 텐션을 느꼈을 것이다. "호텔과 관광지 정보는 어디로 부터 오는 것일까?" 걱정하지 마라. 곧 충분히 알게 될 것이다. 아래 Query 들은 고객에 호텔을 예약하기 위해 필요한 것들이다.

• Q6. 확정 번호 기준으로 예약 조회
• Q7.  호텔, 날짜, 고객 이름으로 예약 조회
• Q8. 고객 이름으로 모든 예약 조회
• Q9. 고객 디테일 정보 조회

 위 모든 쿼리는 Application 의 Workflow 에서 추출해낸 것이다. 다이어그램의 각 박스들은 Application 의 Workflow 를 나타내고 박스 사이의 화살표는 각 Workflow 사이의 쿼리를 나타낸다. Application 의 모델링이 잘 되었다면, Workflow 의 각 단계는 다음 단계를 "Unlock" 하는 작업을 수행한다. 예를들어, "관광지 근처 호텔 보기" 작업은 Application 이 Unique Key 를 포함한 여러개의 호텔을 알 수 있도로 한다. 선택된 호텔의 키는 선택된 호텔의 자세한 정보를 얻어오기 위해서 Q2 의 한부분으로 사용된다. 객실을 예약하는 행위는 예약 데이터를 생성한다. 이 데이터로 고객과 호텔의 직원은 다양한 추가적인 Query 를 이요해 접근이 가능할 것이다.

 

출처 - https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_queries.html