Naming Rules DynamoDB의 테이블, Attributes 와 다른 오브젝트들은 이름을 갖는다. 이름은 의미를 잘 전달할 수 있어야하며 간결해야한다. 예를들어, 상품, 책, 저자와 같이 이름만으로 의미를 알 수 있어야한다. 아래 설명들은 DynamoDB 의 네이밍 규칙을 설명한다: 모든 이름은 UTF-8 로 인코딩되며 대소문자를 구별한다. 테이블명과 인덱셔명은 3글자이상 255자이하여야하며 아래여야하며 아래 문자들로 구성될 수 있다 a-z A-Z 0-9 _ - . Attribute 이름은 한개 이상의 문자여야하며 64KB 이하여야한다. Attribute 이름은 가능한 짧게 관리하는것을 권장한다. Attribute 이름 또한 Read 요청에 응답값으로 함께 전달되기 때문이다. 아래 이름들은 At..

쿼리를 정의했다면, 카산드라 테이블을 설계한 준비가 된 것이다. 첫번째로 각 쿼리에 포함되어있는 논리 모델을 포함하는 테이블을 만들고 구상중인 모델의 엔티티와 관계를 그린다. 각 테이블의 이름을 지정하려면 주로 조회하는 엔티티 이름으로 시작하는 이름을 지을 수 있다. 다른 관계가 있는 에티티의 요소로 Query 를 한다면 이 두가지 테이블의 이름을 붙이고 by 로 구분을 지을 수 있다. 예를 들어 hotels_by_poi 다음에 테이블의 PK 를 결정하고 추가 Parititon Key 를 Query 요소를 기반으로 추가하고 Clustering 요소를 고유성과 필요한 정렬을 제공하기 위해 추기해야한다. PK 를 설계하는 것은 특히 중요하다. PK 가 각 Partition 에 어떻게 저장될지 그리고 Disk..

이 호텔 도메인을 위해 Query 우선 접근 방법으로 데이터 모델링을 해보자. Application 을 위한 UI 디자인은 쿼리를 추출해내기 위한 좋은 결과물이다. 당신이 프로젝트 Stakeholder 와 UX 디자이너와 논의한다고 가정해보자. 그 대화를 통해 아래오 같은 Query 들을 추출해낼 수 있을 것이다. Q1. 호텔 근처의 관광지는? Q2. 주어진 호텔의 이름과 위치와 같은 정보는? Q3. 관광지 근처의 호텔은? Q4. 주어진 기간동안 이용 가능한 객실은? Q5. 객실의 별점과 어메니티는? 이와 같이 쿼리를 속기헤보는 것은 전체를 설명하는 것보다 도움이될 때가 종종 있다. 여기에 리스트된 Query 들은 Q1, Q2, 등등 으로 넘더링되어있다. 이제 Application 이 성공하여 고객이 호..

데이터 모델링을 하기 위해 호텔 도메인을 이용해보자. 호텔에 객실에 머무는 게스트가 있고 각 호텔은 여러개의 Room 을 가지고 있다. 게스트가 예약한 Room 에 대한 정보가 있고 각 Room 에서 제공되는 Amentity 가 있다. 관심이 있을만한 "공원", "박물관", "쇼핑" 과 같이 게스트들이 관심있어할만한 데이터 또한 Point Of Interest 에 저장된다. RDBMS Design 만약 당신이 새로운 데이터 기반 Application 을 구축한다면, 적절한 normalized 테이블과 FK 를 사용하여 데이터를 모델링할것이다. 아래 도표는 관계형 데이터베이스를 사용한 데이터 모델링을 나타낸다. 관계형 데이터베이스는 Many to Many Join 을 활용한다. Hotel Points , ..
카산드라는 테이블에 데이터를 저장한다. 각 테이블은 Row 와 Column 으로 구성되어있다. CQL 은 테이블에 저장된 데이터를 찾기위한 Query 로 사용된다. 카산드라 데이터 모델은 Query 에 최적화 되어있다. 카산드라는 관계형 데이터베이스에서 사용하는 관계형 데이터 모델링을 지원하지 않는다. What is Data Modeling? 데이터 모델링은 엔티티와 엔티티간의 관계를 식별하는 과정이다. 관계형 데이터베이스에서는 다른테이블의 데이터와 연관짓기 위하여 FK 를 테이블에 지정하였다. Application 에서 데이터베이스로 만드는 쿼리는 테이블의 구조에 기인하고 테이블 조인에 의해서 데이터가 조회된다. 카산드라에서는 데이터 모델링은 Query-Driven 이다. 데이터 접근 패턴과 Appli..

Dynamo 카산드라는 분산형 Key-value 시스템인 Amazon 의 Dynamo 에 많은 기능들을 의존한다. Dynamo 시스템의 각 노드들은 아래와 같은 세개의 주요 요소가 있다. 분할된 Datset 에 대한 조정 요청 Ring 멤버십과 실패 탐지 Local 의 지속 저장 엔진 카산드라는 Log Structured Merge Tree(LSM) 기반의 스토리지 엔진을 사용하면서 위에서 두가지 클러스터링 요소들을 주로 이끌어냈다. 특히 카산드라는 Dynamo 의 아래 스타일들을 의존한다: 변하지 않는 Hashing 을 사용한 데이터 Partitioning 버전으로 관리된 데이터를 사용하는 Multi Master Gossip 프로토콜을 사용하여 실패 탐지와 분산 클러스터 멤버십 하드웨어의 증분 scal..
Overview 카산드라는 오픈소스, 분산, NoSQL 데이터베이스이다. 카산드라는 넓게 분할된 Column 기반 스토리지 모델을 제공한다. 카산드라는 최초에 Facebook 에 의해서 디자인 되었으며 Amazon 의 Dynamo 분산 스토리지를 구현하기 위한 Event Driven 아키텍쳐, Replication 기술, 구글의 Bigtable 데이터와 스토리지 Engine Model 들을 사용하였다. Dynamo 와 Bigtable 은 둘 다 확장성, 안정성과 고가용성 Storage System 을 위해 개발되었지만 개선할 부분들이 존재했다. 카산드라 는 이 두가지 시스템의 조합으로 동종 최고의 성능으로 디자인 되었다. Application 이 read, write 에 낮은 latency 가 필요해지고..
- Total
- Today
- Yesterday
- notify()
- custom config data convertion
- wait()
- Flux
- mariadb-connector-j
- ConcurrentHashMap
- Lazy
- DyanomoDB
- RouteDefinition
- MariaDB
- aurora
- router
- Seperate Chaining
- ResultSet
- circurit breaker
- N+1
- getBoolean
- GlobalFilter
- spring cloud gateway
- reative
- HashMap
- msyql-connector-java
- reactor
- RoutePredication
- notifyAll()
- referencedColumnName
- AbstractMethodError
- rate limit
- mariada-connector
- dynamodb
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |