[database] NoSQL 데이터 저장소를 사용하여 어떤 확장 성 문제가 발생 했습니까? [닫은]
NoSQL은 관계형 데이터베이스의 역사와 ACID 보증을 위반하는 비 관계형 데이터 저장소를 말합니다. 많이 사용되는 오픈 소스 NoSQL 데이터 저장소는 다음과 같습니다.
- Cassandra (Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit 및 Twitter에서 사용되는 Java로 작성된 표)
- CouchDB (Erlang으로 작성되고 BBC 및 Engine Yard에서 사용하는 문서)
- 다이너마이트 (Erlang으로 작성된 키-값, Powerset에서 사용)
- HBase (Bing에서 사용되는 Java로 작성된 키-값)
- 하이퍼 테이블 (바이두에서 사용하는 C ++로 작성된 표)
- Kai (키-값, Erlang으로 작성)
- MemcacheDB (C로 작성되고 Reddit에서 사용되는 키-값)
- MongoDB (C ++로 작성되고 Electronic Arts, Github, NY Times 및 Sourceforge에서 사용하는 문서)
- Neo4j (일부 스웨덴어 대학에서 사용하는 Java로 작성된 그래프)
- Project Voldemort (Java로 작성되고 LinkedIn에서 사용하는 키-값)
- Redis (C로 작성된 키-값, Craigslist, Engine Yard 및 Github에서 사용)
- Riak (Comcast 및 Mochi Media에서 사용되는 Erlang으로 작성된 키-값)
- Ringo (Erlang으로 작성된 키-값, Nokia에서 사용)
- 스칼라리스 ( OnScale 에서 사용하는 Erlang으로 작성된 키-값)
- Terrastore (문서, Java로 작성)
- ThruDB (C ++로 작성된 문서, JunkDepot.com 에서 사용)
- 도쿄 내각 / 도쿄 폭군 (C로 작성된 키-값, Mixi.jp (일본 소셜 네트워킹 사이트)에서 사용)
데이터 리더를 사용하여 해결 한 특정 문제 (SO 리더)가 어떤 NoSQL 데이터 저장소를 사용했는지 알고 싶습니다.
질문 :
- NoSQL 데이터 저장소를 사용하여 어떤 확장 성 문제를 해결 했습니까?
- 어떤 NoSQL 데이터 저장소를 사용 했습니까?
- NoSQL 데이터 저장소로 전환하기 전에 어떤 데이터베이스를 사용 했습니까?
직접적인 경험을 찾고 있습니다. 그러지 않으면 대답하지 마십시오.
답변
로드를 처리 할 수 있도록 작은 하위 프로젝트를 MySQL에서 CouchDB로 전환했습니다. 결과는 놀랍습니다.
약 2 년 전, http://www.ubuntuusers.de/ (아마도 가장 큰 독일 리눅스 커뮤니티 웹 사이트) 에 자체 작성 소프트웨어가 릴리스되었습니다 . 이 사이트는 Python으로 작성되었으며 모든 예외를 잡아서 다른 소규모 MySQL 기반 웹 사이트로 보낼 수있는 WSGI 미들웨어를 추가했습니다. 이 작은 웹 사이트는 해시를 사용하여 다른 버그를 확인하고 발생 횟수와 마지막 발생 횟수를 저장했습니다.
안타깝게도 릴리스 직후에 역 추적 로거 웹 사이트가 더 이상 응답하지 않았습니다. 우리는 메인 사이트의 프로덕션 DB에 잠금 문제가있어 거의 모든 요청에 예외가 발생했으며 테스트 단계에서 탐색하지 않은 다른 버그도 있습니다. 기본 사이트의 서버 클러스터 (트레이스 백 로거 제출 페이지라고도 함) 그리고 그것은 트레이스 백 로거를 호스팅하는 작은 서버에게는 너무 많은 길이었습니다 (이것은 이미 개발 목적으로 만 사용되었던 오래된 서버였습니다).
현재 CouchDB는 다소 인기가 있었으므로 그것을 사용 해보고 작은 역 추적 기록기를 작성하기로 결정했습니다. 새로운 로거는 단일 파이썬 파일로만 구성되었으며, 정렬 및 필터 옵션과 제출 페이지가 포함 된 버그 목록을 제공했습니다. 그리고 백그라운드에서 CouchDB 프로세스를 시작했습니다. 새로운 소프트웨어는 모든 요청에 매우 신속하게 응답했으며 방대한 양의 자동 버그 보고서를 볼 수있었습니다.
한 가지 흥미로운 점은 이전의 솔루션이 기존 전용 서버에서 실행되고 있었지만 새로운 CouchDB 기반 사이트는 리소스가 매우 제한된 공유 xen 인스턴스에서만 실행되었다는 것입니다. 또한 키-값 저장소의 강점을 사용하여 수평 적으로 확장하지도 않았습니다. CouchDB / Erlang OTP가 어떤 것도 잠그지 않고 동시 요청을 처리하는 능력은 이미 요구를 충족시키기에 충분했습니다.
이제 빠르게 작성된 CouchDB-traceback 로거가 여전히 실행 중이며 기본 웹 사이트에서 버그를 탐색하는 데 유용한 방법입니다. 어쨌든 약 한 달에 한 번 데이터베이스가 너무 커지고 CouchDB 프로세스가 종료됩니다. 그러나 CouchDB의 compact-db 명령은 크기를 몇 GB에서 몇 KB로 다시 줄이고 데이터베이스가 다시 실행 중입니다 (cronjob을 추가하는 것을 고려해야 할 수도 있습니다 … 0o).
요약하면 CouchDB는 분명히이 하위 프로젝트에 대한 최선의 선택 (또는 적어도 MySQL보다 더 나은 선택)이었으며 잘 작동합니다.
답변
내 현재 프로젝트입니다.
18,000 개의 객체를 표준화 된 구조로 저장 : 8 개의 서로 다른 테이블에 9 만 행. Java 객체 모델에 검색하고 매핑하는 데 1 분이 걸렸습니다. 모든 것이 올바르게 색인화되어 있습니다.
간단한 텍스트 표현 (1 개의 테이블, 18,000 개의 행, 3 초)을 사용하여 키 / 값 쌍으로 저장하여 모두 검색하고 Java 객체를 재구성합니다.
비즈니스 측면에서 : 첫 번째 옵션은 실현 가능하지 않았습니다. 두 번째 옵션은 앱이 작동 함을 의미합니다.
기술 세부 정보 : SQL 및 NoSQL 모두를 위해 MySQL에서 실행! 우수한 트랜잭션 지원, 성능 및 데이터 손상, 우수한 확장 성, 클러스터링 지원 등의 입증 된 실적을 위해 MySQL을 고수합니다.
MySQL의 데이터 모델은 이제 주요 필드 (정수)와 큰 “값”필드입니다. 기본적으로 큰 TEXT 필드입니다.
우리는 새로운 플레이어 (CouchDB, Cassandra, MongoDB 등)와 함께 가지 않았습니다. 각각 자체적으로 훌륭한 기능 / 성능을 제공하지만 상황에 따라 항상 단점 (예 : 누락 / 미성숙 한 Java 지원)이 있었기 때문입니다.
MySQL을 사용 (AB)의 추가 혜택은 – 우리의 모델의 비트 할 관계형 작업은 쉽게 우리의 키 / 값 저장소 데이터에 연결할 수 있습니다.
업데이트 : 여기 실제 상사 영역 ( “제품”으로 작업하지 않음)이 상사가 나를 쏘지 않고 텍스트 내용을 어떻게 표현했는지에 대한 예가 있지만, 재귀 적 측면 (여기서는 하나의 엔티티)을 포함하여 아이디어를 전달합니다. “포함 된”제품). 정상화 된 구조에서 이것이 어떻게 여러 종류의 풍미에 제품을 결합시키는 지, 다른 제품이 포함되어 있는지 등의 몇 가지 표가 될 수 있음이 분명합니다.
Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]
답변
Todd Hoff의 highscalability.com 은 일부 사례 연구를 포함하여 NoSQL에 대한 많은 정보를 제공합니다.
상용 Vertica 컬럼 DBMS는 SQL을 지원하더라도 목적에 맞을 수 있습니다. 분석 쿼리를위한 기존 관계형 DBMS와 비교할 때 매우 빠릅니다. Vertica와 map-reduce를 대조 한 Stonebraker 등의 최근 CACM 논문을 참조하십시오 .
업데이트 : 그리고 트위터 는 HBase, Voldemort, MongoDB, MemcacheDB, Redis 및 HyperTable을 포함한 여러 다른 것보다 Cassandra 를 선택 했습니다.
업데이트 2 : Rick Cattell은 고성능 데이터 저장소 에서 여러 NoSQL 시스템 비교를 발표했습니다 . 그리고 Rick의 논문에 대한 highscalability.com의 의견은 여기에 있습니다 .
답변
우리는 데이터의 일부를 mysql에서 mongodb로 옮겼습니다. 확장 성이 아니라 파일 및 비 테이블 데이터에 더 적합하기 때문에 확장 성이 뛰어납니다.
프로덕션에서는 현재 다음을 저장합니다.
- 25,000 개 파일 (60GB)
- 1 억 3 천만 개의 다른 “문서”(350GB)
매일 약 10GB의 매출이 발생합니다.
데이터베이스는 mongodb python api (pymongo)를 사용하여 apache / wsgi / python 클라이언트와 함께 두 개의 노드 (6x450GB sas raid10)에 “페어링 된”구성으로 배포됩니다. 디스크 설정은 아마도 과잉이지만 mysql에 사용하는 것입니다.
pymongo 스레드 풀과 관련된 문제와 mongodb 서버의 차단 특성 외에도 좋은 경험이었습니다.
답변
직접적인 경험이 없기 때문에 굵은 글씨로 된 것에 대해 사과드립니다. 그러나이 블로그 게시물 세트는 CouchDB의 문제를 해결하는 좋은 예입니다.
본질적으로 textme 응용 프로그램은 CouchDB를 사용하여 폭발적인 데이터 문제를 처리했습니다. 그들은 많은 양의 아카이브 데이터를 처리하기에 SQL이 너무 느리고 CouchDB로 옮겼다는 것을 발견했습니다. CouchDB가 해결할 수있는 문제와 문제 해결 방법을 파악하는 전체 과정에 대해 설명합니다.
답변
Postgresql과 Memcached에 저장하는 데 사용했던 일부 데이터를 Redis 로 옮겼습니다 . 키 값 저장소는 계층 적 개체 데이터를 저장하는 데 훨씬 적합합니다. ORM을 사용하여 BLOB을 RDBMS에 맵핑하는 것보다 훨씬 빠르고 개발 시간과 노력을 덜어 BLOB 데이터를 저장할 수 있습니다.
POCO 객체를 한 줄로 저장하고 검색 할 수 있는 오픈 소스 c # redis 클라이언트 가 있습니다.
var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });
키 값 저장소는 새 서버를 추가 한 다음로드를 균등하게 분할하여 새 서버를 포함 할 수 있으므로 ‘스케일 아웃’이 훨씬 쉽습니다. 중요한 것은 확장 성을 제한하는 중앙 서버가 없다는 것입니다. (단, 요청을 배포하려면 일관된 해싱 전략이 필요합니다).
Redis는 여러 클라이언트에게 빠르고 동시 적이며 원자적인 액세스를 제공하는 스테로이드의 ‘관리되는 텍스트 파일’이라고 생각하므로 텍스트 파일이나 내장 데이터베이스를 사용하는 데 사용한 모든 것이 이제 Redis를 사용합니다. 예를 들어, 우리의 모든 서비스에 대해 실시간 통합 롤링 오류 로그를 얻으려면 (우리에게 어려운 작업이었습니다), 이제 Redis 서버 사이드 목록에 오류를 미리 추가하여 몇 줄로만 수행 할 수 있습니다. 그런 다음 목록을 트리밍하여 마지막 1000 개만 유지하십시오.
var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);