그래서... 이 NoSQL 같은 것은

그래서... 이 NoSQL 같은 것은

저는 MongoDB를 보고 있는데 매료되었습니다.약간 다른 방식으로 데이터베이스를 구성하는 대신 CPU와 RAM이 있는 만큼의 성능을 무료로 제공받는 것으로 보입니다.우아하고 유연해 보이지만 레일즈처럼 빠르게 거래하는 건 아닙니다.그래서 꿍꿍이 속이 뭔데요?관계형 데이터베이스는 내가 Mongo와 함께 할 수 없거나 전혀 할 수 없는 것을 나에게 무엇을 제공합니까?다시 말해, (기존 NoSQL 시스템의 미숙함과 변화에 대한 저항성을 제외하고) 전체 산업이 MySQL에서 뛰어오르지 않는 이유는 무엇입니까?

제가 이해한 바로는, 확장하면 MySQL이 Memcache를 공급하게 됩니다.이제 저는 처음부터 똑같이 성과가 있는 것으로 시작할 수 있는 것 같습니다.

인간관계를 초월한 거래는 할 수 없다는 걸 알아요이것이 언제 큰 일이 될까요?

저는 http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html 을 읽었지만, 제가 이해하기로는, 그의 주장은 기본적으로 실제 도구를 사용하는 실제 기업은 SQL을 피할 필요가 없기 때문에 SQL을 버릴 필요가 있다고 느끼는 사람들은 SQL을 잘못하고 있다는 것입니다.하지만 어떤 "기업"도 페이스북이나 구글만큼 많은 동시 사용자를 상대할 필요가 없기 때문에 그의 요점을 잘 모르겠습니다. (월마트는 180만 명, 페이스북은 3억 명의 사용자를 보유하고 있습니다. 3억 명의 사용자가 있습니다.)

난 진심으로 이것이...트롤링 안한다고 약속할게요

저도 MongoDB의 열렬한 팬입니다.그렇긴 하지만, RDBMS를 완전히 대체하는 것은 절대 아닙니다. 페이스북은 3억 명의 사용자를 가지고 있지만, 만약 당신의 친구들 중 일부가 목록에 한 번 나타나지 않거나, 가끔 요청할 때 사진 앨범 중 하나가 누락된다면, 당신은 알아차릴 수 있습니까?아마 아닐 것입니다.상태 업데이트가 몇 분 동안 모든 친구에게 전달되지 않더라도 상관이 있습니까?전혀.월마트의 대차대조표가 일치하지 않으면 누군가가 머리를 잃을까요?물론입니다.

NoSQL 데이터베이스는 관계가 엄격하지 않고 데이터 무결성이 동기화되지 않는 "퍼지" 환경에 적합합니다.RDBMS는 데이터 세트가 매우 복잡하고 관계적인(따라서 이름) 경우에도 여전히 중요하며 순수한 상태를 유지해야 합니다.

NoSQL에 대한 큰 추진은 지난 30년 동안 RDMBS 시스템을 두 시나리오 모두에 사용해 왔다는 사실에서 비롯되었습니다.이제 여러 상황에 적합한 툴이 있습니다.사실, 어떤 사람들은 가장 많이 논쟁할 것입니다.하지만 아무도 모든 것을 주장하지 않을 것입니다.

저는 이것을 렉스의 답변에 대한 논쟁으로 씁니다.

나는 nosql이 관계없고 모호하다는 생각에 이의를 제기합니다.

저는 수년 전에 C와 코볼과 함께 CODASYL과 함께 일했습니다. CODASYL에서는 엔티티 관계가 매우 밀접합니다.

대조적으로, 관계형 데이터베이스 시스템은 관계에 대해 매우 자유로운 정책을 가지고 있습니다.외부 키를 식별할 수 있는 한 특별한 관계를 형성할 수 있습니다.

SQL이 RDBMS와 동의어인 것으로 간주되는 경우가 많지만, 사람들은 CODASYL, XML, 반전 세트 등을 위한 SQL 드라이버를 작성해 왔습니다.

RDBMS/SQL은 데이터 또는 관계의 정밀도와 같지 않습니다.사실, RDBMS는 관계에 대한 부정확함과 잘못된 인식에서 지속적인 원인이었습니다.예를 들어 RDBMS가 어떻게 하둡보다 더 나은 데이터 및 관계 무결성을 제공하는지 모르겠습니다.JDO 레이어를 구축하면 하둡에 있는 엔티티 간의 양호하고 깨끗한 관계 네트워크를 구축할 수 있습니다.

하지만 SQL을 사용하면 애드혹 관계를 스크립팅할 수 있는 기능이 제공되기 때문에 애드혹 관계가 관계를 왜곡하고 문제를 일으키는 지속적인 원인이라는 것을 알 수 있습니다.

