테이블을 샤딩하거나 파티셔닝하기 전의 제한사항

Question

저는 데이터베이스 시스템 설계가 처음입니다. 많은 기사를 읽은 후 샤딩이나 파티셔닝 없이 테이블 1개를 가져야 하는 한도가 무엇인지 정말 혼란스럽습니다. 보편적인 답변을 제공하는 것이 정말 어렵다는 것을 알고 있습니다. 상황은 다음과 같은 요인에 따라 달라집니다.

행 크기
데이터 유형(문자열, blob 등)
활성 문의 수
어떤 쿼리
색인
다시 읽기/다시 쓰기
예상되는 지연

그런데 누군가 이런 질문을 하면

매일 10억 개의 데이터와 수백만 개의 행이 추가된다면 어떻게 하시겠습니까? 이러한 대규모 데이터베이스의 경우 읽기 4회, 쓰기 1회, 업데이트 2회 쿼리에 대한 대기 시간은 5밀리초 미만이어야 합니다.
행이 1,000만 개밖에 없는데 업데이트 및 읽기 양이 많다면 무엇을 선택하시겠습니까? 추가된 새 줄의 수는 중요하지 않습니다. 높은 일관성과 낮은 대기 시간이 요구됩니다.

행 개수가 100만 개 미만이고 행 크기가 수천 개씩 증가하는 경우 선택은 간단합니다. 그러나 선택 항목에 수백만 또는 수십억 개의 행이 포함되면 상황이 더욱 까다로워집니다.

참고: 질문에 지연 횟수를 언급하지 않았습니다. 제발 귀하가 편안하게 느끼는 지연 횟수를 기준으로 답변하십시오. 또한 구조화된 데이터에 대해서도 이야기하고 있습니다.

잘 모르겠지만 3가지 구체적인 질문을 추가할 수 있습니다:

Amazon 또는 전자상거래 주문 관리 시스템용 SQL 데이터베이스를 선택한다고 가정해 보겠습니다. 주문 건수는 매일 수백만 개씩 증가하고 있습니다. 이미 10억 개의 레코드가 있습니다. 이제 데이터 아카이브가 없다고 가정합니다. 초당 1,000개 이상의 쿼리로 높은 읽기 쿼리를 제공합니다. 그리고 또한 쓰여졌습니다. 읽기:쓰기 비율은 100:1
이제 더 작은 숫자의 예를 들어보겠습니다. abc 또는 전자상거래 주문 관리 시스템용으로 SQL 데이터베이스를 선택한다고 가정해 보겠습니다. 주문량이 매일 수천개씩 늘어나고 있습니다. 이미 천만 개의 레코드가 있습니다. 이제 데이터 아카이브가 없다고 가정합니다. 초당 1만 개가 넘는 쿼리로 높은 읽기 쿼리를 제공합니다. 그리고 또한 쓰여졌습니다. 읽기와 쓰기 비율은 10:1
세 번째 예: 공짜 배포. 우리는 1000만 개의 선물을 나눠줄 것입니다. 사용자당 1개의 상품이 제공됩니다. 높은 일관성과 낮은 대기 시간이 목표입니다. 이미 무료 배포를 기다리는 사용자가 2천만 명이라고 가정하면, 시간이 시작되면 모든 사용자가 무료 혜택을 손에 넣으려고 노력할 것입니다.

참고: 이 질문에서는 다음을 선택한다고 가정합니다. SQL 솔루션. 또한 제공된 사용 사례가 논리적으로 이해되지 않는 경우 무시하세요. 수치적 지식을 습득하는 것이 목표입니다.

벤치마크가 무엇인지 이해하도록 도와줄 수 있는 사람이 있나요? 현재 작업 중인 프로젝트의 실제 수치를 보면 이것이 쿼리가 너무 많은 대규모 데이터베이스에서 관찰된 대기 시간임을 알 수 있습니다. 특정 대기 시간에 대한 특정 수의 쿼리에 대한 선택 테이블 수를 정당화하는 데 도움이 될 수 있는 모든 것입니다.

Answer 1

MySQL에 대한 몇 가지 답변. 모든 데이터베이스에는 디스크 공간, 네트워크 대기 시간 등이 적용되므로 다른 엔진도 유사할 수 있습니다.

