MongoDB의 성장… 이제 무엇을 해야 할까요?

Question 1

현재 성능이 너무 느리거나 한계에 도달한 경우 세 가지 옵션이 있습니다. 그리고 어떤 문제에도 적용됩니다.

수직으로 크기 조정: 기계의 출력을 높이는 것을 의미합니다. 더 많은 CPU 또는 더 많은 RAM.
수평으로 크기 조정: 일꾼의 수를 늘리는 것을 의미합니다. 더 많은 프로세스, 더 많은 스레드, 더 많은 머신.
디자인 변경: 다르게 해보세요. 다른 소프트웨어, 다른 알고리즘, 다른 저장 시스템, 기타 무엇이든.

옵션에서 1)과 2)를 제외하면 3)의 해결방법만 남습니다. 그러니 가세요 ...

Answer

현재 성능이 너무 느리거나 한계에 도달한 경우 세 가지 옵션이 있습니다. 그리고 어떤 문제에도 적용됩니다.

수직으로 크기 조정: 기계의 출력을 높이는 것을 의미합니다. 더 많은 CPU 또는 더 많은 RAM.
수평으로 크기 조정: 일꾼의 수를 늘리는 것을 의미합니다. 더 많은 프로세스, 더 많은 스레드, 더 많은 머신.
디자인 변경: 다르게 해보세요. 다른 소프트웨어, 다른 알고리즘, 다른 저장 시스템, 기타 무엇이든.

옵션에서 1)과 2)를 제외하면 3)의 해결방법만 남습니다. 그러니 가세요 ...

Question 2

우리는 Mongo 포럼에 이와 동일한 질문을 올렸고 Mongo CTO는 인덱스 최적화 방법에 대한 자신의 프레젠테이션을 검토하겠다고 응답했습니다.

http://www.10gen.com/presentations/mongosf2011/schemascale

이 프레젠테이션에서 Horowitz 씨는 샤딩/수평 확장이 많은 상황에서 과도할 수 있으며 설계 접근 방식(Mongo에 특정한 다소 비직관적인 접근 방식 포함)이 특정 서버 규모를 훨씬 더 확장할 수 있다는 점을 명시적으로 밝혔습니다.

이는 클라이언트 측 논리를 사용하여 db가 "정규화되지 않은" 여러 방식으로 사용되는 방식을 최적화하는 것을 포함하여 몇 가지 흥미로운 개념을 제시했습니다. 프레젠테이션에는 "책에 따라 구축하면 스케일링과 관련된 원치 않는 문제가 쉽게 발생할 수 있다"는 효과에 대한 명확한 하위 텍스트가 있습니다. 예를 들어, Mr. Horowitz(MongoDB 제조사인 10Gen의 CTO)는 "레코드"당 하나의 문서 대신에 문서에 약 100개의 "레코드"를 넣어 "버킷" 종류가 되는 "하이브리드" 설계를 제시합니다. 접근의. 이는 인덱스 공간을 줄이기 위해 명시적으로 수행됩니다. 이는 클라이언트에서 코딩된 것이며 MongoDB의 "기능"이 아닙니다. 이 하이브리드 접근 방식은 우리에게 효과적일 수 있으며 인덱스 크기를 4배 또는 8배 향상시킬 수 있습니다.

그는 또한 기본적으로 대부분의 쿼리가 인덱스의 "오른쪽 부분"에만 액세스하도록 인덱스 디자인을 최적화하는 "오른쪽 균형 잡힌" btree에 대해 설명합니다. 전체 인덱스가 RAM에 맞습니다). 인덱스 전체를 쿼리해야 하므로 이 접근 방식은 도움이 되지 않습니다.

우리는 이러한 개념을 시스템 검토의 일부로 사용할 것입니다.

(흥미롭게도 제가 이 질문을 게시한 모든 곳 중에서 건설적인 답변을 한 유일한 사람은 MongoDB 자체의 CTO였습니다.)

업데이트(2017)

