자동매매를 위한 데이터베이스 테이블 설계 방식에 따른 장단점 비교

안녕하세요. 주식관련 투자 지식을 공유하는 인천고래입니다.

기존에 사용하던 자동매매프로그램의 데이터 저장 방식을 새롭게 리빌딩하고 있는 단계에 있습니다.

이 글은 리빌딩 단계의 최초라고 할 수 있는 데이터를 저장하는 테이블을 어떻게 구성을 하는 것이 좋을지에 대한 고찰 했던 사항들을 정리한 글입니다.

 

이 글이 자동매매를 구현하시는 여러분들에게 조금이나마 도움이 되기를 바랍니다. ^^

 

자동매매를 위한 데이터베이스 테이블 설계 방식에 따른 장단점 비교

자동 매매를 하기 위해서는 전체 종목에 대해서(우선주, 스펙주 등은 제외) 데이터를 저장을 해야 하는데

2300여 종목의 일별 데이터를 10년 이상 저장하고, 이후에도 지속적으로 누적될 예정이고

이를 통해서 특정 데이터를 특정 알고리즘에 의해 전 종목의 부합 여부를 판단하여 추출을 해야하는

다중 데이터 쓰기 & 다중 데이터  읽기를 진행해야 하기 때문에 크게 두 가지 방식이 고려될 수 있다고 보여집니다.

• 각 종목별 개별 테이블을 생성 (2300개 테이블)
• 하나의 테이블에 모든 종목의 데이터를 저장 (daily_stock_data 단일 테이블 운영)

두 방식에 대한 쿼리 속도, 유지보수, 확장성, 백업 및 복구 등의 관점에서 분석한 내용을 정리 & 기록합니다.

---

1. 각 종목별 개별 테이블을 생성하는 경우

이러한 경우라면 특정 데이터베이스에 종목별로 약 2300개의 개별 테이블을 생성이 되는 경우입니다.

1-1. 장점

1. 쿼리 속도가 상대적으로 빠를 가능성이 있음

• 개별 테이블로 분리되므로 각 종목 데이터에 대한 SELECT 및 INSERT 속도가 향상될 수 있음.
• stock_code를 WHERE 조건으로 사용하는 경우 인덱스 탐색 없이 전체 테이블 스캔을 줄일 수 있음.

2. 병렬 처리 가능

• 종목별 데이터 수집 및 업데이트 시, 동시에 여러 테이블을 병렬로 갱신할 수 있음.
• 여러 워커(worker) 프로세스를 사용하여 동시 처리 성능을 높일 수 있음.

3. 일부 종목 데이터만 유지보수 가능

• 특정 종목 데이터만 유지보수, 백업, 삭제, 변경 가능하여 불필요한 데이터 접근을 최소화할 수 있음.
• 데이터 정리 및 아카이브(오래된 종목 데이터 이동) 시 테이블 단위로 수행 가능.

 

1-2. 단점

1. 테이블 개수가 많아 관리가 복잡

• 2300개의 테이블을 직접 생성, 삭제, 변경하는 관리 비용 증가.
• 스키마 변경이 필요할 경우, 모든 테이블을 수정해야 하는 부담이 생김.

2. JOIN 연산 시 불리함

• 여러 종목 데이터를 한 번에 분석하려면 UNION ALL 또는 다중 JOIN을 수행해야 함.
• 이는 전체 데이터 조회 시 비효율적이며 성능 저하를 유발할 가능성이 있음.

3. 데이터베이스 커넥션 관리 문제

• 개별 테이블에 대해 동시 쓰기/읽기가 발생하면, DB 커넥션 수가 증가하여 성능에 부담이 될 수 있음.
• 대형 데이터베이스에서는 테이블 개수 제한이 걸릴 가능성이 있음.

4. 테이블 개수에 따른 메타데이터 관리 비용 문제

 

• 2,300여개의 개별 테이블을 유지할 경우, DBMS는 메타데이터(테이블 스키마, 인덱스 정보 등)
• 대형 데이터베이스에서는 테이블 개수 제한이 걸릴 가능성이 있음.

 

---

2. 하나의 테이블에 모든 종목의 데이터를 저장

