개발놀이터

이번 포스팅에서는 CAP정리를 간단하게 복기해보고 CP, AP 데이터베이스의 특징에 대해서 정리해보도록 하겠습니다.  CAP 정리CAP 정리는 2000년에 Brewer가 발표한 이론으로서 "분산 시스템에서 C, A, P를 모두 만족하는 데이터베이스는 없다" 라는 이론입니다. 이 이론에 대한 증명이 끝났기 때문에 더이상 이론이 아니라 정리라고 불러야하는 것이죠.  CAP 정리에 대해 포스팅한 것이 있어서 그걸 좀 가져와봤습니다.  https://coding-review.tistory.com/312 CAP 정리와 한계 PACELC 정리이번 포스팅에서는 Brewer (브루어)의 CAP정리에 대해서 알아보도록 하겠습니다. CAP정리가 20년도 더 된 정리이기 때문에 그걸 보완한 PACELC 정리에 대해서도 알아..

NoSQL 중에서 가장 인기있는 데이터베이스를 꼽아보라고 한다면 당연 MongoDB이지않을까 싶습니다. 저도 NoSQL에 대해서 공부하기 전에도 MongoDB는 알고 있었을 정도니까 말 다한것이죠.  오늘 포스팅에선 NoSQL 그 중에서 MongoDB가 어느 부분이 특별해서 이렇게 많은 개발자들에게 사랑받고 있는지 정리해봤습니다.  MongoDB의 구성 요소MongoDB의 구성요소는 RDBMS의 그것과 굉장히 닮아있습니다. 하나씩 살펴보겠습니다.  Collection : Collection은 RDBMS에서 테이블에 해당하는 개념으로 문서들의 집합체입니다. Collection은 스키마가 따로 존재하지 않아서 다양한 구조의 문서를 저장할 수 있습니다. Document : MongoDB의 데이터 저장 단위로 ..

약 20일전에 "메세지 브로커의 근심과 걱정" 이라는 포스팅을 작성하였습니다.  https://coding-review.tistory.com/566 메세지 브로커의 근심과 걱정마이크로 서비스와 메세지 브로커는 뗄 수 없는 사이입니다. 서로 다른 도메인이 여러개의 서버로 나눠져 있는 상황에서 모든 서버에 동일하게 데이터를 전달해야 하는 경우에 메세지 브로커만coding-review.tistory.com 위의 포스팅에서는 데이터베이스의 트랜잭션과 메세지 브로커의 통합을 위해서 어떤 부분을 고려해야 하는지에 대한 내용이었습니다.  정상적인 상황에서는 문제 없지만 만약 예외 상황에서 트랜잭션 롤백이 되었을 때 메세지 브로커도 그에 맞춰서 메세지가 전송되지 않아야하는데 트랜잭션과 메세지 브로커를 통합하는 것은 또..

MySQL의 InnoDB 스토리지 엔진의 기본 격리수준은 REPEATABLE READ입니다. 하지만 REPEATABLE READ에서 발생할 수 있는 문제 중 하나인 Phantom Read를 피할 수는 없는데요.  MySQL은 각종 locking 매커니즘을 이용해서 Phantom Read를 막을 수 있었다고 MySQL팀은 설명했습니다. 하지만 무조건 Phantom Read가 발생하지 않는 것은 아닙니다.  이번 포스팅에선 MySQL에 사는 유령에 대해서 공부해보고 정리해봤습니다.  Phantom Read우선 Phantom Read에 대해서 간단하게 짚고 넘어가도록 하겠습니다.  어떤 상황이 Phantom Read를 발생시킬까요? A트랜잭션이 SELECT 쿼리를 날린다B트랜잭션이 이후 INSERT 쿼리를 날..

MySQL은 다양한 레플리케이션 전략을 가지고 있습니다. 동기, 반동기, 비동기 이렇게 세 가지 전략을 가지고 있죠. 그 중에서 Orchestrator는 비동기 레플리케이션을 구현할 수 있게 해주는 서드파티 툴입니다.  이번 포스팅에선 Orchestrator가 어떻게 자동으로 장애회복을 할 수 있는지, 어떻게 레플리케이션을 구축할 수 있는지에 대해서 공부해보고 정리해봤습니다.  Orchestrator가 뭐야?Orchestrator는 MySQL진영의 레플리케이션을 구축하기위한 서드파티 툴입니다. Orchestrator는 GUI로 MySQL서버들을 관리할 수 있다는 것만으로도 쓸만한 이유가 되는 툴인데요.    이렇게 노드의 위치를 옮겨가면서 노드들을 관리할 수 있습니다.  노드를 끌어다 마스터노드로 놓으면..

