이제 그 컴퓨터 모바일 기술악천후 속에서 개발된, 첫 번째 중요한 문제는 서로 의사 소통을 유지하는 능력에 초점을 맞추고 있습니다.

메신저를 사용하면 개인 회의에서 비즈니스 회의에 이르기까지 모든 문제를 실시간으로 논의할 수 있습니다. 따라서 그들의 인기는 멀티플레이어 게임에 못지 않습니다.

모든 인스턴트 메신저에는 오래된 메시지가 빠르게 축적되는 한 가지 문제가 있습니다. 그들은 장치에서 추가 메모리를 차지합니다.

Discord에서 채팅 지우기(지침)

메신저에서 정기적으로 통신하면 장치의 메모리가 막히는 경향이 있습니다. 메시지가 누적되고 많은 메시지가 의미적 로드를 전달하지 않습니다. 따라서 제거가 필요합니다.

또한 모든 서신을 저장하는 것은 매우 위험합니다. 데이터 유출 가능성이 높기 때문에 자신에 대한 훼손 증거로 사용될 수 있습니다. 이러한 사건의 결과를 막기 위해서는 적시에 역사를 정리해야 합니다. Discord에서는 세 가지 방법으로 이 작업을 수행할 수 있습니다.

• 채널을 삭제합니다.
• 각 메시지의 개별 삭제.
• 지난 주의 모든 메시지를 삭제합니다.

보낸 후 모든 채널 구성원이 메시지를 보기 전에 메시지를 삭제할 수 있는 시간은 몇 초뿐입니다. 청소 방법의 선택은 상황에 따라 매우 다르며 서버 작성자의 개인적인 필요에 따라 선택됩니다. 사용 지침과 함께 각 방법에 대해 자세히 알아보십시오.

방법 1, 전체 채널을 삭제하고 새로운 P2를 생성>

더 쉬운 옵션은 생각할 수 없습니다. 주제가 소진되거나 토론에 타협적인 정보가 많이 축적되면 채널을 완전히 삭제하고 새 채널을 만드십시오. 삭제는 몇 초 안에 발생하며 복원할 수 없습니다.

주목! 있다면 중요한 정보, 별도의 문서에 다시 작성하거나 스크린샷으로 저장합니다.

몇 가지 간단한 단계를 따라야 합니다.

그런 다음 새 이름을 만들면 같은 이름으로도 만들 수 있습니다.

방법 2: 각 메시지를 개별적으로 삭제

가장 긴 청소 시간. 시간 소모가 많기 때문에 소량의 제거에만 적합합니다. 사용 지침:

채널의 모든 사용자에 대해 삭제된 메시지가 손실됩니다. 북마크한 경우 사라집니다.

방법 3: 지난 7일 청소

이 방법은 차단하려는 사용자의 게시물에만 적용됩니다. 블랙리스트에 보내기 전에 사용자의 편지 기록을 삭제할 기간을 선택할 수 있습니다.

• 24시간 동안.
• 또는 지난 7일(그리고 밤).

사람을 블랙리스트에 올리는 방법:

• 사용자 이름을 클릭 마우스 오른쪽 버튼으로 클릭마우스를 누르고 - 금지(사용자의 닉네임이 다음에 표시됨)를 선택합니다.

원하는 경우 이유를 지정하고 필드를 비워 둘 수 있습니다.

얼마나 자주 채팅을 지워야 합니까?

채팅 정리는 전적으로 커뮤니티 테마에 따라 다릅니다. 유머를 주고받으면 삭제해도 소용이 없고, 원하는 항목으로 돌아갈 수 있도록 모든 것을 그대로 두는 것이 좋습니다.

조건부로 다양한 주제에 대한 완전한 토론의 자유가있는 집단 잡동사니가 있다면 적어도 며칠에 한 번 정리하는 것이 좋습니다. 물론 이상적으로는 하루에 한 번입니다. 이 문제에는 특별한 요구 사항이 없으므로 각 관리자는 이 문제에 대한 기준을 스스로 설정합니다.

세상에 현대 기술인터넷을 통한 통신은 거의 처음입니다. 이것은 매우 편리하므로 사람들은 점점 더 다양한 인스턴트 메신저(같은 또는 텔레그램)를 가제트에 설치하고 개인 및 비즈니스 서신. 이러한 경우 불일치가 요구됩니다. 그러나 시간이 지남에 따라 불필요한 문자가 많이 쌓여 장치가 막히고 제 3자를위한 것이 아닌 개인 메시지가 여전히 누군가에 의해 읽힐 위험이 있으며 "채팅을 지우는 방법 디스코드에서?”

