SpacetimeDB, 정말 확장되나요? — 수평 확장의 숨겨진 대가
Ok, but Does It Scale?
SpacetimeDB는 확장성에 대한 질문을 가장 많이 받습니다. 확장에는 컴퓨팅, 스토리지, 네트워킹이라는 세 가지 차원이 있으며, 각각 독립적으로 확장될 수 있습니다. 스토리지의 수평 확장은 비교적 간단하지만, 모든 컴퓨팅과 네트워킹이 수평 확장 가능한 것은 아닙니다. 일반적인 수평 확장 OLTP 데이터베이스(CockroachDB, Spanner 등)는 트랜잭션당 막대한 오버헤드를 지불하며, 충돌하는 트랜잭션에서 매우 낮은 성능을 보입니다. SpacetimeDB는 높은 동시성 성능을 제공하며, 병렬화 가능한 OLTP 워크로드를 확장하기 위한 도구를 제공합니다.
수평 확장이 더 많은 컴퓨터로 더 많은 일을 하는 것처럼 보이지만, 실제로는 더 많은 컴퓨터로 더 적은 일을 하는 경우가 많습니다. 개념적으로 한 대의 컴퓨터가 1밀리초에 할 수 있는 일을 10대의 컴퓨터가 100밀리초에 할 수도 있습니다.
HN 토론
63- timssopomo
Spacetime은 정말 흥미로운 기술처럼 들리지만, CRDB와의 비교가 적절한지 잘 모르겠습니다.
저는 Cockroach Labs에서 일한 적이 있습니다. CRDB가 해결하는 문제는 근본적으로 다릅니다. CRDB는 트랜잭션이 직렬화 가능하고 내구성이 있음을 보장해야 하고, 애플리케이션이 노드 또는 리전 장애에서도 일관성을 유지하면서 생존할 수 있어야 할 때 솔루션으로 적합합니다. 단순한 배포에서는 단일 코어에서 작업하는 것보다 훨씬 느리지만, 그것은 데이터 손실 없이 노드 손실을 견딜 수 있는 능력에 대해 지불하는 대가입니다.
Spacetime이 CRDB가 해결하는 핵심 문제, 즉 단일 노드 장애를 데이터 손실이나 가용성 손실 없이 허용할 수 있다는 것을 어떻게 해결하는지 보여주는 내용은 보이지 않습니다. 기본적으로 트랜잭션이 완료되기 전에 디스크에 기록되어야 한다고 들리는데, 이는 단일 노드에서는 내구성을 보장하지만, 네트워크 오버헤드를 감수하고 트랜잭션 처리량(특히 쓰기)을 희생하지 않고서는 노드 간 일관성을 보장할 수 없습니다.
또한, 제가 거의 모든 인시던트를 처리하면서 몇 년 동안 일했을 때 네트워크에 묶인 클러스터를 본 기억이 없습니다. 다른 모든 것과 마찬가지로 트레이드오프가 있습니다. 처리량을 포기하고 일관성과 가용성을 얻는 대신, 노드 장애로 인한 데이터 손실이나 가용성 문제를 피하기 위해 엔지니어링할 필요가 없습니다. 제가 잘못 이해한 것이 아니라면, Spacetime은 완전히 다른 문제를 해결하고 있습니다.
- chermi
주제에서 벗어나지만... 제 친구가 하버드 미니 MBA에서 (농담 삼아) 얻은 주요 교훈은 SEAS 프로그램에 있는 동안 VC/기술 관련 사업가들 앞에서 똑똑해 보이려면 이 질문을 하면 된다는 것이었습니다.
그런 다음 우리는 실제로 스타트업을 설립했고 이것이 어리석은 질문이 아니라는 것을 깨달았습니다. 하지만 기본 경로가 VC 자금 조달일 때 그것은 순환적인 것일 수도 있습니다. 음.
- philippta
저는 얼마 전에 Postgres를 단일 노드 및 다중 노드 구성에서 CockroachDB와 벤치마킹했는데, 제가 발견한 결과는 이 게시물에서 말하는 내용과 일치합니다.
https://github.com/philippta/postgresql-cockroachdb-benchmar...
- echohack5
사이드 프로젝트(예: https://heat.echohack.app)에 Spacetime을 많이 사용해 온 사람으로서, 저는 그것이 작동하는 속도에 계속해서 감명을 받고 있습니다.
데이터베이스 공간에서 흥미로운 일이 많이 일어나고 있다고 생각합니다. Vitess/Neki, 벡터 스토어, Spacetime은 모두 정말 좋은 일입니다. 데이터베이스 개발자들이 드라마로 가득한 타임라인을 가지고 있는 것처럼 보이는 것은 유감입니다. 모든 것이... 함께 매우 흥미진진합니다.
어쨌든, 개선이 필요한 몇 가지 사항(이 중 일부는 이 블로그 게시물에서 다루어집니다):
1. 백업(빠른 복구) 및 재해 복구(느리고 내구성 있는 복구)
이것은 중요한 것이지만, 때로는 속도만이 충족해야 할 유일한 목표는 아닙니다. 모든 것이 다운되더라도 (결국) 시스템을 다시 온라인으로 되돌릴 수 있다는 확신이 필요합니다. 오늘날 저는 그렇게 할 방법이 없습니다.
2. 읽기 복제본은 분석 워크로드에 확실히 유용할 것입니다.
3. S3에 대한 내구성 있는 쓰기는 간헐적인 버스트 워크로드(예: CI 시스템)에 유용할 것입니다.
Spacetime 팀이 할 일이 많다고 생각합니다. 기술 때문만이 아니라(그것도 어렵지만) AI 모델들이 Neon과 Postgres만 존재하는 것처럼 결정했기 때문입니다.
Spacetime에 밝은 미래가 있다고 생각하며, 팀이 우주에 새로운 것을 새기기 위해 열심히 일하는 동안 모든 것이 잘 되기를 바랍니다.
- themgt
> 데이터베이스에 서버 로직을 직접 배포할 수 있습니다.
> 귀하의 애플리케이션 또는 서비스가 프로덕션 환경에서 SpacetimeDB 인스턴스를 하나만 사용하는 경우에만 라이선스 작업을 사용할 수 있으며, 데이터베이스 서비스에 라이선스 작업을 사용할 수 없습니다.
따라서 OSS 제품으로서 SpacetimeDB는 확장되지 않습니다.