트래픽이 적은 사이트의 생산 데이터베이스로서의 SQLITE?

https://stackoverflow.com/questions/913067

06-09-2019
|

문제

나는 20 명의 동시 사용자를받을 수있는 사이트의 SQLITE를 제작 데이터베이스로 사용하는 것을 고려하고 있지만, 그 중 많은 배수 일 수있는 피크의 잠재력을 가지고 있습니다 (사이트는 열린 인터넷에서 액세스 할 수 있고 항상 존재하기 때문입니다. 누군가가 많은 사람들을 한 번에 사이트로 이끌 수있는 링크를 게시 할 가능성).

sqlite는 가능성이 있습니까?

이상적인 제작 시나리오가 아니라는 것을 알고 있습니다. 나는 이것이 현실적인 가능성의 영역 내에 있는지 묻습니다.

해결책

SQLITE는 모든 종류의 동시성을 지원하지 않으므로 프로덕션 웹 사이트에서 실행하는 데 문제가있을 수 있습니다. '더 가벼운'데이터베이스를 찾고 있다면 CouchDB와 같은 현대적인 개체 문서 상점을 시도하는 것이 좋습니다.

반드시 SQLITE에 대해 계속 발전하면 처음에 사용하는 것이 좋습니다. 애플리케이션에 더 많은 사용자가 트랙을 따라 가면 Postgres 또는 MySQL로 전환하려고합니다.

SQLITE의 저자는 이것을 다룹니다 웹 사이트상에서:

SQLITE는 대부분의 저급 트래픽 웹 사이트 (대부분의 웹 사이트)의 데이터베이스 엔진으로 훌륭하게 작동합니다. SQLITE가 처리 할 수있는 웹 트래픽의 양은 웹 사이트가 데이터베이스를 얼마나 많이 사용하는지에 따라 다릅니다. 일반적으로, 100k 미만의 적중을 얻는 모든 사이트는 SQLITE에서 잘 작동해야합니다. 100K 히트/데이 그림은 단단한 상한이 아닌 보수적 인 추정치입니다. SQLITE는 트래픽의 10 배로 작동하는 것으로 입증되었습니다.

