Webshop 스토리지를 NoSQL 솔루션으로 이동

Question

SQL Server 관계형 데이터베이스를 기반으로하는 webshop 솔루션을 사용했다면, NoSQL 스토리지로 이동하는 이유는 무엇입니까? 관계에 크게 의존하는 데이터 저장소를 NoSQL으로 마이그레이션하는 것이 의미가 있습니까? 처음부터 시작한다면, 잠시 후에 기사, 분류, 세금 계산서, 가격표 등과 같은 테이블의 묶음과 그 사이의 관계의 크기로 끝날 웹샵 프로젝트에 대해 관계형 데이터베이스에 NoSQL 솔루션을 선택 하시겠습니까? ?

MongoDB에 대한 .NET (4.0) 또는 .NET 4.0에 대한 MongoDB 지원에 대한 지원은 무엇입니까? MongoDB를위한 EF 마법사, L2SQL 마법사 등과 같은 풍부한 코드 생성 도구를 사용할 수 있습니까?

NoSQL은 문서 저장소, 간단한 개체 모델에 가장 적합합니다.

이 질문에 대한 귀하의 답변은 적절한 인프라 설계 결정을 내리는 데 도움이 될 것입니다.

업데이트 : ASP.NET MVC에서 솔루션을 개발하고 모델 클래스를 많이 사용하는 경우 DB4o를 선택하여 데이터 저장소간에 개체를 직렬화 및 비 직렬화하는 것이 가장 쉬운 방법일까요?

Answer 1

글쎄, 꽤 개방적인 질문입니다. 기존 소프트웨어

음을위한 NoSQL에-데이터 저장소에

마이그레이션은 종종 기존의 관계형 기술에 대한 경험과 지식이 많이있다. 응용 프로그램이 정상적으로 실행되면 노력할 가치가 없을 것입니다. 그러나 현재 솔루션에 해결할 수없는 문제가있는 경우 옵션입니다.

그것도 많이되는 NoSQL에 대한 관계에 의존하는 데이터 저장소를 마이그레이션 할 의미가 있습니까?

그럼 세 가지 기술 (Document-DB, RDBMS, 개체 데이터베이스)이 서로 매우 다르다는 점을 고려해야합니다.

• 관계형 세계에서는 데이터를 표준화하고 런타임에 함께 결합합니다. 데이터 크기가 커지지 않는 한이 작업은 정상적으로 작동합니다. 여기에서 종종 문제가 시작됩니다. 많은 양의 정규화 된 데이터가있을 때 많은 조인이 필요하며 많은 비용이 소요됩니다. 물론 개체와 테이블 간의 매핑이 까다로울 수 있습니다.
• 개체 데이터베이스에서 각 개체는 개별적으로 저장되고 '관계'는 포인터 형식으로 저장됩니다. 따라서 객체 A가 객체 B에 대한 참조를 가질 때, 객체 - 데이터베이스는이 참조를 저장합니다. 따라서 '관계'를 검색하려면 조인 작업이 필요하지 않습니다. 그러므로 '관계'는 싸다. 결론적으로 객체 데이터베이스는 관계를 처리하는 데 실제로 유용합니다.
• MongoDB와 같은 문서 데이터베이스에서 완전한 개체 그래프가 문서로 저장됩니다. document-database는 문서 수준에서 작동합니다. 그래서 여기에는 진정한 '관계'가 없습니다. 일반적으로 문서를 저장 /로드합니다. 따라서 대부분의 작업이 단일 문서에서만 작동하도록 시나리오를 모델링 할 수 있다면 매우 효과적이며 쉽게 수행 할 수 있습니다.

여기에 MongoDB를 (문서 데이터베이스) 및 db4o는 (객체 데이터베이스)를 모델 데이터베이스에 맞아야 결국

의 디자인 차이를 비교하는 좋은 blog-post을합니다. 예를 들어, 관계 데이터베이스에 대해 모델을 사용하고 문서 데이터베이스에 1 : 1을 저장하려고 시도하지 마십시오. Ayende's blog about modeling for a object-database도 참조하십시오.