Discord에서 채팅 메시지를 삭제하는 방법

방법 1. 하나의 메시지로 통신 삭제

이 옵션은 채팅을 완전히 정리하는 데 많은 시간이 걸리므로 자신 또는 다른 사용자의 일부 문자만 삭제해야 하는 경우에 적합합니다. 프로세스 자체는 다음과 같습니다.

• 프로그램을 엽니다.
• 당신이 일할 대화를 입력하십시오;
• 제거하려는 메시지 위로 마우스 커서를 이동하고 클릭합니다(선택한 메시지의 오른쪽에 있는 세로 세 개의 점을 클릭할 수도 있음).
• 팝업 창에서 "메시지 삭제"를 선택하십시오.
• 작업을 확인합니다.

방법 2. 전체 채팅 삭제

귀중한 정보가 포함되어 있지 않은 경우 Discord의 모든 메시지를 삭제하는 방법은 무엇입니까? 이 작업을 수행하려면 다음과 같은 여러 작업을 수행해야 합니다.

• 응용 프로그램을 다운로드하십시오.
• 파괴할 채널을 선택하십시오.
• 그 위로 마우스 포인터를 이동하고 오른쪽에 나타나는 톱니바퀴 아이콘을 클릭하십시오.
• 열리는 메뉴에서 빨간색 항목 "채널 삭제"를 선택하십시오.
• 나타나는 질문에 "예"라고 대답하십시오.

방법 3: 스크립트 실행

이 방법은 대본에 정통하지 않은 사람들에게는 위험할 수 있습니다. 시작하기 전에 개인 데이터에 액세스할 수 있는 정보가 포함되어 있지 않은지 확인해야 합니다. 스크립트가 정직한 발신자로부터 전송되었다고 확신하는 경우 다음을 수행하십시오.

• 그것을 복사하십시오;
• SMS 텍스트 입력 필드에 붙여넣기
• 운영.

이렇게 하면 많은 수의 메시지를 제거할 수 있습니다. 그러나 반복할 가치가 있으며 숙련된 사용자에게만 적합합니다.

방법 4: 지난 7일 동안의 대화 삭제

이러한 시스템은 특정 사람의 메시지를 삭제하는 경우에 적합합니다. 단계별 지침다음과 같이 보입니다.

• 편지를 삭제할 사용자를 마우스 오른쪽 버튼으로 클릭하십시오.
• 나타나는 메뉴에서 "금지"를 선택하십시오.
• 청소를 수행할 원하는 시간 간격(24시간 또는 7일)을 표시하고 "금지"를 클릭합니다.

이 참가자는 관리자나 채팅 작성자가 차단을 해제할 때까지 더 이상 대화에 참여할 수 없습니다.

Discord 채팅 명령이란 무엇입니까?

Discord의 모든 메시지를 한 번에 삭제할 수 있는 방법은 없지만 한 번에 최대 100개의 메시지를 삭제할 수 있는 방법은 있습니다. 이를 위해 Discord에서 채팅 명령이 있는 Mee6 봇이 설치되어 통신이 지워집니다. 절차는 다음과 같습니다.

• 사용 가능한 사이트로 이동하십시오.
• "Discord에 추가" 버튼을 클릭하여
• 관리자인 경우 "Authorize" 항목을 선택하여 서버에 연결합니다.

• Mee6과의 공개 서신;
• 대시보드에 액세스하기 위해 클릭해야 하는 링크가 환영 메시지에 나타납니다.
• "The Moderator Plugin"을 연결하면 "!clear"를 지우는 명령이 있습니다(이는 열리는 창에서 노란색으로 "Disabled" 항목을 클릭하면 수행되며, 그 후에는 "Enabled"로 변경되고 파란색, 성공적인 연결을 나타냄).

명령 사용 규칙을 주의 깊게 읽으십시오. 그런 다음 텍스트 채널이나 개인 서신으로 이동하여 "명령을 선택하여 청소를 수행할 수 있습니다. [이메일 보호됨]사용자 이름". 결과적으로 100 최근 게시물제거됩니다.

몇 개의 메시지만 지우려면 "!clear xx" 명령을 사용하십시오. 여기서 xx 대신 1에서 99 사이의 메시지 수를 지정합니다.

대화 상대가 삭제된 메시지를 보나요?

