WAL2 모드에서는 하나 대신 두 개의 WAL 파일을 사용함. 파일은 "<데이터베이스>-wal"과 "<데이터베이스>-wal2"로 명명됨. 데이터가 데이터베이스에 쓰여질 때, 쓰기 작업은 첫 번째 WAL 파일에 새 데이터를 추가하는 것으로 시작함. 첫 번째 WAL 파일이 충분히 커지면, 쓰기 작업은 두 번째 WAL 파일에 데이터를 추가하도록 전환함. 이 시점에서 첫 번째 WAL 파일은 체크포인트를 할 수 있고(이후에 덮어쓸 수 있음), 두 번째 WAL 파일이 충분히 커지고 첫 번째 파일이 체크포인트된 후에는 다시 첫 번째 WAL 파일로 전환함. 이런 과정이 계속됨.
이 방식은 매우 논리적이어서 처음부터 WAL 모드가 이렇게 구현되지 않은 이유를 이해할 수 없음. 아마도 시기상조로 여겨진 최적화였을 수도 있음.
이 모드가 일반적으로 사용 가능해지기를 기대함.
Bedrock
Bedrock은 더 흥미로운 브랜치임.
WAL2 + CONCURRENT 기능을 포함함.
Expensify가 단일 노드에서 4M QPS까지 확장하는 데 사용하는 브랜치임(6년 전).
WAL2 모드와 유사한 기술인 left-right primitive에 대한 링크 제공.
이 기술은 링크된 구현보다 오래되었지만 독립적으로 재발견되었으며, 특히 Noria라는 다른 고성능 SQL 데이터베이스를 지원하기 위해 작성됨.
WAL2 모드에서는 하나 대신 두 개의 WAL 파일을 사용함. 파일은 "<데이터베이스>-wal"과 "<데이터베이스>-wal2"로 명명됨.
얼마나 많은 사람들이 wal 파일을 삭제할지 궁금함. wal2로 전환했으니 wal 파일은 남은 것으로 생각할 수 있기 때문.
Microsoft SQL Server는 유사한 아키텍처를 사용하지만 별도의 로그 파일 대신 물리적(디스크 상의) 로그 파일 내에 Virtual Log Files(VLF)를 할당함. VLF는 링 버퍼에서 할당되며 수천 개까지 있을 수 있음.
이 기능이 아직 출시되지 않았다는 것을 알 수 있음.
WAL이 데이터 무결성을 유지하고 충돌로부터 복구하는 데 도움이 되기 위해 존재한다는 점이 항상 걱정되었음. 그러나 파일 자체가 배치로 쓰여지고(디스크에 신뢰성 있게 커밋됨) 데이터베이스의 모든 변경 후가 아니라 성능을 얻기 위해 그렇게 함. 이것이 목적을 무너뜨리지 않는가? 일반적으로 데이터베이스에 특정하지 않고, 이에 대한 답을 찾지 못함.
이것이 Litestream과 같은 새로운 분산 SQLite 시스템에 어떤 영향을 미칠지 궁금함.
Hacker News 의견
Bedrock
WAL2 모드와 유사한 기술인 left-right primitive에 대한 링크 제공.
Microsoft SQL Server는 유사한 아키텍처를 사용하지만 별도의 로그 파일 대신 물리적(디스크 상의) 로그 파일 내에 Virtual Log Files(VLF)를 할당함. VLF는 링 버퍼에서 할당되며 수천 개까지 있을 수 있음.
이 기능이 아직 출시되지 않았다는 것을 알 수 있음.
WAL이 데이터 무결성을 유지하고 충돌로부터 복구하는 데 도움이 되기 위해 존재한다는 점이 항상 걱정되었음. 그러나 파일 자체가 배치로 쓰여지고(디스크에 신뢰성 있게 커밋됨) 데이터베이스의 모든 변경 후가 아니라 성능을 얻기 위해 그렇게 함. 이것이 목적을 무너뜨리지 않는가? 일반적으로 데이터베이스에 특정하지 않고, 이에 대한 답을 찾지 못함.
이것이 Litestream과 같은 새로운 분산 SQLite 시스템에 어떤 영향을 미칠지 궁금함.
그래서 기본적으로 데이터베이스를 위한 더블 버퍼링인가? 이해가 됨.
WAL2 모드는 HC-tree 백엔드 연구의 벤치마크에 포함되었음.