본문 바로가기

MongoDB Authentication Mechanism 1. MongoDB Authentication Mechanism MongoDB 는 Login 시에 authentication mechanism 을 사용하게 되어있다. 여러 Mechanism 들이 사용 가능하지만, 사용되는 방식은 "MONGODB-CR / SCRAM-SHA-1" 크게 두가지이다. 2.x 버전에서는 "MONGODB-CR" 이라는 Mechanism 이 사용되다가, 3.0 version 부터 "SCRAM-SHA-1" 이라는 새로운 Mechanism 이 차용되었다. MongoDB 3.6 version 까지는 "MONGODB-CR" 방식과 "SCRAM-SHA-1" 방식이 모두 사용 가능하지만, MongoDB 4.0 version 부터는 "SCRAM-SHA- 256" 방식이 생기면서 동시에 "MONG..
MySQL 8.0 Atomic DDL (data definition statement) 1. 개요 8.0 에서 새롭게 "Atomic Data Definition Statement Support" 에 대한 내용이 소개 되었다. 2. Atomic DDL 1) 지원되는 DDL 문 Atomic DDL 기능은 DDL 이 지원되는 테이블과 지원되지 않는 테이블 모두 지원한다. table DDL Statement : CREATE / ALTER / DROP ( for databases, tablespaces, tables, indexes, truncate table ) non-table DDL Statement : stored programs, triggers, views, user-defined functions user management Statement : CREATE / ALTER / DROP ..
About Me 안녕하세요. 이 글을 보러오시는 분이 계실지는 모르겠지만, 보신다는건 궁금해하신다는 것이라고 생각하니 그래도 소개를 해야겠습니다.(ㅎㅎ) uzi 는 카카오에 다닐 때 사용하던 닉네임입니다. * Kakao (2017.08. ~ 2019. 12.) - MySQL / MongoDB Engineer * Yanolja (2019. 11. ~ 2020. 11.) - MySQL (Aurora) Engineer * Amazon Web Services (2020. 11. ~ 2021. 04.) - Cloud DBs Support Engineer * Yanolja (2021. 04. ~ ) - MySQL (Aurora) Engineer 주로 Trouble Shooting 이나 성능에 관한 분석을 좋아합니다. DB 만 보는..
MongoDB Plan Cache 1. MongoDB Plan Cache 사용 이유 MongoDB 에서 Execution Plan 은 101건의 document 를 반환하는 Plan 을 사용한다. 이 행위를 쿼리가 요청될 때마다, 매번 하는 것은 사실 비효율적인 행위이다. 그래서 MongoDB 에서는 Plan Cache 라는 개념을 사용한다. 이는 MySQL 의 Query Cache 랑은 다른 개념이다. MongoDB 의 Plan Cache 는 Query Shape (쿼리 패턴이라고 이해해도 좋다.) 별 어떤 Execution Plan 을 사용할지 Caching 해두는 공간이다. Plan Cache 가 처음부터 Plan 을 Caching 을 해두는 것은 아니고, 실제 쿼리가 실행 되었을 때 만들어진 Execution Plan 을 캐싱한다..
MongoDB Query Execution Plan 1. MongoDB 에서의 Query Execution Plan MongoDB 의 Optimizer 는 기본적으로 Rule Based 로 동작한다. 하지만 Rule Based 와 Cost Based 의 각 장단점은 명확하기때문에, MongoDB 에서는 Rule Based 를 기본으로 사용하면서 단점을 보완하기위해 추가적인 방법을 이용한다. Execution Plan 을 세울 때, 먼저 Rule Based 로 Execution Plan 을 세우고 실제 해당 Plan 을 실행한다. 그리고 모든 Execution Plan 들 중에 "101건" 의 Document 를 가장 빨리 반환하는 Plan 을 최종적으로 Execution Plan 으로 잡는다. 이 단계에서 선택된 Plan 은 "Winning Plan" ,..
MySQL 8.0 binlog_row_metadata 1. 개요 MySQL 8.0 에서 추가된 "binlog_row_metadata" 변수가 있다. 해당 값은 "MINIMAL" 과 "FULL" 값을 설정할 수 있다. binlog 작성 시 row 의 meta 정보를 함께 기록하는 것인데, "FULL" 로 설정을 하게되면 MINIMAL 과 생각보다 큰 binlog 사이즈를 가지게 된다. 구성하는 요소가 무엇인지, 어떤 형식으로 binary log 에 남게되는지 보고자 한다. 해당 파라메터는 Global dynamic variable 이다. 2. binlog_row_metadata 란 ? 목적 1) 마스터와 슬레이브가 테이블 구조가 다를 경우, 슬레이브는 전송된 데이터로부터 metadata 를 사용 2) 외부 소프트웨어가 메타 데이터를 사용하여 row event..
MySQL JSON 이 BLOB, TEXT 에 비해 느린 이유 (JSON source 분석) 배경 해당 내용은 JSON Function 을 전혀 사용하지않고, json 의 모든 값들을 Fetch 할 때의 이야기이다. ========================================================================= MySQL 에서 JSON Data 를 Client 단으로 보내줄 때 다른 Type 의 컬럼들에 비해 CPU Usage 를 많이 사용한다. 이는 MySQL 의 경우 JSON type 을 내부적으로 binary 형태로 저장하고, TEXT type 은 string 형태로 저장하기때문이다. Client 단에서 데이터를 요청했을 때, TEXT type 의 경우 type conversion 없이 string 형태 그대로 전송을 해주면되지만, JSON type 의 ..
MySQL 8.0 Optimizer Trace MySQL 8.0 에서만 특정 쿼리가 2초만에 끝나는 use index 힌트를 무시하고 자꾸 600초 가량이 걸리는 Full Table Scan 을 선택해서 부하 테스트가 잘 안됐다. 기존 원본 버전인 MariaDB 10.0 버전에서는 원하는대로 use index 만으로도 원하는 인덱스를 잘 사용했는데, 타겟 버전인 MySQL 8.0 에서만 이슈가 있던 부분이다. ( force index 는 잘 됨 ) 그래서 MySQL 8.0 에서는 optimizer 부분이 어떻게 바뀌었는지 Optimizer Trace 를 살펴보면서 정리했다. Cost-based Query Optimization 1. 기본 컨셉 Assign Cost to Operations Assign Cost to partial or alternat..