가끔 쓸데없는 글이나 주제를 벗어난 글을 쓰다가 실수를 눈치채면 바로 편지를 지우고 대화 상대가 디스코드에서 삭제된 메시지를 보았는지 생각하는 경우가 있습니다. 다른 참가자가 편지를 읽기 전에 이 작업이 완료되면 삭제된 메시지는 비밀로 유지됩니다.

위 자료를 바탕으로 Discord에서 채팅을 지우는 몇 가지 옵션이 있음을 알 수 있습니다. 선택하는 방법은 삭제할 메시지 수에 따라 다릅니다.

자신만의 Discord 서버를 만든 후 많은 초보자들이 서버 관리에 대해 다양한 질문을 할 수 있습니다. 이러한 질문 중 하나는 "Discord에서 모든 메시지를 삭제하는 방법"일 수 있습니다. 이 질문은 불필요한 메시지 하나를 삭제하는 것부터 전체 데이터베이스를 엿보는 것에서 지우는 것에 이르기까지 여러 가지 이유가 있습니다.

Discord에서 대화 삭제

불행히도 개발자는 Discord의 모든 메시지를 한 번에 삭제하는 방법을 제공하지 않았습니다. 그러나 화내지 마십시오! 이 금지를 부분적으로 우회하는 많은 방법이 있습니다.

방법 1: 하나의 메시지로 대화 삭제

이 방법은 서신을 부분적으로만 삭제해야 하는 경우에만 적합합니다. 이 방법은 대규모 청소 옵션으로 작업을 여러 번 반복해야 하는 비용이 필요하므로 최악의 방법입니다.

방법 2: 채팅을 삭제하여 Discord의 모든 메시지 삭제

다음과의 통신 삭제 이 방법상당히 빨리 할 수 ​​있습니다. 유일한 단점은 채널을 다시 만들고 설정을 지정해야 한다는 것입니다. 주요 장점 - 선택한 채널에 저장된 Discord의 모든 메시지를 삭제할 수 있습니다.

공식적으로 Discord는 그룹이나 채팅과 같은 개념을 인식하지 않는다는 것을 기억하십시오. 그룹 커뮤니케이션을 수행할 수 있는 장소로 가장 흔히 이해됩니다. Discord에서만 그러한 장소를 채널이라고 조금 다르게 부릅니다. 이 경우 채널은 텍스트와 음성의 두 가지 유형이 될 수 있습니다. 많은 사람들이 Discord를 선호하는 이유는 참가자가 음성 채널을 떠나지 않고 여러 텍스트 채널에서 동시에 통신할 수 있기 때문입니다.

방법 3: 반응을 사용하여 불일치 대화 삭제

반응을 사용하여 Discord의 모든 메시지를 삭제하는 것은 불가능하며 단독으로 일부 프로세스를 관리하는 데 도움이 됩니다.

예를 들어 최대 9개의 답변으로 구성된 설문조사를 Discord 서버에 추가할 수 있는 유용한 봇이 있습니다. 반응의 도움으로 어떤 답변 옵션이 선택되었는지 확인할 수 있습니다. 사용자 정의또한 제거하십시오. 처음에 반응은 이모티콘 이모티콘에 대한 것이었습니다.

방법 4: 지난 주의 메시지 삭제

조금 쉴 곳도 있고 급진적 인 방법메시지를 지우기 위해. 그러나 지난 7일 동안 Discord의 모든 메시지를 삭제할 수 있습니다.

이 방법은 전체 채팅이 아닌 개별 사용자의 메시지를 지워야 하는 경우에만 적합합니다.

마지막으로 차단된 사용자는 서버에서 차단됩니다. 즉, 작성자 또는 관리자 권한이 있는 구성원이 차단을 해제할 때까지 리소스에 대한 초대 링크를 사용할 수 없습니다. 사람을 차단 해제하는 방법은 다음과 같습니다.

방법 5: Mee6 봇

Discord에서 모든 메시지를 삭제할 수는 없지만 한 번에 최대 100개의 메시지를 삭제할 수 있는 방법이 있습니다. 이렇게 하려면 추가 Mee6 봇을 설치하기만 하면 됩니다. 이것이 가장 간단하고 쉽다는 것을 인정해야 합니다. 빠른 방법, 대화를 삭제할 수 있습니다.

본질적으로 Mee6은 음악 봇이지만 몇 가지 유용한 기능이 있습니다.

1. 첫 번째 단계는 봇을 서버에 추가하는 것입니다. 이 링크를 따르십시오.
2. 실행 명령 " 디스코드에 추가».
3. Mee6 봇을 승인합니다.
4. 다음으로 Mee6이 지배할 서버를 선택해야 합니다.
   