우리는 궁극적으로 Mongodb가 프로덕션 환경에 적합하지 않다는 것을 발견했습니다. 몇 달에 한 번씩 전체 DB를 덤프/폐기하고 모든 데이터가 손실됩니다. (주 데이터 소스가 아니기 때문에 만족스럽지는 않지만 문제를 안고 살아갈 수 있습니다.)

이제 우리는 Elasticsearch 스택으로 이동하는 프로젝트를 완료했으며 현재 이를 프로덕션에 적용하고 있습니다. (우리는 수년간 Elasticsearch를 성공적으로 사용해 왔습니다.) Elasticsearch 데이터는 예를 들어 Microsoft SQL Server만큼 내구성이 없지만(복구할 수 없는 데이터 손실로 Elasticsearch 클러스터가 실패하는 경우가 있었습니다) Elasticsearch는 최소 10배(경험적으로는 100배 이상)입니다. ) Mongodb보다 더 안정적입니다. (Elasticsearch는 지능적으로 Windows를 프로덕션 플랫폼으로 지원하는 척하지 않습니다. 이는 Mongodb의 큰 죄악 중 하나입니다.)

우리는 앞으로 몇 주 동안 Mongodb의 전체 환경을 제거할 것으로 예상합니다.

앞으로!

업데이트(2018-2019)

Elasticsearch 스택이 제공되었습니다. 우리는 그것이 매우 안정적이고 확장성이 뛰어나며 전혀 뒤돌아보지 않는다는 것을 알았습니다. 몽고는 그 당시에는 좋은 냄새가 났지만 몇 년이 지난 지금은 없어졌고, 잘 없어졌습니다. 우리는 두 개의 탄력적 클러스터를 실행하고 있는데, 하나는 로그 데이터(Mongo 서버를 대체함)용이고 다른 하나는 실제 애플리케이션 데이터용입니다. 각 클러스터에는 1~2TB의 데이터가 있습니다. 그것은 걸렸다많은확장성과 성능 모두에 탄력성을 부여하기 위해 아키텍처 작업(특히 애플리케이션 측면)을 수행하지만 실제로는 그렇게 합니다.

Answer

우리는 Mongo 포럼에 이와 동일한 질문을 올렸고 Mongo CTO는 인덱스 최적화 방법에 대한 자신의 프레젠테이션을 검토하겠다고 응답했습니다.

http://www.10gen.com/presentations/mongosf2011/schemascale

이 프레젠테이션에서 Horowitz 씨는 샤딩/수평 확장이 많은 상황에서 과도할 수 있으며 설계 접근 방식(Mongo에 특정한 다소 비직관적인 접근 방식 포함)이 특정 서버 규모를 훨씬 더 확장할 수 있다는 점을 명시적으로 밝혔습니다.

이는 클라이언트 측 논리를 사용하여 db가 "정규화되지 않은" 여러 방식으로 사용되는 방식을 최적화하는 것을 포함하여 몇 가지 흥미로운 개념을 제시했습니다. 프레젠테이션에는 "책에 따라 구축하면 스케일링과 관련된 원치 않는 문제가 쉽게 발생할 수 있다"는 효과에 대한 명확한 하위 텍스트가 있습니다. 예를 들어, Mr. Horowitz(MongoDB 제조사인 10Gen의 CTO)는 "레코드"당 하나의 문서 대신에 문서에 약 100개의 "레코드"를 넣어 "버킷" 종류가 되는 "하이브리드" 설계를 제시합니다. 접근의. 이는 인덱스 공간을 줄이기 위해 명시적으로 수행됩니다. 이는 클라이언트에서 코딩된 것이며 MongoDB의 "기능"이 아닙니다. 이 하이브리드 접근 방식은 우리에게 효과적일 수 있으며 인덱스 크기를 4배 또는 8배 향상시킬 수 있습니다.

그는 또한 기본적으로 대부분의 쿼리가 인덱스의 "오른쪽 부분"에만 액세스하도록 인덱스 디자인을 최적화하는 "오른쪽 균형 잡힌" btree에 대해 설명합니다. 전체 인덱스가 RAM에 맞습니다). 인덱스 전체를 쿼리해야 하므로 이 접근 방식은 도움이 되지 않습니다.