예를 들어 daily_stock_data 테이블 하나에 stock_code 컬럼을 추가하여 관리하는 형식입니다.

2-1. 장점

1. 유지보수가 용이함

• 테이블 개수를 관리할 필요가 없음 (2300개의 테이블을 운영하는 복잡성 제거).
• 스키마 변경이 쉬움 (테이블을 변경할 때 한 곳만 수정하면 됨).

2. 데이터 분석이 용이함

• 종목 간 비교 분석, 시장 트렌드 분석이 JOIN 없이 가능.
• 동일 테이블 내에서 WHERE stock_code='005930' AND Date BETWEEN '2024-01-01' AND '2024-12-31' 형태로 빠르게 조회 가능.

3. 백업 및 복구가 용이함

• 전체 데이터를 한 번에 백업하거나 복구할 수 있어 장애 대응이 쉬움.
• 특정 종목만 백업하려면 stock_code 필터링을 이용하면 됨.

4. 확장성이 높음

• 종목이 추가되거나 삭제되더라도, 테이블 개수 변화 없이 stock_code만 관리하면 됨.
• 대규모 데이터 처리에 유리하며, 분석용 데이터베이스로도 적합함.

---

2-2. 단점

1. 인덱스 최적화가 필수

• stock_code, Date 컬럼에 적절한 인덱스를 설계해야 쿼리 속도를 유지할 수 있음.
• 예를 들어, (stock_code, Date) 복합 인덱스를 사용하면 개별 종목 조회 속도를 빠르게 유지할 수 있음.

2. 동시 쓰기 성능 저하 가능성

• 2300개 종목의 데이터가 하나의 테이블에 들어가므로, 동시 업데이트 시 Lock 경합 발생 가능.
• 파티셔닝 (Partitioning) 을 적용하여 종목별 데이터 저장을 분산하는 것이 필요할 수 있음.

3. 대량 데이터 삭제 시 부하 발생

• 일부 종목 데이터를 아카이빙하거나 삭제할 때, 하나의 테이블에서 특정 종목만 삭제하는 작업이 부담이 될 수 있음.
• 삭제 성능 최적화를 위해 파티셔닝 또는 파티션 삭제 활용 가능.

---

3. 비교표: 각 방법의 장단점 정리

구분개별 테이블 방식 (2300개)단일 테이블 방식 (daily_stock_data)

쿼리 속도	개별 종목 조회는 빠름	인덱스 최적화 필요
JOIN / 집계 분석	불편함 (UNION ALL 필요)	매우 편리 (GROUP BY 활용 가능)
유지보수 용이성	테이블 관리 복잡	유지보수 간단
확장성	테이블 개수 증가 시 문제 발생	종목 추가/삭제가 용이
백업 및 복구	종목별 백업은 쉬우나 전체 복구가 어려움	전체 백업 및 복구 용이
동시 쓰기 성능	테이블별로 분산 가능	동시 쓰기 부하 발생 가능 (파티셔닝 필요)
삭제 성능	종목별 삭제 용이	특정 종목만 삭제 시 부하 가능 (파티셔닝 필요)

---

4. 추천하는 데이터베이스 설계

① 단일 테이블(daily_stock_data)을 유지하되, 파티셔닝을 적용하는 방식이 가장 효율적

• stock_code를 기준으로 파티셔닝을 적용하여 테이블을 논리적으로 분할하면, 조회 및 쓰기 성능을 향상시킬 수 있음.

예제: stock_code별 RANGE 또는 LIST 파티셔닝

CREATE TABLE daily_stock_data (
    stock_code TEXT NOT NULL,
    stock_name TEXT,
    Date DATE NOT NULL,
    Open REAL,
    High REAL,
    Low REAL,
    Close REAL,
    Volume REAL,
    Amount REAL,
    PRIMARY KEY (stock_code, Date)
) PARTITION BY LIST (stock_code);

 

 

---

5. 어떤 방식을 선택해야 할까?

위에서 알아본 바와 같이 각각의 장단점은 극명하게 존재하는 것 같습니다.