5. 다음 창에서는 추가된 봇이 사용할 수 있는 권한을 설정할 수 있습니다.
6. "승인"을 클릭한 후 로봇이 아닌지 확인하십시오.
   
7. 봇을 서버에 추가하면 봇의 구성 및 매개변수를 설정해야 하는 창이 열립니다. 예를 들어, 여러 플러그인이 포함되었습니다. 그 중 하나가 도움입니다.
   
8. 변경 사항을 적용하려면 확인란을 선택하고 " 업데이트", 즉. 업데이트.
   
9. 명령의 작동을 확인하려면 채팅에서 서버에 메시지!도움말을 보내십시오.
   
10. 그런 다음 플러그인의 다양한 지점에 대한 설명이 봇의 개인 메시지로 나와야 합니다.
11. Mee6의 지원 게시물에서 게시물 삭제 명령 세트에 "Moderator" 플러그인이 포함될 수 있음이 분명합니다. 봇 구성 편집 창에서 "조정자" 섹션 옆에 "비활성화됨"이라는 캡션이 있는 주황색 타원을 클릭합니다.
    
12. 플러그인 추가를 확인합니다.
    
13. !Clear 명령의 포함에 유의하고 "업데이트" 작업으로 변경 사항을 저장하십시오. !clear xx 명령을 사용하면 한 번에 최대 100개의 메시지를 삭제할 수 있습니다. 여기서 xx 대신 삭제할 메시지 수를 추가해야 합니다.
    
14. !clear 50 명령으로 메시지를 보냅니다.
    
15. 즉, 최근 50개의 메시지가 채팅에서 삭제됩니다. 삭제된 메시지의 카운트다운은 서신이 종료된 시점부터입니다. 즉, 먼저 새 메시지가 삭제된 다음 이전 메시지만 삭제됩니다.
    

인터페이스를 통해 통신을 삭제할 수 있는 작업 알고리즘 휴대전화, 수행된 작업과 완전히 유사합니다. 그래서 우리는 그것들을 설명하지 않을 것입니다.

• 번역

Discord는 사용자 제작 콘텐츠와 마찬가지로 예상보다 빠르게 성장하고 있습니다. 사용자가 많을수록 채팅에 더 많은 메시지가 표시됩니다. 7월에는 매일 4천만 개의 메시지, 12월에는 1억 개의 메시지, 1월 중순에는 1억 2천만 개의 메시지를 발표했습니다. 우리는 즉시 채팅 기록을 영구적으로 저장하기로 결정했습니다. 그러면 사용자가 언제든지 돌아와서 언제 어디서나 데이터에 액세스할 수 있습니다. 장치. 이것은 많은 양의 데이터이며 그 흐름과 양이 증가하고 있으며 모든 데이터를 사용할 수 있어야 합니다. 어떻게 합니까? 카산드라!

우리는 무엇을 했습니까?

Discord의 원래 버전은 2015년 초에 두 달도 채 안 되어 작성되었습니다. 아마도 하나 최고의 DBMS빠른 반복을 위한 것은 MongoDB입니다. Discord의 모든 것은 특별히 단일 MongoDB 복제본 세트에 저장되었지만 새로운 DBMS로의 간단한 마이그레이션을 위해 모든 것을 준비하고 있었습니다(복잡성과 알려지지 않은 안정성으로 인해 MongoDB 샤딩을 사용하지 않을 것임을 알고 있었습니다). 사실 그것은 우리의 일부입니다 기업 문화: 빠르게 경험할 수 있는 디자인 새로운 기능제품이지만 항상 보다 안정적인 솔루션을 지향합니다.

메시지는 channel_id 및 created_at 에 단일 복합 인덱스가 있는 MongoDB 컬렉션에 저장되었습니다. 2015년 11월경, 우리는 데이터베이스의 메시지 1억 개라는 이정표에 도달했고, 우리를 기다리고 있는 문제를 이해하기 시작했습니다. 데이터와 인덱스가 더 이상 RAM에 맞지 않고 지연이 예측할 수 없게 됩니다. 더 적합한 DBMS로 마이그레이션할 때입니다.

올바른 DBMS 선택

새로운 DBMS를 선택하기 전에 사용 가능한 읽기/쓰기 패턴과 현재 솔루션에 문제가 있는 이유를 이해해야 했습니다.

