tldr;
카우치톡의 저장 방식은 ID로 키가 지정된 jpeg와 wav 리소스만 있으면 됩니다. 흥미로운 점은 순차적 키를 가정하는 애플리케이션 모델로, 프론트엔드에서 쿼리 없이 데이터에 색인을 생성할 수 있다는 점입니다. 마지막 키를 감지하려면 이미지 태그에서 브라우저 이벤트를 관찰하고 404에서 멈추기만 하면 됩니다.
무엇을 말하나요?
푸시 투 토크 메시징이 인기라는 것은 누구나 알고 있으며, HTML5의 오디오/비디오 기능 덕분에 자바스크립트에서 이 기능을 사용할 수 있게 되었습니다. 웹 개발자로서 저는 항상 오늘날 브라우저의 실용성을 한 단계 끌어올리는 데 관심이 많습니다. 아직 카우치토크를 사용해 보지 않으셨다면 지금 바로 사용해 보세요(구글 크롬 필요).
디자인 고려 사항
카우치톡 앱에서 강조하고 싶었던 카우치베이스 서버의 주요 측면은 속도입니다. 푸시 투 토크는 특히 성능에 민감합니다. 지연 시간이 10분의 1초만 늘어나도 앱이 재미있다가도 느려질 수 있습니다. 카우치베이스 서버의 관리형 메모리 아키텍처는 현재 표시되는 성능이 주로 엔드투엔드 인터넷 지연 시간에 의해 제한되며 애플리케이션 서버의 응답 시간은 주로 데이터 크기에 따라 달라집니다. 작은 썸네일은 몇 밀리초 안에 제공되지만, 큰 이미지는 연결 속도에 의해 제한되기 때문에 더 오래 걸릴 수 있습니다.
구현(아키텍처 및 데이터 모델)
애플리케이션 서버는 이미지와 오디오 클립을 읽고 쓰기 위한 HTTP 서버와 클라이언트에 새 메시지 ID를 전달하는 웹 엔드포인트만 있는 매우 단순한 서버입니다.
HTTP 서버 요청은 어떤 방식으로든 node.js 서버 간에 로드 밸런싱할 수 있으므로 애플리케이션의 해당 측면을 확장하려면 Couchbase Server 크기 조정 관행을 따르고 필요한 경우 node.js 서버를 더 추가하면 됩니다.
PubNub은 룸 멤버에게 새로운 변경 사항을 알리는 데 사용됩니다. PubNub 메시지에는 실제 이미지나 오디오 클립이 포함되지 않습니다. 대신 메시지에는 클라이언트가 미디어를 요청하는 데 사용할 수 있는 문서 ID가 전송됩니다.
데이터 모델은 INCR 키 패턴에 의해 구동되므로, 룸의 각 메시지에 대해 클라이언트는 메시지를 저장할 의사를 선언하고 서버는 메시지를 저장할 키를 제공합니다. 키의 형식은 다음과 같습니다. 룸 시퀀스 여기서 시퀀스는 증분하는 정수입니다. 클라이언트는 이미 자신이 어느 방에 있는지 알고 있으므로 현재 시퀀스를 알고 있으면 키를 생성하여 최근 메시지를 다시 채울 수 있습니다.
클라이언트가 다음 메시지 ID를 요청하면 키를 증가시키고 그 결과를 클라이언트로 다시 보냅니다. 증가 연산은 원자적이므로 충돌 없이 키 공간을 구성하는 데 사용할 수 있습니다.
cb(err, ["snap",room,result.value].join('-'))
})
이 키 패턴은 Couchbase Server에서 관련 데이터를 관리할 수 있는 좋은 방법입니다. 또 다른 예로 블로그 게시물의 댓글 수를 알고 있다면 모든 댓글을 로드할 수 있습니다. 또는 CouchTalk의 경우, 클립의 길이와 새 스냅샷을 얼마나 자주 찍는지만 알면 클립에 몇 개의 스냅샷이 포함되어 있는지 추적할 필요가 없습니다.
이미지나 오디오를 서버에 저장할 때 '설정' 대신 '추가' 명령을 사용하여 이미지와 오디오를 변경할 수 없도록 하고, 한 번 설정하면 수정할 수 없도록 합니다.
바이너리 버퍼를 데이터베이스에 직접 저장하고 있다는 점에 유의하세요. 감사합니다 Couchbase!
