빙응의 공부 블로그

이번 장은 MyISAM은 제외합니다.📝4.1 MySQL 엔진 아키텍처MySQL 서버는 다른 DBMS에 비해 구조가 상당히 독특합니다.사용자 입장에서는 거의 차이가 없지만 이러한 독특한 구조 때문에 엄청난 기능을 누릴 수 있어요.반대로 다른 DBMS에서 발생하지 않는 문제도 생깁니다. 🧷4.1.1 MySQL 전체 구조 MySQL은 일반 RDBMS와 같이 대부분의 프로그래밍 언어를 모두 지원합니다. MySQL은 크게 MySQL 엔진과 스토리지 엔진으로 구분이 가능합니다.책에서는 이렇게 구분한 이유를 MySQL의 쿼리 파서와 옵티마이저 등과 같은 기능을 스토리지 엔진과 구분해서 설명하기 위해서 한 것입니다. 그렇기에 이 둘을 합친 것 자체가 사실상 MySQL 서버입니다. 📌 4.1.1.1 MySQL 엔진..

📝 2장 MySQL 시스템 변수의 특징 MySQL 서버는 기동하면서 설정 파일의 내용을 읽어 메모리와 작동 방식을 초기화하고, 접속된 사용자를 제어하기 위해 값을 별도로 저장한다. 이러한 값을 시스템 변수라고 한다. CMD에서 SHOW VARIABLES && SHOW GLOBAL VARIABLES로 확인 가능하다.SHOW VARIABLES && SHOW GLOBAL VARIABLES 📌 적용 범위 측면의 시스템 변수시스템 변수 값이 어떻게 MySQL 서버와 클라이언트에 영향을 미치는지 판단하려면 각 변수가 무엇인지 알아야 한다.시스템 변수는 적용 범위에 따라 글로벌과 세션으로 나뉘며 일반적으로 세션별로 적용되는 시스템 변수의 경우 글로벌 변수 뿐만아니라 세션 변수에도 동시에 존재한다.글로벌 변수하나의..

📝1장 왜 MySQL을 사용하는가? "어떤 DBMS를 사용해야 할지 모르겠습니다. 어떤 DBMS가 좋은가요??" 책에 따르면, 10년 전에는 DBMS 선택지가 많지 않아 오라클과 MySQL이 주요 선택지였습니다. 당시 오라클은 MySQL보다 성능이 뛰어났지만, 가격이 너무 비쌌습니다. 시간이 지나 데이터의 양이 수백 배, 수천 배로 늘어나면서, 오라클의 비용을 감당하기 어려운 상황이 생겼고, 결과적으로 MySQL이 유일한 대안으로 자리 잡게 되었습니다.  현재는 어떨까요? 시대가 발전하면서 RDBMS만이 아닌 다양한 종류의 DBMS가 등장했습니다. NoSQL을 시작으로 객체 관계형인 PostgreSQL까지요  이 상황에서 DBMS는 어떻게 고르는게 좋을까요?그것은 다음 순서로 고려하는게 좋은 것 같습니..

📝 개요사용자의 부정적인 서비스 경험은 사용자의 이탈을 낳는다.그렇기에 모니터링이 필요하다.모니터링서비스를 지속적으로 관찰하고 장애 발생을 미연에 방지하는 활동예를 들어보자- 응답이 늦는다.   - CPU 사용 급등, 메모리 부족 -> 로직 내부에서 CPU 자원을 너무 많이 사용 최적화가 필요모니터링의 주요 자원 지표 - CPU 사용량 - 메모리 사용량 - 디스크 사용량 - 네트워크 IO모니터링은 사용자의 불편함을 초래하는 이슈들이 발생할 수 있는 것들을 미리 체크하는 것이다. 📝 최적화의 필요성CPU 사용량이 매우 올랐다고 생각해보자...📌 개선방법?원인을 분석하지 않고 단순하게 생각해보자.....CPU가 올랐으니 CPU 성능을 올리면 되지 않을까?????바로바로 AWS 추가 결제 비용 이슈서비스..

📝개요이번에 선배 추천으로 원티드 프리 온보딩 챌린지를 해보았다.양질의 정보를 현업 개발자분이 알려주는 거라 매우 보물같은 시간이였기에 내가 공부한 부분을 남길 생각이다. 사전 과제 기준으로 작성하기에 한번 사전 과제를 해보는 것도 좋다quddaz/wanted-preonboarding-20 (github.com) GitHub - quddaz/wanted-preonboarding-20Contribute to quddaz/wanted-preonboarding-20 development by creating an account on GitHub.github.com1단계를 최소한으로 구현하였다! 이번 포스팅은 개념적인 부분에 해당할 것! 📝오류에 대해 생각해보기📌 생각해보자Q1 = "a" + 1 Q2 = ..

📝캐시 캐시가 없으면 해당 페이지 새로고침마다 이미지 등을 다운받아야 한다. 이것은 매우 비효율적인 행위로 캐시는 자신의 브라우저에 저장되어 다운로드를 안하고 사용할 수 있다. 캐시는 유효 시간을 가지고 있으며, 유효 시간 만료 후의 특별한 로직을 가지고 있다. Last-Modified + if-modified-since 캐시 유효 시간이 초과해서 서버에 다시 요청하면 데이터가 변경이 안되어도 다시 다운받아야 한다. 이것을 해결하기 위한 방법이 Last-Modified + if-modified-since (검증헤더 + 조건부요청)이다. 밑은 코드는 캐시 생성 과정이다. 해당 코드에서 60초 후 캐시가 만료되었을 때 요청을 다시보내면 서버에서 데이터 수정일을 비교하여 수정되지 않았다면 클라이언트는 다시 캐..