Extreme Sharding : 사용자 당 하나의 SQLITE 데이터베이스
https://stackoverflow.com/questions/128919
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
저는 이메일 서비스와 소셜 네트워크 사이에있는 웹 앱에서 작업하고 있습니다. 나는 그것이 미래에 정말로 커질 수있는 잠재력을 가지고 있다고 생각하기 때문에 확장성에 대해 걱정하고 있습니다.
하나의 중앙 집중식 MySQL/innoDB 데이터베이스를 사용한 다음 해당 시간이 오면 분할하는 대신 각 활성 사용자에 대해 별도의 SQLITE 데이터베이스를 작성하기로 결정했습니다.
그렇게하면 데이터베이스를 백업하는 것이 각 사용자의 복사만큼 쉽습니다. 작은 데이터베이스 파일은 하루에 한 번 원격 위치로 파일입니다.
새로운 파일을 저장하기 위해 하드 디스크를 추가하는 것만 큼 스케일링이 쉽습니다.
앱이 단일 서버를 넘어서 자라면 Glusterfs를 사용하여 파일 시스템 수준에서 서버를 연결하고 앱을 변경하지 않은 앱을 실행하거나 간단한 SQLITE 프록시 시스템을 조작하여 각 서버가 인접한 서버에서 SQLITE 파일을 조작 할 수 있도록하는 간단한 SQLITE 프록시 시스템을 조작 할 수 있습니다.
각 HTTP 요청은 한 번에 하나 또는 두 개의 데이터베이스 파일 만 터치하고 SQLITE는 어쨌든 읽기에만 블록을 차단하기 때문에 동시성 문제가 최소화됩니다.
이 접근 방식이 내 앱이 우아하게 확장하고 시원하게 많은 것을 지원할 수 있다고 내기하고 있습니다. 독특한 특징. 내가 틀린 내기? 내가 놓친거야?
업데이트 나는 지금까지 잘 작동하는 덜 극단적 인 솔루션으로 가기로 결정했습니다. 정확하게 고정 된 수의 파편 -256 SQLITE 데이터베이스를 사용하고 있습니다. 각 사용자는 간단한 해시 함수에 의해 임의의 샤드에 할당되어 묶여 있습니다.
내 앱의 대부분의 기능은 요청 당 하나 또는 두 개의 파편에 대한 액세스가 필요하지만 특히 사용자에 따라 256 개 중 10 ~ 100 개의 다른 파편에서 간단한 쿼리를 실행 해야하는 하나가 있습니다. 테스트에 따르면 모든 데이터가 RAM으로 캐시되면 약 0.02 초 이하가됩니다. 나는 그것과 함께 살 수 있다고 생각합니다!
업데이트 2.0 앱을 MySQL/InnoDB에 포팅했으며 정기적 인 요청에 대해 동일한 성능을 얻을 수 있었지만 Shard Walking이 필요한 요청에 대해 InnoDB는 4-5 배 더 빠릅니다. 이런 이유로, 다른 이유로, 나는이 아키텍처를 떨어 뜨리고 있지만, 누군가가 그것을 사용하기를 바랍니다. 감사합니다. 감사합니다.
해결책
이것이 실패 할 곳은 당신이 "Shard Walking"이라고 불리는 일을해야한다면 많은 다른 사용자들의 모든 데이터를 찾는 것입니다. 이러한 특정 종류의 "쿼리"는 프로그래밍 방식으로 수행되어 각 SQLITE 데이터베이스를 차례로 요청해야하며 사이트의 가장 느린 측면 일 것입니다. 데이터가 별도의 데이터베이스로 "샤드"된 모든 시스템에서 일반적인 문제입니다.
모든 데이터가 사용자에게 독립적 인 경우, 이는 효과적인 디자인을 만드는 열쇠는 데이터가 어떻게 사용될 가능성이있는 방법과 한 사람의 데이터가 상호 작용하는지 아는 것입니다. 다른 사람의 데이터 (컨텍스트에서).
파일 시스템 리소스를 조심해야 할 수도 있습니다. SQLITE는 훌륭하고 훌륭하며 빠르며 빠르지 만 "표준 데이터베이스"(예 : MySQL, PostgreSQL 등)를 사용할 때는 캐싱 및 쓰기 혜택을 얻을 수 있습니다. '다시 설계. 제안 된 디자인에서는 그 중 일부를 놓치게됩니다.
다른 팁
유지 보수 악몽처럼 들립니다. 스키마가 모든 DBS에서 변경되면 어떻게됩니까?
한 가지 가능한 문제는 각 사용자마다 하나의 데이터베이스가 디스크 공간을 사용하고 RAM을 매우 비효율적으로 사용하고 사용자 기반이 증가함에 따라 가볍고 빠른 데이터베이스 엔진을 사용하는 이점이 완전히 손실된다는 것입니다.
이 문제에 대한 가능한 해결책은 만들어내는 것입니다.미니 시드"아마도 1024 sqlite 데이터베이스로 구성된 각각 100 명의 사용자. 데이터가보다 효율적으로 포장되기 때문에 사용자 접근 방식 당 DB보다 효율적입니다. SQLITE를 사용하고 있기 때문에 InnoDB 데이터베이스 서버 접근 방식보다 가볍습니다.
동시성도 꽤 좋지만 쿼리는 덜 우아합니다 (shard_id yuckiness). 어떻게 생각해?
http://freshmeat.net/projects/sphivedb
SPHIVEDB는 SQLITE 데이터베이스의 서버입니다. JSON-RPC를 사용하여 HTTP를 사용하여 SQLITE 데이터베이스를 사용하기위한 네트워크 인터페이스를 노출시킵니다. 여러 sqlite 데이터베이스를 하나의 파일로 결합하는 것을 지원합니다. 또한 여러 파일의 사용을 지원합니다. Extreme Sharding Schema (사용자 당 하나의 SQLITE 데이터베이스를 위해 설계되었습니다.
각 사용자에 대해 별도의 데이터베이스를 작성하는 경우 관계를 설정하지 않는 것처럼 들립니다. 왜 관계형 데이터베이스를 사용합니까?
기본적으로 서버 측 Sqllite 데이터베이스를 클라이언트의 백업 및 동기화 사본으로 사용하고 싶었던 것과 동일한 아키텍처를 고려하고 있습니다. 모든 데이터에서 쿼리에 대한 나의 아이디어는 전체 텍스트 검색에 Sphinx를 사용하고 모든 데이터의 플랫 덤프에서 Scribe로 Hadoop 작업을 실행 한 다음 결과를 WebServies로 노출시키는 것입니다. 이 게시물은 나에게 생각에 대한 잠시 일시 정지를 제공하므로 사람들이 그들의 의견에 따라 계속 응답하기를 바랍니다.
데이터가 쉽게 보충하기 쉬운 경우 표준 데이터베이스 엔진을 사용하지 말고 DB가 병목 현상이되어 데이터베이스가 다른 인스턴스에 따라 데이터베이스를 샤드 할 수있을 정도로 규모가 커지는 이유는 무엇입니까? 효과는 동일하지만 작은 작은 데이터베이스 점수를 사용하지 않습니다.
실제로, 당신은 아마도 단일 사용자가 아닌 일부 공유 데이터가있을 수 있으며, 둘 이상의 사용자에 대한 데이터에 액세스해야 할 것입니다. 그러나 이것은 어느 시스템에도 문제를 일으킬 것입니다.
사용자 당 하나의 데이터베이스가 있으면 물론 개별 사용자 데이터를 쉽게 복원 할 수 있지만 @남자 스키마 변경에는 일부 작업이 필요할 것이라고 말했습니다.
힘들게 만들기에는 충분하지 않지만 사소한 일을하기에 충분합니다.