sqlite 웹 사이트 (https://www.sqlite.org/)는 물론 SQLITE 자체를 사용 하고이 글을 쓰는 시점에서 하루에 약 400K ~ 500K HTTP 요청을 처리하며 그 중 약 15-20%는 데이터베이스를 터치하는 동적 페이지입니다. 동적 컨텐츠는 웹 페이지 당 약 200 개의 SQL 문을 사용합니다. 이 설정은 단일 VM에서 실행되는 물리적 서버를 23 개와 공유하지만 여전히 부하 평균을 0.1 미만으로 유지합니다.

그래서 나는 길고 부족하다고 생각합니다. 가서 가십시오. 그것이 당신에게 잘 작동하지 않으면 엔터프라이즈 급 데이터베이스로의 전환은 어쨌든 상당히 사소합니다. 그러나 스키마를 처리하고 성장과 효율성을 염두에두고 데이터베이스를 설계하십시오.

여기에 있습니다 실 프로덕션 웹 애플리케이션에 SQLITE를 사용하는 것에 대한 독립적 인 의견이 있습니다. 혼합 된 결과와 함께 사용 된 것 같습니다.

편집 (2014):

이 답변이 게시되었으므로 SQLITE는 이제 다중 스레드 모드 그리고 미리 로깅 모드를 작성하십시오 이는 저조도 트래픽 사이트에 대한 적합성에 대한 평가에 영향을 줄 수 있습니다.

Charles Leifer가 글을 썼습니다 블로그 게시물 SQLITE의 WAL (Write Af

다른 팁

sqlite에서 작은 발췌 웹 사이트 모든 것을 말합니다.

입니다 데이터가 분리되었습니다 네트워크의 응용 프로그램에서? → 선택하십시오 클라이언트 서버

많은 병발 사정 작가? → 선택하십시오 클라이언트 서버

빅 데이터? → 클라이언트/서버를 선택합니다

그렇지 않으면 → 선택하십시오 sqlite!

sqlite "그냥 작동"(물론 그렇지 않을 때까지)

우리는 종종 내부 데이터베이스에 sqlite를 사용합니다. 직원 디렉토리, 이벤트 캘린더 및 기타 인트라넷 서비스는 모두 가벼운 데이터베이스에서 실행됩니다. MySQL과 같은 "실제"데이터베이스에서 수행하는 규모로 이러한 앱을 실행하는 것이 큰 과잉입니다. 이는 단일 미드 레인지 컴퓨터에서 4 개의 다른 가상 머신을 따라 실행 중이라는 점을 고려할 때 특히 그렇습니다.

어느 시점에서 우리는 단일 재부팅이 필요한 단일 재부팅만으로 몇 달 동안 SQLITE DB를 실행하는 바깥 쪽 면도 사이트를 가졌습니다. 분명히, 그것은 트래픽이 매우 낮았지만, 그것이 한 일에 대해 잘 어울 렸습니다.

우리는 환경에서 비슷한 옵션을 만났습니다. 절대적으로 글이 없습니다, 그리고 우리는 sqlite를 사용하여 선택했습니다.

내 참조 블로그 게시물 주제 :

글쎄,이 솔루션이 이론적으로 가능하게 만드는 주요 가정은 SQLite 데이터베이스가 완전히 읽기 전용이라는 것입니다. 우리의 서버 코드는 절대 변경해서는 안됩니다. 읽기 잠금 장치가 없기 때문에 잠금 문제가 해결됩니다. 우리는 인터넷에서 아무데도 찾을 수 없었습니다. 누구에게도 글이 없을 때 SQLITE를 읽는 데 문제가 있다고 말할 수 없습니다. 가능할 수 있습니다!

나는 그것이 당신의 읽기/쓰기 비율이 무엇인지에 달려 있다고 생각합니다. 데이터베이스에서 대부분 읽는 경우 괜찮을 수도 있습니다. SQLITE에 다중 사용자를 쓰는 것은 데이터베이스를 잠그는 방법 때문에 문제가 될 수 있습니다.

사람들은 동시성 문제에 대해 이야기하지만 SQLITE는 들어오는 요청을 캐시하고 얼마 동안 기다리게합니다. 즉시 타임 아웃이 아닙니다.

기본 타임 아웃 설정에 대한 내용을 읽었습니다. 사람들 이이 설정을 조정하지 않았을까요?

사이트 사용에 따라 다릅니다. 대부분의 시간에 데이터를 읽는 경우 DB에 무엇이든 사용하고 응용 프로그램의 데이터를 캐시하여 우수한 성능을 달성 할 수 있습니다.

매우 낮은 트래픽 웹 서버 (게놈 데이터베이스)에서 사용하고 있으며 문제가 없습니다. 그러나 선택된 진술 만 있습니다. DB에 대한 글은 없습니다.

이미 훌륭한 답변에 추가하려면 :이 경우 서버가없는 솔루션으로 작업하고 있기 때문에 복제 또는 DB의 수평 스케일링 및 기타 고급 옵션에 작별 인사를 할 수 있습니다. 여러 사용자가 동일한 정확한 정보를 업데이트하는 경우에도 최선의 선택이 아닙니다. 미래에 데이터베이스를 샤워해야한다면 데이터를 마이그레이션하고 다른 것으로 이동해야합니다. 또한로드 밸런서와 여러 시스템이 관련된 경우 SQLITE를 사용하는 경우 데이터 중심성을 유지하기가 어려울 것입니다. 이것이 권장되지 않는 이유 중 일부일뿐입니다. 소규모 프로젝트에 적합하며 개발에 좋습니다.

대기열이 SQLITE의 많은 동시성 쓰기 문제를 피하면서 도망 칠 수있는 것 같습니다. sqlite db에 직접 쓰는 대신 큐에 쓸 것입니다. 그런 다음 첫 번째 첫 번째 아웃 모드에서 SQLITE DB에 순차적으로 쓸 것입니다. 응용 프로그램이 작성할 가치가 있거나 클라이언트/서버 DB로 넘어갈 가치가있는 경우 응용 프로그램이 필요한 위치에 도달하는지 확실하지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow