SQLite 데이터베이스에서 동시 쓰기가 허용되지 않는 이유는 무엇입니까?


79

SQLite에서 Java를 사용하여 데이터베이스 프로그래밍을하고 있습니다.

데이터베이스에 한 번에 하나의 연결에만 쓰기 기능이 있고 한 번에 많은 연결에 읽기 기능이 있다는 것을 알았습니다.

SQLite 아키텍처가 왜 이렇게 설계 되었습니까? 작성중인 두 가지가 데이터베이스의 동일한 위치에 작성되지 않는 한, 왜 두 번의 쓰기가 불가능합니까?



5
SQLite는 "lite"로 설계 되었기 때문입니다. 적은 메모리와 낮은 처리 성능. SQLite가 동일한 파일에 대한 여러 쓰기를 처리하는 방법을 생각해보십시오. 현재 디자인은 구현하기 쉽습니다. 전체 파일이 잠겨 있고 다른 사람들은 기다려야합니다. 보다 세분화 된 수준에서 쓰기 동시성을 처리하려면 RDMS에서 얻을 수있는 행 / 페이지 잠금이 필요합니다. 요구 사항에 쓰기 동시성이 필요하면 SQLite가 후보가 아니며 대신 가벼운 RDBMS를 찾아보십시오. en.wikipedia.org/wiki/…
Thomas Carlisle

답변:


157

"다중 동시 쓰기"는 단일 데이터베이스 작성기보다 핵심 데이터베이스 엔진에서 수행하기가 훨씬 어렵습니다. 그것은 SQLite의 디자인 매개 변수를 넘어서며, 포함하면 SQLite의 유쾌한 작은 크기와 단순성을 파괴 할 수 있습니다.

높은 수준의 쓰기 동시성 지원은 DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL 및 Sybase와 같은 대규모 데이터베이스 엔진의 특징입니다. 그러나 기술적으로 달성하기는 어렵 기 때문에 데이터베이스, 테이블 및 행 잠금 또는보다 현대적인 구현에서는 다중 버전 동시성 제어 와 같은 광범위한 동시성 제어 및 최적화 전략이 필요 합니다 . 이 문제 / 요구 사항에 대한 연구는 방대하며 수십 년 전으로 거슬러 올라갑니다 .

SQLite는 여러 작성자를 지원하는 대부분의 서버 중심 DBMS와 디자인 철학이 다릅니다. SQL의 강력한 기능과 관계형 모델을 개별 응용 프로그램에 제공하고 실제로 각 응용 프로그램에 포함 할 수 있도록 설계되었습니다. 그 목표는 상당한 절충이 필요합니다. 여러 동시 작성기를 처리하는 데 필요한 상당한 인프라와 오버 헤드를 추가하지 않는 것도 그 중 하나입니다.

이 철학은 SQLite의 적절한 사용 페이지 에 대한 설명으로 요약 할 수 있습니다 .

SQLite는 클라이언트 / 서버 데이터베이스와 경쟁하지 않습니다. SQLite는 fopen ()과 경쟁합니다.


41
+1. SQLite는 In-process 데이터베이스입니다. 서버 기반 DB에있는 것처럼 중앙 중재자가 없습니다. 작가들은 서로 직접 협력하고 신뢰해야합니다. 한 명의 악의적 인 작가가 협조하지 않으면 혼란에 빠질 수 있습니다.
Jörg W Mittag

12
또한 SQLite가 실행되는 일부 환경은 여러 프로세스를 지원하지 않을 수도 있습니다.
david25272

1
아마도 악의적 인 글은 이미 협조하지 않으면 혼란에 빠질 수 있습니다. 그들은 SQLite 코드를 사용하여 그것을 할 수는 없지만, unlink ()를 호출 할 수있는 자체 코드를 가질 수 있습니다.
bdsl

12
동시 앱에는 중간 정도가 많지 않습니다. 까다로운 조건 및 엣지 사례를 포함하여 본질적으로 100 %의 동시성, 일관성 및 데이터 무결성을 얻거나 그렇지 않습니다. 그렇지 않으면 깨지기 쉽고 느리고 충돌하기 쉬우 며 사람들은 매우 빨리 신뢰하지 않습니다. 그러나 일상적으로 올바르게하는 것은 끝이 어렵다. 핵심 지원의 부족없이 작가가 스스로 인터리브 된 글을 조정할 수있는 환경은 많지 않습니다.
Jonathan Eunice

8
@bdsl 모든 종류의 데이터베이스는 작성자 제대로 작동하지 않으므로 데이터를 잃지 않는다고 가정 해야합니다. 저자는 SQLite를 경쟁 업체로 선정 fopen()하므로 일반 텍스트 파일에 동시 쓰기 작업과 함께 제공되는 모든 털이 문제를 고려하십시오.
Blrfl

12

물건을 같은 장소에 쓸 것인지 말을 할 수있는 서버가 없기 때문입니다. 파일에 쓰려고하는 프로세스는 두 가지뿐입니다.

주석에서 지적한 바와 같이, 내부 쓰레드가 동시 쓰기를 지원할 수도 있습니다. 이것이 얼마나 잘 작동하는지 확실하지 않습니다 (그에 대해 많이 생각하지 않았 음). 어쨌든 SQLite가 스레드를 사용하지 않는 이유는 다음과 같습니다. Dr Hipp는 스레드가 악하다고 생각합니다.

DR Hipp이 스레드가 악하다고 생각한다는 사실은 SQLite FAQ에 문서화되어 있습니다.


2
이것은 동시 쓰기가 허용되지 않는 기술적 인 이유를 설명하지만 디자인 결정이 내려진 이유는 설명하지 않습니다.
Robert Harvey

3
한 번에 하나의 쓰기 만 처리하도록 SQLite를 설계하기로 한 결정.
Robert Harvey

7
@Goyo 서버는 동시 쓰기를 처리 할 필요가 없습니다. 데이터베이스 서버가 별도의 프로세스이므로 SQLite 내부에 동일한 목적을 수행하는 별도의 스레드가있을 수 있습니다. Robert Harvey는 맞습니다. SQLite 팀은 설계 결정을 내 렸으며 단일 라이브러리가 동시 쓰기를 처리하는 능력과는 아무런 관련이 없습니다 (이론적으로는 가능하기 때문).

1
이 대답은 나에게 잘 보인다. 동시 쓰기를 처리하려면 서버 또는 다중 스레드 sqlite 구현이 필요합니다. 두 가지 모두 다른 디자인 결정에 의해 배제되었으므로 동시 쓰기를 구현하는 것은 매우 어려울 것입니다.
jpa

5
@jpa : SQLite는 이미 "서버"없이 여러 프로세스 / 스레드간에 잠금을 동기화하도록 관리합니다. OS가 제공하는 잠금 / 동기화 / IPC / 충분한 것을 사용하는 "서버"는 필요하지 않지만 실제로는 매우 복잡합니다. 게시물에 언급 된 "내부 스레드"는 의미가 없습니다.
Mat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.