NoSQL 데이터 저장소를 사용하는 데 어떤 확장성 문제가 발생했습니까?
NoSQL은 관계형 데이터베이스 및 ACID 보증의 이력과 단절되는 비관계형 데이터 저장소를 말합니다.인기 있는 오픈 소스 NoSQL 데이터 저장소는 다음과 같습니다.
- Cassandra(표로 작성, Java로 작성, Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit 및 Twitter에서 사용)
- CouchDB (문서, 얼랑어로 작성, BBC 및 Engine Yard에서 사용)
- 다이노마이트(키 값, 얼랑으로 작성, Powerset에서 사용)
- HBase (key-value, Java로 작성, Bing에서 사용)
- 하이퍼테이블(표, Baidu에서 사용하는 C++로 작성)
- Kai (키 값, 얼랑어 표기)
- Memcache DB(키 값, C로 작성, Reddit에서 사용)
- MongoDB (문서, Electronic Arts, Github, NY Times 및 Sourceforge에서 사용하는 C++로 작성됨)
- Neo4j (그래프, 자바로 작성, 일부 스웨덴 대학에서 사용)
- Project Voldemort(키-값, Java로 작성, LinkedIn에서 사용)
- Redis(키 값, C로 작성, Craigslist, Engine Yard 및 Github에서 사용)
- Riak (키 값, 얼랑어로 작성, Comcast와 Mochi Media에서 사용)
- Ringo(키 값, Erlang으로 작성, Nokia에서 사용)
- 스칼라(키 값, Erlang으로 작성, OnScale에서 사용)
- 테라스토어(문서, Java로 작성됨)
- ThroughDB (document, C++로 작성, JunkDepot.com 에서 사용)
- 도쿄 내각/도쿄 폭군 (키 값, C로 작성, Mixi.jp (일본 사회관계망 사이트)에서 사용)
나는 당신이 데이터스토어를 사용하여 해결한 구체적인 문제들, 즉 SO 리더가 어떤 NoSQL 데이터스토어를 사용했는지 알고 싶습니다.
질문:
- NoSQL 데이터 저장소를 사용하여 해결한 확장성 문제는 무엇입니까?
- 어떤 NoSQL 데이터 저장소를 사용했습니까?
- NoSQL 데이터 저장소로 전환하기 전에 사용한 데이터베이스는 무엇입니까?
제가 직접 경험을 찾고 있으니, 그런 경험이 없는 한 대답하지 말아주세요.
제가 지금 하고 있는 프로젝트.
18,000개의 객체를 정규화된 구조로 저장: 8개의 다른 테이블에 걸쳐 90,000개의 행을 저장합니다.검색하고 자바 객체 모델에 매핑하는 데 1분이 걸렸습니다. 모든 것이 정확하게 색인화되어 있습니다.
경량 텍스트 표현을 사용하여 키/값 쌍으로 저장: 테이블 1개, 행 18,000개, 3초로 모두 검색하고 Java 객체를 재구성합니다.
비즈니스 측면에서: 첫 번째 옵션은 실현 가능하지 않았습니다.두 번째 옵션은 우리의 앱이 작동한다는 것을 의미합니다.
기술상세: SQL과 NoSQL 모두 MySQL에서 실행!MySQL을 사용하여 데이터를 손상시키지 않는 우수한 트랜잭션 지원, 성능 및 입증된 실적, 확장성, 클러스터링 지원 등을 지원합니다.
MySQL의 데이터 모델은 이제 핵심 필드(정수)와 큰 "가치" 필드(기본적으로 큰 TEXT 필드)에 불과합니다.
신규 플레이어(CouchDB, Cassandra, MongoDB 등)는 모두 자체적으로 우수한 기능/성능을 제공하지만, 상황에 따라 항상 단점(예: Java 지원 누락/미숙)이 존재하기 때문에 사용하지 않았습니다.
MySQL을 사용할 경우의 추가적인 이점 - 관련적으로 작동하는 모델의 비트를 키/밸류 스토어 데이터에 쉽게 연결할 수 있습니다.
업데이트: 다음은 텍스트 콘텐츠를 어떻게 표현했는지 보여주는 예입니다. 실제 비즈니스 영역이 아니라("제품"을 사용하지 않고), 재귀적 측면(한 개체, 여기 제품, 다른 개체 포함)을 포함한 아이디어를 전달합니다.정규화된 구조에서 이것이 꽤 많은 테이블이 될 수 있기를 바랍니다. 예를 들어 제품의 맛 범위에 제품을 결합하는 것, 다른 제품이 포함된 것 등입니다.
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}
]
부하를 처리할 수 있도록 MySQL에서 CouchDB로 소규모 서브 프로젝트를 전환했습니다.결과는 놀라웠습니다.
약 2년 전, 우리는 http://www.ubuntuusers.de/ 에 직접 작성한 소프트웨어를 공개했습니다. (아마도 독일 Linux 커뮤니티 웹사이트 중 가장 큰 사이트일 것입니다.)이 사이트는 Python으로 작성되어 있으며 WSGI 미들웨어를 추가하여 모든 예외를 파악하고 이를 다른 소규모 MySQL 기반 웹사이트로 전송할 수 있습니다.이 작은 웹사이트는 해시를 사용하여 다양한 버그를 파악하고 발생 횟수와 마지막 발생 횟수도 저장했습니다.
불행하게도 출시 직후 추적 기록기 웹사이트는 더 이상 반응을 보이지 않았습니다.테스트 단계에서 탐색하지 못한 몇 가지 버그뿐만 아니라 거의 모든 요청에 예외를 두는 메인 사이트의 생산 db에 몇 가지 잠금 문제가 있었습니다.당사 메인 사이트의 서버 클러스터는 초당 몇 k번씩 트레이스백로거 제출 페이지를 호출합니다.또한 추적 로거를 호스팅하는 소규모 서버(이미 오래된 서버로 개발 목적으로만 사용됨)에게는 너무 과했습니다.
이 시기에 카우치DB가 인기가 있었기 때문에, 저는 그것을 사용해보고 그것으로 작은 트레이스백로거를 쓰기로 결정했습니다.새 로거는 정렬 및 필터 옵션이 포함된 버그 목록과 제출 페이지를 제공하는 단일 파이썬 파일로만 구성되었습니다.그리고 배경으로 카우치DB 프로세스를 시작했습니다.새로운 소프트웨어는 모든 요청에 매우 빠르게 응답했고 우리는 방대한 양의 자동 버그 보고서를 볼 수 있었습니다.
한 가지 흥미로운 점은 이전의 솔루션이 오래된 전용 서버에서 실행되고 있다는 것입니다. 반면에 새로운 CouchDB 기반 사이트는 매우 제한된 리소스를 사용하는 공유 xen 인스턴스에서만 실행된다는 것입니다.키 값 저장소의 강점을 수평적으로 확장하는 데 사용해 본 적도 없습니다.CouchDB/Erlang OTP가 아무것도 잠그지 않고 동시 요청을 처리할 수 있는 능력은 이미 필요에 충분히 부합했습니다.
현재 빠르게 작성된 카우치DB 추적 로거는 여전히 실행 중이며 메인 웹사이트에서 버그를 탐색하는 데 도움이 되는 방법입니다.어쨌든 한 달에 한 번 정도 데이터베이스가 너무 커져서 카우치DB 프로세스가 중단됩니다.그러나 CouchDB의 compact-db 명령어는 크기를 수 GB에서 일부 KB로 다시 줄이고 데이터베이스가 다시 실행됩니다(아마도 여기에 cronjob을 추가하는 것을 고려해야 할 것입니다... 0o).
요약하자면, 카우치DB는 분명 이 서브 프로젝트를 위한 최선의 선택(또는 적어도 MySQL보다 더 나은 선택)이었고 그 역할을 잘 수행합니다.
Todd Hoff의 highscalability.com 에는 몇 가지 사례 연구를 비롯하여 NoSQL에 대한 많은 정보가 있습니다.
상용 Vertica columnal DBMS는 SQL을 지원하더라도 사용자의 목적에 적합할 수 있습니다. 분석 쿼리를 위한 기존 관계형 DBMS에 비해 매우 빠릅니다.지도 축소와 Vertica를 비교한 Stonebraker 등의 최근 CACM 논문을 참조하십시오.
업데이트: 그리고 트위터는 HBase, 볼드모트, 몽고DB, MemcacheDB, Redis, 그리고 HyperTable을 포함한 여러 다른 것들보다 카산드라를 선택했습니다.
업데이트 2: Rick Cattell은 고성능 데이터 저장소의 여러 NoSQL 시스템을 비교하여 발표했습니다.그리고 릭의 논문에 대한 highscalability.com 의 의견은 여기에 있습니다.
데이터의 일부를 mysql에서 mongodb로 옮겼습니다. 확장성을 위해서가 아니라 파일 및 비표형 데이터에 더 적합하기 때문입니다.
현재 생산 중인 제품은 다음과 같습니다.
- 파일 25,000개(60GB)
- 1억 3천만 개의 기타 "문서"(350GB)
하루 매출이 약 10GB에 이릅니다.
데이터베이스는 mongodb python api(pymongo)를 사용하여 apache/wsgi/python 클라이언트가 있는 2개의 노드(6x450GB sas raid10)에 "페어된" 구성으로 배포됩니다.디스크 설정이 오버킬일 수도 있지만 그것이 mysql에 사용되는 것입니다.
pymongo 스레드 풀과 mongodb 서버의 차단 특성과 관련된 몇 가지 문제를 제외하고는 좋은 경험이 되었습니다.
저는 직접적인 경험이 없기 때문에 대담한 글을 반대하게 되어 죄송합니다만, 이 블로그 게시물들은 카우치DB의 문제를 해결하는 좋은 예입니다.
기본적으로 텍스트미 애플리케이션은 폭발적으로 증가하는 데이터 문제를 해결하기 위해 카우치DB를 사용했습니다.이들은 SQL이 너무 느려서 대량의 아카이브 데이터를 처리할 수 없다는 사실을 발견하고 이를 CouchDB로 옮겼습니다.이는 훌륭한 읽기이며, 그는 카우치DB가 어떤 문제를 해결할 수 있는지 그리고 그것들이 어떻게 해결하게 되었는지를 알아내는 전 과정에 대해 이야기합니다.
Postgresql에 저장하던 데이터 중 일부를 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);
저는 직접 경험은 없지만, 이 블로그 항목은 꽤 흥미로웠습니다.
소프트웨어 도메인 개체(예: SalesOrder, customer...)를 2차원 관계형 데이터베이스(행 및 열)에 매핑하려면 저장/업데이트하는 코드가 많이 필요하고 여러 테이블에서 도메인 개체 인스턴스를 인스턴스화하는 작업이 필요합니다.이 모든 디스크 판독기를 사용하면 성능이 향상되는 것은 말할 것도 없습니다.판매 주문서 또는 고객 레코드와 같은 도메인 개체를 보거나 manip화하는 데만 사용됩니다.
ODBMS(Object Database Management Systems)로 전환했습니다.이러한 기능은 나열된 noSQL 시스템의 기능을 뛰어 넘습니다.GemStone/S(Smalltalk용)가 그러한 예입니다.여러 언어에 대한 드라이버가 있는 다른 ODBMS 솔루션도 있습니다.핵심 개발자의 장점인 클래스 계층 구조는 자동으로 데이터베이스 스키마, 하위 클래스 및 모든 것입니다.객체 지향 언어를 사용하여 객체를 데이터베이스에 영구적으로 유지할 수 있습니다.ODBMS 시스템은 ACID 수준의 트랜잭션 무결성을 제공하므로 금융 시스템에서도 작동합니다.
기본적으로 각 장치별로 시계열 센서를 저장하는 M2M 시스템을 위해 MySQL(InnoDB)에서 카산드라로 전환했습니다.각 데이터는 (device_id, date) 및 (device_id, type_of_sensor, date)로 인덱싱됩니다.MySQL 버전은 2천만 행을 포함하고 있었습니다.
MySQL:
- 마스터-마스터 동기화로 설정합니다.동기화 손실과 관련하여 거의 문제가 발생하지 않았습니다.그것은 스트레스였고 특히 처음에는 고치는 데 몇 시간이 걸릴 수 있었습니다.
- 삽입 시간은 문제가 되지 않았지만 쿼리를 수행하는 데는 데이터가 증가함에 따라 점점 더 많은 메모리가 필요했습니다.문제는 지수가 전체적으로 고려된다는 것입니다.제 경우에는 메모리에 로드하는 데 필요한 인덱스 중 매우 얇은 부분만 사용하고 있었습니다(몇 퍼센트의 장치만 자주 모니터링되고 최신 데이터에 저장되어 있었습니다).
- 백업하기가 어려웠습니다.Rsync는 큰 InnoDB 테이블 파일에서 빠른 백업을 할 수 없습니다.
- 시간(시간)이 너무 많이 걸렸기 때문에 무거운 테이블 스키마를 업데이트할 수 없다는 사실이 금방 드러났습니다.
- 데이터를 가져오는 데 몇 시간이 걸렸습니다(결국 인덱싱이 완료된 경우에도).최상의 복구 방안은 데이터베이스의 복사본 몇 개(데이터 파일 + 로그)를 항상 보관하는 것이었습니다.
- 한 호스팅 회사에서 다른 호스팅 회사로 이동하는 것은 정말 큰 일이었습니다.복제는 매우 신중하게 처리해야 했습니다.
카산드라:
- MySQL보다 설치가 더 쉽습니다.
- RAM이 많이 필요합니다.2GB 인스턴스는 처음 버전에서는 실행할 수 없었으므로 이제 1GB 인스턴스에서 작동할 수 있지만 (데이터 플러시가 너무 많음) 이는 아닙니다.우리의 경우에는 8GB를 주는 것으로 충분했습니다.
- 데이터를 구성하는 방법을 이해하고 나면 저장이 쉽습니다.요청이 좀 더 복잡합니다.하지만 일단 그것을 극복하면, 그것은 정말로 빠릅니다. (정말로 하고 싶지 않으면 실수를 할 수 없습니다.)
- 이전 단계가 제대로 이루어졌더라면 지금과 마찬가지로 매우 빠른 속도로 유지됩니다.
- 데이터가 백업되도록 구성되어 있는 것 같습니다.모든 새 데이터는 새 파일로 추가됩니다.개인적으로는 그렇지 않지만, 매일 밤과 종료 전에 데이터를 플러시하여(보통 업그레이드의 경우) 복원에 걸리는 시간을 단축할 수 있습니다. 로그를 읽을 수 있는 시간이 줄어들기 때문입니다.파일이 압축되어 있으면 파일을 많이 만들지 않습니다.
- 데이터를 가져오는 것은 엄청나게 빠릅니다.호스트 수가 많을수록 속도도 빨라집니다.기가바이트의 데이터를 내보내고 가져오는 것은 더 이상 문제가 되지 않습니다.
- 스키마가 없는 것은 매우 흥미로운 일입니다. 왜냐하면 데이터가 필요에 따라 진화하도록 만들 수 있기 때문입니다.즉, 동일한 열 패밀리에 다른 버전의 데이터가 동시에 있다는 것을 의미할 수 있습니다.
- 호스트를 추가하는 것은 쉽지만(빠른 것은 아니지만) 다중 데이터 센터 설정에서는 해보지 못했습니다.
참고: 엘라스틱 검색(루신을 기반으로 한 문서)도 사용한 적이 있는데 NoSQL 데이터베이스로 봐야 한다고 생각합니다.분산되고 신뢰성이 높으며 빠른 경우가 많습니다(일부 복잡한 쿼리는 성능이 떨어질 수 있음).
없어.절차상 전화할 수 있는 간편하고 무료인 키 값 스토어를 사용하고 싶은데 윈도우 플랫폼에 그런 것이 있는 것이 아닙니다.지금은 Sqlite를 사용하지만 도쿄 캐비닛 같은 것을 사용하고 싶습니다.버클리DB에 "이슈" 라이센스가 있습니다.
그러나 Windows OS를 사용하려면 NoSQL 데이터베이스를 선택할 수 없습니다.그리고 항상 C# 프로바이더가 있는 것은 아닙니다.
MongoDB를 해봤는데 Sqlite보다 40배나 빨라서 사용해야 할 것 같습니다.하지만 저는 여전히 간단한 프로세스 솔루션을 희망합니다.
redis를 사용하여 기계 전체에 로깅 메시지를 저장했습니다.그것은 구현하기가 매우 쉬웠고, 매우 유용했습니다.빨간색은 정말 바위입니다.
고정 스키마가 없다는 것이 우리에게 큰 장점이었기 때문에 포스트그레스 데이터베이스를 카우치DB 문서 데이터베이스로 대체하였습니다.각 문서에는 해당 문서에 접근하는 데 사용되는 색인 수가 가변적입니다.
저는 과거에 Couchbase를 사용한 적이 있으며, 리밸런싱 문제와 기타 여러 문제에 직면했습니다.현재 저는 여러 제작 프로젝트에서 Redis를 사용하고 있습니다.Redis 클러스터의 확장을 담당하는 Redis 관리 서비스인 redislabs.com 을 사용하고 있습니다.공급자 모델에서 Redis를 사용하는 방법과 C# 개체를 Redis에 저장하는 방법을 보여주는 객체 지속성에 대한 비디오를 http://thomasjaeger.wordpress.com 블로그에 게시했습니다.한번 보세요.
3.0이 출시된 지금 이 글을 읽는 사람에게 카우치베이스를 한 번 더 시도해보라고 권하고 싶습니다.200개 이상의 새로운 기능이 있습니다.Couchbase Server의 성능, 가용성, 확장성 및 쉬운 관리 기능은 매우 유연하고 가용성이 높은 데이터베이스를 제공합니다.관리 UI가 내장되어 있고 API가 클러스터 노드를 자동으로 검색하므로 애플리케이션에서 DB로 로드 밸런서가 필요 없습니다.현재 관리형 서비스는 없지만 AWS, Red Hat Gears, Cloudera, Rackspace, CloudSoft와 같은 Docker Containers 등을 기반으로 카우치베이스를 실행할 수 있습니다.재조정과 관련하여 구체적으로 무엇을 언급하느냐에 따라 다르지만 카우치베이스는 설계된 대로 노드 장애 후 자동으로 재조정되지 않습니다.그러나 관리자는 첫 번째 노드 장애에 대해 자동 페일오버를 설정할 수 있으며, API를 사용하여 활성화하거나 나머지를 사용하기 전에 읽기 위해 복제본 vbucket에 액세스할 수도 있습니다.API를 사용하면 모니터링 도구를 통해 페일오버를 수행할 수 있습니다.이것은 특별한 경우이지만 가능합니다.
노드가 완전히 오프라인 상태가 되어 다시 돌아오지 않거나 새로운 노드가 자동으로 균형을 맞출 준비가 되지 않는 한 거의 모든 모드에서 균형을 재조정하지 않는 경향이 있습니다.가장 성능이 뛰어난 NoSQL 데이터베이스가 무엇인지 알고 싶은 모든 사용자에게 도움이 되는 몇 가지 가이드가 있습니다.
마지막으로 분산 쿼리를 위해 N1QL을 확인하는 것도 권장합니다.
읽어주셔서 감사하고 도움이 더 필요하면 저나 다른 사람들에게 알려주세요!
오스틴
저는 예전에 Vertica를 사용한 적이 있습니다.이 제품은 기둥 모양의 압축을 사용하여 디스크 읽기 속도를 높이고 하드웨어를 최대한 활용하기 위한 스토리지 요구를 낮춥니다.데이터 로드 속도가 빨라지고 동시성이 높아져 지연 시간을 최소화하면서 더 많은 사용자에게 분석 데이터를 제공할 수 있습니다.
이전에는 수십억 개의 레코드를 보유한 Oracle 데이터베이스에 대해 쿼리를 수행했는데 성능이 매우 최적화되지 않았습니다.SSD로 최적화한 후에도 쿼리를 실행하는 데 8~12초가 걸렸습니다.따라서 읽기에 최적화된 분석 지향 데이터베이스를 보다 빠르게 사용해야 할 필요성을 느꼈습니다.희박한 서비스 계층 뒤에 Vertica Cluster를 설치하면 1초 미만의 성능으로 API를 실행할 수 있습니다.
Vertica는 질의 실행을 최적화하는 형식으로 프로젝션에 데이터를 저장합니다.구체화된 보기와 유사하게 프로젝션은 쿼리에 사용될 때마다 결과 집합을 계산하는 것이 아니라 디스크 또는 SSD에 저장합니다.프로젝션은 다음과 같은 이점을 제공합니다.
- 데이터를 압축하고 인코딩하여 저장 공간을 줄입니다.
- 데이터베이스 클러스터 전체에 배포를 단순화합니다.
- 고가용성 및 복구 기능을 제공합니다.
Vertica는 세그멘테이션(Segmentation)을 사용하여 데이터를 클러스터에 분산시켜 데이터베이스를 최적화합니다.
- 분할은 데이터의 일부를 노드에 배치합니다.
- 모든 노드에 데이터를 균등하게 분배합니다.따라서 각 노드는 쿼리 프로세스의 일부를 수행합니다.
- 쿼리는 클러스터에서 실행되고 모든 노드는 쿼리 계획을 수신합니다.
- 쿼리 결과가 집계되어 출력을 생성하는 데 사용됩니다.
자세한 내용은 Vertica 설명서 @ https://www.vertica.com/knowledgebase/ 를 참조하십시오.
언급URL : https://stackoverflow.com/questions/2285045/what-scalability-problems-have-you-encountered-using-a-nosql-data-store
'programing' 카테고리의 다른 글
| 반복기에서 맵() 사용 (0) | 2023.11.06 |
|---|---|
| Python 3에서 문자열 리터럴 앞에 있는 'b' 문자 do 제거 (0) | 2023.11.06 |
| 구글은 URL에서 검색 대신 #를 사용합니다. 왜죠? (0) | 2023.11.06 |
| 각도 자재 테이블에서 행 인덱스 가져오기 v5 (0) | 2023.11.06 |
| 한 컨트롤러에서 언로드하기 전에 AngularJS window.on이 다른 컨트롤러에서 트리거됨 (0) | 2023.11.06 |