저는 회사의 RoR 프로젝트 디자인 작업을하고 있으며, 개발 팀은 이미 디자인, 특히 데이터베이스에 대한 약간의 논쟁을 벌이고 있습니다.PostgreSQL 테이블의 크기가 너무 큽니까?
우리는 Message이라는 모델을 유지해야합니다. 이드 이외에는 단지 3 개의 db 컬럼을 갖는 매우 작은 모델입니다. 그러나 우리가 생산에 갈 때 이러한 모델이 많이있을 것입니다. 우리는 하루에 1,000,000 건의 삽입을보고 있습니다. 모델은 인덱싱 할 수있는 두 개의 외래 키로 만 검색됩니다. 또한 모델을 삭제할 필요도 없지만 3 개월이 지나면 모델을 보관할 필요가 없습니다.
그래서이 테이블을 Postgres에 구현하면 중요한 성능 문제가 발생하는지 궁금합니다. 누가 큰 문제가 될 것인지 여부를 알려주는 매우 큰 SQL 데이터베이스 경험이 있습니까? 그렇다면 대체 방법은 무엇입니까?
테이블 당 행 수가 문제가되지 않습니다.
따라서 대략 90 일 동안 1 백만 개의 행이 9 천만 행입니다. 나는 Postgres가 당신이하고있는 것에 대한 모든 세부 사항을 알지 못해도 그것을 다룰 수는 없다.
데이터 배포에 따라 인덱스와 필터링 된 인덱스 및 테이블 파티셔닝을 혼합하여 사용할 때 어떤 성능 문제가 있는지 파악한 후 처리 속도를 높일 수 있습니다. 문제는 내가 아는 다른 RDMS에서도 동일합니다. 프로세스에서 3 개월 분량의 데이터 디자인 만 필요로하면 더 이상 필요하지 않은 데이터를 정리할 수 있습니다. 그렇게하면 테이블에 일정한 양의 데이터를 갖게됩니다. 운 좋게도 얼마나 많은 데이터가 존재하는지 알고, 볼륨을 테스트하여 얻은 결과를 확인하십시오. 9000 만 개 행이 하나 개의 테이블을 테스트하는 것처럼 쉽지가 될 수 있습니다 크게> 1 억 개 행이 테이블에
select x,1 as c2,2 as c3
from generate_series(1,90000000) x;
http://www.postgresql.org/about/
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
PostgreSQL에 9 천만 행이 문제가되지 않는다는 것에 동의합니다. PostgreSQL과의 ORM에서는 문제가 될 수 있습니다. (실제로 어떤 DBMS와 ORM이 되었습니까?) –
@ MikeSherrill'Catcall '좋은 점은 "PostgreSQL 테이블의 크기가 너무 큽니까"입니다. – Kuberchaun
@ MikeSherrill'CatRecall '왜 ORM에서 문제가 될 수 있습니까? :) – yeyo
또 다른 방법은 쿼리 속도를 높이기 위해 오프 시간 클러스터에 색인에서 가장 자주 사용되는 표는 입니다. Google은 2 억 1800 만 개가 넘는 행을 가진 표를 보유하고 있으며 30 배 개선 된 점을 발견했습니다.
좋은 캐싱 레이어와 PG의 구성이 약간이라면 괜찮을 것입니다. 케이스별로 성능 문제를 해결하고 사전 최적화하지 않도록하십시오. 즉, 파티셔닝 및 복제는 항상 병목 현상이 발생했을 때 활용할 수있는 훌륭한 옵션입니다. –
관련 질문 [here] (http://stackoverflow.com/questions/13639626/database-columns-in-select-or-create-statements/13639920#13639920) 및 [여기] (http://stackoverflow.com/ 질문/12606842/what-that-the-the-the-maximum-of-a-postgresql- 선택 쿼리). –
5 개 이상의 TB PostgreSQL 데이터베이스에서 하루에 약 3 천만 개의 메시지를 처리하므로 정상적으로 작동합니다. –