NoSQL 혁명에 대한 7 가지 확실한 진실

NoSQL 유행어는 몇 년 동안 전이되었습니다. 이러한 빠른 데이터 저장소에 대한 흥분은 중독되어 왔으며 NoSQL의 획기적인 매력을 본 사람만큼 죄책감이 있습니다. 하지만 신혼 여행이 끝 나가고 있습니다. 이제 우리의 열정과 약간의 눈빛을 가진 단단한 진실의 균형을 맞출 때입니다.

우리를 오해하지 마십시오. 우리는 데이터 저장을위한 간단한 메커니즘을 구축하는 최신 실험을 시도하고 있습니다. MongoDB, CouchDB, Cassandra, Riak 및 기타 NoSQL 우수성에서 여전히 깊은 가치를 발견합니다. 우리는 여전히 가장 신뢰할 수있는 데이터 중 일부를 이러한 코드 스택에 넣을 계획입니다. 매일 더 잘 성장하고 더 많은 테스트를 거쳤기 때문입니다.

[추가 : NoSQL 우수성 : 새로운 애플리케이션을위한 새로운 데이터베이스 | 우선 검토 : Oracle NoSQL 데이터베이스 | 데일리 뉴스 레터에서 매일 주요 스토리의 요약을 확인하십시오. ]

그러나 NoSQL 시스템은 완벽한 적합성과는 거리가 멀고 종종 잘못된 방식으로 문지르 기 때문에 우리는 마찰을 느끼기 시작했습니다. 가장 똑똑한 개발자들은 처음부터 이것을 알고있었습니다. 그들은 SQL 매뉴얼을 태우지 않았고 한때 헌신적 인 SQL 공급 업체의 영업 팀에게 불쾌한 그램을 보냈습니다. 아니요, 똑똑한 NoSQL 개발자들은 NoSQL이 "Not Only SQL"을 의미한다고 단순히 언급했습니다. 대중이 두문자어를 잘못 해석했다면 그것이 그들의 문제였습니다.

따라서 크고 작은이 불만 목록은이 사실을 문서화하고 공기를 제거하려는 시도입니다. 그것은 우리가 장단점과 타협을 더 잘 이해할 수 있도록 일을 바로 잡는 것을 의미합니다.

NoSQL의 확실한 진실 No. 1 : JOIN은 일관성을 의미합니다.

사람들이 SQL 시스템에 대해 가지고있는 첫 번째 불만 중 하나는 두 테이블간에 JOIN을 실행하는 데 드는 계산 비용입니다. 아이디어는 데이터를 한곳에 만 저장하는 것입니다. 고객 목록을 보관하는 경우 한 테이블에 주소를 입력하고 다른 모든 테이블에 고객 ID를 사용합니다. 데이터를 가져올 때 JOIN은 ID를 주소와 연결하고 모든 것이 일관성을 유지합니다.

문제는 JOIN이 비쌀 수 있으며 일부 DBA는 복잡한 JOIN 명령을 만들어 마음을 흔들어 가장 빠른 하드웨어조차도 슬러지로 바꾼다는 것입니다. NoSQL 개발자가 JOIN 부족을 기능으로 전환 한 것은 놀라운 일이 아닙니다. 고객의 주소를 다른 모든 것과 동일한 테이블에 보관합시다! NoSQL 방식은 각 개인에 대한 키-값 쌍을 저장하는 것입니다. 때가되면 모두 회수합니다.

아아, 테이블의 일관성을 원하는 사람들은 여전히 ​​JOIN이 필요합니다. 고객에 대한 모든 정보와 함께 고객의 주소를 저장하기 시작하면 종종 각 테이블에 해당 주소의 여러 사본이 생성됩니다. 그리고 복사본이 여러 개인 경우 동시에 모두 업데이트해야합니다. 때로는 작동하지만 작동하지 않으면 NoSQL이 트랜잭션을 지원할 준비가되지 않은 것입니다.

잠깐, 왜 고객 정보가 담긴 별도의 테이블이 없습니까? 이렇게하면 변경할 레코드가 하나뿐입니다. 좋은 생각이지만 이제 자신의 논리로 JOIN을 직접 작성해야합니다.

NoSQL 하드 진실 No. 2 : 까다로운 트랜잭션

속도를 원하기 때문에 테이블에 참여하지 않고 살 수 있다고 가정 해 봅시다. 이는 허용되는 절충안이며 때때로 SQL DBA는 이러한 이유로 테이블을 비정규 화합니다.

