Hacker News 의견

• 블로그 작성자가 이 글을 쓰면서 매우 즐거웠음을 언급함. 수천 줄의 자바스크립트를 사용하여 인터랙티브한 비주얼을 만들었음
• SQLite+NVMe를 오랫동안 지지해왔음을 밝힘. 이는 새로운 패턴으로, 수평 확장 없이도 문제를 해결할 수 있는 가능성을 제공함
  • 성능 문제에서는 지연 시간이 가장 중요함
  • 특히 순차적으로 처리해야 하는 경우에 더욱 중요함
  • NVMe에서 SQLite를 실행하면 다른 제공자가 제공할 수 없는 지연 시간 이점을 얻을 수 있음
  • 대부분의 실제 사용 사례에서 메모리 실행이 NVMe 지속성보다 큰 이점을 제공하지 않음
• 제품 홍보라는 것을 잊을 정도로 정보가 풍부했음을 칭찬함. 훌륭한 비주얼과 상호작용성을 언급함
• 디스크 IO 애니메이션을 보면서 Melvin Kaye를 떠올림
  • Mel은 시간 지연 루프를 작성하지 않았음
  • Flexowriter가 출력 문자 사이에 지연이 필요할 때도 마찬가지였음
  • 드럼에 명령어를 배치하여 필요할 때마다 읽기 헤드 바로 뒤에 위치하도록 했음
  • 드럼은 다음 명령어를 찾기 위해 완전한 회전을 수행해야 했음
• 블로그가 좋음을 언급함. 일반적으로 클라우드 스토리지가 "비정상적으로 느림"을 지적함
  • 최근 S3/오브젝트 스토리지에 증분 인덱스를 저장하는 지원을 추가했음을 언급함
  • NVMe를 더 오래 사용한 이유는 이전 기사에서 언급한 성능상의 이점 때문임
  • 더 나은 제공으로 이 분야를 혁신할 누군가가 있으면 좋겠다고 밝힘
• 분산 스토리지에 대해 이 기사에서 충분히 다루지 않은 점을 지적함
  • 일부 시스템은 기본적으로 복제를 지원하지 않음
  • Cassandra 클러스터와 MySQL은 마스터 슬레이브 복제를 할 수 있지만, 많은 시스템은 그렇지 않음
  • 클라우드에서 NVMe 스토리지를 사용할 때 유지보수 간격과 클라우드에서 시작된 드레인을 존중해야 함
  • 스토리지를 컴퓨팅과 분리하면 클라우드 운영자가 필요에 따라 컴퓨팅을 이동할 수 있음
  • 데이터가 컴퓨팅과 독립적이므로 클라우드 운영자가 데이터 시스템과 드레인을 관리할 수 있음
• Metal이 매우 멋져 보임. 이전 직장에서 GCP의 인스턴스 로컬 SSD를 사용하려 했을 때 심각한 신뢰성 문제가 있었음을 언급함
  • 장치의 블록이 데이터를 잃는 문제가 있었음
  • 이 상황이 개선되었는지 궁금해함
  • 사용 중인 머신 타입을 묻고 있음
  • 해결책으로 Discord의 네트워크 디스크를 사용하는 방법을 언급함
• PlanetScale Metal이 매우 견고해 보임. 릴리스에서 지연 시간이 크게 감소하는 것을 보는 것이 항상 흥미로움
• 매우 훌륭한 기사임. 랜덤 쓰기의 시각화가 매우 잘 되어 있음
  • 클라우드에서 네트워크 연결 스토리지의 또 다른 문제는 IOPS 제한임
  • AWS와 Google Cloud를 포함한 많은 클라우드 제공자가 이 모델을 사용하며, 전송할 수 있는 IO 작업의 양을 제한함
  • 스토리지가 컴퓨팅 인스턴스에 직접 연결되어 있으면 IO 작업에 인위적인 제한이 없음
  • 하드웨어가 허용하는 한 빠르게 읽고 쓸 수 있음
  • "IOPS" 제한이 특정 네트워크 트래픽에 대한 제한인지 궁금해함
  • EBS 볼륨 네트워크 트래픽을 의미하는지 묻고 있음
  • 비용 절감이 가능한지, AWS의 이상한 차익 거래 때문인지, 아니면 EBS 네트워킹을 덜 함으로써 효율성을 얻는 것인지 궁금해함
  • 스토리지와 컴퓨팅을 같은 머신에 두는 것이 지연 시간 측면에서 이점이 있음을 명확히 봄
  • 비용 대비 처리량 측면에서도 이점이 있는지 궁금해함
• "서버리스" 데이터베이스 제공자가 어떻게 "저지연" 액세스를 광고하는지 궁금해함
  • S3와 같은 오브젝트 스토리지를 사용하며, 이는 네트워크 스토리지보다 지연 시간이 훨씬 나쁠 것으로 예상됨
  • 캐싱 레이어를 구축했음을 언급하며, 로컬에 연결된 NVMe에 데이터를 유지하겠다고 밝힘