고양이 두 잔

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며1편에서 4편까지가 쿼리를 빠르게 만들고 데이터를 설계하는 이야기였다면, 이 글은 그 데이터베이스를 살아 있게 유지하는 이야기다. 쿼리를 아무리 잘 짜고 인덱스를 잘 걸어도, PostgreSQL을 운영하다 보면 쿼리 계획과는 무관한 곳에서 시스템이 무너진다. 그 대표적인 두 함정이 autovacuum이 뒤처져 ..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며앞선 세 편은 데이터가 쌓인 뒤에도 되돌릴 수 있는 처방, 즉 진단과 튜닝, 그리고 분산 처리를 다루었다. 이번 편은 한번 정하면 되돌리기가 매우 어려운 결정, 즉 설계를 다룬다. 설계가 까다로운 이유는, 수억 행이 쌓인 뒤에 바꾸려면 테이블을 통째로 다시 만들다시피 해야 하기 때문이다. 그래서 데이터 타입과 ..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며2편까지는 한 대의 데이터베이스 안에서 쿼리를 빠르게 만드는 방법을 다루었다. 그러나 1편에서 보았듯, 가장 큰 기계의 천장에 닿거나 데이터가 한 대에 들어가지 않으면 여러 대로 나누는 분산 처리로 넘어가야 한다. 이 편은 그 분산 처리의 일반 개념을 다루되, 사실상 표준으로 자리 잡은 Spark의 용어와 동작..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며1부에서는 대용량 데이터가 느린 이유와 최적화의 공통 원리를 다루었다. 이번 편은 그 원리 가운데 단일 데이터베이스에서 되돌릴 수 있는 처방, 즉 튜닝을 PostgreSQL 기준으로 구체화한다. 모든 손질은 진단이 먼저이므로, 어디가 왜 느린지를 실행계획으로 읽는 데서 출발한다. 그다음 전체 탐색을 줄이는 인덱..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며데이터의 양이 적을 때는 쿼리를 어떻게 작성하든 결과가 빠르게 돌아온다. 그러나 데이터가 수억 행 규모에 이르면 같은 쿼리가 갑자기 수십 초씩 걸리기 시작한다. 이 차이는 쿼리 문장의 우열보다 데이터가 물리적으로 어디에 있고 얼마나 움직이는지에서 비롯된다. 이 글은 대용량 데이터가 왜 느려지는지를 먼저 살피고..

목차 들어가며관계형 데이터베이스(RDBMS)를 고를 때 PostgreSQL, MySQL, MariaDB는 가장 먼저 검토되는 세 가지 오픈소스 선택지이다. 결론부터 말하면, 새로 시작하는 프로젝트에서 데이터 정합성과 복잡한 질의, 그리고 확장성이 중요하다면 PostgreSQL이 합리적인 기본값이다. 반대로 단순한 데이터 입출력 위주이거나 기존 LAMP(리눅스·아파치·MySQL·PHP로 구성된 전통적 웹 환경)를 그대로 활용해야 한다면 MySQL이나 MariaDB가 더 나을 수 있다. 스택오버플로우(Stack Overflow) 2025 개발자 설문에서 PostgreSQL은 사용률 55.6퍼센트를 기록하며 2위 MySQL(40.5퍼센트)과 약 15퍼센트 포인트 격차로 가장 많이 쓰이는 데이터베이스에 올랐다...

목차 FastAPI와 SQLAlchemy, 그리고 Pydantic을 이용한 토이 프로젝트를 진행하던 중 PostgreSQL을 사용해야 할 일이 생겼다. 그냥 MySQL을 사용했어도 되지만, SQLAlchemy와 궁합이 좋은 디비가 PostgreSQL이라길래. 찍먹 하듯이 잠깐 사용하고 넘어가게 될 테지만, 그래도 이렇게 만난 것을 기념으로 블로그에 정리를 해두기로 했다. PostgreSQL, 시작해 보자. Brief History PostgreSQL의 독음은 '포스트그레스큐엘'이다. MySQL을 '마이 에스큐엘'이라고 부르는 것과 차이가 있는데, 포스트그레스큐엘의 개발 과정을 살펴보면 그 이유를 알 수 있다. 포스트그레스큐엘은 캘리포니아대학 버클리분교의 Ingres 프로젝트에서 시작되었다. 이후 문제점을..

목차 벡터 데이터베이스는 벡터 검색 기반 환경을 만들고자 하는 개발자를 위한 것이다. 개발자는 임베딩으로 생성된 벡터를 벡터 데이터베이스에 인덱싱 할 수 있으며, 이를 통해 인접 벡터를 쿼리 하여 유사한 데이터를 찾을 수 있다. 위 설명은 AWS 공식문서에 쓰인 번역문이다. https://aws.amazon.com/ko/what-is/vector-databases/ 벡터 데이터베이스란? 벡터 데이터베이스 설명 - AWS 정보는 다양한 형태로 제공됩니다. 텍스트 문서, 리치 미디어, 오디오와 같이 비정형 정보도 있고 애플리케이션 로그, 테이블, 그래프와 같이 정형화된 정보도 있습니다. 인공 지능과 기계 학습( aws.amazon.com 그러니까 한 마디로 말하자면 고차원 데이터를 벡터 형태로 임베딩 하여 ..

목차 NoSQL NoSQL은 Not only SQL의 약자이며, 기존의 관계형 데이터베이스에서 벗어난 저장방식을 가리킨다. 이에 관한 더 자세한 설명 및 SQL과의 비교는 예전에 정리한 적이 있으므로, 해당 게시글로 대체한다. [데이터베이스]SQL vs. NoSQL [데이터베이스]SQL vs. NoSQL NoSQL는 Not only SQL의 약자로, SQL만을 사용하지 않는 DBMS(DataBase Management System)을 말한다. 관계형 데이터베이스를 주로 사용하는 SQL과 달리 여러 유형의 데이터베이스를 사용하는 넓은 범위라고 보 gnidinger.tistory.com 이 글에서는 Node.js, TypeScript, 그리고 mongoose를 사용하는 환경을 기반으로 mongoDB의 1:N..

목차 _id 몽고디비는 컬렉션에 도큐먼트가 생성될 때마다 자동으로 생성되는 고유한 필드로, ObjectId라는 특수한 데이터 타입을 가진다. 이 타입은 12바이트의 숫자, 정확하게는 24글자의 16진수로 표현된다. 이 숫자는 다시 네 개의 요소로 나뉘는데, 각 요소에 대한 설명은 다음과 같다. Timestamp: ObjectId가 생성된 시간. 이를 이용한 시간순 정렬도 가능 Machine ID: 디비가 돌아가는 머신(컴퓨터)의 식별자이다. 이를 이용해 같은 머신에서 생성된 객체를 구별할 수 있다. Process ID: 몽고디비 프로세스의 ID. 동일한 머신에서 돌아가는 다른 몽고디비 프로세스가 생성한 객체와 구별할 수 있다. Counter: 랜덤값으로 시작하는 카운터 값이다. 동일한 시간, 머신, 프로..