저는 우리 회사의 RoR 프로젝트를위한 설계 작업을하고 있으며, 우리 개발 팀은 이미 설계, 특히 데이터베이스에 대해 약간의 논쟁을 벌였습니다.
Message지속되어야 하는 모델 이 있습니다. 이것은 id 이외의 db 열이 3 개 밖에없는 매우 작은 모델이지만, 프로덕션 단계에서는 이러한 모델이 많이있을 것입니다. 우리는 하루에 최대 1,000,000 건의 삽입을보고 있습니다. 모델은 색인화 할 수있는 두 개의 외래 키로 만 검색됩니다. 또한 모델을 삭제할 필요가 없지만 약 3 개월이 지나면 보관할 필요도 없습니다.
그래서 우리가 궁금해하는 것은 Postgres에서이 테이블을 구현하면 심각한 성능 문제가 발생하는지 여부입니다. 누구든지 이것이 문제가 될지 여부를 알려주기 위해 매우 큰 SQL 데이터베이스에 대한 경험이 있습니까? 그렇다면 어떤 대안을 선택해야합니까?
답변
테이블 당 행은 그 자체로 문제가되지 않습니다.
따라서 대략 90 일 동안 하루에 1 백만 개의 행을 말하면 9 천만 행입니다. 나는 Postgres가 당신이하는 일에 대한 모든 세부 사항을 알지 않고는 그것을 다룰 수없는 이유를 보지 못합니다.
데이터 배포에 따라 인덱스, 필터링 된 인덱스 및 일종의 테이블 파티셔닝을 혼합하여 사용할 수 있습니다. 귀하의 문제는 내가 아는 다른 RDMS에서도 동일합니다. 데이터를 제거하는 프로세스에서 3 개월 분량의 데이터 디자인 만 필요하다면 더 이상 필요하지 않습니다. 이렇게하면 테이블에 일관된 양의 데이터를 유지할 수 있습니다. 운 좋게도 얼마나 많은 데이터가 존재할지 알고 볼륨에 대해 테스트하고 얻는 것을 확인하십시오. 9 천만 개의 행이있는 하나의 테이블을 테스트하는 것은 다음과 같이 쉽습니다.
select x,1 as c2,2 as c3
from generate_series(1,90000000) x;https://wiki.postgresql.org/wiki/FAQ
Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited답변
행이 1 억 이상인 테이블에서 쿼리 속도를 크게 높이는 또 다른 방법은 쿼리에서 가장 자주 사용되는 인덱스의 테이블을 업무 외 시간에 클러스터링하는 것입니다. 2 억 1,800 만 개 이상의 행이있는 테이블이 있으며 30 배 개선 된 것으로 나타났습니다.
또한 매우 큰 테이블의 경우 외래 키에 대한 인덱스를 만드는 것이 좋습니다.