비즈니스 및 산업 프로세스의 통계 분석을 통해 작업할 수 있는 기회를 얻은 SQL은 이전에 어떤 관계도 인식되지 않았던 관계를 탐색할 수 있는 능력을 제공했습니다.통계 분석 작업을 할 수 있는 기회는 SQL 프로그래머가 일반적으로 생각할 수 없는 통찰력을 주었습니다.

예를 들어 프로세스 집합을 반영하도록 스키마를 설계하고 정규화할 수 있습니다.여러분이 깨닫지 못할 수도 있는 것은 관계가 시간이 지남에 따라 변한다는 것입니다.통계적 특성을 통해 스키마가 이전처럼 "적절하게 정규화"되지 않을 수 있음을 알 수 있습니다.프로세스의 주요 구성 요소가 시간이 지남에 따라 변형되었음을 나타냅니다.그러나 통계적이지 않은 프로그래머들은 이를 이해하지 못하고 RDBMS가 데이터 무결성과 관계 정밀도를 위한 완벽한 솔루션이라고 계속해서 주장하고 있습니다.

그러나 관계 연결 데이터베이스에서는 관계에 있는 도면요소를 나타나는 대로 연결할 수 있습니다.관계가 변형되면 연결은 자연스럽게 데이터와 함께 변형됩니다.스키마를 재규격화하는 비용이 많이 들지 않고 데이터베이스 시스템 내에서 관계와 그 돌연변이를 문서화합니다.이 시점에서 RDBMS는 임시 ddb로만 사용할 수 있습니다.

그러나 RDBMS를 사용하면 관계를 유연하게 변형할 수 있습니다. 이는 SQL이 가장 잘 수행하기 때문입니다.맞습니다. BCNF 또는 4NF를 수행하는 한 매우 사실입니다.그렇지 않으면 쿼리와 데이터 로더가 복제된 작업을 수행하는 것을 볼 수 있습니다.그러나 RDBMS 사업에서 오랜 세월을 보내셨다면 적어도 BCNF는 매우 비싸고 운영상 비효율적이며 우리가 계획을 망친 2.5NF에 대해 지속적으로 유죄라는 것을 깨달으셨을 것입니다.

RDBMS와 SQL이 데이터와 관계의 무결성을 촉진한다고 말하는 것은 완전히 잘못된 표현입니다.너무 작은 회사에서 일하거나 2년 이상 자리에 머무르지 않은 경우 RDBMS로 인해 발생하는 데이터의 양이나 정보의 변형 및 문제를 볼 수 없습니다.RDBMS의 남용은 경영진이 컴퓨터 애플리케이션에 의해 보기에 제한을 받는 원인이며, 기업들이 사랑하는 RDBMS 스키마를 존중하는 것에 제한을 받은 프로그래머들에 의해 보기가 제한되었기 때문에 시장 행동의 변화를 보지 못하는 기업들의 재정적 실패의 원인입니다.

그렇기 때문에 SQL 프로그래머들은 왜 당신의 회사 통계학자가 당신이 꼼꼼하게 만든 당신의 애플리케이션을 사용하기를 거부하는지 이해하지 못하지만 그들은 대학 인턴을 고용하여 개인 서버에 데이터를 다운로드하기 위해 SQL을 작성하고 당신의 회사 임원들은 당신의 회사 대신 회계사와 통계학자의 스프레드시트를 신뢰하는 법을 배웁니다.애플리케이션이 프로세스와 함께 변형되지 않기 때문에 우아한 다중 계층 애플리케이션을 사용할 수 있습니다.

불가능할 수도 있지만 시간이 지남에 따라 프로세스가 어떻게 변형되는지 인식할 수 있는 통계적 이해를 얻어서 올바른 기술적 결정을 내릴 수 있도록 권장합니다.

사람들이 SQL을 사용하지 않는 이유는 임시 관계 분석을 수행할 수 있는 SQL과 같은 좋은 스크립팅 환경이 없기 때문입니다.SQL이 없는 기술이 정확성이나 무결성이 부족하기 때문은 아닙니다.오늘날 우리가 가지고 있는 빠르고 민첩한 애플리케이션 개발 태도와 전략 때문에 임시 관계 분석은 매우 중요합니다.

한 번에 하나씩 질문을 드리겠습니다.

인간관계를 초월한 거래는 할 수 없다는 걸 알아요이것이 언제 큰 일이 될까요?

사진 계단식 삭제.또는 기본적인 참조 무결성.외부 키의 개념은 "수집"(테이블의 몽고 용어)에 걸쳐 적용될 수 없습니다.단일 "문서"(일명 AKA 레코드)에 대해서만 원자적 쓰기를 수행할 수 있습니다.따라서 DB에 문제가 있는 경우 DB의 데이터를 분리할 수 있습니다.