• 읽기가 극히 무작위적이며 읽기/쓰기 비율이 약 50/50이라는 것이 금세 분명해졌습니다.
• 무거운 음성 채팅 서버 Discord는 거의 메시지를 보내지 않았습니다. 즉, 그들은 며칠에 하나 또는 두 개의 메시지를 보냈습니다. 1년에 이러한 유형의 서버는 1000개 메시지의 이정표에 도달하지 못할 것입니다. 문제는 이렇게 적은 수의 메시지라도 이 데이터를 사용자에게 전달하기가 더 어렵다는 것입니다. 단순히 사용자에게 50개의 메시지를 반환하면 많은 임의의 디스크 조회가 발생하여 디스크 캐시 플러시가 발생할 수 있습니다.
• 헤비급 Discord 개인 텍스트 채팅 서버는 상당한 양의 메시지를 보내며 연간 100K에서 1M 메시지 범위에 쉽게 속합니다. 일반적으로 최신 데이터만 요청합니다. 문제는 이러한 서버의 구성원이 일반적으로 100명 미만이므로 데이터 요청 속도가 느리고 디스크 캐시에 있을 가능성이 낮다는 것입니다.
• 대규모 공개 Discord 서버는 많은 메시지를 보냅니다. 하루에 수천 개의 메시지를 보내는 수천 명의 회원이 있습니다. 연간 수백만 개의 메시지를 쉽게 입력할 수 있습니다. 그들은 거의 항상 지난 1시간 동안 보낸 메시지를 요청하며 이런 일이 자주 발생합니다. 따라서 데이터는 일반적으로 디스크 캐시에 있습니다.
• 우리는 내년에 사용자가 무작위 읽기를 생성하는 훨씬 더 많은 방법을 갖게 될 것이라는 점을 알고 있었습니다. 즉, 지난 30일 동안의 멘션을 보고 기록에서 그 순간으로 이동하고, 고정 게시물을 보고 이동하고, 전체 텍스트 검색을 수행하는 기능입니다. . 이 모든 것은 더 많은 무작위 읽기를 의미합니다!

그런 다음 요구 사항을 정의했습니다.

• 선형 확장성- 나중에 결정을 수정하거나 데이터를 수동으로 다른 샤드로 이동하고 싶지 않습니다.
• 자동 장애 조치- 우리는 밤에 잠을 자는 것을 좋아하고 가능한 한 Discord를 자가 치유로 만듭니다.
• 작은 지원- 설치하자마자 작동해야 합니다. 데이터가 증가함에 따라 노드를 더 추가하기만 하면 됩니다.
• 직장에서 입증우리는 새로운 기술을 시도하는 것을 좋아하지만 너무 새롭지는 않습니다.
• 예측 가능한 성능- 95%의 경우에서 API 응답 시간이 80ms를 초과하면 메시지가 전송됩니다. 또한 Redis 또는 Memcached에서 메시지를 캐시해야 하는 필요성에 직면하고 싶지 않습니다.
• Blob 스토리지 아님- Blob을 지속적으로 역직렬화하고 데이터를 첨부해야 하는 경우 초당 수천 개의 메시지를 작성하는 것이 효과적이지 않습니다.
• 오픈 소스- 우리는 우리가 우리 자신의 운명을 통제한다고 믿으며, 제3자 회사에 의존하고 싶지 않습니다.

Cassandra는 우리의 모든 요구 사항을 충족하는 유일한 DBMS로 판명되었습니다. 확장하는 동안 노드를 추가하기만 하면 애플리케이션에 영향을 주지 않고 노드 손실을 처리할 수 있습니다. Netflix 및 Apple과 같은 대기업에는 수천 개의 Cassandra 노드가 있습니다. 관련 데이터는 디스크에 나란히 저장되어 최소한의 조회와 클러스터 전체의 쉬운 배포를 보장합니다. DataStax에서 유지 관리하지만 공개적으로 배포됩니다. 소스 코드그리고 커뮤니티 세력.

선택을 한 후에는 그가 정말로 정당하다는 것을 증명할 필요가있었습니다.

데이터 모델링

초보자에게 Cassandra를 설명하는 가장 좋은 방법은 KKV라는 약어입니다. 두 글자 "K"는 기본 키를 포함합니다. 첫 번째 "K"는 파티션 키입니다. 데이터가 있는 노드와 디스크에서 데이터를 찾을 위치를 결정하는 데 도움이 됩니다. 섹션 내부에는 많은 행이 있으며 섹션 내부의 특정 행은 두 번째 "K"인 클러스터링 키에 의해 결정됩니다. 파티션 내에서 기본 키로 작동하고 행이 정렬되는 방식을 정의합니다. 섹션을 정렬된 사전으로 생각할 수 있습니다. 이러한 모든 특성이 결합되어 매우 강력한 데이터 모델링이 가능합니다.

