조회수·댓글을 D1로 — 스키마, 1회 시드, 30분 중복 제거, 그리고 옛 IP 로그를 옮기지 않은 결정

Sat, 07 Nov 2026 07:05:00 +0900

폰 시절 조회수는 JSON 파일 하나, 방문 기록은 또 다른 JSON 파일, 댓글은 또 다른 파일이었다. Node 서버가 메모리에서 30분 중복 방지를 하고 주기적으로 파일에 썼다. 클라우드로 오면서 이 셋을 D1 하나로 모았다. D1은 Cloudflare의 서버리스 SQLite다. 이 글은 그 스키마와, 옮기면서 내린 결정들이다.

표 일곱 개

CREATE TABLE IF NOT EXISTS meta (k TEXT PRIMARY KEY, v TEXT);
CREATE TABLE IF NOT EXISTS views (slug TEXT PRIMARY KEY, n INTEGER NOT NULL DEFAULT 0);
CREATE TABLE IF NOT EXISTS views_daily (day TEXT PRIMARY KEY, n INTEGER NOT NULL DEFAULT 0);
CREATE TABLE IF NOT EXISTS recent_views (k TEXT PRIMARY KEY, ts INTEGER NOT NULL);
CREATE TABLE IF NOT EXISTS visitors (id INTEGER PRIMARY KEY AUTOINCREMENT, ts INTEGER NOT NULL,
 ip TEXT, slug TEXT, country TEXT, city TEXT, lat REAL, lon REAL);
CREATE TABLE IF NOT EXISTS visitor_daily(day TEXT NOT NULL, ip TEXT NOT NULL, PRIMARY KEY (day, ip));
CREATE TABLE IF NOT EXISTS comments (id TEXT PRIMARY KEY, slug TEXT NOT NULL, name TEXT NOT NULL,
 content TEXT NOT NULL, password_hash TEXT NOT NULL, ip TEXT,
 created_at INTEGER NOT NULL, edited_at INTEGER);

마이그레이션 도구는 쓰지 않았다. 첫 요청이 들어올 때 CREATE TABLE IF NOT EXISTS 묶음을 한 번 실행하고, 그 결과를 모듈 변수에 캐시해 같은 인스턴스에서는 다시 돌지 않게 했다. 표가 몇 개 안 되고 변경도 드물어서 이 정도가 알맞았다. 나중에 열을 추가할 일이 생겼을 때는 PRAGMA table_info로 열이 없을 때만 ALTER TABLE을 하는 작은 마이그레이션 목록을 보탰다.

개인정보 on Simon의 AI 시대에 살아남는 법

조회수·댓글을 D1로 — 스키마, 1회 시드, 30분 중복 제거, 그리고 옛 IP 로그를 옮기지 않은 결정

표 일곱 개