CPU와 RAM이 있는 만큼의 성능을 무료로 얻을 수 있습니까?

무료는 아니지만, 확실히 다른 절충안이 있습니다.예를 들어, Mongo는 단일 레코드, 키/값 조회를 실행하는 데 탁월합니다.그러나 Mongo는 관계형 쿼리를 실행하는 데 서툴러요.대부분의 경우 map-reduce를 사용해야 합니다.Mongo는 "RAM 창녀"입니다.Mongo는 기본적으로 중요한 데이터 세트에 대해 64비트를 요구합니다.Mongo는 드라이브 공간을 흡수하고 140GB DB를 로드하며 사용 중 스왑 파일이 증가함에 따라 200GB 이상을 사용할 수 있습니다.

그리고 여전히 빠른 드라이브를 원할 것입니다.

사실 MongoDB는 최첨단 하드웨어(64비트, 많은 RAM, SSD)를 지원하는 DB 시스템이라고 해도 과언이 아닙니다.즉, 전체 DB는 RAM에서 데이터 인덱스 데이터를 검색하고(Hello 64비트) 드라이브에서 집중적인 랜덤 검색을 수행하는(Hello SSD) 중심입니다.

전체 업계가 MySQL에서 뛰어내리지 않는 이유는 무엇입니까?

1. ACID를 준수하지 않습니다.아마 은행 시스템에 상당히 좋지 않을 것입니다(물론 대부분은 여전히 플랫 파일을 처리하고 있지만, 그건 다른 문제입니다).그러나 Mongo를 사용하여 "안전한" 쓰기를 강제로 수행하고 데이터가 디스크에 도달하도록 보장할 수 있지만 한 번에 하나의 "문서"만 사용할 수 있습니다.
2. 그것은 아직 매우 어립니다.많은 대기업들이 여전히 VB6로 작성된 SQL Server 2000 앱에서 이전 버전의 Crystal Reports를 실행하고 있습니다.또는 엔터프라이즈 서비스 버스를 구축하여 수년간 구축한 이기종 환경을 관리하고 있습니다.
3. 그것은 매우 다른 패러다임입니다.아마도 제가 Mongo 메일링 목록(그리고 여기)에서 정기적으로 보는 질문의 30%는 기본적으로 "X 쿼리를 어떻게 하나요?" 또는 "이 데이터를 어떻게 구성하나요?"와 관련이 있을 것입니다.MongoDB를 사용하려면 일반적으로 사전에 정규화를 해제해야 합니다.이것은 조금 어려울 뿐만 아니라 훈련되지 않았습니다.대부분의 사람들은 학교에서 "정상화"만 배울 뿐, 아무도 우리에게 성과를 위해 정상화하는 방법을 가르쳐주지 않습니다.
4. 모든 것에 적합한 도구는 아닙니다.솔직히 저는 MongoDB가 거래 데이터를 읽고 쓰는 데 훌륭한 도구라고 생각합니다.현대 앱의 대부분을 구성하는 단순한 "일회성" CRUD.그러나 MongoDB는 보고를 잘 하지 못합니다.사실 다음 단계는 "Mongo for everything"이 아니라 "Mongo for transactional"과 "MySQL for reporting"이라고 솔직히 상상합니다."실시간 보고"를 삭제할 정도로 데이터가 커지면 Map-Reduce를 사용하여 보고 DB를 채우는 것은 그리 나쁘지 않은 것 같습니다.

제가 이해한 바로는, 확장하면 MySQL이 Memcache를 공급하게 됩니다.이제 저는 처음부터 똑같이 성과가 있는 것으로 시작할 수 있는 것 같습니다.

솔직히, 저는 제 프로젝트 중 몇 가지를 위해 이 일을 하고 있습니다.다시 말하지만, 저는 MongoDB가 실제로 유효한 캐싱 계층을 만든다고 생각합니다.실제로 파일 백업 캐슁 계층을 만듭니다.따라서 MySQL 변경 사항을 Mongo로 푸시할 수 있다면 캐시 누락 없이 Memcached를 받을 수 있습니다.또한 새 서버에서 "캐시를 워밍업"하고 파일을 복사하여 올바른 폴더를 가리키기만 하면 Mongo를 시작할 수 있습니다. 이것은 정말 쉽습니다.

Facebook이 데이터스토어에 대해 임의 쿼리를 얼마나 자주 실행한다고 생각하십니까?모든 것이 웹 앱인 것은 아니며, 반대로 모든 데이터 세트를 심층적으로 분석할 필요는 없습니다.

NoSQL은 기본적으로 사람들이 자신의 필요에 따라 적극적으로 결정하지 않고 일부 기본값을 선택했기 때문에 적합하지 않은 작업에 RDBMS를 사용하는 것에 해당하는 것에 대한 반동적인 대응이라고 생각합니다."MySQL"(또는 일반적으로 RDBMS)에서 업계 전반에 걸쳐 동일한 실수를 반복하면 진자가 반대로 흔들리게 됩니다.