MongoDB의 메시지는 channel_id 및 created_at를 사용하여 인덱싱되었음을 기억하십니까? channel_id는 모든 메시지가 채널에서 작동하기 때문에 파티션 키가 되었지만, created_at은 두 개의 메시지가 동시에 생성될 수 있기 때문에 좋은 클러스터링 키를 제공하지 않습니다. 운 좋게도 Discord의 모든 ID는 실제로 Snowflake에서 생성되므로 시간순으로 정렬됩니다. 그래서 그들은 사용될 수 있었습니다. 기본 키는 (channel_id, message_id)가 되었습니다. 여기서 message_id는 Snowflake입니다. 이는 채널이 로드될 때 메시지를 찾을 정확한 범위를 Cassandra에 알릴 수 있음을 의미합니다.

다음은 메시지 테이블에 대한 단순화된 스키마입니다(약 10개의 열을 건너뜁니다).

CREATE TABLE 메시지(channel_id bigint, message_id bigint, author_id bigint, 콘텐츠 텍스트, PRIMARY KEY(channel_id, message_id)) WITH CLUSTERING ORDER BY(message_id DESC);
Cassandra의 스키마는 관계형 데이터베이스 스키마와 유사하지만 일시적인 성능 영향 없이 쉽게 변경할 수 있습니다. 우리는 Blob 스토리지와 관계형 스토리지를 최대한 활용했습니다.

기존 메시지를 Cassandra로 가져오기 시작하자마자 100MB보다 큰 파티션이 발견되었다는 경고가 로그에서 즉시 나타났습니다. 야아?! 결국 Cassandra는 2GB 파티션을 지원한다고 주장합니다!분명히 가능성 자체가 이것이 수행되어야 함을 의미하지는 않습니다. 큰 파티션은 클러스터를 압축하거나 확장하는 등의 작업을 수행할 때 Cassandra의 가비지 수집기에 많은 부하를 줍니다. 파티션이 크다는 것은 그 안의 데이터를 클러스터 전체에 분산할 수 없다는 의미이기도 합니다. 일부 Discord 채널이 수년간 존재할 수 있고 크기가 지속적으로 증가할 수 있기 때문에 파티션 크기를 어떻게든 제한해야 한다는 것이 분명해졌습니다.

우리는 메시지를 시간별로 블록(버킷)으로 배포하기로 결정했습니다. Discord에서 가장 큰 채널을 살펴보고 약 10일 단위로 메시지를 저장하면 100MB 제한에 편안하게 들어갈 수 있다고 결정했습니다. 블록은 message_id 또는 timestamp에서 가져와야 합니다.

DISCORD_EPOCH = 1420070400000 BUCKET_SIZE = 1000 * 60 * 60 * 24 * 10 def make_bucket(snowflake): 눈송이가 None인 경우: timestamp = int(time.time() * 1000) - DISCORD가 생성된 경우 Snowflake else가 포함됩니다. DISCORD_EPOCH 이후 #초. 타임스탬프 = 눈송이 ID >> 22 return int(timestamp / BUCKET_SIZE) def make_buckets(start_id, end_id=None): return range(make_bucket(start_id), make_bucket(end_id) + 1)
Cassandra 파티션 키는 합성될 수 있으므로 새 기본 키는 ((channel_id, bucket), message_id) 입니다.

CREATE TABLE 메시지(channel_id bigint, 버킷 int, message_id bigint, author_id bigint, 콘텐츠 텍스트, PRIMARY KEY((channel_id, 버킷), message_id)) WITH CLUSTERING ORDER BY(message_id DESC);
채널의 최근 메시지를 쿼리하기 위해 현재 시간에서 channel_id까지의 블록 범위를 생성했습니다(이 또한 Snowflake와 같이 시간순으로 정렬되며 첫 번째 메시지보다 오래되어야 함). 그런 다음 충분한 메시지를 수집할 때까지 파티션을 순차적으로 폴링합니다. 이 방법의 단점은 때때로 활성 Discord 인스턴스가 시간이 지남에 따라 충분한 메시지를 수집하기 위해 많은 다른 블록을 폴링해야 한다는 것입니다. 실제로 활성 Discord 인스턴스의 경우 일반적으로 첫 번째 섹션에 충분한 메시지가 있고 대부분이 있기 때문에 모든 것이 순서대로 되어 있는 것으로 나타났습니다.

Cassandra로의 메시지 가져오기는 순조롭게 진행되었으며 프로덕션에서 시험해 볼 준비가 되었습니다.

