ExtendDB: 데이터베이스에서 DynamoDB API 실행
병원 기록 시스템이 건물 내부에 있어야 한다고 가정해 보겠습니다. 환자 데이터는 온프레미스 네트워크를 떠나지 마십시오. 감사자는 모든 종속성을 승인합니다. 개발용 노트북에는 인터넷이 전혀 없습니다. 팀에서 이미 신청서를 작성했습니다. DynamoDB API에 대해 마음에 들었습니다. 한 자릿수 밀리초 키 조회, 깨끗한 항목 모델, 베이비시터로의 스키마 마이그레이션이 없습니다. 하지만 관리형 DynamoDB는 클라우드 서비스 및 "AWS로 데이터 보내기"는 여기서 시작이 아닙니다.
ExtendDB은 바로 그 간격을 위해 만들어졌습니다. 그것은 말한다 DynamoDB 유선 프로토콜은 사용자가 실행하는 데이터베이스에 데이터를 저장합니다.
ExtendDB란 무엇입니까?
ExtendDB는 PostgreSQL과 같이 사용자가 직접 실행하는 데이터베이스 위에 DynamoDB JSON 유선 프로토콜을 구현하는 AWS의 오픈 소스 어댑터(Rust로 작성)입니다. 기존 AWS SDK와 AWS CLI는 변경 없이 계속 작동합니다. 엔드포인트 URL만 이동하므로 관리형 클라우드 서비스에 데이터를 보내지 않고도 DynamoDB API를 얻을 수 있습니다.
ExtendDB는 AWS DynamoDB 엔지니어가 작성한 AWS의 오픈 소스 어댑터입니다. 그리고 announced on the AWS Database Blog — 이는 Rust에서 DynamoDB JSON 유선 프로토콜을 구현합니다. 왜냐하면 그것은 관리형 서비스와 동일한 HTTP API, 기존 AWS SDK 및 AWS CLI 작업은 변경되지 않았습니다. 이동하는 유일한 것은 엔드포인트 URL입니다. 코드 재작성도 없고 새로운 클라이언트 라이브러리도 없습니다.
흥미로운 부분은 해당 API 뒤에 무엇이 있는지입니다. ExtendDB에는 플러그형이 가능합니다. 스토리지 백엔드: PostgreSQL은 참조 구현이고 Cassandra는 또 다른 가능한 백엔드로 언급되었습니다. 새로운 백엔드는 코어를 수정하지 않고 구현하므로 DynamoDB 호환성 계층 스토리지 계층은 독립적으로 진화합니다.
따라서 요청은 다음과 같이 진행됩니다.
지원하는 것과 지원하지 않는 것
getting-started docs 및 공지사항에 따르면, ExtendDB(v0.1)는 대부분의 애플리케이션이 실제로 호출하는 작업을 다룹니다.
- 테이블 — 생성, 삭제, 설명, 나열, 업데이트.
- 항목 — 넣기, 가져오기, 삭제, 업데이트(
SET/REMOVE/ADD/ 포함)DELETE업데이트 작업). - 쿼리 및 스캔 — 주요 조건, , 예측, 페이지 매김 및 보조 인덱스.
- 배치 —
BatchGetItem및BatchWriteItem. - —
TransactGetItems및TransactWriteItems. - , , 가져오기/내보내기 및 태그.
의도적으로 구현하지 않는 것은 DynamoDB 관련 관리 기능 — 특히 전역 테이블 및 지역 간 복제. 이는 관리형 서비스의 속성입니다. API 표면이 아닌 글로벌 인프라이므로 귀하가 직접 호스팅하는 어댑터입니다.
대 DynamoDB 로컬
이미 사용 중일 수도 있습니다.
오프라인 개발용 DynamoDB Local. 그거 싱글이에요
하나의 단위 테스트를 위한 JAR(또는 amazon/dynamodb-local Docker 이미지)
기계. ExtendDB는 단일 프로세스 도구인 로컬보다 더 광범위한 것을 목표로 합니다.
개발, 온프레미스 배포, 엣지 및 에어갭 환경,
DynamoDB API를 원하지만 데이터는 있는 하이브리드/멀티 클라우드 설정
귀하가 제어하는 인프라.
및 관리형 DynamoDB
이는 AWS가 명시적으로 그리는 선이며 중요합니다.
ExtendDB는 DynamoDB가 아닙니다. 대체가 아닌 호환 가능한 구현입니다. 매니지드 서비스의 경우. 성능 특성, 확장 동작 및 작동 속성이 다릅니다.
구체적으로 ExtendDB를 실행할 때:
- 데이터베이스의 가용성과 백업은 귀하가 소유합니다. 관리되는 데이터는 없습니다. 다중 AZ 내구성 또는 특정 시점 복구가 귀하를 대신해 수행됩니다. 그것은 귀하에게 달려 있습니다 그리고 PostgreSQL 작업.
- 엔드포인트에서는 TLS가 필수입니다.
- 자격 증명은 IAM과 유사하지만 AWS IAM과는 별개입니다 — ExtendDB에는 자체 자격 증명이 있습니다 자격 증명 모델; AWS 계정에 대해 인증하지 않습니다.
v0.1이고 라이센스 Apache 2.0입니다. 초기 소프트웨어로 취급: 적합 프로덕션 규모의 관리형 DynamoDB를 위한 드롭인 스왑이 아닌 위의 환경에 적합합니다.
ExtendDB 자체는 RCU나 WCU를 측정하지 않습니다. 용량은 PostgreSQL의 문제입니다. 언제
동일한 API 호출이 온디맨드 방식으로 관리형 DynamoDB에 도달합니다. 1KB
PutItem 청구서 1 WCU 및 4KB GetItem 청구서 0.5 RCU
결국 일관성이 있습니다. 대기 시간에 대한 벤치마크 ExtendDB; 사용하다
pricing calculator 클라우드가 무엇인지 비교하기 위해
청구서는 동일한 액세스 패턴과 같습니다.
설정
ExtendDB는 Linux 및 macOS에서 실행되며 Rust 1.85+ 및 PostgreSQL 14+. 흐름은 두 가지 명령입니다.
extenddb init
extenddb serveinit은 PostgreSQL 데이터베이스에 스키마를 프로비저닝합니다. serve이 시작됩니다
https://127.0.0.1:8000와 같은 엔드포인트에서 수신 대기하는 유선 프로토콜 서버
(TLS가 필요하므로 https).
사용자 정의 엔드포인트와 동일한 방식으로 AWS SDK를 지정합니다. URL만 지정하면 됩니다. 자격 증명이 변경됩니다.
import {DynamoDBClient} from '@aws-sdk/client-dynamodb';
const client = new DynamoDBClient({
endpoint: 'https://127.0.0.1:8000',
region: 'local',
credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});클라이언트 구성 이후의 모든 것 — PutItem, Query, TransactWriteItems —
관리형 DynamoDB에 대해 작성하는 코드와 동일합니다. 단일 테이블
항목 레이아웃은 클라우드에서와 동일하게 작동합니다.
| PK | SK | type | backend | createdAt |
|---|---|---|---|---|
| TENANT#acme | AUDIT#2026-06-24 | event | postgres | 2026-06-24T09:00:00Z |
| TENANT#acme | AUDIT#2026-06-24b | event | postgres | 2026-06-24T09:01:12Z |
| TENANT#beta | AUDIT#2026-06-24 | event | postgres | 2026-06-24T09:02:40Z |
DynoTable에서 해보기
ExtendDB는 DynamoDB 유선 프로토콜을 사용하므로 별도의 연결이 필요하지 않습니다. 이를 위한 관리 도구 — ExtendDB 엔드포인트의 DynoTable를 가리킵니다. 같은 방법으로 연결하면 DynamoDB Local: 오프라인 만들기 (로컬) 프로필(ExtendDB 포트 및 일회용 자격 증명 및 DynoTable 포함) 항목을 찾아보고, 쿼리하고, 편집합니다. 단, 지금은 PostgreSQL의 지원을 받습니다. JAR의 메모리 내 저장소 대신 자체 디스크에 저장됩니다.
이는 유선 프로토콜 호환성의 이점입니다.
SQL Workbench, 시각적 쿼리 빌더 및 항목
ExtendDB에 대한 모든 작업을 변경 없이 편집하면 실제 GUI를 얻을 수 있습니다.
scan 스크립트를 작성하지 않고 자체 호스팅 데이터.
계획해야 할 한 가지 주의 사항: ExtendDB의 엔드포인트는 HTTPS 전용인 반면 DynoTable의 엔드포인트는
오프라인 프로필(대부분의 DynamoDB-Local 설정과 마찬가지로)은 루프백을 대상으로 합니다.
host:port. 클라이언트나 도구에 일반 텍스트 루프백 수신기가 필요한 경우
ExtendDB 앞에서 TLS를 종료하고(또는 로컬 역방향 프록시를 실행하고)
GUI — 어느 쪽이든 연결 프로토콜은 여전히 DynamoDB JSON입니다.
함정
- v0.1을 프로덕션 DynamoDB로 취급하지 마십시오. 확장성, 지연 시간 및 내구성 AWS가 아닌 PostgreSQL입니다. 워크로드에 대한 벤치마크 그것에 의존하십시오.
- 글로벌 테이블/교차 지역 복제가 없습니다. 귀하의 디자인이 다음 사항에 의존하는 경우 다중 지역 활성-활성, ExtendDB는 경로가 아닙니다. 이는 관리형 서비스입니다. 특징.
- 기본 데이터베이스를 직접 백업하세요. 관리형 PITR이 없습니다. 에
삭제된 PostgreSQL 볼륨이 사라졌습니다.
pg_dump/ WAL 아카이빙 연결 다른 PostgreSQL. - 자격 증명은 AWS IAM이 아닌 ExtendDB 자체입니다. IAM 정책을 기대하지 마세요. 액세스를 관리하는 역할 또는 조건 키 — 해당 인증 모델은 그렇지 않습니다. 이월하다.
다음 단계
- 먼저 액세스 패턴을 모델링하세요. 동일합니다. single-table design 규율은 다음과 같은 경우에 적용됩니다. 백엔드는 DynamoDB 또는 PostgreSQL-via-ExtendDB입니다.
- 읽기 및 쓰기를 빌드하고 검사합니다. DynamoDB Expression Builder, 그런 다음 변환 일반 JSON과 와이어 형식 사이의 고정 장치 DynamoDB-JSON converter.
- 라이브 ExtendDB 인스턴스를 살펴볼 준비가 되면 연결하세요. DynoTable 다른 테이블처럼 찾아보세요.