SQLite에서 늘 영감을 받음. 전반적으로 좋아하지만, 쓰기를 하지 않는다면 꽤 과한 선택이기도 함
그래서 SQLite를 넘어서지는 못하겠지만, 훨씬 가볍고 빠르며 zstd 압축 파일에서도 동작하는 형식을 만들었음. 인덱스가 매우 작고 SQLite처럼 바이너리나 텍스트를 담을 수 있음
압축 해제·읽기·검색을 담당하는 wasm 부분은 비압축 기준 38KB, gzip 기준 아마 16KB 정도임. SQLite의 wasm과 글루 코드 1.2MB와 비교하면 3% 크기인데 검색과 로딩은 훨씬 빠름
내 프로그램은 열 기반도 아니고 스프레드시트 관리에는 맞지 않지만, 사전과 이미지·오디오 파일 아카이브에는 잘 맞음
jbig2 디코더도 17KB wasm 모듈로 포팅해서, 페이지당 8KB짜리 흑백 스캔도 읽을 수 있고 여전히 알아볼 만함 https://github.com/tnelsond/peakslab
SQLite는 매우 잘 설계됐고, PeakSlab은 매우 단순함
“SQLite의 wasm과 글루 코드 1.2MB”라고 했는데, 현재 trunk의 표준 비축소 형태는 실제로 1.7MB임. 문서가 JS 코드만큼 거의 들어 있어서 WASM과 JS가 거의 반반으로 나뉨. 다만 축소하면 1.2MB가 맞음
참고로 내가 그 유지관리자임
현재 trunk 기준 수치는 sqlite3.wasm 896745, sqlite3.mjs 816270(문서 포함 비축소), sqlite3.mjs 431388(문서 제외 비축소), sqlite3.mjs 310975(축소)임
PeakSlab은 몰랐는데 정말 멋지고 새로움. 사전 성능도 뛰어나 보이고, 나중에 다시 쓰려고 북마크해둘 만함
SQLite도 나름 단순하고, 그 SQL 방언의 설계 원칙이 마음에 듦
“오른쪽 조인은 방향이 반대인 왼쪽 조인일 뿐이니 그런 건 필요 없다” 같은 식임
물론 더 단순하거나 더 특화된 건 항상 가능함. 데이터베이스를 쓰는 많은 앱은 SQLite만으로도 충분히 잘 돌아갈 것이고, 어떤 앱은 SQLite 같은 DB 대신 텍스트 파일만으로도 충분할 듯함
SQLite를 항상 좋아해왔지만, 어떤 회사들은 사용을 금지한다고 들었음
이유는 앱용 데이터베이스를 너무 쉽게 만들 수 있어서, 애플리케이션의 초핵심 구성요소가 그냥 파일처럼 보이게 되기 때문임. 그 파일은 어떤 확장자든 가질 수 있고, 다른 서버로 복사될 수도 있음. 그 안에 개인식별정보가 들어 있어도 마찬가지임
회사 안의 앱 수만큼 이 상황이 늘어난다고 생각하면 꽤 난장판이 될 수 있음
DevOps와 DBA 팀은 데이터베이스가 누가 봐도 데이터베이스 서버인 크고 무거운 장비이길 선호함. 연결하는 행위도 명확히 드러나고 등등
그래도 SQLite는 여전히 좋아함
그렇다면 같은 회사들이 Excel도 금지하는지가 궁금함. Excel 스프레드시트는 예상 못 한 곳에서 그림자 데이터베이스가 되는 일이 많음
그래서 그런 설정 파일은 AppData나 dotfile 디렉터리, 또는 MacOS의 ~/Library 안에 있는 대응 위치에 넣음
예전에는 “SQLite는 장난감 제품이고 실제 데이터에는 믿을 수 없다”고 생각했지만, 이제는 “거의 모든 것에 SQLite를 쓰자” 쪽으로 바뀌었음 단일 작성자, 다중 읽기자 패턴에 맞출 수 있다면 SQLite는 매우 좋음. 올바른 설정만 쓰면 데이터를 잃지 않는데, 그 설정은 1분 정도 검색하면 알 수 있음
요즘 내 앱 대부분은 그냥 Go 바이너리 + SQLite + systemd 서비스 파일 조합임
아직 데이터를 잃은 적이 없고, 성능도 훌륭하며 대부분의 앱에는 충분함
단일 작성자는 실제로는 흔히 말하는 것만큼 큰 문제가 아님. 요즘 NVMe 드라이브는 대단해서 최적화된 WAL 설정이면 초당 5천 쓰기는 쉽게 나옴. 대부분의 앱이 꿈도 못 꿀 수준임
심지어 평범한 VPS에서 배치 작성자 패턴으로 초당 18만 쓰기도 해봤음
백엔드 노드를 여러 개 쓰는지 궁금함. 그렇다면 서로 다른 노드에서 SQLite 파일에 어떻게 접근하는지도 궁금함
“이 글을 쓰는 시점(2018-05-29)…”이라고 되어 있으니 거의 8년 된 소식임. 그래도 지금까지 몰랐기 때문에 불만은 아니고, 올려줘서 고마운 쪽에 가까움
수학 쪽 뇌가 잠깐 고장 나서 6년이라고 착각했음
데이터를 저장할 때 300~500년 뒤까지 계획하고, 온갖 혁신과 기본적인 기술 노후화를 견디게 하려면 장기적 사고가 정말 필요함
가장 오래 살아남은 종이 매체는 무엇일까?
추천 기준이 꽤 느슨해 보임. XLS가 “선호”로 들어가 있음
공공 부문 데이터 보존에는 SQLite가 최고의 선택지 중 하나일 수 있음
명세가 공개되어 있고, 널리 채택됐으며, 앞으로도 읽을 수 있을 가능성이 높음
특정 운영체제나 서비스 의존성이 작고, 특허 위험도 낮음
장기 지속성 관점에서는 특정 회사나 서비스에 의존하지 않는 것이 매우 중요함
아키비스트들은 원본에 가까운 형식도 좋아함. SQLite는 CSV로는 표현하기 어려운 관계형 관계를 그대로 담을 수 있게 해줌
SQLite를 좋아하고 공유해줘서 좋지만, 제목 끝에는 “(2018)”이 붙어야 할 듯함
“이 글을 쓰는 시점(2018-05-29)에 데이터셋용으로 권장되는 다른 저장 형식은 XML, JSON, CSV뿐이다”라고 되어 있음
참고로 그 뒤에 목록에 형식이 많이 추가됐음
선호 형식으로는 데이터가 완전하고 세부사항과 정밀도를 유지하는 한, 네이티브나 바이너리 형식보다 플랫폼 독립적인 문자 기반 형식이 우선됨. 잘 개발되고 널리 채택된 사실상 시장 표준이 포함됨
예를 들면 공개 검증 도구가 있는 잘 알려진 스키마 기반 형식, TSV·CSV·고정폭 같은 줄 지향 형식, .db·.db3·.sqlite·.sqlite3 같은 플랫폼 독립 개방 형식이 있음
또 특정 직업군에서 사실상 표준이거나 여러 도구가 지원하는 독점 형식도 포함됨. 예를 들어 Excel .xls/.xlsx, Shapefile 같은 것임
문자 인코딩은 UTF-8, BOM이 있는 UTF-16, US-ASCII 또는 ISO 8859-1, 그 외 이름 있는 인코딩 순으로 선호됨
허용 형식으로는 데이터의 경우 전문 커뮤니티나 정부기관이 표준으로 승인한 비독점 공개 문서화 형식(CDF, HDF 등), 사용 가능한 스키마가 있는 텍스트 기반 데이터 형식이 있음
묶음이나 전송용으로는 암호화·비밀번호·기타 보호 메커니즘이 없는 ZIP, RAR, tar, 7z가 허용됨 https://www.loc.gov/preservation/resources/rfs/data.html
바로 어제도 HN 상단에서 SQLite 글을 본 지 좀 됐다고 생각했음
SQLite의 단순함과 속도를 정말 좋아하고, 개인 프로젝트와 업무 프로젝트 양쪽에서 써봤음
그래도 일상 업무에서는 결국 Excel로 가게 됨. Excel을 더 좋아해서가 아니라, 워낙 널리 쓰이다 보니 덜 기술적인 이해관계자나 임원과 데이터셋을 공유하고 탐색할 때 마찰이 가장 적은 방식이기 때문임
이걸로 세계관이 갑자기 깨질 거라고 생각하진 않지만, 나에게 유용했던 만큼 도움이 될 수도 있으니 Metabase를 봐볼 만함
직접 호스팅할 수 있고, 이해관계자에게 데이터를 소화하기 쉬운 형태로 보여주는 것만 원한다면 정말 단순함. 물론 과하게 파고들면 인생의 모든 결정을 후회할 수도 있지만, 나는 그러지 않으려고 자제함 https://www.metabase.com/
SQLite가 동작하려면 텍스트 파싱에 의존한다는 점이 늘 거슬렸음. 왜 질의를 텍스트로 써야 하고, 프로그램 로직으로 표현하면 안 되는지 모르겠음
이 때문에 관계형 데이터베이스를 한 번도 써본 적이 없음. 싫어하기 때문임. 순수 구조화 데이터보다 성능이 좋을 수 있다는 건 알지만, SQL과 SQL이라는 발상 자체가 싫고, 쓰거나 배우거나 그것에 의존하는 시스템을 사용하고 싶지 않음
PHP 수준으로 잘못된 접근처럼 느껴짐. 이걸 완화할 방법이 있을까? SQL 때문에 SQLite를 계속 포기하고 싶지는 않지만, 도저히 받아들여지지 않음. 문자열을 만들거나 스택 어디에도 문자열 파싱이 들어가는 게 싫고, 그냥 잘못된 느낌임
SQLite는 놀랄 만큼 다재다능함. 불과 몇 주 전에도 SQLite에서 프로세스 간 큐, 스트림, 발행/구독 등을 구현하는 확장이 공개됐음
Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
실시간 알림은 SQLite 백엔드로 전체 앱을 구현할 때 빠져 있던 큰 조각 중 하나였는데, 이제 꽤 괜찮은 해법이 생김
SQLite가 이 정도의 기관 차원 인정을 받는 걸 보니 좋음. 단일 파일 형식 덕분에 전통적인 데이터베이스 덤프보다 아카이브 저장이 엄청나게 단순해짐
Hacker News 의견들
SQLite에서 늘 영감을 받음. 전반적으로 좋아하지만, 쓰기를 하지 않는다면 꽤 과한 선택이기도 함
그래서 SQLite를 넘어서지는 못하겠지만, 훨씬 가볍고 빠르며 zstd 압축 파일에서도 동작하는 형식을 만들었음. 인덱스가 매우 작고 SQLite처럼 바이너리나 텍스트를 담을 수 있음
압축 해제·읽기·검색을 담당하는 wasm 부분은 비압축 기준 38KB, gzip 기준 아마 16KB 정도임. SQLite의 wasm과 글루 코드 1.2MB와 비교하면 3% 크기인데 검색과 로딩은 훨씬 빠름
내 프로그램은 열 기반도 아니고 스프레드시트 관리에는 맞지 않지만, 사전과 이미지·오디오 파일 아카이브에는 잘 맞음
jbig2 디코더도 17KB wasm 모듈로 포팅해서, 페이지당 8KB짜리 흑백 스캔도 읽을 수 있고 여전히 알아볼 만함
https://github.com/tnelsond/peakslab
SQLite는 매우 잘 설계됐고, PeakSlab은 매우 단순함
참고로 내가 그 유지관리자임
현재 trunk 기준 수치는 sqlite3.wasm 896745, sqlite3.mjs 816270(문서 포함 비축소), sqlite3.mjs 431388(문서 제외 비축소), sqlite3.mjs 310975(축소)임
지금 보니 더 이상 BSD 라이선스도 아니고, 어쨌든 SQLite 때문에 거의 사라졌지만, 기본적인 디스크 기반 키-값 저장소 용도로 쓰였음
“오른쪽 조인은 방향이 반대인 왼쪽 조인일 뿐이니 그런 건 필요 없다” 같은 식임
물론 더 단순하거나 더 특화된 건 항상 가능함. 데이터베이스를 쓰는 많은 앱은 SQLite만으로도 충분히 잘 돌아갈 것이고, 어떤 앱은 SQLite 같은 DB 대신 텍스트 파일만으로도 충분할 듯함
https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)
SQLite를 항상 좋아해왔지만, 어떤 회사들은 사용을 금지한다고 들었음
이유는 앱용 데이터베이스를 너무 쉽게 만들 수 있어서, 애플리케이션의 초핵심 구성요소가 그냥 파일처럼 보이게 되기 때문임. 그 파일은 어떤 확장자든 가질 수 있고, 다른 서버로 복사될 수도 있음. 그 안에 개인식별정보가 들어 있어도 마찬가지임
회사 안의 앱 수만큼 이 상황이 늘어난다고 생각하면 꽤 난장판이 될 수 있음
DevOps와 DBA 팀은 데이터베이스가 누가 봐도 데이터베이스 서버인 크고 무거운 장비이길 선호함. 연결하는 행위도 명확히 드러나고 등등
그래도 SQLite는 여전히 좋아함
https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
“다른 서버로 복사될 수 있다”는 건 스프레드시트도 마찬가지임
중앙화된 데이터 접근이 바람직하다는 점을 부정하는 건 아니지만, 그 논리는 충분히 정교해 보이지 않음
예전에는 “SQLite는 장난감 제품이고 실제 데이터에는 믿을 수 없다”고 생각했지만, 이제는 “거의 모든 것에 SQLite를 쓰자” 쪽으로 바뀌었음
단일 작성자, 다중 읽기자 패턴에 맞출 수 있다면 SQLite는 매우 좋음. 올바른 설정만 쓰면 데이터를 잃지 않는데, 그 설정은 1분 정도 검색하면 알 수 있음
요즘 내 앱 대부분은 그냥 Go 바이너리 + SQLite + systemd 서비스 파일 조합임
아직 데이터를 잃은 적이 없고, 성능도 훌륭하며 대부분의 앱에는 충분함
심지어 평범한 VPS에서 배치 작성자 패턴으로 초당 18만 쓰기도 해봤음
“이 글을 쓰는 시점(2018-05-29)…”이라고 되어 있으니 거의 8년 된 소식임. 그래도 지금까지 몰랐기 때문에 불만은 아니고, 올려줘서 고마운 쪽에 가까움
수학 쪽 뇌가 잠깐 고장 나서 6년이라고 착각했음
2026년 권장 저장 형식: https://www.loc.gov/preservation/resources/rfs/data.html
가장 오래 살아남은 종이 매체는 무엇일까?
공공 부문 데이터 보존에는 SQLite가 최고의 선택지 중 하나일 수 있음
명세가 공개되어 있고, 널리 채택됐으며, 앞으로도 읽을 수 있을 가능성이 높음
특정 운영체제나 서비스 의존성이 작고, 특허 위험도 낮음
장기 지속성 관점에서는 특정 회사나 서비스에 의존하지 않는 것이 매우 중요함
SQLite를 좋아하고 공유해줘서 좋지만, 제목 끝에는 “(2018)”이 붙어야 할 듯함
“이 글을 쓰는 시점(2018-05-29)에 데이터셋용으로 권장되는 다른 저장 형식은 XML, JSON, CSV뿐이다”라고 되어 있음
선호 형식으로는 데이터가 완전하고 세부사항과 정밀도를 유지하는 한, 네이티브나 바이너리 형식보다 플랫폼 독립적인 문자 기반 형식이 우선됨. 잘 개발되고 널리 채택된 사실상 시장 표준이 포함됨
예를 들면 공개 검증 도구가 있는 잘 알려진 스키마 기반 형식, TSV·CSV·고정폭 같은 줄 지향 형식, .db·.db3·.sqlite·.sqlite3 같은 플랫폼 독립 개방 형식이 있음
또 특정 직업군에서 사실상 표준이거나 여러 도구가 지원하는 독점 형식도 포함됨. 예를 들어 Excel .xls/.xlsx, Shapefile 같은 것임
문자 인코딩은 UTF-8, BOM이 있는 UTF-16, US-ASCII 또는 ISO 8859-1, 그 외 이름 있는 인코딩 순으로 선호됨
허용 형식으로는 데이터의 경우 전문 커뮤니티나 정부기관이 표준으로 승인한 비독점 공개 문서화 형식(CDF, HDF 등), 사용 가능한 스키마가 있는 텍스트 기반 데이터 형식이 있음
묶음이나 전송용으로는 암호화·비밀번호·기타 보호 메커니즘이 없는 ZIP, RAR, tar, 7z가 허용됨
https://www.loc.gov/preservation/resources/rfs/data.html
바로 어제도 HN 상단에서 SQLite 글을 본 지 좀 됐다고 생각했음
SQLite의 단순함과 속도를 정말 좋아하고, 개인 프로젝트와 업무 프로젝트 양쪽에서 써봤음
그래도 일상 업무에서는 결국 Excel로 가게 됨. Excel을 더 좋아해서가 아니라, 워낙 널리 쓰이다 보니 덜 기술적인 이해관계자나 임원과 데이터셋을 공유하고 탐색할 때 마찰이 가장 적은 방식이기 때문임
직접 호스팅할 수 있고, 이해관계자에게 데이터를 소화하기 쉬운 형태로 보여주는 것만 원한다면 정말 단순함. 물론 과하게 파고들면 인생의 모든 결정을 후회할 수도 있지만, 나는 그러지 않으려고 자제함
https://www.metabase.com/
이 때문에 관계형 데이터베이스를 한 번도 써본 적이 없음. 싫어하기 때문임. 순수 구조화 데이터보다 성능이 좋을 수 있다는 건 알지만, SQL과 SQL이라는 발상 자체가 싫고, 쓰거나 배우거나 그것에 의존하는 시스템을 사용하고 싶지 않음
PHP 수준으로 잘못된 접근처럼 느껴짐. 이걸 완화할 방법이 있을까? SQL 때문에 SQLite를 계속 포기하고 싶지는 않지만, 도저히 받아들여지지 않음. 문자열을 만들거나 스택 어디에도 문자열 파싱이 들어가는 게 싫고, 그냥 잘못된 느낌임
SQLite는 놀랄 만큼 다재다능함. 불과 몇 주 전에도 SQLite에서 프로세스 간 큐, 스트림, 발행/구독 등을 구현하는 확장이 공개됐음
Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
실시간 알림은 SQLite 백엔드로 전체 앱을 구현할 때 빠져 있던 큰 조각 중 하나였는데, 이제 꽤 괜찮은 해법이 생김
SQLite가 이 정도의 기관 차원 인정을 받는 걸 보니 좋음. 단일 파일 형식 덕분에 전통적인 데이터베이스 덤프보다 아카이브 저장이 엄청나게 단순해짐