Redis의 "모든 것이 하나의 스레드에서 직렬화된" 동시성 없는 모델을 어느 정도 따를지에 대한 고민이 있음
SQLite의 저수준 라이브러리를 사용하고, WAL을 활성화하며, 읽기용 goroutine마다 커넥션을 사용하고, 전용 writer 스레드로 버퍼링된 채널/큐를 통해 쓰기 배치를 보내면 SQLite에서 더 나은 성능을 얻을 수 있음
이를 통해 SQLite의 내장 커넥션별 뮤텍스를 끄고도 각 커넥션이 한 번에 하나의 스레드에서만 사용되므로 스레드 안전성을 유지할 수 있음
네트워크 요청/소켓에서 들어오는 파라미터 바이트를 버퍼에 복사하거나 SQLite에서 직접 소켓으로 복사하는 등 arena 스타일의 큰 버퍼를 사용하면 개별 문자열 할당 및 전달을 줄여 시간을 많이 절약할 수 있음
Go에서 SQLite로부터 최대 쓰기 처리량을 얻으려고 노력한 경험에서 나온 팁들임
Redis와 SQLite를 모두 좋아해서 두 가지를 결합하기로 결정함. SQLite는 많은 작은 쿼리에 특화되어 있어 관계형 엔진이 Redis에 가까워질 수 있는 만큼 가까워졌기에 잘 맞을 것 같음
TigerBeetle의 상태 머신을 교체하여 Redis API를 구현할 누군가를 기다리고 있음
데이터 세트가 메모리에 맞는지 여부에 대해 생각할 필요가 없는 Redis 대안이 있으면 좋겠음
Redis의 전체 가치 제안은 메모리에서 작동하여 메모리와 같은 성능을 제공한다는 것임. 디스크로 이동하면 Redis를 사용할 이유가 거의 없음
네트워크 I/O가 추가되면 Redis의 환상적인 성능 중 많은 부분이 사라짐. SaaS 호스팅 Redis 서비스를 사용하면 성능이 큰 타격을 받음. 자체 클러스터에서 Redis 호환 키/값 스토어를 더 쉽게 실행할 수 있다면 이는 이점임
이것 또는 Garnet이 Redis 명령을 더 많이 지원하는지 궁금함. 로컬 디버깅 목적으로 프로그램에 Redis 호환 기능의 하위 집합을 내장하려고 하는데, 중간에 API가 있어 지원되지 않는 Redis 명령에 대해 보호할 수 있음
Foursquare가 MongoDB를 유명하게 만들었을 때 누군가 MySQL에 구현된 NoSQL DB의 PoC를 게시했지만 유행하지는 않았음. 하지만 DB가 필요할 때마다 SQL을 다시 발명하지 않도록 하기 위해 얼마나 많은 성능을 희생했는지 생각하게 만듦. 이와 같은 실험을 좋아하며 때로는 새로운 프로젝트로 이어짐
Redis를 DB 앞에 캐시 레이어로 사용함. 이 개념을 이해하지 못함
그런데 SetMaxConnections(1)을 사용하고 있지만, WAL 모드(사용 중임)에서 SQLite는 읽기를 차단하지 않는 쓰기를 지원하므로 읽기 동시성을 허용하면 이점이 있을 수 있음
Hacker News 의견