• 행 수에 관계없이 "포인트 쿼리"(적절한 인덱스를 사용하여 행 가져오기)에는 밀리초가 걸립니다.
• 실행하는 데 몇 시간, 심지어 며칠이 걸리는 것을 작성하는 것도 가능합니다SELECT. 따라서 쿼리가 이와 같이 병리적인지 이해해야 합니다. (이것은 "지연 시간"이 높은 예라고 생각합니다.)
• 단일 서버에서 필요한 쓰기 수를 유지할 수 없는 경우 "샤딩"이 필요합니다.
• 복제를 사용하고 읽기를 복제본으로 보내면 대규모 읽기를 "무한대로" 확장할 수 있습니다.
• PARTITIONing(특히 MySQL에서) 용도는 거의 없습니다. 자세한 내용: 파티션
• INDEX 성능에 매우 중요합니다.
• 데이터 웨어하우스 애플리케이션의 경우 대규모 성능을 위해서는 "요약 테이블"을 구축하고 유지 관리하는 것이 중요합니다. (일부 엔진에는 도구가 내장되어 있습니다.)
• 每天插入1백만 행은 문제가 되지 않습니다. (물론 일부 스키마 설계로 인해 이 문제가 발생할 수 있습니다.) 경험상 100/초는 문제가 되지 않을 수 있지만 그 이후에는 더 어려워질 수 있습니다. 고속 수집
에 대한 추가 정보
• 네트워크 대기 시간은 주로 클라이언트와 서버 사이의 거리에 따라 달라집니다. 지구 반대편에 도달하는 데는 200밀리초 이상이 걸립니다. 반면에 클라이언트와 서버가 같은 건물에 있으면 대기 시간은 1밀리초 미만입니다. 반면에 쿼리를 실행하는 데 걸리는 시간을 언급하는 경우 다음과 같은 몇 가지 경험 법칙이 있습니다. HDD 디스크에 도달해야 하는 간단한 쿼리의 경우 10ms, SSD의 경우 1ms입니다.
• UUID와 해시는 데이터가 너무 커서 RAM에 캐시할 수 없는 경우 성능에 매우 해롭습니다.
• 저는 읽기와 쓰기를 독립적으로 판단하는 것을 선호하기 때문에 읽기/쓰기 비율에 대해서는 언급하지 않았습니다.
• "초당 10,000회 읽기"는 달성하기 어렵습니다. 실제로 이것이 필요한 애플리케이션은 거의 없습니다. 아니면 동일한 목표를 달성하기 위한 더 나은 방법을 찾을 수도 있습니다. 사용자는 얼마나 빨리 쿼리를 실행할 수 있나요? 어쩌면 초당 하나? 동시에 몇 명의 사용자가 연결하고 활성화할 수 있습니까? 수백.
• (내 의견) 대부분의 벤치마크는 쓸모가 없습니다. 일부 벤치마크에서는 한 시스템이 다른 시스템보다 두 배 빠른 것으로 나타날 수 있습니다. 그래서 뭐? 일부 벤치마크에 따르면 활성연결이 수백 개가 넘으면 처리량이 지연되고 대기 시간이 무한대에 도달하는 경향이 있습니다. 그래서 뭐. 애플리케이션이 한동안 실행된 후 실제 쿼리를 캡처하는 것이 아마도 최고의 벤치마크일 것입니다. 그러나 그 용도는 여전히 제한적입니다.
• 단일 테이블은 거의 항상 분할 테이블(여러 테이블, 파티션, 샤드)보다 낫습니다. 구체적인 사례가 있으면 테이블 디자인의 장단점에 대해 논의할 수 있습니다.
• 행 크기 및 데이터 유형 - 큰 열(TEXT/BLOB/JSON)은 "로그되지 않은" 상태로 저장되므로 [잠재적으로] 추가 디스크 적중이 발생합니다. 디스크 적중은 모든 쿼리에서 가장 비용이 많이 드는 부분입니다.
• 활성 쿼리 – 수십 번 후에 쿼리가 서로 충돌합니다. (쇼핑 카트를 밀고 있는 많은 쇼핑객이 있는 식료품점을 상상해 보십시오. "너무 많은" 쇼핑객이 있고 모두가 쇼핑을 마치는 데 오랜 시간이 걸립니다.)

대규모 데이터베이스에 들어가면 각각 다른 특성을 지닌 몇 가지 유형이 있습니다.

• 데이터 웨어하우스(센서, 로그 등) - 효율적인 "보고"를 위한 요약 테이블, 대규모 "사실" 테이블(일부 "차원 테이블" 포함)에 추가됩니다.
• 검색(제품, 웹페이지 등) - EAV는 문제가 있는 경우가 많습니다.
• 뱅킹, 주문 처리 - 이는 ACID 기능과 거래 처리 필요성에 매우 중요합니다.
• 미디어(이미지 및 비디오) - 합리적으로 빠른 검색 등을 수행하면서 거대한 개체를 저장하는 방법입니다.
• '가장 가까운 찾기' - 2D 색인이 필요합니다. SPATIAL 또는 일부 기술 여기