무거운 발사

산출 새로운 시스템프로덕션은 항상 무섭기 때문에 사용자에게 영향을 주지 않고 테스트하는 것이 좋습니다. MongoDB 및 Cassandra에서 읽기/쓰기 작업을 복제하도록 시스템을 구성했습니다.

출시 직후 버그 추적기는 author_id가 0이라는 오류를 표시했습니다. 어떻게 null이 될 수 있습니까? 필수 필드입니다!

결국 일관성

Cassandra는 유형 시스템입니다. 즉, 일반적으로 우리가 원했던 접근성을 위해 보장된 무결성이 희생되었습니다. Cassandra는 쓰기 전에 읽기를 권장하지 않으므로(읽기 작업이 더 비쌉니다) 특정 열만 제공되더라도 Cassandra가 하는 일은 업데이트와 upsert뿐입니다. 또한 모든 노드에 쓸 수 있으며 " 마지막 기록각 열에 대해 "승리"합니다. 이것이 우리에게 어떤 영향을 미칩니까?

레이스 컨디션 예시 편집/삭제

다른 사용자가 동일한 게시물을 삭제하는 동안 사용자가 게시물을 편집하는 경우 Cassandra는 업데이트 및 삽입만 기록하기 때문에 기본 키와 텍스트를 제외하고 데이터가 완전히 누락된 행으로 끝납니다. 이 문제에 대한 두 가지 가능한 솔루션이 있습니다.

1. 메시지를 편집하는 동안 전체 메시지를 다시 씁니다. 그러면 부활 가능성이 있습니다. 삭제된 메시지다른 열의 동시 항목에 대한 충돌 가능성을 추가합니다.
2. 손상된 메시지를 식별하고 데이터베이스에서 제거하십시오.

필요한 열(이 경우 author_id)을 정의하고 비어 있는 경우 게시물을 삭제하여 두 번째 옵션을 선택했습니다.

이 문제를 해결하는 동안 쓰기 작업이 상당히 비효율적이라는 것을 알았습니다. Cassandra는 궁극적으로 일관성이 있기 때문에 데이터를 즉시 삭제할 수 없습니다. 삭제를 다른 노드에 복제해야 하며 노드를 일시적으로 사용할 수 없는 경우에도 수행해야 합니다. Cassandra는 삭제를 "툼스톤"이라는 독특한 형식의 레코드와 동일시하여 이를 처리합니다. 읽기 작업 중에는 도중에 만나는 "삭제 표시"를 건너뜁니다. "삭제 표시"의 수명은 구성할 수 있으며(기본적으로 10일) 기간이 만료된 경우 기본 압축 중에 영구적으로 제거됩니다.

열을 삭제하고 열에 0을 쓰는 것은 정확히 같은 것입니다. 두 경우 모두 "비석"이 생성됩니다. Cassandra의 모든 쓰기는 업데이트 및 삽입이므로 처음에 0을 쓰더라도 삭제 표시를 만듭니다. 실제로 우리의 전체 메시지 레이아웃은 16개의 열로 구성되어 있지만 평균 메시지에는 4개의 값만 설정되어 있습니다. 우리는 보통 아무 이유 없이 카산드라에 12개의 묘비를 기록했습니다. 문제에 대한 해결책은 간단했습니다. 데이터베이스에 0이 아닌 값만 씁니다.

성능

Cassandra는 읽기보다 쓰기에서 더 빠른 것으로 알려져 있으며 이것이 바로 우리가 관찰한 것입니다. 쓰기 작업은 1밀리초 미만의 간격으로 발생하고 읽기 작업은 5밀리초 미만입니다. 이러한 비율은 액세스하는 데이터 유형에 관계없이 관찰되었습니다. 성능은 테스트 주간 내내 변경되지 않았습니다. 놀랍지 않습니다. 우리는 정확히 우리가 기대했던 것을 얻었습니다.

로그의 데이터에 따른 읽기/쓰기 지연

빠르고 안정적인 읽기 성능을 유지하기 위해 다음은 수백만 개의 메시지가 있는 채널에서 1년 된 메시지로 이동하는 예입니다.

큰 놀라움

모든 것이 순조롭게 진행되어 Cassandra를 기본 데이터베이스로 출시하고 일주일 만에 MongoDB 서비스를 중단했습니다. 그녀는 완벽하게 일을 계속했습니다 ... 약 6 개월 동안 어느 날 그녀가 응답하지 않을 때까지.