MongoDB가 귀하의 사용 사례에 적합하다면 반드시 그렇게 하십시오.사용 사례가 모두 사용 사례라고 가정하지 마십시오.모든 시나리오에 맞는 기술은 없습니다.초음속 제트기의 발명은 화물 열차의 사용을 없애지 못했습니다.

NoSQL에 대한 큰 반발은 많은 NoSQL 옹호자들의 사고방식에 뿌리를 두고 있습니다.구체적으로, "SQL은 너무 어렵다, 나는 그것을 할 필요가 없다"라고 가장 잘 요약된 태도입니다.나는 NoSQL이 많은 경우에 무지를 높이는 것처럼 보이기 때문에 싫어합니다.

인간관계를 초월한 거래는 할 수 없다는 걸 알아요이것이 언제 큰 일이 될까요?

당신이 예상하는 것보다 더 자주.일관된 데이터 세트를 가정할 수 없을 때 잘못될 수 있는 많은 것들이 있습니다.

저는 MongoDB, Redis(키-값 쌍이 목록, 설정 및 정렬 세트를 지원하는 것 이상), Tokyo Trivant, Memcached 및 MySql & Postgre를 사용했습니다.SQL.

NoSQL DB와 SQL 기반 DB 간의 인수는 완전히 근거가 없습니다.사용 사례에 따라 적절한 모델을 선택해야 합니다.ACID 규정 준수가 필요한 경우 Postgre와 같은 SQL DB를 사용합니다.SQL, Oracle 등고성능이 필요하지만 데이터에 대한 관심이 줄어들면 SQL DB가 없는 것으로 간주할 수 있습니다.그것들은 근본적으로 다른 기술입니다.모델의 조합을 사용할 수도 있습니다.NoSQL을 사용하면 관계, 제약 및 트랜잭션이 누락됩니다.사실, 그것이 NoSQL이 더 빠른 이유 중 하나입니다.

MongoDB에서 두 달 동안 집계 데이터를 잃어버리면..어떻게 잃어버렸는지 전혀..하지만 백업이 있었고 몇 분 동안 데이터가 손실되었습니다.MongoDB를 백업과 함께 가져왔습니다.NoSQL을 사용하는 경우 DB 백업을 위해 때때로 백업을 수행하거나 cron 작업을 예약합니다.이는 SQL DB에도 적용됩니다.

SQL RDBMS와 비교하여 NoSQL DB는 더 젊고 현재 본격적인 개발 단계에 있지만 고성능, 간편한 복제를 위한 범위에서 성숙한 NoSQL DB입니다.

제 웹사이트(stacked.in )에서 저는 redis DB만을 사용했고, MySQL보다 훨씬 빠르게 작동합니다.

NoSQL이 완전히 새로운 것은 아닙니다.결국, 그들은 SQL과 관계형 데이터베이스 이전에 무언가를 사용해야 했습니다.사실, MUMPS와 CODASYL과 같은 시스템은 동일한 방식으로 작동하며 수십 년이 되었습니다.관계형 데이터베이스는 임의의 방법으로 데이터를 쿼리할 수 있는 기능을 제공합니다.

고객, 고객의 구매 내역 및 구매한 품목에 대한 데이터베이스가 있다고 가정합니다.NoSQL DB에는 항목을 포함하는 구매 및 구매를 포함하는 고객이 있을 수 있습니다.이렇게 하면 특정 고객이 어떤 항목을 구입했는지 쉽게 알 수 있지만 어떤 고객이 어떤 항목을 구입했는지는 쉽게 알 수 없습니다.관계형 DB에는 고객, 구매, 품목 및 품목과 구매를 연결하는 테이블이 있습니다.SQL에서 두 쿼리는 모두 공식화하기에 사소한 것이며 데이터베이스 엔진이 모든 어려운 작업을 대신 수행합니다.

또한 NoSQL 추세의 일부는 속도, 확장성 및 비용을 위해 일관성 또는 안정성을 희생하는 것입니다.관계형 DB는 확장이 가능하지만 가격이 저렴하지는 않습니다.http://tpc.org 에 가면 RDB를 찾을 수 있습니다.수백 개의 코어에서 동시에 실행되는 MS는 분당 수백만 개의 트랜잭션을 제공하지만 비용은 수백만 달러에 이릅니다.

데이터가 관계형 대수학을 활용하지 않거나 ACID 보장이 필요하지 않으면 해당 용도에만 맞는 언어를 사용하여 아무것도 얻을 수 없습니다.

언급URL : https://stackoverflow.com/questions/3183067/so-this-nosql-thing