MySQL 테이블에 대해 '너무 많은' 행은 몇 개입니까?
중복 가능성:
데이터베이스에 너무 많은 행이 있습니까?
사용자가 포함될 응용프로그램에 대한 데이터베이스 구성표를 작성하고 있으며 각 사용자는 '즐겨찾기'와 같은 관계 테이블에 많은 행을 가질 것입니다.각 사용자는 수천 개의 즐겨찾기를 가질 수 있으며, 등록된 사용자는 수천 명(시간이 지남에 따라)일 수 있습니다.
사용자가 삭제되지 않는 이유는 다른 엔티티가 고아가 되거나 삭제(원하지 않음)될 수 있기 때문이며, 따라서 이러한 테이블은 계속해서 커질 것이기 때문입니다. 결과 테이블이 너무 클 수도 있습니다(예: 1kk 행).그리고 저는 이것에 대해 걱정하고 오래된 사용자와 비활성 사용자를 삭제로 표시하고 그들에게만 영향을 주는 관계(예: 즐겨찾기 및 기타 기본 설정)를 제거해야 합니다.
이 길이 맞나요?아니면 mysql이 테이블에서 1kk 행을 쉽게 처리할 수 있습니까?알려진 제한이 있습니까?아니면 하드웨어에 완전히 의존합니까?
나는 Kennepette와 Brian의 의견에 동의합니다 - 몇 가지 주의 사항.
데이터가 본질적으로 관계형이고 SQL과 잘 작동하는 쿼리에 종속되는 경우, 기존의 하드웨어 요구사항 없이 수억 개의 레코드로 확장할 수 있어야 합니다.
인덱싱, 쿼리 조정 및 속도 향상을 위해 관계형 모델을 희생시키는 데 투자해야 합니다.테이블을 설계할 때는 최소한 성능에 따라 고개를 끄덕여야 합니다. 예를 들어 키의 문자열보다 정수를 선호합니다.
그러나 문서 중심의 요구사항이 있거나, 무료 텍스트 검색이 필요하거나, 계층적 관계가 많은 경우에는 다시 살펴봐야 할 수도 있습니다.
ACID 트랜잭션이 필요한 경우 트랜잭션에 관심이 없는 경우보다 확장성 문제가 먼저 발생할 수 있습니다(실제로는 이 문제가 영향을 미치지 않지만). 장기간 실행되거나 복잡한 트랜잭션이 있는 경우 확장성이 상당히 빠르게 저하됩니다.
확장성 요구사항을 염두에 두고 프로젝트를 처음부터 구축하는 것이 좋습니다.과거에 제가 했던 일은 수백만 개의 레코드가 있는 테스트 환경을 설정하는 것입니다(DB Monster를 사용했지만 아직도 레코드가 있는지는 잘 모르겠습니다). 그리고 Jmeter와 같은 로드 테스트 도구를 사용하여 이 데이터베이스에 대해 정기적으로 진행 중인 코드를 테스트합니다.
수백만 개의 행은 괜찮고, 수천만 개의 행은 괜찮습니다. 원격으로 괜찮은 서버(예: 몇 Gbps의 RAM, 충분한 디스크 공간)만 있으면 됩니다.빠른 검색을 위해 인덱스에 대해 배워야 하지만 MySQL이 처리할 수 있다는 점에서는 문제가 없습니다.
다음은 innodb의 클러스터된 기본 키 인덱스(myisam에서는 사용할 수 없음)를 활용하는 잘 설계/정규화된 innodb 스키마를 사용하여 무엇을 얻을 수 있는지 보여주는 예입니다.예제는 스레드가 있는 포럼을 기반으로 하며 로드 중에 5억 개의 행과 0.02초의 쿼리 실행 시간을 가집니다.
MySQL 및 NoSQL: 올바른 것을 선택할 수 있도록 도와줍니다.
대부분 하드웨어에 의존하지만 MySQL은 상당히 잘 확장됩니다.테이블 크기에 대해서는 크게 걱정하지 않겠습니다. 나중에 문제가 된다면 언제든지 파티션을 사용하여 스트레스를 완화할 수 있습니다.
언급URL : https://stackoverflow.com/questions/5350581/how-many-rows-are-too-many-for-a-mysql-table
'programing' 카테고리의 다른 글
| 필수_라벨 5 유효성 검사인 경우 (0) | 2023.08.06 |
|---|---|
| 비트 열에 SUM을 사용하려면 어떻게 해야 합니까? (0) | 2023.08.06 |
| Javascript 변수를 PHP POST에 전달 (0) | 2023.08.01 |
| 어떤 키 저장소가 앱에 서명하는 데 사용되었는지 어떻게 알 수 있습니까? (0) | 2023.08.01 |
| 항상 Android:configChanges="키보드 숨김|방향"을 사용하지 않는 이유는 무엇입니까? (0) | 2023.08.01 |