2012-02-23 3 views
1

여기에 새 프로젝트를 시작하면 많은 양의 사용자 데이터를 저장하게 될 것입니다. 나는 처음부터 확장 가능한 시스템을 만들기 위해 각 사용자의 데이터 (본질적으로 그들이 저장 한 파일 목록)를 별도의 SQLite 데이터베이스에 저장하는 새로운 아이디어를 고려하고있다. 사용자 ID를 가진 MySQL의 거대한 테이블. 파일 목록에는 파일과 관련된 다른 메타 데이터가 저장되므로 파일 시스템을 사용하는 것만으로는 옵션이 아닙니다.MySQL에 비해 사용자 당 개별 SQLite 데이터베이스?

사용자가 로그인하여 파일을 볼 때 MySQL이 "파일"테이블의 모든 레코드를 하나씩 꺼내기보다는 모든 SQLite 데이터베이스에 모든 데이터를 표시하는 것이 더 빠를 것이라고 생각했습니다. ID로 사용자의 파일. 각 사용자는 쉽게 10,000 이상의 항목을 가지며 처음에는 최소 400 명의 사용자가 있습니다. 그래서 10,000 개의 행을 가진 400 개의 개별 SQLite 데이터베이스 또는 400 만 개의 단일 MySQL 테이블? 400 명의 사용자가 거의 동시에 로그인하는 경우는 거의 없으며 데이터베이스가 색인 된 경우에도 데이터베이스에없는 사용자의 데이터를 처리해야하는 것은 비효율적 인 것처럼 보입니다.

SQLite의 최대 제한은 잠금이지만 운좋게도이 경우에는 데이터베이스에 쓰는 단일 프로세스 만 있으므로 여기서 문제가되어서는 안됩니다. 개별적인 SQLite 데이터베이스를 백업하는 추가 된 관리는 모두 증분 파일 시스템 백업의 일부가 될 것이기 때문에 사소한 것입니다.

생각하십니까? 의견? 이 생각을 끝내고 있습니까?

+0

데이터베이스에 쓰는 단일 프로세스가 있는지 어떻게 확인합니까? 사용자가 두 개의 탭을 열었 으면 어떻게 될까요? – miki

+0

miki, SQLite에서 처리 할 수 ​​있습니다. –

+0

안녕하세요 Miki - 사용자가 인터페이스를 통해 파일을 추가하거나 수정할 수 없습니다. 파일은 외부 소스의 사용자에게 "푸시 (push)"되며 그 모든 것은 단일 야간 프로세스로 수행됩니다. –

답변

2

사용자가 로그인하여 파일을 볼 때 MySQL이 "파일"테이블의 모든 레코드를 가져 오지 않고 단일 SQLite 데이터베이스에 모든 데이터를 표시하는 것이 더 빠를 것이라고 생각했습니다 ID로 한 사용자의 파일을 내보내십시오.

아니요, MySQL 데이터베이스를 적절하게 색인화하면 안됩니다. 4 백만 건의 레코드가 올바르게 설정되어 있다면 문제가 발생하지 않아야합니다.

+0

MySQL은 4 백만 건의 레코드를 처리 할 수 ​​있다고 확신합니다. SQLite 옵션 대 서버 리소스가 얼마나 많은지 궁금합니다. 그것을 측정하는 쉬운 방법은 없습니다. 나는 이미 10,000,000 개의 시뮬레이션 된 레코드를 가진 MySQL 데이터베이스를 만들었지 만 적절한 수의 SQLite 데이터베이스를 만들었고 상당히 어려웠습니다 (아직 노력할만한 가치가 있는지 확신 할 수 없습니다). –

+1

한 가지 고려해야 할 것은 SQLite 데이터베이스를 수백, 수천 또는 그 이상의 SQLite 데이터베이스로 분할하는 것이 유지 관리 측면에서 엄청난 고통이 될 것이라는 것입니다. 스키마를 변경해야하는 경우 어떻게해야합니까? 모든 사용자의 파일 수에 대한 통계를 가져 오려면 어떻게해야합니까? – ceejayoz

1

최근 데이터베이스와 테이블이 이미 열려있는 단일 서버 인스턴스를 쿼리하는 것 (MySQL)과 비교할 때 수천 개의 데이터베이스 파일 (SQLite)을 열고 닫는 것이 훨씬 더 비쌉니다.

사용자가 400 명이 아닙니다. 이러한 수준에서 성능 문제는 전혀 볼 수 없습니다.

+0

감사합니다. Emil, 고맙습니다. 그것은 나의 초기 생각 이었지만 다른 의견을 내기 위해 항상 돈을 지불합니다! –

0

나는 이것이 전혀 비례하지 않을 것이라고 생각합니다. 현재 서버보다 앞서서 두 번째 데이터베이스 서버를 가져 오려고한다고 가정 해 봅시다. 어떤 사용자 ID가 있습니까? MySQL의 마스터/슬레이브 복제는 당신이 그 문제에 대해 걱정할 필요가 없다는 것을 의미합니다.

나는 또한 당신이 이것을 실행하고있는 OS가 모든 파일들을 최적화 된 방식으로 유지하는데 어려움을 겪을 것이라고 생각한다. MySQL을 사용하면 단편화 및 기타 등등을 처리하면서 테이블을 쉽게 최적화 할 수 있습니다. SQLite를 사용한다면, MySQL이 테이블의 해당 부분을 찾고있는 것보다 더 많은 리소스를 사용하여 파일 메모리를 찾고로드 할 수 있습니다.

재미있는 생각의 실험이지만, 나는 그것이 당신이 찾고있는 것을 할 것이라고 생각하지 않습니다. 확장 성 있고 빠른 것을 정말로 만들고 싶다면, MongoDB : http://www.mongodb.org/을보십시오. 빠르고 유연하며 잘 비례합니다. 또한 파일 목록을 유지하고 업로드 한 사용자를 검색 할 수 있습니다. 예를 들어 이전에 보지 못한 파일 만 저장하는 것처럼 Dropbox를 사용하려는 경우 유용 할 수 있습니다.

2

저는 제가 만든 앱으로이 일을 아주 잘하고 있습니다. 각 사용자는 자신의 SQLite 데이터베이스를 가지고 있습니다.내가 Dropbox를 통해 데이터를 백업하고 iOS 앱의 일치하는 SQLite 데이터베이스 (Dropbox를 통해)에 동기화 할 수 있도록 허용하기 때문에이 이유가 있습니다.

장점은 :
- 사용자 데이터를 격리하고, 지원을하고 한 번에 하나의 데이터베이스를보고 쉽게된다.
- 언제든지 데이터를 Dropbox로 보낼 준비가되었습니다. 쉽게 휴대 할 수 있습니다.

단점 :
은 - 언급 한 바와 같이, 스키마 변경은 고통입니다. 각 SQLite db에 "version"이라는 테이블을 유지하고 스키마가 어떤 버전인지 나타내는 버전 번호를 추적해야합니다. 스키마 변경에는 끔찍한 변경 쿼리를 작성하고 내 서버에 저장된 모든 데이터베이스 파일을 반복하는 작업이 포함됩니다.
- 서버가 많은 별도의 데이터베이스를 열 때 더 많은 부하를 부담 할 가능성이 있습니다. 색인화 된 MySQL 데이터베이스가 더 빠를 것이라고 생각합니다.

전반적으로 작동하지만 스키마 변경으로 인해 모든 데이터를 단일 MySQL 데이터베이스로 통합하려고합니다.

행운을 빈다.

관련 문제