From d98f80dde3052acae503c589e15b5243afb864b7 Mon Sep 17 00:00:00 2001 From: eunhhu Date: Wed, 30 Sep 2026 07:56:49 +0100 Subject: Compare TPC-C on the SD card with SQLite committing in groups, not each transaction The 90x of 092 was against SQLite's defaults committing each transaction; tuned for the card and grouped as Pure groups, SQLite is 4-11x behind, the bytes it writes a transaction being the difference. --- CHECKPOINT.md | 6 ++++-- README.md | 8 +++++--- docs/research/092-tpcc.md | 2 ++ 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/CHECKPOINT.md b/CHECKPOINT.md index 644a6cd..57a2ee8 100644 --- a/CHECKPOINT.md +++ b/CHECKPOINT.md @@ -21,11 +21,13 @@ | 메모리 한도 | 앱마다 상태의 예산이 있다(`--memory`). 목록의 항목, 텍스트, outbox, 들은 번호를 저장 형식의 바이트로 센다(어느 기기에서나 같다). 예산을 넘기며 늘리는 사건은 거절하고(503 `memory`) 줄이는 사건은 받는다. 받는 쪽이 늦으면 outbox가 차서 클라이언트까지 역압이 가고, 가득 찬 받는 쪽은 링크로 알려 보내는 쪽이 다시 보내지 않는다. 답(`--reply`)은 자기 보내기의 자리를 쓴다. 상태 4 MB를 준 노드는 부하 아래 상주 9.6–9.8 MiB에 멈춘다(예산 없이 30초에 45.9 MiB). 오래 붙든 스냅숏은 그때 상태 한 벌만 쥔다(전: 30초에 678 MiB) | [설계 013](docs/design/013-memory-budget.md), [104](docs/research/104-where-memory-goes.md) | | 표면과 메신저 | 사람을 위한 표면이 노드 안에서 돈다(`pure-serve --surface`): 마지막 저장의 스냅숏을 제자리에서 읽고, 친 키와 글자는 HTTP 요청과 같은 줄로 소유자에게 간다. Vega의 디스플레이·픽셀이 그 표면이다. 두 노드의 메신저(Vega `examples/messenger.aup`)는 서로에게 봉인·인증해 보내고, 한 줄이 상대 노드에 보이기까지 RAM 저장소에서 p50 0.79 ms·p99 1.1 ms, SD 카드에서 p50 3.5 ms(꼬리는 SD의 동기화) | [설계 010](docs/design/010-surfaces.md), [089](docs/research/089-messenger.md) | | 표 크기의 상태 | 목록이 영속 B+트리다(변경·키 탐색·저장본 위치 O(log n), 스냅숏 O(1), 1,600만 항목, 런타임 상태 1 GiB). pgbench의 TPC-B 같은 이체(세 표의 행과 이력, 한 트랜잭션)가 10만 계좌에서 RAM 24.5k/s(전: 3만 계좌 3.2k/s), SD 카드 내구 1,339/s(SQLite WAL FULL 84–153/s) | [090](docs/research/090-tables.md) | -| 일반 트랜잭션 | TPC-C의 다섯 트랜잭션을 aup 앱 하나로 쓴다(여러 표 읽기·쓰기, 조각 훑기, 중복 없는 셈, 실패하면 통째 되돌림). 같은 입력에서 SQLite와 아홉 표의 모든 행이 같다. W=1에서 RAM 초당 39,977건(SQLite FULL 9,529, 트랜잭션당 CPU 44–49 µs, HTTP·JSON 포함), SD 카드 내구 4,502건(SQLite FULL 50, NORMAL 372) | [092](docs/research/092-tpcc.md) | +| 일반 트랜잭션 | TPC-C의 다섯 트랜잭션을 aup 앱 하나로 쓴다(여러 표 읽기·쓰기, 조각 훑기, 중복 없는 셈, 실패하면 통째 되돌림). 같은 입력에서 SQLite와 아홉 표의 모든 행이 같다(창고 하나와 넷). RAM 초당 36,567건(W=4 32,765; 조율한 SQLite 10,357, 트랜잭션당 CPU 46–54 µs, HTTP·JSON 포함), SD 카드 내구 4,980건(W=4 4,590). SQLite도 카드에 맞게 조율하고 묶어 커밋하면 739건(W=4 426)이다. 남은 차이는 거래당 쓰는 바이트다(SQLite는 페이지째 써서 8–18배) | [092](docs/research/092-tpcc.md), [106](docs/research/106-tpcc-conditions-first.md) | | 질의 | 질의는 앱의 상태 위에 보기를 더한 모듈이다(`aup query`, `PUT·GET /queries/이름`). 검증한 뒤 스냅숏에서 돌고, 열 안의 fold가 그 행을 읽는다(상관 부질의). 잎이 항목을 필드별로 들고, fold와 필터는 잎 하나씩 돌며(결함이 날 잎만 항목별로), 열 안의 그룹·순위 fold는 목록을 한 번 지나 모든 행에 답한다. 10만 계좌에서 지점별 합계 4.9 ms(SQLite 45, 인덱스를 주면 14.3), 조인 0.48 ms(1.47), 자기 조인 순위 6.8 ms(2,840, 인덱스를 주면 7.6). Pure에는 인덱스 선언이 없다 | [091](docs/research/091-queries.md) | 키로 나눈 소유자와 저장을 넘길 스레드는 하지 않기로 했다. 이 장치는 동기화를 한 줄로 세워, 나누면 쓰기가 23% 줄고 넘겨도 -기기의 일은 줄지 않는다([084](docs/research/084-parallel-syncs.md)). 대신 압축한 파일이 한 주기의 0을 미리 가져 커밋이 새 +기기의 일은 줄지 않는다([084](docs/research/084-parallel-syncs.md)). 다만 동기화가 공짜인 RAM에서 TPC-C는 소유자 하나가 +병목이다(코어의 94%, 터미널을 늘려도 그대로). 그 시간의 3분의 1은 스냅숏이 공유한 노드를 복사하는 데 간다. 덜 복사하는 길과 +키로 나눈 소유자를 다음 설계로 함께 본다([106](docs/research/106-tpcc-conditions-first.md)). 대신 압축한 파일이 한 주기의 0을 미리 가져 커밋이 새 블록을 받지 않는다(저장소 커밋 +21%, 저널 커밋 −59%, [085](docs/research/085-cycle-sized-files.md)). 남은 것: macOS 검증, `bool`·`i64`, 압축을 없애는 제자리 재사용 저장소(085 다음), 응답을 기다리는 출력의 묶음 전달(083), 앱 diff --git a/README.md b/README.md index 2826f3d..0d93d9a 100644 --- a/README.md +++ b/README.md @@ -17,9 +17,11 @@ their own (`aup query`), verified when registered and shown from snapshots. Fold fold in a table's column is answered for every row from one pass over its list, so on pgbench's tables of 100,000 accounts a group-by, a join and a correlated rank run 3–420x faster than on SQLite, and faster than SQLite given a DBA's indexes but for one count, with no index declared. TPC-C's five transactions, written as one aup app, leave -SQLite's state row for row from the same inputs, and run 4x faster than SQLite in RAM (39,977 against 9,529 a -second, HTTP and JSON included) and 90x faster on an SD card (4,502 against 50), both syncing each commit -([092](docs/research/092-tpcc.md)). Measurements against axum and drogon on a Raspberry Pi 5 +SQLite's state row for row from the same inputs, with one warehouse or four, and run 3.2–3.5x faster than a tuned +SQLite in RAM (36,567 against 10,357 a second, HTTP and JSON included) and 4–11x faster on an SD card than SQLite +tuned for the card and committing in groups as Pure does, both answering once the commit is on the device: SQLite +writes whole pages, 8–18x the bytes a transaction ([092](docs/research/092-tpcc.md), +[106](docs/research/106-tpcc-conditions-first.md)). Measurements against axum and drogon on a Raspberry Pi 5 are in [075](docs/research/075-http-host-against-axum.md), [077](docs/research/077-apps-as-http-services.md), [080](docs/research/080-snapshot-reads.md), [081](docs/research/081-tail-records.md), [082](docs/research/082-json-in-place.md), [083](docs/research/083-delivery-over-http.md), diff --git a/docs/research/092-tpcc.md b/docs/research/092-tpcc.md index 247c189..4cac74e 100644 --- a/docs/research/092-tpcc.md +++ b/docs/research/092-tpcc.md @@ -175,6 +175,8 @@ W=1(창고 하나, 초기 행 약 57만), Raspberry Pi 5(4코어), 서버는 코 카드는 상태에 따라 흔들린다. 압축 기록으로 128터미널을 세 번 재니 4,502–6,824건이었다(그 전에는 3,073–5,396건). SQLite FULL은 44–57건이었다. 로그로 옮기기 전(목록을 트리에 두던 때)에는 30초 가운데 16초가 0이었다. 이제는 매초 처리한다. +이 SQLite는 기본 설정으로 트랜잭션마다 커밋했다. SQLite도 카드에 맞게 조율하고 Pure처럼 묶어 커밋하게 한 비교, 그리고 창고 +넷은 [106](106-tpcc-conditions-first.md)에 있다. 차이는 4–11배로 줄고, 남은 것은 거래당 쓰는 바이트다. SQLite의 `synchronous=NORMAL`(WAL 체크포인트 때만 동기화해 전원이 끊기면 최근 커밋을 잃는다)은 초당 36건(1스레드), 372건(4스레드)이다. `OFF`(동기화 없음)는 8,941건이다. Pure는 내구성을 낮추지 않고도 NORMAL의 12배다. -- cgit v1.2.3