MongoDB 또는 MongoDB에서 .NET 4.0을 지원하는 .NET (4.0)의 지원 기능은 무엇입니까?

Gates VP has already answered this for MongoDB. db4o의 .NET 4.0 버전이 개발 중입니다. 한편 3.5 버전은 4.0 프레임 워크에서도 잘 작동합니다.

MongoDB에 대해 EF 마법사, L2SQL 마법사 등과 같은 풍부한 코드 생성 도구를 사용할 수 있습니까?

MongoDB 및 db4o의 경우 코드를 생성 할 필요가 없습니다. 클래스가 스키마입니다. 개체를 저장하면 데이터베이스가 나머지 개체를 처리합니다.또한 Gates VP answer

내가 지금까지 읽은 것처럼 NoSQL은 문서 저장, 단순한 개체 모델에 가장 적합하기 때문에.

범위가 상당히 넓습니다. 정말 간단한 키 - 값 저장소에서 고급 문서 데이터베이스, 열 기반 데이터베이스, 그래프 데이터베이스 및 개체 데이터베이스에 이르기까지 다양합니다.

물론 문서 데이터베이스 (예 : 블로그 소프트웨어)를 저장할 때 문서 데이터베이스가 탁월합니다. 그래프 및 객체 데이터베이스는 극단적 인 복잡한 데이터 구조를 처리하는 데 적합합니다.

Answer 2

좋아, 그게 많은 질문이야, 내가 실제로 말할 수있는 것들을 보자.

기존 관계형 데이터 스토어를 마이그레이션하는 것이 합리적입니까?

정말 큰 성능 문제가있는 경우가 아니면. 여기 거래가 "웹 스케일"성능 문제는 일반적으로 비정규 화에 의해 해결됩니다. MongoDB는 본질적으로 비정규 화 된 데이터베이스입니다.

처음부터 시작, 당신은 인터넷 쇼핑몰 프로젝트에 대한 관계형 하나 이상되는 NoSQL 솔루션을 선택한다면

...

예. MongoDB는 일반적인 웹 기반 프로젝트에 매우 자연스럽게 적합합니다. 그러나 SQL 경험이 많다면 아마도 약간의 어색함을 느낄 것입니다.

.NET 4.0 지원? MongoDB를위한 EF 마법사, L2SQL 마법사 등과 같은 풍부한 코드 생성 도구를 사용할 수 있습니까?

Mongo에는 .NET 용 드라이버가 있습니다.

Mongo 용 L2SQL 또는 EF 마법사는 없지만 실제로는 없어야합니다. 솔직히, 가장 많이 놓친 부분은 DB를 분석하기위한 Enterprise Manager입니다.

MongoDB에는 EF 마법사가 필요하지 않습니다. EF는 DB와 객체 간의 "임피던스 불일치"에 대한 MS의 솔루션입니다. MongoDB에는 "임피던스 불일치"가 없으므로 DB에있는 객체를 채우고 이동하십시오. L2SQL에서도 마찬가지입니다. 사람들은 약간의 Linq 지원 (빠른 구글)을 만들었지 만 조인과 같은 것들은 작동하지 않을 것입니다. 몽고는 조인을하지 않습니다.

"데이터 개체"관점에서 볼 때 Mongo는 매우 간단한 프레임 워크 만 있으면됩니다. 솔직히 DB에 속성을 채우는 것만 큼 간단합니다. "열 추가"를 원하면 개체에 속성을 추가하기 만하면 DB에 저장이 시작됩니다. 그래서 L2SQL과 같은 것들은 정말로 불필요 해지기 시작합니다.

틀리게하지 마라. 다른 쿼리 패러다임을위한 여지가 있지만, 당신은 새로운 영역에있다. (모든 키 - 값 및 문서 - 지향 상점을위한 것입니다).