우리는 이러한 개념을 시스템 검토의 일부로 사용할 것입니다.

(흥미롭게도 제가 이 질문을 게시한 모든 곳 중에서 건설적인 답변을 한 유일한 사람은 MongoDB 자체의 CTO였습니다.)

업데이트(2017)

우리는 궁극적으로 Mongodb가 프로덕션 환경에 적합하지 않다는 것을 발견했습니다. 몇 달에 한 번씩 전체 DB를 덤프/폐기하고 모든 데이터가 손실됩니다. (주 데이터 소스가 아니기 때문에 만족스럽지는 않지만 문제를 안고 살아갈 수 있습니다.)

이제 우리는 Elasticsearch 스택으로 이동하는 프로젝트를 완료했으며 현재 이를 프로덕션에 적용하고 있습니다. (우리는 수년간 Elasticsearch를 성공적으로 사용해 왔습니다.) Elasticsearch 데이터는 예를 들어 Microsoft SQL Server만큼 내구성이 없지만(복구할 수 없는 데이터 손실로 Elasticsearch 클러스터가 실패하는 경우가 있었습니다) Elasticsearch는 최소 10배(경험적으로는 100배 이상)입니다. ) Mongodb보다 더 안정적입니다. (Elasticsearch는 지능적으로 Windows를 프로덕션 플랫폼으로 지원하는 척하지 않습니다. 이는 Mongodb의 큰 죄악 중 하나입니다.)

우리는 앞으로 몇 주 동안 Mongodb의 전체 환경을 제거할 것으로 예상합니다.

앞으로!

업데이트(2018-2019)

Elasticsearch 스택이 제공되었습니다. 우리는 그것이 매우 안정적이고 확장성이 뛰어나며 전혀 뒤돌아보지 않는다는 것을 알았습니다. 몽고는 그 당시에는 좋은 냄새가 났지만 몇 년이 지난 지금은 없어졌고, 잘 없어졌습니다. 우리는 두 개의 탄력적 클러스터를 실행하고 있는데, 하나는 로그 데이터(Mongo 서버를 대체함)용이고 다른 하나는 실제 애플리케이션 데이터용입니다. 각 클러스터에는 1~2TB의 데이터가 있습니다. 그것은 걸렸다많은확장성과 성능 모두에 탄력성을 부여하기 위해 아키텍처 작업(특히 애플리케이션 측면)을 수행하지만 실제로는 그렇게 합니다.

Question 3

실제로 스케일링 문제가 없기 때문에 "스케일링" 문제에 대한 답변이 마음에 들지 않을 수도 있습니다. 설계 및 구현 문제가 있습니다. 효율적으로 색인을 생성하지 않습니다.

진지하게, 만약 당신이 그 크기의 인덱스를 반드시 유지해야 한다고 생각한다면, 당신이 찾는 모든 데이터베이스 제품의 RAM에 엄청나게 큰 인덱스를 유지하는 동일한 문제에 직면하게 될 것입니다. 해당 인덱스를 저장하려면 고용량 서버(DL380 G7이 이를 만들 수 있고 중급 상용 서버이므로 이색적이지 않음)를 구입해야 합니다.

도움을 주기 위해 "mongodb optimizing indexes"를 검색하면 몇 가지 유용한 링크가 나타납니다.

http://www.mongodb.org/display/DOCS/Optimization

http://www.10gen.com/events/indexingmatters

http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/

http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer

연구를 완료한 것에 대해 방어적인 반응을 보일 수도 있지만 프로덕션에서 MongoDB를 사용하는 사람들은 당신이 많은 점을 놓치고 있다는 것을 알고 있습니다.

또한 "요점: MongoDB는 FOSS이지만 이를 실행하려면 하드웨어에 $$$$$$$를 지출해야 합니까? 상용 SW를 구입하는 것이 낫습니다!"라는 의견이 있습니다. 무지와 오만의 비명.

Answer