나는 최근에 그것을 알았습니다. Red Hat은 Satellite에서 MongoDB 지원을 제거합니다. (라이센스 변경으로 인해 발생한다고 합니다.) 지난 몇 년 동안 MongoDB가 얼마나 끔찍한지, 누구도 그것을 사용해서는 안 된다는 수많은 기사를 봤기 때문에 이런 생각을 하게 되었습니다. 하지만 이 기간 동안 MongoDB는 훨씬 더 성숙한 제품이 되었습니다. 무슨 일이에요? 모든 혐오감이 정말 새로운 DBMS 초기 마케팅의 실수 때문일까요? 아니면 사람들이 MongoDB를 잘못된 곳에서 사용하고 있는 걸까요?

내가 MongoDB를 옹호하고 있다고 느끼신다면 읽어주세요. 부인 성명 기사 끝에서.

새로운 경향

나는 말할 수 있는 것보다 더 오랜 세월 동안 소프트웨어 업계에서 일해왔지만, 여전히 우리 업계를 강타한 트렌드 중 극히 일부에만 노출되었습니다. 나는 4GL, AOP, Agile, SOA, Web 2.0, AJAX, 블록체인 등의 등장을 목격했습니다. 목록은 끝이 없습니다. 매년 새로운 트렌드가 나타납니다. 일부는 빠르게 사라지는 반면 일부는 소프트웨어 개발 방식을 근본적으로 변화시킵니다.

모든 새로운 트렌드는 일반적인 흥분을 불러일으킵니다. 사람들은 탑승하거나 다른 사람들이 생성하는 소음을 보고 군중을 따릅니다. 이 프로세스는 Gartner에 의해 성문화되었습니다. 과대광고 주기. 논란의 여지가 있지만 이 타임라인은 기술이 결국 유용해지기 전에 기술에 어떤 일이 일어나는지 대략적으로 설명합니다.

그러나 때때로 단 하나의 특정 구현에 의해 주도되는 새로운 혁신이 나타나거나 이 경우처럼 두 번째 혁신이 나타납니다. NoSQL의 경우 MongoDB의 출현과 급격한 성장으로 인해 과대 광고가 크게 이루어졌습니다. MongoDB는 이러한 추세를 시작하지 않았습니다. 실제로 대규모 인터넷 회사는 대량의 데이터를 처리하는 데 문제가 발생하기 시작했으며 이로 인해 비관계형 데이터베이스가 다시 등장했습니다. 전반적인 움직임은 Google의 Bigtable 및 Facebook의 Cassandra와 같은 프로젝트에서 시작되었지만 대부분의 개발자가 액세스할 수 있는 가장 유명하고 액세스 가능한 NoSQL 데이터베이스 구현이 된 것은 MongoDB였습니다.

참고: 내가 문서 데이터베이스를 열 기반 데이터베이스, 키/값 저장소 또는 일반적인 NoSQL 정의에 속하는 수많은 다른 유형의 데이터 저장소와 혼동하고 있다고 생각할 수도 있습니다. 그리고 당신 말이 맞아요. 그러나 그 당시에는 혼란이 지배했습니다. 모두가 NoSQL에 푹 빠져, 모두가 되었습니다. 절대적으로 많은 사람들이 다양한 기술의 차이점을 보지 못했지만 필요했습니다. 많은 사람들에게 MongoDB는 동의어 NoSQL.

그리고 개발자들은 이에 대해 비난했습니다. 어떤 문제라도 해결하기 위해 마법처럼 확장되는 스키마 없는 데이터베이스에 대한 아이디어는 매우 유혹적이었습니다. 2014년경에는 XNUMX년 전 MySQL, Postgres 또는 SQL Server와 같은 관계형 데이터베이스를 사용했던 모든 곳에서 MongoDB 데이터베이스를 배포하기 시작한 것으로 보입니다. 이유를 묻는 질문에는 "이것이 웹의 규모입니다"라는 진부한 대답부터 "내 데이터는 매우 느슨하게 구조화되어 있고 스키마 없이 데이터베이스에 잘 맞습니다."라는 좀 더 사려 깊은 대답을 얻을 수 있습니다.

