MySQL 서버가 시작되거나 종료될 때는 MySQL 서버(InnoDB 스토리지 엔진)의 버퍼 풀 내용을 백업하고 복구하는 과정이 내부적으로 실행된다.
실제 버퍼 풀의 내용을 백업하는 것이 아니라,
버퍼 풀에 적재돼 있던 데이터 파일의 데이터 페이지에 대한 메타 정보를 백업하기 때문에 용량이 크지 않으며, 백업 자체는 매우 빠르게 완료된다.
하지만 MySQL 서버가 새로 시작될 때는 디스크에서 데이터 파일들을 모두 읽어서 적재해야 하므로 상당한 시간이 걸릴 수도 있다.
NoSQL(HBase와 MongoDB)는 특정 유스케이스에 적합한 DBMS인 반면, MySQL 서버와 같은 DBMS는 범용 DBMS 영역에 속한다.
어떤 서비스를 개발하든 초기에는 범용 DBMS를 선택하고, 사용량이나 데이터의 크기가 커지면 일부 도메인 또는 테이블의 데이터만 전용 DBMS로 이전해서 확장하는 형태를 대부분 회사에서 선택하고 있다.
그래서 어떤 서비스를 개발하더라도 RDBMS 선택을 피할 수 없으며, 그 선택의 첫 번째 후보로 MySQL 서버가 견고히 자리잡고 있다.
최근에는 다양한 프로그래밍 언어에서 ORM 도구를 지원하고 있으며, 많은 프로젝트에서 ORM 기능을 채택하고 있다.
ORM 사용 시 개발 생산성 측면에서 효과가 좋지만, ORM은 DBMS와의 인터랙션을 블랙박스로 만들어 버리기 때문에 ORM 도구가 DBMS로 어떤 쿼리를 실행하는지을 알기 어렵다.
ORM을 사용했을 때 테이블의 레코드를 1건만 읽어도 될 쿼리를 몇만 똔느 몇십만 레코드를 읽어서 처리하도록 쿼리를 생성하는 경우가 드물지 않게 발생하는 것을 경험했다.
AWS 같은 클라우드 환경의 DBMS 서버들은 자원을 무제한 사용하도록 해주고 사용한 만큼 비용을 가져간다.
즉, 컴퓨팅 자원이 쉽게 낭비될 수 있는 환경이고 이런 낭비는 결국 비용 증가로 연결될 것이다.
결국 사용자 입장에서 필요한 만큼 지식과 경험을 쌓아, 더욱 효율적이고 최적화된 형태로 개발이 이뤄질 수 있도록 해야한다.
출처 : Real MySQL 8.0 (1권)개발자와 DBA를 위한 MySQL 실전 가이드