다만, 단일 테이블에서의 단점은 파티셔닝을 통해서 해결할 수 있는 만큼 이 방식이 가장 유지보수 및 운영 효율성이 높은 선택이 될 것 같네요.

 

다만 여기에서는 중요한 것이 지금 선택한 사항이 향후 다른 방식으로의 전환이 쉬운지를 판단해야 하는데

즉, 방식 전환을 할 경우 유지보수 및 데이터마이그레이션 비용에 대해서 판단을 해야 한다는 것입니다.

5-1. 테이블 설계의 유지보수 비용

• 단일 테이블은 유지보수가 간단함 (스키마 수정, 백업, 데이터 관리 등).
• 반면, 개별 테이블은 테이블 개수가 많아질수록 유지보수 비용이 급격히 증가함.
• 처음부터 단일 테이블로 시작하면 유지보수 비용이 줄어들고, 개별 테이블로 전환하는 경우도 비교적 쉽다.
  
  

5-2. 데이터 마이그레이션 비용

• 개별 테이블 → 단일 테이블로 데이터를 이동하는 것은 시간과 비용이 많이 듦.
  • 모든 테이블을 하나로 합치면서 데이터 정합성 유지가 필요함.
  • 스키마 변경이 필요하고, 백업 및 복구 작업이 번거로워짐.
• 반대로, 단일 테이블에서 개별 테이블로 나누는 것은 비교적 간단함

 

즉, 현 시점에서는 단기적으로 유지보수 비용이 큰 상황을 직면하는 것 보다는 단일 테이블 설계를 통해 유지보수가 간단하게 진행을 한 뒤 개별 테이블 진행여부를 판단하는 것이 좋을 것 같습니다.

 

---

6. 내용 정리

위의 내용들을 종합적으로 정리를 해 보면 아래와 같습니다.

✅ 처음부터 "단일 테이블 + 파티셔닝"을 적용하고, 이후 필요하면 개별 테이블로 전환.
✅ 유지보수 비용과 데이터 마이그레이션 부담을 고려하면, 처음부터 개별 테이블을 유지하는 것은 비효율적.
✅ 특정 종목의 조회 빈도나 성능 이슈가 발생할 때, 일부 종목만 개별 테이블로 전환하는 방식이 최적.

6-1. 최적의 단계적 접근 방법

1. Step 1: "단일 테이블 + 파티셔닝"으로 시작 (테이블 관리 최소화)
2. Step 2: 특정 종목의 조회 빈도가 높아지면 해당 종목만 개별 테이블로 분리
3. Step 3: 오래된 데이터를 종목별 테이블로 이관하여 저장 공간 최적화

즉, 유지보수 비용을 최소화하고 데이터 구조를 유연하게 만들려면, 처음부터 단일 테이블로 시작하는 것으로 진행하는 것으로 결정하는 것이 최선이라고 보여집니다.

 

이것으로 데이터베이스 구축 시 종목별로 데이터를 저장할지? 하나의 테이블에 전체 종목의 데이터를 저장할지에 대한 고민하실 시간을 줄여들일 수 있도록 글을 작성해 봤는데 도움이 되었으면 합니다.

 

긴 글 읽어 주셔서 감사드립니다.

지나가시는 길에 발자국(댓글) 하나 남겨주시면 더더욱 감사하겠습니다. ^^

 

---

 

자신만의 매매법을 자동매매 프로그램으로 만들거나 

기법이 확률이 떨어진다면 백테스팅을 사용해서 확률을 높여야 합니다. 

아래의 링크를 통해서 요청하시면 요청하신 이상(가격대비 성능의 최대치)의 결과물을 받아 보실 수 있습니다.

한 방에 주식 데이터 만들기 - 크몽

 

---

 

다른 보조지표에 대해서는 아래의 링크 글을 통해 자세히 알아 볼 수 있습니다.

보조지표 리스트 (추세, 모멘텀, 채널, 변동성, 거래량, 기타 지표)

---

 

단기적인 스윙 및 세력 매집 분석에 용이한 기준봉에 대해서는 아래의 링크 글을 통해 자세히 알아 볼 수 있습니다.

'주식 기준봉' 카테고리의 글 목록