문제는 NoSQL로 인해 다양한 항목을 일관되게 유지하기가 어렵다는 것입니다. 여러 테이블에 대한 변경이 함께 이루어 지도록하는 트랜잭션이없는 경우가 많습니다. 이를 위해, 당신은 혼자이며, 충돌은 테이블이 일관되지 않게 만들 수 있습니다.

가장 초기의 NoSQL 구현은 이러한 트랜잭션을 무시했습니다. 그들은 그렇지 않은 경우를 제외하고는 일관된 데이터 목록을 제공 할 것입니다. 즉, 오류가 물질적 차이를 만들지 않는 가장 낮은 값의 데이터를 추구했습니다.

이제 일부 NoSQL 구현은 트랜잭션에 접근하는 것을 제공합니다. 예를 들어, Oracle의 NoSQL 제품은 하나의 노드에 기록 된 데이터에 대한 트랜잭션 제어를 제공하고 여러 노드에서 유연한 양의 일관성을 선택할 수 있도록합니다. 완벽한 일관성을 원하면 각 쓰기가 모든 노드에 도달 할 때까지 기다려야합니다. 다른 여러 NoSQL 데이터 저장소는 이와 같은 구조와 보호 기능을 추가하는 실험을하고 있습니다.

NoSQL의 확실한 진실 3 : 데이터베이스는 스마트 할 수 있습니다.

많은 NoSQL 프로그래머는 가벼운 코드와 간단한 메커니즘이 어떻게 매우 빠르게 작동하는지 자랑하고 싶어합니다. 작업이 NoSQL의 내부처럼 단순 할 때 일반적으로 맞지만 문제가 더 어려워지면 변경됩니다.

JOIN의 오래된 도전을 고려하십시오. NoSQL 프로그래머가 자신의 논리로 자신의 JOIN 명령을 생성하기 시작하면이를 효율적으로 수행하기 시작합니다. SQL 개발자는 JOIN 명령을 최대한 효율적으로 처리하기 위해 수십 년 동안 정교한 엔진을 개발해 왔습니다. 한 SQL 개발자는 자신의 코드를 회전하는 하드 디스크와 동기화하여 머리가 올바른 지점 바로 위에있을 때만 데이터를 요청한다고 말했습니다. 이것은 극단적 인 것처럼 보일 수 있지만 SQL 개발자는 수십 년 동안 유사한 해킹 작업을 해왔습니다.

프로그래머가이 모든 잠재 인텔리전스를 활용하기 위해 SQL 쿼리를 구조화하려고 노력하는 데 며칠을 소비한다는 것은 의심의 여지가 없습니다. 탭하는 것은 간단하지 않을 수 있지만 프로그래머가 그것을 알아 내면 데이터베이스는 정말 노래 할 수 있습니다.

SQL과 같은 정교한 쿼리 언어는 항상 NoSQL에있는 것과 같은 정교하지 않은 쿼리 언어를 능가 할 가능성이 있습니다. 단순한 결과로는 문제가되지 않지만, 동작이 복잡해지면 데이터 바로 옆의 머신에서 SQL이 실행됩니다. 데이터를 가져오고 작업을 수행하는 오버 헤드가 거의 없습니다. NoSQL 서버는 일반적으로 데이터를 이동하는 곳으로 전송해야합니다.

NoSQL의 확실한 진실 4 : 너무 많은 액세스 모델

이론적으로 SQL은 표준 언어로 간주됩니다. 한 데이터베이스에 SQL을 사용하는 경우 다른 호환 버전에서 동일한 쿼리를 실행할 수 있어야합니다. 이 주장은 몇 가지 간단한 쿼리로 작동 할 수 있지만 모든 DBA는 동일한 데이터베이스의 다른 버전에 대한 SQL의 특이성을 배우는 데 수년이 걸릴 수 있음을 알고 있습니다. 키워드가 재정의되고 한 버전에서 작동했던 쿼리가 다른 버전에서 작동하지 않습니다.

NoSQL은 훨씬 더 난해합니다. 바벨탑과 같습니다. 처음부터 NoSQL 개발자들은 가능한 최고의 언어를 상상하려고 노력했지만 상상력이 매우 다릅니다. 이 실험의 온상은 도구 사이를 건너 뛰려고 할 때까지 좋습니다. CouchDB에 대한 쿼리는 매핑 및 축소를위한 한 쌍의 JavaScript 함수로 표현됩니다. 초기 버전의 Cassandra는 Thrift라는 원시 저수준 API를 사용했습니다. 최신 버전은 서버에서 구문 분석하고 이해해야하는 SQL과 유사한 쿼리 언어 인 CQL을 제공합니다. 각각은 나름대로 다릅니다.

