데이터베이스 테이블 (SQL Server 버전 8, 9 또는 10) 중 하나에 많은 데이터를 저장하는 소프트웨어를 개발합니다. 하루에 약 100,000 개의 레코드가 해당 테이블에 삽입된다고 가정 해 보겠습니다. 이것은 연간 약 3,600 만 개의 레코드입니다. 성능이 떨어질 까봐 걱정이되어 테이블 당 레코드 수를 줄이기 위해 매일 새 테이블 (이름에 현재 날짜가있는 테이블)을 만들기로 결정했습니다.
그게 좋은 생각인지 말씀해 주시겠습니까? SQL Server 테이블에 대한 레코드 제한이 있습니까? 또는 성능이 크게 저하되기 전에 테이블에 저장할 수있는 레코드 수 (다소)를 알고 있습니까?
답변:
이에 대한 일반적인 대답을 제공하기는 어렵습니다. 실제로 여러 요인에 따라 다릅니다.
기타
여기 다른 곳에서 대답했듯이, 하루에 100,000, 따라서 테이블 당 과잉입니다. 매월 또는 매주 아마도 분기별로 제안 할 것입니다. 테이블이 많을수록 더 큰 유지 관리 / 쿼리 악몽이 될 것입니다.
다음은 SQL Server 2008 R2 의 최대 용량 사양 중 일부입니다.
bigint)
SQL Server 2008 R2에는 60 억 개가 넘는 행이있는 3 열 테이블이 있습니다.
우리는 고객을 위해 분 단위 시스템 분석 차트를 만들기 위해 매일 쿼리합니다. 데이터베이스 성능 저하를 발견하지 못했습니다 (매일 ~ 1GB가 증가한다는 사실 때문에 백업 관리가 원하는 것보다 약간 더 복잡해집니다).
2016 년 7 월 업데이트
백업이 2 년 이상 된 레코드를 잘라내기로 결정할 수있을만큼 충분히 커지기 전에 최대 245 억 행 으로 만들었습니다 (고가의 테이프를 포함하여 여러 백업에 저장되는 최대 700GB). 이 결정에서 성과가 중요한 동기가 아니었다는 점은 주목할 가치가 있습니다 (즉, 여전히 훌륭하게 작동하고 있음).
SQL Server에서 200 억 개의 행을 삭제하려는 경우이 기사를 적극 권장 합니다 . 링크가 죽는 경우 관련 코드 (전체 설명은 기사 참조) :
ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO
BEGIN TRY
BEGIN TRANSACTION
-- Bulk logged
SELECT *
INTO dbo.bigtable_intermediate
FROM dbo.bigtable
WHERE Id % 2 = 0;
-- minimal logged because DDL-Operation
TRUNCATE TABLE dbo.bigtable;
-- Bulk logged because target table is exclusivly locked!
SET IDENTITY_INSERT dbo.bigTable ON;
INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
SET IDENTITY_INSERT dbo.bigtable OFF;
COMMIT
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0
ROLLBACK
END CATCH
ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO
2016 년 11 월 업데이트
이 정도의 데이터를 단일 테이블에 저장할 계획이라면하지 마십시오. 테이블 파티셔닝을 고려하는 것이 좋습니다 (수동으로 또는 Enterprise 에디션을 실행하는 경우 기본 제공 기능 사용). 이렇게하면 테이블을 한 번 (주 / 월 / 기타) 자르는 것만 큼 쉽게 오래된 데이터를 삭제할 수 있습니다. Enterprise (우리가없는)가없는 경우 한 달에 한 번 실행하고 2 년 이상 된 테이블을 삭제하고 다음 달의 테이블을 만들고 모든 파티션을 조인하는 동적 뷰를 다시 생성하는 스크립트를 작성하면됩니다. 쉬운 쿼리를 위해 함께 테이블. 분명히 "한 달에 한 번"및 "2 년 이상"은 사용 사례에 맞는 것을 기반으로 정의해야합니다.
상황에 따라 다르지만 단순성을 위해 모든 것을 하나의 테이블에 보관하는 것이 좋습니다.
하루에 100,000 개의 행이 실제로 그렇게 많은 양은 아닙니다. (서버 하드웨어에 따라 다름). 개인적으로 MSSQL이 단일 테이블에서 문제없이 최대 1 억 개의 행을 처리하는 것을 보았습니다. 색인을 순서대로 유지하는 한 모든 것이 좋습니다. 핵심은 인덱스를 디스크로 교체 할 필요가 없도록 메모리 힙 을 확보하는 것입니다.
반면에 데이터를 사용하는 방법에 따라 쿼리를 많이 만들어야하고 며칠에 걸친 데이터가 필요하지 않은 경우 (테이블을 조인 할 필요가 없음) 여러 테이블로 분리하는 것이 더 빠릅니다. 이는 10 초마다 50,000 개의 기기에서 값을 읽을 수있는 산업 공정 제어와 같은 애플리케이션에서 자주 사용됩니다. 이 경우 속도는 매우 중요하지만 단순성은 중요하지 않습니다.
디스크 공간이 충분할 때까지 테이블을 채울 수 있습니다. 더 나은 성능을 위해 SQL Server 2005로 마이그레이션 한 다음 테이블을 분할하고 다른 디스크에 부품을 배치 할 수 있습니다 (실제로 도움이 될 수있는 RAID 구성이있는 경우). 분할은 SQL Server 2005 엔터프라이즈 버전에서만 가능합니다. 다음 링크에서 분할 예제를 볼 수 있습니다. http://technet.microsoft.com/en-us/magazine/cc162478.aspx
또한 가장 많이 사용되는 데이터 부분에 대한보기를 만들 수도 있습니다. 이는 솔루션 중 하나이기도합니다.
이것이 도움이 되었기를 바랍니다.
Windows2003의 SQL Server 8에서 내가 만난 가장 큰 테이블은 5 개 열이있는 7 억 9 천만 명이었습니다. 그러나 그것이 좋은지 여부는 SLA 및 사용 사례에 대해 측정하는 것입니다. 예를 들어 50-100,000,000 개의 레코드를로드하고 여전히 작동하는지 확인합니다.
SELECT Top 1 sysobjects.[name], max(sysindexes.[rows]) AS TableRows,
CAST(
CASE max(sysindexes.[rows])
WHEN 0 THEN -0
ELSE LOG10(max(sysindexes.[rows]))
END
AS NUMERIC(5,2))
AS L10_TableRows
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id]
WHERE sysobjects.xtype = 'U'
GROUP BY sysobjects.[name]
ORDER BY max(rows) DESC
테이블을 매월 분할하십시오. Oracle 또는 MSSQL과 같이 일일 유입량이 많은 테이블을 처리하는 가장 좋은 방법입니다.