지금 이 글이 상위에 떠 있는 게 재밌는 상황 경험 중 설명 Differential Datalog(이 저장소)과 Rust를 활용해서 실시간 전략 게임 만드는 작업 진행 중 DDL이 게임 로직을 담당하는 구조이고, 새로운 아이디어를 배워보고 여러 삽질 경험을 쌓으려는 의도
진행 상황 기대 중인 입장 설명, 결과가 궁금해지는 상황
Differential Datalog 개발이 비활성화된 상황이라서, 그 구현이 어디까지 가능한지, 지금 어느 정도 완성되어 있는지 궁금한 상태
mangle datalog을 Rust로 포팅하려고 조금 진전 이뤄낸 경험 공유 Rust 구현은 여기에서 확인 가능 golang 버전과 같은 저장소에 존재 작업이 더딘 이유는 우선순위가 낮은 것도 있지만, 'second system syndrome' 현상(처음 만든 것보다 두 번째 만들 때 욕심이 많아져 작업이 느려지는 현상) 때문임 Rust 버전의 mangle은 메모리 매핑을 통해 언제든지 디스크에서 데이터를 가져오고 쓸 수 있어 대용량 데이터 처리 가능 golang 버전은 전체 데이터를 메모리에 올려 처리하는 구조임 이 글이 좋은 점은 datalog 파서 구성이 잘 되어있고, LSM 트리 언급이 있어 이해가 잘 된다는 점, data frog에 비해 훨씬 따라가기 쉽다는 점 Rust에는 proc-macros를 활용한 ascent, crepe 등 다양한 datalog 구현이 존재하지만, 실행 중 쿼리를 동적으로 처리하는 데는 제약이 있음 쿼리와 프로그램이 고정된 정적 분석 케이스라면 proc macro 접근법도 충분히 훌륭하다고 생각하는 입장
datalog 열정가들 일부가 꾸준히 모여 활동하는 모습이 보기 좋은 상황 최근 datalog 르네상스가 주춤하는 분위기인데, Datalog 2.0 컨퍼런스도 예전에 비해 소규모였고, HYTRADBOI 컨퍼런스 2회차에서는 datalog 관련 논의 자체가 크게 줄었음 첫 번째 대회에서는 논문의 1/4이 datalog 관련이었던 기억 다른 참가자들이 최근 datalog 프로젝트 경험을 나눠주는 게 큰 힘이 됨 요즘 구식 SQL 데이터베이스에서 대규모 소프트웨어 마이그레이션을 준비하며 데이터 품질 파이프라인을 만들고 있는 중 datalog 쿼리는 잘 구조화하면 가독성이 높아서, 데이터 품질 문제 탐색에 SQL보다 훨씬 효율적인 도구라고 생각
Datalog 2.0 컨퍼런스 참석 인원 적은 게 datalog 자체의 침체라기보다는 행사 구조 문제의 영향이 크다는 의견 Datalog 2.0은 LPNMR이라는 덜 알려진 유럽 컨퍼런스의 위성 행사였고, 이번에는 미국 Dallas에서 랜덤하게 진행됨 본인도 Datalog 2.0에 논문을 제출했으나, 핵심 저자는 따로 있었고, 실제로 datalog 분야 종사자도 행사에 별로 참여하지 않았음 Nemo solver를 발표한 유럽 쪽 참가자가 눈에 띄던 상황 요지는 올해 Datalog 2.0 참석자 수 적었던 것은 행사 자체의 특수성과 위성 행사였던 점이 더 크고, datalog 엔진 구현 자체에 대해 큰 혁신은 남아있지 않다는 관점에서는 동의 실제 연구 흐름은 기본 datalog보다는 stream 기반(HydroFlow), choice(Dusa), chase engine(Egglog) 등 더 흥미로운 주제로 발전 monotonic, chain-forward saturation(Horn clauses)가 엔지니어링적으로 충분히 정립된 방법이라서, 이 위에 semirings, Z-sets 등 새로운 이론 탐구가 이루어지고 있는 상황 설명
필자가 datalog 관련 작업을 잘 한다고 생각하지만, 도입부에서 binary join을 가르치는 방식은 이상적 상황이 아니면 금방 복잡해져서 아쉽다는 입장 generic join 계열 방식이 더 직관적으로 일반화 가능하다는 생각 worst-case optimal join algorithm에 대한 wiki 설명 참고 권장
관련 이야기로, McSherry의 이전 블로그 글에서는 binary join을 적절한 쿼리 플랜 조정으로 worst-case 최적화 런타임 달성 가능함을 증명한 과정 확인 가능 블로그 포스트 참고 안내
해당 블로그 포스트 오프닝에서 "I, a notorious villain, was invited for what I was half sure was my long-due comeuppance."라는 문장이 가장 인상적이었던 올해 최고의 기술 블로그 글 오프닝이라는 생각 글 내내 작가의 유쾌한 서술이 돋보였고, 이렇게 깊이 있는 기술적 주제를 재미있게 읽을 수 있는 글은 드물다는 생각 aliasing 쿼리 최적화 여정을 탐정 소설처럼 흥미롭게 풀어낸 구성 50GB 메모리 사용에 좌절하고, 5GB로 최적화 성공했을 때 같이 응원하게 되는 느낌 코드와 글 솜씨 모두 훌륭하다고 평가
예전에 몇몇 Clojure 팬이 datalog가 SQL보다 더 우수하다고 믿었고, 관계형 DB들이 전부 SQL만 지원하는 게 아쉽다고 말하던 경험 들은 적 있음 왜 그렇게 생각하는지는 직접 파고들어보진 못함
Clojure나 Datomic의 datalog 방언은 나에게는 익숙하지 않지만, datalog 자체에는 공감하는 입장 온라인 notebook 환경에서 datalog를 활용해볼 수 있는 Percival 추천 percival.ink 활용, datalog의 핵심 개념만 익히면 구현마다 손쉽게 전환 가능 Percival을 fork해서 datalog를 SQLite로 컴파일하는 버전도 만든 경험 있음, 포크 버전은 아직 집계 함수나 고급 조인은 미완성 상태이지만 기본 쿼리는 잘 동작함 Logica는 Google 연구원이 만든 훨씬 진지하고 완성도 높은 datalog->SQL 컴파일러로, BigTable, DuckDB 등 다양한 SQL 방언 지원 Logica 참고 재귀 쿼리/규칙을 다룰 때 datalog가 월등히 쉽다는 점이 인상적 SQL로는 가능은 하지만 마치 점토를 빨대로 마시는 느낌 Frank McSherry가 만드는 Materialize.com은 “WITH MUTUALLY RECURSIVE” SQL 형태를 제공하며, Materialize 블로그 참고 중 Notion의 페이지 로드 쿼리와 데이터 동기화에 활용 검토 중 Feldera도 재귀 뷰를 위한 유사한 폼이 있음 Feldera 블로그 포스트 참고 Feldera의 장점은 각 “규칙” 혹은 서브뷰를 독립된 statement로 분리해 작성 가능, 반면 한 문장에 모두 담을 필요 없음 단점은 SQL 문법이 Apache Calcite에서 온 제약이 많다는 점 Materialize SQL은 PostgreSQL 호환성에 노력 중인 인상
얼마 전까지 VMware가 differential datalog에서 멀어졌다는 이야기 본 것 기억 McSharry의 새로운 글이 반가운 상황
Differential Datalog 팀이 Feldera라는 회사를 설립했고, Feldera 웹사이트에서 확인 가능 differential datalog에서 differential SQL로 전환하게 된 이유는 datalog가 시장에서 실제로 채택되기 어렵다는 점 때문이라고 추정
datalog와 Rust를 함께 쓰고 싶다면 cozodb 추천 cozodb는 Rust로 작성되어 datalog 쿼리 문법 지원
cozodb도 흥미로운 프로젝트지만 비활성화된 프로젝트로 보임 2024년 11월쯤에 소스 코드를 살펴보면서 sqlite 저장 백엔드에 간단하게 개선할 수 있는 포인트(이슈 #285)를 발견한 경험 있음
Hacker News 의견