각 도구에는 고유 한 특성이있을뿐만 아니라 완전히 다른 철학과 표현 방식이 적용됩니다. 데이터 저장소간에 쉽게 전환 할 수있는 방법은 없으며 앞으로 전환 할 수있는 옵션을 제공하기 위해 많은 글루 코드를 작성해야하는 경우가 많습니다. 시스템에 키와 값의 쌍을 채우는 경우에는 그렇게 어렵지 않을 수 있지만 도입하는 복잡성이 증가할수록 점점 더 악화 될 수 있습니다.

NoSQL 하드 진실 No. 5 : 스키마 유연성은 발생하기를 기다리는 문제

NoSQL 모델의 훌륭한 아이디어 중 하나는 스키마가 필요하지 않다는 것입니다. 즉, 프로그래머는 테이블의 각 행에 사용할 수있는 열을 미리 결정할 필요가 없습니다. 한 항목에는 20 개의 문자열이 첨부되고 다른 항목에는 12 개의 정수가있을 수 있으며 다른 항목은 완전히 비어있을 수 있습니다. 프로그래머는 무언가를 저장해야 할 때마다 결정할 수 있습니다. 그들은 DBA의 허가를 요청할 필요가 없으며 새로운 칼럼을 추가하기 위해 모든 서류를 작성할 필요가 없습니다.

그 모든 자유는 중독성있는 것처럼 들리며 오른손으로는 개발 속도를 높일 수 있습니다. 하지만 세 팀의 개발자가 사용할 수있는 데이터베이스에 정말 좋은 생각일까요? 6 개월 이상 지속될 수있는 데이터베이스에서도 작동 할 수 있습니까?

즉, 개발자는 이전 쌍을 데이터베이스에 던질 수있는 자유를 원할 수 있지만, 네 개가 자신의 키를 선택한 후 5 번째 개발자가되고 싶습니까? 각 개발자가 항목에 사용자의 생일을 추가 할 때 자신의 표현을 키로 선택하는 다양한 "생일"표현을 상상하기 쉽습니다. 개발자 팀은 "bday", "b-day", "birthday"등 거의 모든 것을 상상할 수 있습니다.

NoSQL 구조는 스키마 재 구상을 의미하기 때문에이 문제를 제한하는 지원을 제공하지 않습니다. 완전히 멋진 개발자의 감미로운 느낌을 가혹하게하고 싶지는 않습니다. 스키마가 방해가됩니다.

사실 테이블에 열을 추가하는 것은 큰 문제가 아니며 원칙은 실제로 개발자에게 유용 할 수 있습니다. 개발자가 변수 유형을 지정하도록하는 데 도움이되는 것처럼 개발자가 열에 첨부 된 데이터 유형을 지정하도록하는 것도 도움이됩니다. 예, DBA는 개발자가 해당 열을 첨부하기 전에 양식을 세 번 작성하도록 강제 할 수 있지만 프로그래머가 즉석에서 생성 한 6 개의 다른 키를 처리하는 것만 큼 나쁘지는 않습니다.

NoSQL의 확실한 진실 No. 6 : 추가 사항 없음

모든 행의 모든 ​​데이터를 원하지 않고 단일 열의 합계를 원한다고 가정 해 보겠습니다. SQL 사용자는 SUM 작업을 사용하여 쿼리를 실행하고 하나의 번호 만 다시 보낼 수 있습니다.

NoSQL 사용자는 모든 데이터를 자신에게 다시 전달한 다음 직접 추가 할 수 있습니다. 모든 컴퓨터에서 숫자를 더하는 데 거의 같은 시간이 걸리기 때문에 추가는 문제가되지 않습니다. 그러나 데이터를 전송하는 속도가 느리고 모든 데이터를 전송하는 데 필요한 대역폭이 비쌀 수 있습니다.

NoSQL 데이터베이스에는 몇 가지 추가 기능이 있습니다. 데이터를 저장하고 검색하는 것 외에 다른 작업을하고 싶다면 아마도 직접 수행 할 것입니다. 대부분의 경우 데이터의 전체 사본을 사용하여 다른 컴퓨터에서 수행합니다. 실제 문제는 데이터를 전달하는 데 시간이 걸리기 때문에 데이터를 보유한 머신에서 모든 계산을 수행하는 것이 종종 유용 할 수 있다는 것입니다. 하지만 당신에게는 힘든 일입니다.

