빅데이터 이니셔티브에서 성공하기 위한 핵심은 속도, 규모, 구조를 밀리초 미만의 속도로 관리할 수 있어야 한다는 것입니다.
빅 데이터는 큰 용어입니다. 데이터 유형에 대한 개념, 이러한 데이터 유형을 관리하는 수십 가지 기술, 그리고 이러한 모든 기술을 둘러싼 에코시스템을 포괄합니다. 그리고 그 안의 모든 것이 빠르게 움직입니다!
빅 데이터는 빠르게 진화하고 있습니다. 클래식 빅데이터 솔루션오늘날 가장 보편적으로 사용되는 빅데이터 기술 아키텍처는 배치 프로세스를 통해 데이터를 가져오고 내보내는 방식(일반적으로 Hadoop으로)에 의존합니다. 이는 더 나은 고객 인사이트와 예측 분석의 형태로 엄청난 비즈니스 결과를 가져왔지만 실시간 솔루션은 아닙니다. 느립니다.
기술이 점점 더 빠른 속도로 발전함에 따라 빅데이터 솔루션의 모범 사례도 발전하고 있습니다. 최신 빅데이터 솔루션은 스트림 처리를 통한 실시간 데이터 처리에 의존합니다. 최신 빅데이터 솔루션은 Elasticsearch, Storm 등과의 통합을 활용합니다. 이를 통해 운영 요건을 충족하면서 실시간 분석과 검색이 가능합니다. 실시간 분석과 검색을 가능하게 하려면 최신 빅데이터 솔루션에는 고성능이 필요합니다. NoSQL 데이터베이스 확장 가능한 데이터베이스입니다. NoSQL 데이터베이스는 운영 요구 사항을 충족하는 동시에 실시간 분석 및 검색을 지원하는 데 필요한 성능 요구 사항을 충족해야 합니다.
최신 빅 데이터 솔루션은 가장 느린 구성 요소만큼만 빠릅니다. 최근 Mongo와 Cloudera가 발표한 내용을 소개합니다. 고객이 빅데이터 아키텍처의 모범 사례를 이해하도록 돕는 모든 노력에 박수를 보내지만, 진정으로 빠른 빅데이터 아키텍처를 구현하는 데 적합한 NoSQL 솔루션이 무엇인지도 짚고 넘어가야 합니다. 확장 가능한 고성능 NoSQL 데이터베이스는 운영 데이터베이스가 가장 느린 구성 요소가 되지 않도록 보장합니다. 확장하기 어렵고 읽기 및 쓰기 트래픽에 무거운 잠금을 부과하는 NoSQL 데이터베이스는 최신 빅 데이터 솔루션의 잠재력을 활용하지 못합니다. 이것이 바로 MongoDB와 Couchbase Server의 차이점입니다. 물론, MongoDB는 실시간 분석을 위해 설계되지 않았고 최신 빅데이터 솔루션에 필요한 속도를 필요로 하지 않는 기존 빅데이터 솔루션의 일부가 될 수 있습니다. Couchbase Server는 기존 빅 데이터 솔루션과 최신 빅 데이터 솔루션 모두에 포함될 수 있습니다.
앞서 언급한 고전적인 빅 데이터 솔루션은 오늘날 많은 조직에서 사용되고 있습니다. 이 솔루션은 일반적으로 Hadoop과의 통합에 의존합니다. Couchbase Server는 클라우데라 인증 Sqoop 커넥터를 통해 Hadoop과 통합됩니다(링크).
Matt Asay는 대표적인 빅 데이터 사용 사례로 Hadoop이 군중을 분석하고 NoSQL 데이터베이스가 개인과 상호 작용하는 경우를 들었습니다. 개별 상호 작용은 Hadoop에 제공되고 군중 분석은 NoSQL 데이터베이스에 제공됩니다. Couchbase의 경우, 이것은 단순한 사용 사례가 아닙니다. 고객 레퍼런스입니다. AOL은 지능형 광고를 구현하기 위해 전통적인 빅 데이터 솔루션에서 Hadoop과 Couchbase Server를 활용합니다(링크).
LivePerson은 최신 빅데이터 솔루션에서 Hadoop, Storm 및 Couchbase Server를 활용합니다. LivePerson 아키텍처는 배치 지향 처리와 실시간 처리를 모두 활용합니다. LivePerson은 Couchbase, MongoDB, DataStax의 NoSQL 데이터베이스를 고려했습니다. 하지만 높은 처리량 요구 사항을 충족할 수 있는 것은 Couchbase Server뿐이었습니다.
자세한 정보
Big Data Central은 빅데이터 커뮤니티가 사용 사례, 기술 및 아키텍처를 탐색할 수 있는 공간입니다. LivePerson, AOL, PayPal과 같은 Couchbase 고객이 클래식 및 최신 빅 데이터 솔루션에서 NoSQL과 Hadoop을 어떻게 활용하고 있는지 알아보세요.
저는 이 게시물을 읽으며 지적인 분석을 기대했습니다. 하지만 제가 본 것은 마케팅 과대 광고와 풍자뿐이었습니다.
어쩌면 배치 작업이 실행될 때까지 업데이트 후 오래된 데이터를 반환하는 Map Reduce 작업으로 구축되는 인덱스에 대해 이야기해야 할지도 모릅니다. 아니면 저장 엔진만 추가하는 것은 어떨까요? 정말요? 대용량 문서에 대한 대량 업데이트는 카우치베이스에 무리를 줍니다.
서버가 다운되는 것을 보고 싶다면 Couchbase 서버를 업데이트하기 시작하면 됩니다. 그러면 이제 모든 읽기가 현실과 일치하지 않고 서버 저장소가 달걀 프라이를 할 수 있을 정도로 뜨거워진다는 사실을 즐길 수 있습니다.
안녕하세요, 릭,
시간을 내어 의견을 보내주셔서 감사합니다. 우려하신 사항을 해결하도록 노력하겠습니다.
기술적 부채:
이는 높은 수준의 작업이지만 확장성과 성능의 중요성을 강조합니다. 이것이 바로 우리가 벤치마크를 통해 확장성과 성능을 입증한 이유입니다. 그런데 MongoDB는 지난 릴리스에서 향후 성능 향상을 위한 토대를 마련한 것으로 알고 있습니다. 다음 릴리스에 대한 기대가 큽니다.
보조 인덱스(조회수) 및 일관성:
기본적으로 뷰는 점진적으로 증가하므로 결국 일관성을 유지합니다. 그러나 클라이언트는 오래된 플래그(stale=false)를 사용하여 일관성을 유지할 수 있습니다. MongoDB도 쓰기 우려를 통해 비슷한 방식으로 데이터 일관성을 강제한다고 생각합니다. 기본적으로 일관성이 유지되지만(인정됨), '다수'는 대안이 될 수 있습니다.
추가 전용 파일:
예, 저희는 추가 전용 파일을 사용합니다. 최신 데이터베이스는 제자리에서 업데이트하는 방식에서 벗어나고 있다고 해도 과언이 아닙니다. 여기에는 읽기 전용 데이터베이스, 컬럼형 데이터베이스 및 Google Dremel/Cloudera Impala + Parquet이 포함됩니다. 다음은 그 이유 중 일부입니다.
일관된 성능. 제자리 업데이트는 예측이 가능하지만 업데이트는 예측이 불가능합니다.
손상 복원력. 이전 버전으로 복원하는 기능입니다.
솔리드 스테이트 드라이브. "읽기-수정-쓰기" 방식입니다. 제자리에서 업데이트되지 않습니다.
낮은 조각화. 업데이트 크기가 원래 크기보다 크면 문제가 되지 않습니다.
업데이트:
업데이트가 왜 문제라고 생각하는지 잘 모르겠습니다. 추가 전용 파일의 경우 쓰기는 쓰기입니다. 벤치마크를 살펴보는 것이 좋습니다. MongoBD가 보증하는 벤치마크를 알고 계신다면 공유해 주시면 감사하겠습니다. 한번 살펴보고 싶습니다.
벤치마크
http://www.couchbase.com/sites…
몽고DB 및 쓰기 문제
http://aphyr.com/posts/284-cal…
제자리 업데이트와 추가 전용 업데이트 비교
http://blogs.justonedatabase.c…
모든 NoSQL 플랫폼은 아직 갈 길이 멀다. 일부는 다른 플랫폼보다 훨씬 앞서 있으며 데이터베이스에는 원시 성능보다 더 많은 것이 있습니다. 기존의 관계형 플랫폼은 성능만큼이나 깊이 있는 기능을 제공하기 때문에 대부분의 비즈니스 애플리케이션에 선호됩니다.
초기 다수 플레이어가 베팅을 시작하면서 시장에서 NoSQL 플랫폼 간 분리가 시작되고 있는 것은 기능적 깊이 영역입니다.
저는 Couchbase가 MongoDB와 마찬가지로 플랫폼으로서 발전할 것이라고 확신합니다. 제 첫 번째 댓글은 블로그 게시물의 제목이 최소한 정보에 입각한 의견을 유추할 수 있는 내용이었지만 그 내용이 훨씬 부족하다는 점을 지적하기 위한 것이었습니다. 귀하의 후속 댓글은 제가 처음에 기대했던 내용에 더 부합하는 것이었지만, 작성 당시와 관련성이 떨어지는 오래된 블로그 게시물에 대한 링크는 다소 흥미로운 대체물이었습니다.