데이터베이스 파일이 매우 큰 sqlite의 성능 특성은 무엇입니까?

데이터베이스 파일이 매우 큰 sqlite의 성능 특성은 무엇입니까?

문 닫았습니다.이 질문은의견에 입각한현재 답변을 받지 않고 있습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용으로 답변할 수 있도록 질문을 업데이트합니다.

9년전에 문을 닫았습니다.

커뮤니티는 8일 전 이 질문을 재개할 것인지 검토하고 비공개로 했습니다.

원래 근접 사유가 해결되지 않았습니다.

이 질문을 개선합니다.

2020년 업데이트, 질문이 게시된 후 약 11년 만에 종료되어 더 새로운 답변을 방지합니다.

여기 쓰여 있는 것들은 거의 다 낡았습니다.옛날에 sqlite는 메모리 용량 또는 2GB의 스토리지(32비트) 또는 기타 인기 있는 숫자로 제한되었습니다.음, 그건 오래전 일입니다.

공식적인 제한 사항은 여기에 나와 있습니다. 실제로 sqlite는 사용 가능한 스토리지가 있는 한 작동할 가능성이 높습니다.메모리보다 더 큰 데이터 세트에서도 잘 작동하며, 원래 메모리가 얇을 때 만들어졌으며 처음부터 매우 중요한 시점이었습니다.

100GB의 데이터를 저장하는 데는 전혀 문제가 없습니다.TB를 저장하는 데는 문제가 없을 수 있지만, SQLite가 작업에 가장 적합한 툴인지 의문을 제기해야 하며, 전체 데이터베이스(원격 클라이언트, 동시 쓰기, 읽기 전용 복제본, 샤딩 등)의 기능을 필요로 할 수도 있습니다.

---

원본:

sqlite가 지원되는 경우에도 매우 큰 데이터베이스 파일에서는 성능이 좋지 않다는 것을 알고 있습니다(sqlite 웹 사이트에는 1GB 이상의 파일 크기가 필요한 경우 엔터프라이즈 rdbms를 사용하는 것을 고려해 볼 수 있다는 의견이 있었습니다).더 이상 찾을 수 없습니다. 이전 버전의 sqlite)와 관련이 있을 수 있습니다.

하지만 저는 제 목적을 위해 다른 해결책을 고려하기 전에 그것이 실제로 얼마나 나쁜지 알고 싶습니다.

저는 2GB 이후의 멀티 기가바이트 범위의 sqlite 데이터 파일에 대해 말하고 있습니다.이것에 대한 경험이 있는 사람?조언이나 아이디어가 있습니까?

그래서 매우 큰 파일에 대해 sqlite로 몇 가지 테스트를 했고 몇 가지 결론을 내렸습니다 (적어도 특정 애플리케이션에 대해서는).

테스트에는 단일 테이블 또는 여러 테이블이 포함된 단일 sqlite 파일이 포함됩니다.각 표에는 거의 모든 정수와 4개의 색인 8개의 열이 있었습니다.

이 아이디어는 sqlite 파일이 약 50GB가 될 때까지 충분한 데이터를 삽입하는 것이었습니다.

싱글 테이블

하나의 테이블만으로 sqlite 파일에 여러 행을 삽입하려고 했습니다.파일이 약 7GB일 때(행 수에 대해 구체적으로 설명할 수 없어 죄송합니다) 삽입에 시간이 너무 많이 걸렸습니다.모든 데이터를 삽입하는 테스트에 24시간 정도 걸릴 것으로 예상했지만 48시간이 지나도 완료되지 않았습니다.

따라서 하나의 매우 큰 sqlite 테이블에 삽입 및 다른 작업에도 문제가 있을 것이라는 결론을 내릴 수 있습니다.

테이블이 커질수록 모든 인덱스를 삽입하고 업데이트하는 데 시간이 오래 걸리므로 놀랄 일이 아닌 것 같습니다.

다중 테이블

그런 다음 하루에 한 테이블씩 여러 테이블에 걸쳐 데이터를 시간별로 나누어 보았습니다.원래 1개 테이블의 데이터는 ~700개 테이블로 분할되었습니다.

이 설정은 삽입에 문제가 없었고, 매일 새로운 테이블이 생성되었기 때문에 시간이 더 오래 걸리지 않았습니다.

진공 문제

i_like_caffeine에서 지적한 바와 같이 VACUUM 명령어는 sqlite 파일의 크기가 클수록 문제가 됩니다.삽입/삭제를 더 많이 하면 할수록 디스크의 파일 조각화가 심해지므로 주기적으로 VASUAN을 실행하여 파일을 최적화하고 파일 공간을 복구하는 것이 목표입니다.

그러나 문서에서 지적한 바와 같이 데이터베이스의 전체 복사본은 진공 상태가 되도록 만들어지므로 완료하는 데 시간이 매우 오래 걸립니다.따라서 데이터베이스가 작을수록 이 작업은 더 빨리 완료됩니다.

결론들

특정 애플리케이션의 경우 진공 성능과 삽입/삭제 속도를 모두 최대한 활용하기 위해 하루에 하나씩 여러 db 파일로 데이터를 분할할 것입니다.

이것은 질의를 복잡하게 만들지만, 저에게는 이 정도의 데이터를 색인할 수 있다는 것이 가치 있는 거래입니다.추가적인 이점은 전체 db 파일을 삭제하여 하루 분량의 데이터를 삭제할 수 있다는 것입니다(애플리케이션의 일반적인 작업).

