Back to the Basics

주로 단일 인덱스를 많이 사용해 왔고 복합인덱스를 가끔 사용하곤 한다. 최근 면접 질문에서 관련 이야기가 나왔고 제대로 대답을 하지 못했다. 복합인덱스가 어떻게 저장되는지, 복합인덱스의 순서를 어떻게 해야 효과적으로 사용할 수 있는지에 대한 것은 사용하는 입장에서 당연히 알아야 할 개념이었다. 무턱대고 설정해 놓는다면 인덱스가 소용없게 될 수도 있다. 이번에 인식한 김에 정리를 해보았다.참고로 postgresql을 기준으로 하였다.목차는 아래와 같다1. 복합인덱스란?2. 복합 인덱스의 구조, 어떻게 생겼고 어떻게 작동하나?3. 복합인덱스는 어떻게 설계해야할까?4. 정리1. 복합인덱스란?복합인덱스는 하나 이상의 컬럼을 을 조합하여 만든 인덱스이다. 예를 들어 "name" 과 "age" 라는 두 열에 대해 ..

이전 포스팅 [TEST] 테스트 원칙에 대하여 - 소프트웨어 테스트의 7원칙과 FIRST원칙  에서는 효과적인 테스트 코드 작성을 위해 참고할만한 원칙들을 알아보았다.  이 두 가지 원칙을 요약해 보았다.1. 테스트의 가장 큰 목적은 문제점을 찾는 것이다. 이를 위해 문제가 될 수 있는 다양한 케이스에 대해 수행되어야 한다.2. 모든 것을 테스트하는 것은 불가능하므로 중요한 부분(비즈니스!)에 집중되어야 한다. 3. 테스트는 구현이 아닌 명확한 결과로 성공 여부를 판단할 수 있어야 한다(True or False)4. 테스트는 빠르고 독립적이며, 실행할 때마다 동일한 결과는 제공해야 한다5. 테스트코드는 코드작성과 동시에 또는 그전에 설계되는 것이 이상적이다이번 포스팅에서는 이런 원칙들을 기반으로 테스트코..

이전 회사에서도 테스트 코드 작성에 대한 명확한 지침이 없었다. 그래서 주로 기존에 작성된 테스트 코드들을 참고하며 비슷한 방식으로 작성했다.테스트 코드를 작성하면서 종종 '이 테스트가 과연 의미가 있을까?' 하는 의구심이 들기도 했다. 특히 새로운 기능을 추가하거나 리팩토링을 할 때마다 테스트 코드를 상당 부분 수정해야 하는 경우도 많았다. 이런 비효율로 인해 업무가 많을 때는 테스트 코드 작성을 미루거나 건너뛰기도 했다. 이런 패턴이 반복되다 보니 '내가 테스트를 제대로 작성하고 있는 걸까?' 하는 의구심이 들었다.물론 테스트 코드의 가치는 충분히 이해하고 있다. 기능을 변경했을 때 버그 여부를 빠르게 확인할 수 있고, 테스트를 통해 비즈니스 로직을 더 잘 이해할 수 있다. 개발 과정에서 버그를 조..

자체 서비스에서 주소 검색 서버를 개발하는 프로젝트를 진행했던 적이 있다. 주소 데이터베이스 구축부터 검색 서버까지 개발하는 프로젝트였다. 서드 파티를 사용하면 되지, 왜 자체 주소 검색 서비스를 만드는가에 대한 의문도 있겠지만 이는 도메인 특성상 주소나 영역에 대해서 서드파티로는 한계가 있던 부분이 많았기 때문이었다.이때 사용했던 postgresql의 full text search에 대해 조사했던 것을 다시 정리해 보았다. (나중에는 postgresql > elasticsearch로 개발하였다.)내용이 조금 많기에 순차적으로 포스팅할 예정이다. 이번 포스팅에서는 Full text search에 사용되는 기본 개념을 소개하고 다음 포스팅에서는 정확한 주소 검색을 위해 고민했던 방법에 대해서 정리해 보려고..

서론 .. 주저리주저리이번에 진행하는 프로젝트에서 full text search를 하기위해 Elastic Search를 적용하게 되었다.(여담이지만 개발공부를 할 때에는 MySQL, 회사에 들어와서는 PostgreSQL등 관계형 DB들만 사용해봤는데 No SQL을 직접 사용해 볼 기회가 와서 좋다)full text search를 해야하는 이유는 바로 통합검색을 하기 위함이었다.기존에 사용하던 방식은 postgreSQL 에서 통합검색을 하는 방식이었는데 자유분방한 사용자 입력에 대해 부분검색을 구현하는데 한계가 있어 결국 elasticSearch를 사용하기로 하였다.참고로 full text search란 DB 내에서 특정 키워드나 문서와 일치하는 텍스트를 찾는 검색 방법이다. 일반 검색과 다른점은 일반 검..

Page 는 데이터베이스에서 데이터를 읽어오는 하나의 단위이다. SELECT query를 할 때 내가 원하는 행만 disk에서 가져오는 것이 아니라 page라는 단위로 disk에서 캐싱을 한다. 지금까지는 Database를 단순히 사용하기만 했었다. 하지만 느린 쿼리는 결국 문제를 발생시켰고 쿼리 최적화에 대해 고민을 하다보니 Index의 원리에 대해 알아야 했다. 그러다보니 Database에서 파일을 저장하고 관리하는 방법에 대해 알아야 하는 필요성이 생겼다. 그래서 이번 블로그에는 데이터베이스 페이지의 개념, 디스크에 읽기 및 쓰기 방법, 디스크에 저장되는 방법, Postgres에서 페이지 레이아웃에 대하여 정리해보았다. [목차] Page란? Database에서 읽고 쓰기 과정 Page에 들어가는 ..

일요일 오후 저녁 피크 타임에 우리 팀이 관리하고 있던 서버가 죽어버리는 이슈가 있었다. 소 잃고 외양간 고치는 격으로 rate limit을 뒤늦게 구축하게 되었다. 당시 발생했던 상황들과 rate limit을 구축하면서 공부했던 부분에 대해서 기록을 하기 위해 이번 포스팅의 주제로 Rate limit으로 산정하였다. 먼저 이번 포스팅에서 1.Rate limit이 필요한 이유를 경험담을 담아 이야기 해보고 다음 포스팀에서 "Rate limit의 여러 종류들(알고리즘)"에 대해 알아본다. 그리고 그다음 포스팀에서 1. rest api에서의 rate limit과 graphel에서의 rate limit의 차이점에 대해 정리해 보고 2. 직접 구현을 해본 것에 대해 정리해 보려고 한다. 몇 차례에 걸친 꾀나 시..

SQL이란 SQL은 Structured Query Language의 약자로 국제 표준 데이터베이스 언어이다. 관계형 데이터베이스(RDB)를 지원하는 언어로 주로 사용된다. 관계 대수와 관계 해석을 기초로 한 혼합 데이터이다. 질의어(Query Language)의 기능 뿐 아니라 데이터 구조 정의, 데이터 조작, 데이터 제어 기능을 갖추고 있다. SQL 분류 SQL은 사용 용도에 따라 DDL(데이터 정의어), DML(데이터 조작어),DCL(데이터 제어어)로 구분된다. DDL (Data Difine Language) 데이터 정의어 DDL은 데이터를 정의할 때 사용한다. Schema, Domain, Table, View, Index를 정의 , 변경, 삭제할 때 사용하는 언어이다. DDL은 번역한 결과가 Dat..