이번 포스팅에선 Redis Cluster에 대해서 깊이있게 공부해볼겸 왜 제가 Redis Cluster 대신 Redis Sentinel을 사용하게 되었는지 정리해보는 시간을 가져볼까합니다.  Redis ClusterRedis Cluster는 Redis Sentinel의 상위호환이라며 Redis의 고가용성을 위해서라면 Cluster를 사용해야한다는 포스팅을 어디선가 봤습니다. Cluster가 Sentinel과 어떻게 다르길래 이런말이 나오는지 자세히 알아봤습니다.  Sentinel에 대해서는 아래의 링크에 자세히 설명되어있으니 짚고넘어가지 않습니다! https://coding-review.tistory.com/472 Redis 장애시 RDBMS의 연쇄적인 장애에 대응하기 위한 전략만약 캐싱 솔루션으로 Re..

이번 포스팅은 PostgreSQL의 로드맵인 아래의 링크에서 영감을 받았습니다.  https://roadmap.sh/postgresql-dba DBA Roadmap: Learn to become a database administrator with PostgreSQLCommunity driven, articles, resources, guides, interview questions, quizzes for DevOps. Learn to become a modern DevOps engineer by following the steps, skills, resources and guides listed in this roadmap.roadmap.sh DBA를 위한 로드맵이지만 요즘 데이터베이스를 공부하고 있는..

포스팅을 작성하게 된 계기는 해당 포스팅을 보고 나서입니다.  https://blog.naver.com/shino1025/223124936920 Table Join은 정말 느리지 않은가?RDBMS의 쿼리에서 빼놓을 수 없는 핵심 기능 중 하나가 바로 "JOIN"이다. 조인은 각기 ...blog.naver.com 사실 6개월전에 봤던 게시글인데 오랜만에 북마크 정리하다가 보게 됐습니다.  6개월전에 볼 때와 크게 다르지 않을 것이라고 예상했던 것과 다르게 꽤 많이 다르게 보였습니다.  이전에 봤을 땐 그저 읽고 이해하기만 했는데 이젠 다른 생각이 들기 시작했습니다.  조인 연산, 성능에 영향을 줄까? 안줄까?일단 직관상 영향을 줄 것처럼 생겼습니다. 테이블을 하나만 조회하는 것과 두개, 세개를 조합해서 조..

이번 포스팅은 데이터베이스의 조인 알고리즘과 쿼리를 최적화하는 방법에 대해서 공부해보고 정리해보겠습니다.  데이터베이스를 깊이있게 공부하면 공부할수록 왜 큰 기업들이 DBA라는 직군을 따로 뽑는지 알 수 있게 되는 대목이었습니다. 정말 데이터베이스 하나만으로도 공부해야될게 엄청나게 많네요.  그럼 시작해보겠습니다! 데이터베이스 조인 알고리즘우리가 RDBMS에서 쿼리를 작성하면 우리가 원하는 데이터를 가져오기위해 조인 연산을 진행하게됩니다. 이 조인연산을 최적화하기위해 데이터베이스 내부에선 옵티마이저라는 엔진이 돌아갑니다.  옵티마이저는 데이터베이스의 상태를 파악하고 어떤 조인 알고리즘을 사용하면 좋을지 어떤 인덱스를 사용하면 좋을지 자체적으로 판단하여 조인연산을 최적화합니다.  보통 실행계획을 실행해보면..

https://coding-review.tistory.com/533 Redis Sentinel 도커 배포하기대기열 만들기를 진행한게 벌써 10일 전이네요... Redis Sentinel 정말 골치아픈 녀석이었습니다.  이번 포스팅에선 Redis Sentinel을 도커로 배포하면서 삽질했던 부분들을 정리하고자 글을 쓰게 되었coding-review.tistory.com 이 포스팅에 대부분의 세팅이 담겨있습니다! 위의 링크를 참고해주세요.  이번 배포에서 달라진 것이라면 슬랙과 연동하는 것입니다. Sentinel에선 모니터링과 더불어 알람을 제공해줍니다. 특정 상황이 되면 쉘 스크립트 파일을 실행하는 것이죠.  바로 시작해보죠! #!/bin/bashEVENT_TYPE=$1MASTER_NAME=$2MASTER..