MongoDB와 일반적인 문서 데이터베이스는 기존 관계형 데이터베이스의 여러 가지 문제를 해결한다는 점을 기억하는 것이 중요합니다.

• 엄격한 계획: 관계형 데이터베이스를 사용하면 동적으로 생성된 데이터가 있는 경우 무작위로 "기타" 데이터 열을 생성하거나 거기에 데이터 덩어리를 넣거나 구성을 사용해야 합니다. 에브...이 모든 것에는 심각한 단점이 있습니다.
• 확장의 어려움: 데이터가 너무 많아서 한 서버에 다 들어갈 수 없는 경우 MongoDB는 여러 시스템에 걸쳐 확장할 수 있는 메커니즘을 제공했습니다.
• 복잡한 회로 수정: 마이그레이션이 없습니다! 관계형 데이터베이스에서는 데이터베이스 구조를 변경하는 것이 큰 문제가 될 수 있습니다(특히 데이터가 많은 경우). MongoDB는 프로세스를 크게 단순화할 수 있었습니다. 그리고 진행하면서 회로를 업데이트하고 매우 빠르게 진행할 수 있도록 매우 쉽게 만들었습니다.
• 녹음 성능: MongoDB 성능은 특히 적절하게 구성되었을 때 좋았습니다. 종종 비판을 받았던 MongoDB의 기본 구성조차도 인상적인 성능 수치를 보여주었습니다.

모든 위험은 당신에게 있습니다

MongoDB의 잠재적 이점은 특히 특정 종류의 문제에 대해 엄청났습니다. 문맥을 이해하지 못하고 경험도 없이 위의 목록을 읽는다면 MongoDB가 정말 혁명적인 DBMS라는 인상을 받을 수도 있습니다. 유일한 문제는 위에 나열된 이점에는 여러 가지 주의 사항이 있다는 것입니다. 그 중 일부는 아래에 나열되어 있습니다.

공평하게 말하면 10gen/MongoDB Inc.에는 아무도 없습니다. 다음 내용이 사실이 아니라고 말하지 않을 것입니다. 이는 단지 타협일 뿐입니다.