속도가 언제 문제가 되는지 파일당 테이블 크기도 모니터링해야 할 것 같습니다.

자동 진공 외에 점진적인 진공 방식이 없는 것 같아 아쉽습니다.저의 진공 목표는 파일 조각 모음(파일 공간은 큰 문제가 되지 않음)이기 때문에 사용할 수 없습니다. 하지만 자동 진공에서는 사용할 수 없습니다.사실 설명서에 따르면 단편화가 더 심해질 수 있기 때문에 주기적으로 파일 전체를 진공 상태로 유지해야 합니다.

우리는 플랫폼에서 50GB+의 DBS를 사용하고 있습니다.불평불만은 문제없습니다.모든 것을 제대로 하고 있는지 확인하세요!미리 정의된 문을 사용하고 계십니까? *SQLITE 3.7.3

1. 거래
2. 기명세서

3. 이 설정 적용(DB 작성 직후)

   PRAGMA main.page_size = 4096;
   PRAGMA main.cache_size=10000;
   PRAGMA main.locking_mode=EXCLUSIVE;
   PRAGMA main.synchronous=NORMAL;
   PRAGMA main.journal_mode=WAL;
   PRAGMA main.cache_size=5000;
   

이것이 다른 사람들에게 도움이 되기를 바랍니다. 여기서 잘 작동합니다.

최대 3.5개의 SQLite 데이터베이스를 만들었습니다.GB의 크기에 눈에 띄는 성능 문제가 없습니다.제 기억이 맞다면 SQLite2는 좀 더 낮은 제한이 있었을 것 같은데 SQLite3는 그런 문제가 없다고 생각합니다.

SQLite 제한 페이지에 따르면 각 데이터베이스 페이지의 최대 크기는 32K입니다.그리고 데이터베이스의 최대 페이지는 1024^3입니다.그래서 제 수학으로는 최대 크기가 32테라바이트에 달합니다.SQLite를 사용하기 전에 파일 시스템의 한계에 부딪힐 것이라고 생각합니다.

삽입하는 데 48시간 이상 걸린 대부분의 이유는 인덱스 때문입니다.다음을 수행하는 것이 엄청나게 빠릅니다.

1 - 모든 인덱스 삭제 2 - 모든 삽입 수행 3 - 인덱스 다시 만들기

일반적인 권장 사항 외에:

1. 대량 삽입을 위한 색인을 삭제합니다.
2. 대규모 트랜잭션에서 일괄 삽입/업데이트.
3. 버퍼 캐시/저널/w개의 PRGMAs를 조정합니다.
4. 64비트 시스템을 사용합니다(cache™를 많이 사용하려면).
5. [2014년 7월 추가] 여러 SQL 쿼리 실행 대신 공통 테이블 표현(CTE) 사용!SQLite 릴리스 3.8.3이 필요합니다.

SQLite3을 통해 배운 내용은 다음과 같습니다.

1. 최대 삽입 속도의 경우 스키마를 열 제약 조건과 함께 사용하지 마십시오. (필요에 따라 나중에 변경 테이블 ALTER TABLE에서는 제약 조건을 추가할 수 없습니다.
2. 스키마를 최적화하여 필요한 것을 저장합니다.때로는 데이터베이스에 삽입하기 전에 테이블을 분해하거나 데이터를 압축/변환하는 경우도 있습니다.IP 주소를 (긴) 정수로 저장하는 것이 좋은 예입니다.
3. db 파일당 하나의 테이블 - 잠금 경합을 최소화합니다.(단일 연결 개체를 사용하려면 ATTACH DATABY를 사용합니다.
4. SQLite는 서로 다른 유형의 데이터를 동일한 열에 저장할 수 있으므로(동적 유형), 이를 활용할 수 있습니다.

질문/댓글 환영합니다. ;-)

저는 7GB SQLite 데이터베이스를 가지고 있습니다.내부 조인으로 특정 쿼리를 수행하려면 2.6초가 소요됩니다. 이를 가속화하기 위해 인덱스 추가를 시도했습니다.어떤 인덱스를 추가했느냐에 따라 쿼리가 0.1초로 내려가는 경우도 있고 7초로 올라가는 경우도 있었습니다.제 경우 문제는 열이 매우 중복되면 인덱스를 추가하면 성능이 저하된다는 것이었습니다. :(

SQLite 설명서에는 데이터베이스 파일의 실제 크기 제한이 수십 GB:s라는 문구가 있었습니다.이는 트랜잭션을 시작할 때마다 SQLite가 "더러운 페이지 비트맵을 할당"해야 했기 때문입니다.따라서 데이터베이스의 각 MB에 대해 256바이트의 RAM이 필요했습니다.50GB DB-파일에 삽입하려면 대용량(2^8)*(2^10)=2^18=256MB의 RAM이 필요합니다.

그러나 최근 버전의 SQLite에서는 이 기능이 더 이상 필요하지 않습니다.여기서 더 읽어보세요.

sqlite 스케일링에 대한 주된 불만 사항은 다음과 같습니다.

1. 단일 프로세스 쓰기.
2. 미러링 금지.
3. 복제 금지.

vacuum 명령어를 사용할 때 큰 sqlite 파일에 문제가 생긴 적이 있습니다.

저는 아직 auto_vacuum 기능을 사용해보지 않았습니다.데이터를 자주 업데이트하고 삭제할 것으로 예상되는 경우 이를 살펴볼 가치가 있습니다.

언급URL : https://stackoverflow.com/questions/784173/what-are-the-performance-characteristics-of-sqlite-with-very-large-database-file