SQLite로 큐, 스트림, pub/sub을? Honker의 등장

SQLite 파일 내에서 큐(Queue), 스트림(Stream), pub/sub, cron 스케줄러 기능을 제공하는 'Honker'가 소개됨

Redis + Celery 대신 SQLite를 활용하여 데이터 일관성(Data Consistency)을 확보하고, 운영 부담을 줄이는 것을 목표로 함

폴링 방식(Polling)의 성능 저하 및 SQLite의 동시성(Concurrency) 문제에 대한 커뮤니티의 우려(Community Concerns)가 제기됨

대안 기술(Alternative Technologies), 특히 커널 파일 감시자(Kernel File Watcher) 및 Durable Objects 등, 폴링 방식의 단점을 보완하는 기술들이 제시됨

Honker의 기술적 특징: 폴링 방식

Honker는 SQLite의 `PRAGMA data_version`을 1ms 간격으로 폴링하여 변경 사항을 감지한다. 이는 커밋 시 증가하는 모노토닉 카운터(Monotonic Counter)를 읽는 방식으로, 약 3µs의 짧은 시간 안에 완료된다. 이러한 폴링 방식은 별도의 데이터 격리 아키텍처(Data Isolation Architecture) 없이 구현되어, 데이터베이스(Database) 변경을 즉각적으로 감지할 수 있게 한다. 하지만, 댓글에서는 이러한 폴링 방식이 CPU 자원 낭비(CPU Waste)를 초래할 수 있다는 비판이 제기되었다.

SQLite의 동시성(Concurrency) 문제

Honker는 SQLite를 기반으로 큐(Queue) 기능을 제공하지만, SQLite의 단일 쓰기 프로세스(Single Writer Process) 제약으로 인해 동시성(Concurrency) 문제가 발생할 수 있다는 지적이 있다. 특히, 여러 스레드 또는 프로세스에서 동시에 큐에 접근할 경우, 성능 저하 및 경쟁 조건(Race Condition) 발생 가능성이 있다. 이에 대한 대안으로, 링 버퍼(Ring Buffer) 및 futex/eventfd를 활용한 스레드 간 통신(Inter-Thread Communication) 방식이 제시되었다.

Honker vs 기존 큐 시스템

Honker는 Redis + Celery와 같은 기존 큐 시스템을 대체하는 것을 목표로 한다. Honker는 SQLite를 활용하여 데이터 일관성(Data Consistency)을 확보하고, 운영 복잡성을 줄일 수 있다는 장점이 있다. 하지만, 댓글에서는 Redis와 같은 분산 시스템(Distributed System)이 제공하는 확장성(Scalability) 및 고가용성(High Availability)을 SQLite가 따라갈 수 없다는 비판이 제기되었다. 또한, Honker의 폴링 방식이 성능 병목(Performance Bottleneck)을 유발할 수 있다는 우려도 존재한다.

대안 기술 및 개선 방향

Honker의 폴링 방식에 대한 비판과 함께, 커널 파일 감시자(Kernel File Watcher) 및 mmap'd shm 파일 체크와 같은 대안 기술이 제시되었다. 특히, `inotify`를 활용하여 `-wal` 파일을 감시하는 방법이 언급되었으며, `BEGIN IMMEDIATE TRANSACTION; ROLLBACK;`을 통해 변경 사항의 가시성을 보장해야 한다는 내용이 포함되었다. 또한, Durable Objects와 같은 기술을 활용하여 폴링 없이 큐(Queue) 기능을 구현하는 방안도 제시되었다.