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

Question

저는 데이터베이스 시스템 설계가 처음입니다. 많은 기사를 읽은 후 샤딩이나 파티셔닝 없이 테이블 1개를 가져야 하는 제한이 무엇인지 정말 혼란스럽습니다. 일반적인 답변을 제공하는 것이 정말 어렵다는 것을 알고 있습니다. 행 크기, 데이터 유형(문자열, blob 등) 활성 쿼리 수, 쿼리 인덱스 다시 읽기/다시 쓰기 예상 대기 시간 등의 요소에 따라 다르지만 누군가 이렇게 묻는 경우 매일 10억 개의 데이터와 수백만 개의 행이 추가되는 상황에서 무엇을 하시나요? 이러한 대규모 데이터베이스의 경우 읽기 4개, 쓰기 1개, 업데이트 쿼리 2개의 지연 시간이 5밀리초 미만이어야 합니다. 10개만 있으면

P粉401901266 · Answer

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

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

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

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