나는 최근 SQLite vs MySQL 에 대한이 질문을 읽었 으며 SQLite가 제대로 확장되지 않고 공식 웹 사이트 가 이것을 확인 한다고 지적했습니다 .
SQLite는 얼마나 확장 가능하며 최대 한계는 무엇입니까?
나는 최근 SQLite vs MySQL 에 대한이 질문을 읽었 으며 SQLite가 제대로 확장되지 않고 공식 웹 사이트 가 이것을 확인 한다고 지적했습니다 .
SQLite는 얼마나 확장 가능하며 최대 한계는 무엇입니까?
답변:
어제 작은 사이트를 공개했습니다 *모든 방문자에 대해 공유 SQLite 데이터베이스를 사용한 담당자를 추적합니다. 불행히도, 호스트에 가해지는 작은 부하에도 불구하고 꽤 느리게 달렸습니다. 업데이트 / 삽입이 포함되어 있기 때문에 누군가가 페이지를 볼 때마다 전체 데이터베이스가 잠겨 있기 때문입니다. 곧 MySQL로 전환했으며 테스트 할 시간이 없었지만 SQLite보다 훨씬 확장 가능한 것으로 보입니다. sqlite의 쉘에서 쿼리를 실행하려고 할 때 느린 페이지로드와 때로는 데이터베이스 잠금 오류가 발생한다는 것을 기억합니다. 즉, SQLite에서 다른 사이트를 제대로 실행하고 있습니다. 차이점은 사이트가 정적이므로 (즉, 데이터베이스를 변경할 수있는 유일한 사이트이므로) 동시 읽기에 적합합니다. 이야기의 교훈:
편집 : 나는 방금 SQLite에 공평하지 않을 수도 있다는 것을 깨달았습니다. 웹 페이지에서 SQLite 데이터베이스를 제공 할 때 SQLite 데이터베이스의 열을 색인화하지 않았습니다. 이로 인해 부분적으로 느려졌습니다. 그러나 데이터베이스 잠금에 대한 관찰은 특히 귀찮은 업데이트가있는 경우 SQLite 성능은 MySQL 또는 Postgres와 일치하지 않습니다.
또 다른 편집 : 거의 3 개월 전에 게시 한 이후 SQLite의 확장 성을 면밀히 검토 할 수있는 기회가 있었고 몇 가지 트릭으로 상당히 확장 가능할 수 있습니다. 첫 번째 편집에서 언급했듯이 데이터베이스 인덱스는 쿼리 시간을 획기적으로 단축하지만 SQLite에 대한 것보다 데이터베이스에 대한 일반적인 관찰입니다. 그러나 SQLite 속도를 높이기 위해 사용할 수있는 또 다른 트릭이 있습니다 : transaction . 여러 개의 데이터베이스 쓰기를 수행해야 할 때마다 트랜잭션 안에 두십시오. 쓰기 쿼리가 실행될 때마다 파일에 쓰거나 파일을 잠그는 대신 트랜잭션이 완료되면 쓰기가 한 번만 발생합니다.
첫 번째 단락에서 발표 한 사이트는 SQLite로 다시 전환되었으며 코드를 몇 군데 조정하면 원활하게 실행됩니다.
* 사이트는 더 이상 사용할 수 없습니다
Sqlite는 단일 사용자 측면에서 확장 가능하며 성능이 뛰어난 멀티 기가 바이트 데이터베이스가 있으며 그다지 큰 문제가 없었습니다.
그러나 그것은 이다 그것은 종류의 확장 당신이 무슨 말을하는지에 달려 있으므로, 단일 사용자.
의견에 대한 답변. 다중 사용자 환경에서 Sqlite 데이터베이스를 사용하지 못하게하는 것은 없지만 모든 트랜잭션 (실제로 데이터베이스를 수정하는 모든 SQL 문)은 파일을 잠그므로 다른 사용자가 데이터베이스 에 액세스 할 수 없습니다. 모두 .
따라서 데이터베이스를 많이 수정하면 스케일링 문제가 매우 빠르게 발생합니다. 반면에 쓰기 액세스에 비해 많은 읽기 액세스가있는 경우 그리 나쁘지 않을 수 있습니다.
하지만 SQLite는 코스의 것이다 기능 다중 사용자 환경에서,하지만하지 않습니다 수행 아니라.
SQLite는 sqlite.org 웹 사이트 및 많은 트래픽이있는 사이트를 구동합니다. 그들은 당신이 하루에 100k 미만의 적중을 가졌다 면 SQLite가 잘 작동 할 것을 제안 합니다. 그리고 "Writeahead Logging"기능을 제공하기 전에 작성되었습니다.
SQLite로 작업 속도를 높이려면 다음을 수행하십시오.
미리 쓰기 로깅을 사용하는 방법과 쓰기 속도가 5 배 향상된 방법을 보여주는 " Writeahead Logging으로 SQLite 성능 향상 "이라는 YouTube 비디오를 살펴볼 수 있습니다 .
Sqlite는 데스크톱 또는 In-process 데이터베이스입니다. SQL Server, MySQL, Oracle 및 그 형제는 서버 입니다.
데스크톱 데이터베이스는 그 성격하지 않는 좋은 선택으로되어 있는 요구 사항은 데이터 저장소에 대한 동시 쓰기 액세스를 지원하는 것을 응용 프로그램입니다. 여기에는 일정 수준의 웹 사이트가 포함됩니다. 로그인을해야 할 경우 DB에 대한 쓰기 권한이 필요할 수 있습니다.
이 SQLite 문서 ( http://www.sqlite.org/whentouse.html) 를 읽었 습니까?
SQLite는 일반적으로 트래픽이 적거나 중간 정도 인 웹 사이트 (즉, 모든 웹 사이트의 99.9 %)에 대한 데이터베이스 엔진으로 작동합니다. SQLite가 처리 할 수있는 웹 트래픽의 양은 물론 웹 사이트가 데이터베이스를 얼마나 많이 사용하는지에 달려 있습니다. 일반적으로 하루에 조회수가 10 만 회 미만인 사이트는 SQLite에서 제대로 작동합니다. 100K 조회수 / 일 수치는 상한이 아니라 보수적 인 추정치입니다. SQLite는 트래픽 양의 10 배에 해당하는 것으로 나타났습니다.
SQLite 확장 성은 사용 된 데이터와 형식에 따라 크게 달라집니다. 여분의 긴 테이블 (GPS 레코드, 초당 하나의 레코드)에 대해 힘든 경험을했습니다. 경험 SQLite는이 부분적으로 인덱스를 잡고 성장 이진 트리의 일정 재조정에, 단계 둔화 할 것으로 나타났다 (및 타임 스탬프 인덱스, 당신은 알고 그 나무가 많이 재조정받을 것입니다, 그러나 그것은에 매우 중요하여 검색). 결국 약 1GB (매우 야구장), 쿼리가 느리게 진행됩니다. 마일리지가 다를 수 있습니다.
기억해야 할 것은 SQLite는 모든 데이터에도 불구하고 데이터웨어 하우징을 위해 만들어진 것이 아닙니다. SQLite에 권장되지 않는 다양한 용도가 있습니다 . SQLite의 훌륭한 사람들은 스스로 말합니다.
SQLite를 보는 또 다른 방법은 다음과 같습니다. SQLite는 Oracle을 대체하도록 설계되지 않았습니다. fopen ()을 대체하도록 설계되었습니다.
그리고 이것은 주요 논쟁 (정량적이지 않고, 미안하지만 정 성적)으로 이끄는 반면, SQLite는 모든 용도로 사용되는 것은 아니지만 MySQL은 이상적으로는 아니지만 다양한 용도로 사용될 수 있습니다. 예를 들어, SQLite 대신 MySQL에 Firefox 쿠키를 저장하도록 할 수 있지만 항상 해당 서비스를 실행해야합니다. 반면에 MySQL 대신 SQLite에서 많은 웹 사이트를 실행하는 트랜잭션 웹 사이트를 만들 수 있지만 많은 다운 타임이 예상됩니다.
ATTACH DATABASE모든 테이블과의 가상 데이터베이스 연결을 만드는 데 사용할 수 있습니다 (그러나 데이터베이스는 62 개로 제한됨).
이런 식으로 생각하십시오. 누군가가 사용할 때마다 SQL Lite가 잠 깁니다 (SQLite는 읽기시 잠기지 않습니다). 따라서 여러 동시 사용자가있는 웹 페이지 또는 애플리케이션을 제공하는 경우 한 번에 한 명의 사용자 만 SQLLite를 사용하여 앱을 사용할 수 있습니다. 스케일링 문제가 있습니다. 한 사람의 응용 프로그램이 수백 개의 타이틀, 등급, 정보, 사용법, 재생, 재생 시간을 보유한 음악 라이브러리를 말하는 경우 SQL Lite는 수백만 개의 레코드가 아닌 수천 개의 레코드를 보유하고 있습니다 (하드 드라이브 기꺼이)
반면에 MySQL은 모든 사람들이 동시에 사용하는 서버 앱에 적합합니다. 잠겨 있지 않으며 크기가 상당히 큽니다. 따라서 음악 라이브러리의 경우 MySql은 한 사람 만 볼 수있는 것처럼 죽일 수 있습니다. 단,이 라이브러리는 수천명이 추가하거나 업데이트하는 공유 음악 라이브러리입니다. 그런 다음 MYSQL이 사용됩니다.
따라서 이론적으로 MySQL은 Sqllite보다 확장 성이 뛰어나므로 여러 사용자를 처리 할 수 있지만 단일 사용자 앱에는 과잉입니다.
SQLite에 구축 된 데이터베이스 서버 인 REAL SQL Server를 확인 하는 것이 좋습니다.