개인 미니 게시판 프로젝트를 진행하고 있습니다. 최소한의 구동용으로 더미데이터가 필요해서 더미데이터를 넣는 방법을 찾아보게 되었습니다. mockaroo 라는 사이트에서 만들어주는 데이터가 아주 기깔나던데 무료회원은 1000건의 제한이 있어서 마음에 들지 않았습니다.... 유저 1만 명, 게시글 5만 건, 댓글 10만 건 정도를 생각하고 있었어서 어떤 방법이 있을까 고민하다가, 파이썬의 faker와 csv 라이브러리를 이용해서 csv 파일을 만들고, mysql에서 지원하는 기능으로 csv를 바로 insert 하는 방법으로 더미데이터를 삽입했습니다. 아래는 하루동안 해봤던 삽질과 진행과정입니다. from faker import Faker import datetime from dateutil.parser im..

- 미래의 저를 위해 작성한 게시글입니다.. airbnb 클론 프로젝트에서, github action을 통한 CI/CD를 구축해보는 요구사항이 있어 맛볼 기회가 있었습니다. 사실 github action이라는 말을 들어보기 전까지는 CI/CD라는 것 자체를 알지 못했습니다. 모든게 생소해서 과정은 조금 고생스러웠지만 해놓고 나니 너무 편하고 좋은 기억이 많이 남네요. 추후에도 이 감동과 편리함을 기억하고자 미래의 스스로를 위해 작성합니다. 더보기 CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는..

이 글은 '대규모 서비스를 지탱하는 기술'을 보고 학습한 내용을 정리한 글입니다. 학습을 목적으로 하는 토이 프로젝트에서는 테이블당 레코드의 개수가 많지 않습니다. 전에 진행했던 프로젝트에서는 많아봐야 40 ~ 50개의 데이터를 넣어놓고 나름 만족했던 기억도 있습니다. 데이터가 적으니 I/O 또한 당연히 적을 수 밖에 없고 AWS 프리티어 ec2 인스턴스에서도 성능과 최적화 부족으로 인한 장애는 겪어본 적이 없습니다. 장애는 모두 제 실수로 일어난.... 설정 파일을 잘못 작성했거나, 어플리케이션에 잘못된 코드가 있다거나 하는 문제였습니다. 그런데, 대형 서비스에서는 다른 이야기입니다. 도서에 나온 '하테나' 웹 사이트에서는 2009년 기준으로 한 테이블에 200GB 이상의 데이터가 쌓여있기도 합니다. ..

이 글은 'Real MySQL 8.0 개발자와 DBA를 위한 MySQL 실전 가이드'를 보고 학습한 내용을 정리한 글입니다. B-Tree 인덱스는 인덱스를 구성하는 1. 칼럼의 크기와 2. 레코드의 건수 3. 유니크한 인덱스 키 값의 개수 등에 의해 작업 성능 영향을 받습니다. InnoDB 스토리지 엔진에서, 주기억장치(하드디스크)에 데이터를 저장하는 가장 기본적인 단위를 페이지, 블록이라고 합니다. 이론적으로 디스크의 모든 읽기와 쓰기는 페이지 단위 미만이 될 수 없습니다. 또, 페이지는 InnoDB 스토리지 엔진의 버퍼 풀에서 데이터를 버퍼링(캐싱) 하는 기본 단위입니다. 인덱스 구조에서 루트, 브랜치, 리프 노드를 구분하는 기준이 바로 이 페이지 단위입니다. 흔히 오해하기 쉬운 것이, B-Tree가..

지금 보고 계시는 글은 코드스쿼드 마스터즈 과정에 참여하며 느끼고 학습한 내용을 정리한 글입니다. 저번 주에 시작한 것만 같은 코드스쿼드 과정이 벌써 마무리되었습니다. 마지막까지 유익한 프로젝트와 수업이 진행되어서 떠나기가 더 아쉬웠던 것 같습니다. 개인적인 이유로 수료를 3주 앞두고 떠나게 되었지만 얻은 것이 너무 많아 후회는 없는 것 같습니다. 공부를 거듭하면서 더욱 선명하게 느껴지는 것은, 좋은 개발자가 되는 길은 참 멀다는 사실입니다. 더 많은 지식을 쌓을수록 스스로 얼마나 부족한지 깨닫게 되고 그 때문에 때로는 슬럼프에 빠지기도 했습니다. 선배 개발자분들은 이 과정을 모두 거치고 깨지고 단련된 후의 모습이라는 것이 새삼 대단해 보이는 생각도 듭니다. 갓 전입온 이등병이 병장을 보는 느낌이랄까요...

지난 프로젝트동안 감사하게도 무려 카카오에 재직중이신 Jack에게 코드리뷰를 받을 기회가 있었습니다. 받았던 코멘트 중, 기능 구현에 급급해 당시에는 넘어갔던 내용 중 다시 살펴보니 흥미로운 내용을 공유해보려고 합니다. 음식상품 데이터를 랜덤으로 추출하는 API를 클라이언트쪽에 제공하고 있었습니다. 초기 데이터를 선택해서 뿌려주는 로직이라 위와 같이 ORDER BY RAND() LIMIT 3 이라는 쿼리문을 작성했고, 잘 작동했습니다. 그런데 위 쿼리는 큰 문제가 있습니다. ORDER BY 의 조건에 RAND()라는 함수가 걸려있어 스토리지 엔진이 비효율적으로 작동하기 때문입니다. RAND() 함수는 쿼리 실행 순간에 레코드에 각각 임의의 값을 할당한 후에 그 할당된 값으로 정렬을 수행하게 됩니다. 비용..