NoSQL 솔루션이 등장하고 있습니다. MongoDB의 Map and Reduce 쿼리 구조는 데이터를 정리할 수있는 임의의 JavaScript 구조를 제공합니다. Hadoop은 데이터를 보유하는 머신 스택 전체에 계산을 분산시키는 강력한 메커니즘입니다. 정교한 분석을 구축하기 위해 빠르게 개선되는 도구를 제공하는 빠르게 진화하는 구조입니다. 매우 멋지지만 여전히 새롭습니다. 그리고 기술적으로 Hadoop은 NoSQL과는 완전히 다른 유행어이지만 그 차이는 희미 해지고 있습니다.

NoSQL의 확실한 진실 No. 7 : 적은 도구

물론 NoSQL 스택을 서버에서 실행하고 실행할 수 있습니다. 물론 사용자 지정 코드를 작성하여 스택에서 데이터를 푸시하고 가져올 수 있습니다. 하지만 더 많은 일을하고 싶다면? 멋진보고 패키지 중 하나를 사고 싶다면 어떻게해야할까요? 아니면 그래프 패키지? 아니면 차트 작성을위한 오픈 소스 도구를 다운로드 하시겠습니까?

죄송합니다. 대부분의 도구는 SQL 데이터베이스 용으로 작성되었습니다. 보고서를 생성하거나 그래프를 생성하거나 NoSQL 스택의 모든 데이터로 무언가를 수행하려면 코딩을 시작해야합니다. 표준 도구는 Oracle, Microsoft SQL, MySQL 및 Postgres의 데이터를 스너프 할 준비가되어 있습니다. 데이터가 NoSQL에 있습니까? 그들은 그것에 노력하고 있습니다.

그리고 그들은 그것에 대해 조금씩 노력할 것입니다. NoSQL 데이터베이스 중 하나를 시작하고 실행하기 위해 모든 후프를 뛰어 넘더라도 다음 시스템을 처리하려면 처음부터 다시 시작해야합니다. 20 가지가 넘는 NoSQL 선택 항목이 있으며, 모두 고유 한 철학과 데이터 작업 방식을 자랑합니다. 도구 제작자가 SQL의 특이성과 불일치를 지원하는 것은 충분히 어려웠지만 도구가 모든 NoSQL 접근 방식에서 작동하도록 만드는 것은 훨씬 더 복잡합니다.

이것은 서서히 사라질 문제입니다. 개발자는 NoSQL의 흥분을 느낄 수 있으며 이러한 시스템과 함께 작동하도록 도구를 수정하지만 시간이 걸립니다. 아마도 MongoDB에서 시작될 것입니다. 이것은 Cassandra를 실행하고 있기 때문에 도움이되지 않을 것입니다. 표준은 이와 같은 상황에서 도움이되며 NoSQL은 표준에 적합하지 않습니다.

요약하자면 NoSQL의 단점

이러한 모든 NoSQL 단점은 하나의 간단한 문장으로 줄일 수 있습니다. NoSQL은 속도를 위해 기능을 버리는 것입니다. 기능이 필요하지 않으면 괜찮지 만 나중에 필요하면 죄송합니다.

혁명은 기술 문화에 고유합니다. 새로운 그룹이 와서 지난 세대가 왜 그렇게 복잡한 것을 만들 었는지 궁금해하고 오래된 기관을 무너 뜨리기 시작했습니다. 잠시 후 그들은 모든 오래된 기관이 왜 그렇게 복잡한 지 깨닫기 시작하고 기능을 다시 구현하기 시작합니다.

일부 프로젝트가 트랜잭션, 스키마 및 표준처럼 보이는 것을 다시 추가하기 시작하면서 NoSQL 세계에서 이것을보고 있습니다. 이것이 진보의 본질입니다. 우리는 그것들을 다시 짓기 위해서만 분해합니다. NoSQL은 혁명의 첫 번째 단계로 끝났고 이제 두 번째 단계가 시작되었습니다. 왕이 죽었습니다. 폐하, 만수 무 강하 시옵소서.

관련 기사

  • NoSQL 우수성 : 새로운 애플리케이션을위한 새로운 데이터베이스
  • 우선 검토 : Oracle NoSQL 데이터베이스
  • NoSQL 활용 : MongoDB 검토 중
  • MySQL의 10 가지 필수 성능 팁
  • 관리자를위한 10 가지 필수 MySQL 도구
  • Amazon 클라우드의 마스터 MySQL
  • NoSQL 표준의 시대는 지금

"NoSQL 혁명에 대한 7 가지 확실한 진실"이라는이 이야기는 원래 .com에 게시되었습니다. .com에서 데이터 관리의 최신 개발을 따르십시오. 비즈니스 기술 뉴스의 최신 소식을 보려면 Twitter에서 .com을 팔로우하십시오.