• 거래 손실: 트랜잭션은 많은 관계형 데이터베이스(전체는 아니지만 대부분)의 핵심 기능입니다. 트랜잭션이란 여러 작업을 원자적으로 수행할 수 있고 데이터의 일관성을 유지할 수 있음을 의미합니다. 물론 NoSQL 데이터베이스를 사용하면 트랜잭션이 단일 문서 내에 있을 수도 있고 XNUMX단계 커밋을 사용하여 트랜잭션 의미를 얻을 수도 있습니다. 하지만 이 기능을 직접 구현해야 합니다. 이는 어렵고 시간이 많이 걸리는 작업이 될 수 있습니다. 작업의 원자성을 보장할 수 없기 때문에 데이터베이스의 데이터가 유효하지 않은 상태가 되는 것을 확인할 때까지 문제가 있음을 깨닫지 못하는 경우가 많습니다. 참고: 많은 사람들이 MongoDB 4.0이 작년에 트랜잭션을 도입했지만 몇 가지 제한 사항이 있다고 말했습니다. 기사의 내용은 동일합니다. 기술이 귀하의 요구 사항을 얼마나 잘 충족하는지 평가하십시오.
• 관계 무결성 손실(외래 키): 데이터에 관계가 있는 경우 이를 애플리케이션에 적용해야 합니다. 이러한 관계를 존중하는 데이터베이스를 보유하면 애플리케이션과 프로그래머의 작업이 많이 줄어듭니다.
• 데이터 구조 적용 능력 부족: 엄격한 스키마는 때로는 큰 문제가 될 수 있지만 현명하게 사용하면 좋은 데이터 구조화를 위한 강력한 메커니즘이기도 합니다. MongoDB와 같은 문서 데이터베이스는 놀라운 스키마 유연성을 제공하지만 이러한 유연성으로 인해 데이터를 깨끗하게 유지해야 하는 책임이 없어집니다. 이를 처리하지 않으면 예상한 형식으로 저장되지 않은 데이터를 설명하기 위해 애플리케이션에 많은 코드를 작성하게 됩니다. 우리 회사 Simple Thread에서 자주 말했듯이... 애플리케이션은 언젠가 다시 작성되지만 데이터는 영원히 유지됩니다. 참고: MongoDB는 스키마 검사를 지원합니다. 유용하지만 관계형 데이터베이스에서와 동일한 보장을 제공하지는 않습니다. 우선, 스키마 검사를 추가하거나 변경해도 컬렉션의 기존 데이터에는 영향을 미치지 않습니다. 새 스키마에 따라 데이터를 업데이트하는 것은 사용자의 몫입니다. 이것이 귀하의 필요에 충분한지 스스로 결정하십시오.
• 네이티브 쿼리 언어 / 도구 생태계 손실: SQL의 출현은 절대적인 혁명이었고 그 이후로 아무것도 변하지 않았습니다. 믿을 수 없을 정도로 강력한 언어지만, 또한 매우 복잡합니다. JSON 조각으로 구성된 새로운 언어로 데이터베이스 쿼리를 구성해야 한다는 필요성은 SQL 작업 경험이 있는 사람들에게는 큰 진전으로 간주됩니다. IDE부터 보고 도구까지 SQL 데이터베이스와 상호 작용하는 다양한 도구가 있습니다. SQL을 지원하지 않는 데이터베이스로 이동한다는 것은 이러한 도구의 대부분을 사용할 수 없거나 이를 사용하려면 데이터를 SQL로 변환해야 한다는 것을 의미하는데, 이는 생각보다 어려울 수 있습니다.

MongoDB로 전환한 많은 개발자는 장단점을 실제로 이해하지 못했고 종종 이를 기본 데이터 저장소로 설치하기 시작했습니다. 그 후에는 돌아오기가 매우 어려운 경우가 많았습니다.

무엇을 다르게 할 수 있었나요?

모든 사람이 머리부터 뛰어내려 바닥에 부딪힌 것은 아닙니다. 그러나 많은 프로젝트에서는 MongoDB가 적합하지 않은 곳에 설치했으며 앞으로도 수년 동안 MongoDB와 함께 살아야 할 것입니다. 이러한 조직이 시간을 들여 기술 선택을 체계적으로 고려했다면 많은 조직이 다른 선택을 했을 것입니다.

올바른 기술을 선택하는 방법은 무엇입니까? 기술 평가를 위한 체계적인 프레임워크를 만들려는 여러 시도가 있었습니다. "소프트웨어 조직에 기술을 도입하기 위한 프레임워크" и "소프트웨어 기술 평가를 위한 프레임워크", 그러나 이것은 불필요한 복잡성인 것 같습니다.

두 가지 기본적인 질문만 하면 많은 기술을 지능적으로 평가할 수 있습니다. 문제는 편견 없이 답변을 찾는 데 시간을 투자하면서 책임감 있게 답변할 수 있는 사람을 찾는 것입니다.

문제가 발생하지 않는다면 새로운 도구가 필요하지 않습니다. 점.

질문 1: 내가 해결하려는 문제는 무엇입니까?

문제가 발생하지 않는다면 새로운 도구가 필요하지 않습니다. 점. 해결책을 찾은 다음 문제를 만들어낼 필요가 없습니다. 새로운 기술이 기존 기술보다 훨씬 더 잘 해결되는 문제에 직면하지 않았다면 여기서 논의할 내용이 없습니다. 다른 사람들이 이 기술을 사용하는 것을 보았기 때문에 이 기술 사용을 고려하고 있다면 그들이 직면한 문제를 고려하고 그러한 문제가 있는지 물어보십시오. 다른 사람들이 기술을 사용하고 있기 때문에 기술을 받아들이는 것은 쉽지만, 문제는 자신이 동일한 문제에 직면하는지 이해하는 것입니다.