우리는 Cassandra가 가비지 수집 중에 10초 동안 계속 중지되는 것을 알아차렸지만 이유를 잘 알 수 없었습니다. 우리는 파기 시작했고 로드하는 데 20초가 걸리는 Discord 채널을 찾았습니다. 범인은 퍼즐 앤 드래곤 하위 레딧의 공개 Discord 서버였습니다. 공개니까 같이 보기로 했습니다. 놀랍게도 채널에는 하나의 메시지만 있었습니다. 그 순간 그들이 우리 API를 통해 수백만 개의 메시지를 삭제했고 채널당 하나의 메시지만 남게 된 것이 분명해졌습니다.

주의 깊게 읽었다면 Cassandra가 "툼스톤"("최종 일관성" 장에서 언급)을 사용하여 삭제를 처리하는 방법을 기억할 것입니다. 사용자가 이 채널을 로드하면 메시지가 하나만 있어도 Cassandra는 수백만 개의 메시지 삭제 표시를 효율적으로 스캔해야 합니다. 그런 다음 JVM이 수집할 수 있는 것보다 빠르게 가비지를 생성합니다.

우리는 이 문제를 다음과 같은 방법으로 해결했습니다.

• 메시지 클러스터에서 매일 저녁 Cassandra 복구(엔트로피 방지 프로세스)를 실행하기 때문에 삭제 표시 수명이 10일에서 2일로 단축되었습니다.
• 채널의 빈 블록을 추적하고 앞으로 이를 방지하도록 요청 코드를 변경했습니다. 즉, 사용자가 이 요청을 다시 시작하면 최악의 경우 Cassandra가 가장 최근 블록만 스캔합니다.

미래

에 이 순간복제 팩터 3으로 실행되는 12개 노드의 클러스터가 있으며 필요에 따라 계속해서 새로운 Cassandra 노드를 추가할 것입니다. 우리는 이 접근 방식이 장기적으로 효과가 있다고 생각하지만 Discord가 성장함에 따라 하루에 수십억 개의 메시지를 저장해야 하는 먼 미래처럼 보입니다. Netflix와 Apple은 수백 개의 노드가 있는 클러스터를 실행하므로 현재로서는 아무 것도 걱정할 필요가 없습니다. 그러나 몇 가지 아이디어를 남겨두고 싶습니다.

가까운 미래

• Cassandra 2에서 Cassandra 3으로 메시지 클러스터를 업그레이드하십시오. Cassandra 3의 새로운 스토리지 형식은 스토리지를 50% 이상 줄일 수 있습니다.
• 최신 버전의 Cassandra는 각 노드에서 더 많은 데이터를 더 잘 처리합니다. 우리는 현재 각각에 약 1TB의 압축 데이터를 저장합니다. 이 제한을 2TB로 늘려 클러스터의 노드 수를 줄이는 것이 안전하다고 생각합니다.

먼 미래

• Learn Scylla는 C++로 작성된 Cassandra 호환 DBMS입니다. 정상 작동 시 Cassandra 노드는 실제로 약간의 CPU 리소스를 소비하지만 Cassandra 복구(카운터 엔트로피 프로세스) 중 사용량이 적은 시간에는 CPU에 상당히 의존하며 작성된 데이터의 양에 따라 복구 시간이 늘어납니다. 마지막 수리 이후. Scylla는 수리 속도를 크게 높일 것을 약속합니다.
• 사용하지 않는 피드를 Google Cloud Storage에 보관하고 필요에 따라 다시 업로드하는 시스템을 만듭니다. 우리는 그것을 피하고 싶고 우리가 그것을 할 필요가 없다고 생각합니다.

결론

Cassandra로 전환한 지 1년 이상이 지났지만 "큰 놀라움"잔잔한 수영이었다. 성능과 안정성을 유지하면서 하루에 총 1억 개 이상의 메시지에서 1억 2천만 개 이상의 메시지로 증가했습니다.

이 프로젝트의 성공으로 인해 프로덕션의 다른 모든 데이터도 성공적으로 Cassandra로 마이그레이션했습니다.

이 기사의 계속에서 우리는 수십억 개의 메시지에서 전체 텍스트 검색을 수행하는 방법을 탐구할 것입니다.

아직 전담 DevOps 엔지니어가 없으므로(단 4명의 백엔드 엔지니어만) 걱정할 필요가 없는 시스템이 있다는 것은 정말 멋진 일입니다. 우리는 고용 중이므로 이 퍼즐이 당신의 공상을 간지럽힌다면 연락하십시오.

태그: 태그 추가