발생일: 2021.04.21 키워드: 다이나모디비, 온디맨드, 오토 스케일링, auto scaling 문제: 다이나모디비를 온디맨드 모드로 쓰고 있다. 배치 작업으로 평소보다 많은 데이터를 PUT 했는데, 아래와 같은 에러가 나온다. Throughput exceeds the current capacity for one or more global secondary indexes. DynamoDB is automatically scaling your index so please try again shortly. 온디맨드 모드는 스케일 제한이 없는 걸로 알았는데 왜 그런걸까? 해결책: 테이블 생성 후, 이전 트래픽 대비 많은 데이터를 넣어서 발생한 문제였다. 요약 먼저: 온디맨드도 내부적으론 오토스케일링으로 ..
발생일: 2021.03.14 키워드: DynamoDB, 다이나모디비 문제: 다이나모디비를 써보면서 헷갈렸던 것들, 생각과 달랐거나 고민했던 내용, 중요하다고 생각되는 것들에 대한 정리 해결: 핫파티션은 프로비저닝 모드에서만 해당됨 - 과금 체계는 프로비저닝 모드와 온디맨드 모드가 있고 - 프로비저닝 모드 - 프로비저닝 모드는 RCU와 WCU를 직접 설정하는데, '초당 처리량' 기준임 - 핫파티션 이슈는 프로비저닝 모드에서만 해당됨 - 초당 요청이 할당 받은 처리량을 초과하지 않게 하기 위해 설계해야 함 - 예약 요금은 프로비저닝 모드에서 쓸 RCU,WCU를 미리 사두는 개념 - 온디맨드 모드 - 사용한 RCU와 WCU 만큼 과금하는 모델 - 사용한 만큼 과금되기 때문에, 처리량의 한계와 핫파티션 이슈가 ..
발생일: 2021.02.16 키워드: DynamoDB, 다이나모디비 문제: DynamoDB에 코세라 강좌가 있어 들으면서 정리했던 노트다. https://www.coursera.org/learn/dynamodb-nosql-database-driven-apps 지금보면 너무 기초적인 것 같은데, 당시 흐릿하게 개념이 잡혔던 터라 전체 컨셉을 이해하기에 좋았다. 지금 보더라도 유심히 기억해야할 만한 특징인 볼드로 표시해뒀다. 내용: Relational Databases and the Problem that Need Solving - RDS(Relational Data System)의 특징 - 정형 데이터를 분석하기 좋음 - 스토리지를 많이 차지하고 - 컴퓨팅 비용이 큼 - CAP 정리: 다음과 같은 세 가지..
발생일: 2021.03.09 키워드: DynamoDB, 다이나모디비, Partition Key, Sort Key, 파티션키, 정렬키, PK, SK, GSI 문제: 동료들이 다이나모디비의 파티션키(Partition Key)와 정렬키(Sort Key)의 관계를 헷갈려한다. 해결책: 처음엔 개념이 잘 잡히진 않았는데, 알고보니 간단하고 명확한 개념이었다. 다이나모디비로 설계하면서 자꾸 복잡하다고 느끼는 건, 설계 시점부터 스케일 아웃을 고려하고 있기 때문인 것 같다. RDS에선 스케일을 고려했다기보단, 이름 그대로 관계(relation)에 집중해 설계했던 것 같다. 사용할 땐 쿼리를 조합하면 되니, 설계 시점엔 확장이나 호출 샘플보단 관계를 고민했다. (다른 디비를 설계할 때에도 지금처럼 스케일을 고려해 설계..
발생일: 2020.02.18 키워드: nosql, dynamodb, 다이나모디비 문제: 이번엔 디비를 NoSQL로 AWS의 DynamoDB를 사용해서 구성해보려고 한다. 아키텍처 디자인을 어떻게 해야할까 고민하던 차에, A가 리인벤트 동영상을 추천해줬는데 내용이 좋다. youtu.be/8rEsuvdL17s 아래는 보면서 정리해둔 내용. 해결책: - 한 애플리케이션에 한 개의 테이블 - 파티션 키는 데이터를 골고루 분산하는 용도로 (데이터 분배 결정) - 고유 값이 많은 속성(카디널리티가 높은 속성) - 균일한 비율로 무작위로 요청되는 속성 - 정렬 키는 기존 RDS에서 인덱스를 사용하는 느낌으로 (쿼리, 다양화) - 1:n, m:n 관계 모델링에 활용 - 효율적/선택적 조회 - 범위 조회 - GSI (G..
발생일: 2020.07.30 키워드: mysql, aurora, DB 컬럼 추가, DB 인덱스 추가, add index without lock, add column 문제: 크기가 큰 MySQL (Aurora) 테이블에 컬럼이나 인덱스를 추가하려고 한다. 테이블 크기가 큰 경우, 락 타임이 길어져서 운영 중일 땐 문제가 발생할 수 있다. 어떻게 하면 될까? 해결책: algorithm 절과 lock 절을 이용하면, 락을 걸지 않고 컬럼이나 인덱스를 추가 또는 삭제할 수 있다. 컬럼 추가 규모가 큰 larget_table 에 new_date 란 이름으로 DATETIME 형식의 컬럼을 추가한다고 가정하면, 아래와 같이 하면 된다. ALTER TABLE large_table ADD new_date DATETIME..
발생일: 2019.04.22 키워드: mysql, view, 뷰 문제: 기존 변수를 모두 변경하면서 관련된 테이블의 이름도 함께 변경하려고 한다. 테이블 앨리어스가 있다면 가장 쉽게 운영 중인 서비스에도 문제 없이 적용할 수 있을 것 같다. 가만, view 가 업데이트도 가능했던가? 해결책: 단일 테이블로 생성한 뷰는 업데이트나 인서트도 가능하다. - view 조건에 해당되지 않는 경우에도 업데이트나 인서트가 가능하다. CREATE VIEW emp_view AS SELECT * FROM emp WHERE age > 10 INSERT INTO emp_view (iage) VALUES (5); - 뷰 생성 시 컬럼 앨리어스를 사용한 경우에도 인서트나 업데이트 된다. CREATE VIEW emp_view AS..
발생일: 2017.11.17 키워드: MySQL, LOAD DATA INFILE, insert large amount of dataset into mysql database, 대용량 데이터 추가 문제: 대용량 데이터를 MySQL 디비에 인서트하려고 한다. 가장 효율적인 방법이 뭘까? 해결책: 텍스트 파일을 읽어 테이블에 인서트하는 LOAD DATA INFILE 구문이 있다. 기본 INSERT 구문을 쓰는 것보다 20배 정도 빠르다고 한다. 대략 아래와 같은 포맷으로 실행할 수 있다. LOAD DATA LOCAL INFILE '{file_name}' INTO TABLE {table_name} CHARACTER SET utf8 FIELDS TERMINATED BY '{field_terminator}' # 각..
발생일: 2018.08.28 키워드: max_execution_time, slow query, cpu 100% of database 문제: 실수로 실행 시간이 아주 긴 쿼리가 운영 중인 서비스에서 실행됐다. 서버에서 맺은 커넥션은 타임아웃이 걸려있어서 문제 없이 끊겼는데, MySQL 서버의 CPU는 여전히 100%다. 디비 서버의 모든 커넥션을 끊은 후에도 한동안 CPU가 100%로 유지되더라. 문제가 뭘까. 해결책: 문제의 쿼리는 SELECT 구문으로 무려 80초나 걸리는 것이었는데, 커넥션이 끊긴 이후에도 해당 쿼리는 계속 실행된 게 원인으로 보인다. 동일 쿼리가 여러 번 실행됐을 거고, 이런 이유로 CPU가 계속 100%가 되었던 것으로 추측된다. 커넥션 타임아웃(connet_timeout)을 설정..
발생일: 2018.07.26 키워드: fulltext index, use index, match against 문제: FULLTEXT 인덱스를 적용해 둔 테이블에서 날짜와 주소로 조회하려고 한다. 테이블 크기는 약 1800만 행 정도이고, 컬럼과 인덱스 정보는 아래와 같다. employee: 약 1800만 행 - address: 주소 - join_date: 입사일 인덱스: - address: FULLTEXT index - join_date: index 주소와 날짜로 검색하기 위해 아래와 같이 조회했는데,.. 엄~청 느리다. SELECT * FROM employee WHERE MATCH(address) AGAINST('+서울' IN BOOLEAN MODE) -- (A) AND join_date >= '${..