질문 2: 내가 무엇을 놓치고 있나요?

이는 확실히 더 어려운 질문입니다. 기존 기술과 신기술을 모두 파고들어 잘 이해해야 하기 때문입니다. 때로는 새로운 것을 사용해 무언가를 만들어 보거나 그러한 경험을 가진 사람이 있을 때까지 새로운 것을 실제로 이해하지 못할 수도 있습니다.

둘 다 없다면 이 상품의 가치를 결정하기 위해 가능한 최소 투자액을 생각하는 것이 합리적입니다. 그리고 한번 투자한 후에는 결정을 되돌리기가 얼마나 어렵나요?

사람들은 항상 모든 것을 망친다

가능한 한 공평하게 이러한 질문에 대답하려고 노력할 때 한 가지를 기억하십시오. 인간의 본성과 싸워야 한다는 것입니다. 기술을 효과적으로 평가하기 위해서는 극복해야 할 인지적 편향이 많이 있습니다. 다음은 몇 가지입니다:

• 다수결의 효과 - 모두가 그에 대해 알고 있지만 여전히 그와 싸우는 것은 어렵습니다. 기술이 실제 요구 사항과 실제로 일치하는지 확인하십시오.
• 참신 효과 — 많은 개발자는 오랫동안 사용해 온 기술을 과소평가하고 새로운 기술의 이점을 과대평가하는 경향이 있습니다. 프로그래머뿐만 아니라 모든 사람이 이러한 인지 편향에 취약합니다.
• 긍정적인 특성의 효과 - 우리는 무엇이 있는지 보고 무엇이 부족한지 잊어버리는 경향이 있습니다. 이는 본질적으로 새로운 기술을 과대평가할 뿐만 아니라 그 단점도 무시하기 때문에 참신함 효과와 결합되면 혼란을 초래할 수 있습니다..

객관적인 평가는 쉽지 않지만 근본적인 인지 편향을 이해하면 보다 합리적인 결정을 내리는 데 도움이 됩니다.

개요

혁신이 나타날 때마다 두 가지 질문에 세심한 주의를 기울여 대답해야 합니다.

• 이 도구가 실제 문제를 해결합니까?
• 우리는 상충관계를 잘 이해하고 있나요?

이 두 가지 질문에 자신있게 대답할 수 없다면 몇 걸음 물러서서 생각해 보세요.

그렇다면 MongoDB가 올바른 선택이었을까요? 물론 예; 대부분의 엔지니어링 기술과 마찬가지로 이는 여러 요인에 따라 달라집니다. 이 두 가지 질문에 답한 사람들 중 많은 사람들이 MongoDB의 혜택을 받았으며 계속해서 혜택을 받고 있습니다. 그렇지 않은 분들도 과대광고 주기를 통과하는 방법에 대해 귀중하고 고통스럽지 않은 교훈을 얻으셨기를 바랍니다.

부인 성명

저는 MongoDB와 사랑도 증오도 관계가 없음을 분명히 하고 싶습니다. 우리는 MongoDB가 해결하기에 가장 적합한 종류의 문제를 겪지 않았습니다. 나는 10gen/MongoDB Inc.를 알고 있습니다. 처음에는 매우 과감하게 안전하지 않은 기본값을 설정하고 MongoDB를 모든 데이터 작업을 위한 범용 솔루션으로 어디에서나(특히 해커톤에서) 홍보했습니다. 아마도 나쁜 결정이었을 것입니다. 그러나 이는 여기에 설명된 접근 방식을 확인시켜 줍니다. 이러한 문제는 기술에 대한 피상적인 평가를 통해서도 매우 빠르게 감지될 수 있습니다.

출처 : habr.com