NoSQL 데이터베이스를 사용하는 전자 상거래 웹 사이트가 있습니까?
CouchDB, MongoDB 등과 같은 'NoSQL'데이터베이스에 대해 최근에 많이 읽었습니다. 제가 본 웹 사이트의 대부분은 주로 The New York Times 및 Source forge와 같은 텍스트 기반 웹 사이트입니다.
결제가 큰 문제인 웹 사이트에 이것을 적용 할 수 있는지 궁금합니다. 다음 문제를 생각하고 있습니다.
- 데이터를 얼마나 잘 보호 할 수 있습니까?
- 이러한 시스템이 간편한 백업 / 복원 메커니즘을 제공합니까?
- 트랜잭션이 커밋 / 롤백을 처리하는 방법
몇 가지 측면을 다루는 다음 기사를 읽었습니다.
이 게시물에서 다루는 경우 거래의 측면. 그러나 보안 및 백업 문제는 다루지 않습니다. 누군가이 주제에 대해 밝힐 수 있습니까?
그리고 가능하다면 문서 기반 데이터베이스를 성공적으로 구현 한 전자 상거래 웹 사이트를 아는 사람이 있습니까?
편집 : 2013 년 3 월
원래 MongoDB 및 전자 상거래에 대해 작성한 기사에 대한 링크를 게시했지만 더 이상 거기에서 작성한 모든 내용에 동의하지 않습니다. 나는 여전히 MongoDB의 문서 데이터 모델이 전자 상거래 사이트의 카탈로그 관리 측면과 아마도 쇼핑 카트에 대해 매우 잘 작동 할 수 있다고 믿습니다. 그러나 트랜잭션이 중요한 경우가 분명히 있으며 MongoDB는이를 제공하지 않습니다. 다음으로 많은 표를 얻은이 질문에 대한 답은 고려할 가치가있는 많은 포인트를 만듭니다.
관심있는 사람들을위한 원본 기사는 다음과 같습니다.
http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ (archive.org 링크)
RDBMS를 너무 느리게 만드는 오버 헤드는 ACID 라고도하는 원 자성, 일관성, 격리, 내구성을 보장 합니다. 이러한 속성 중 일부는 돈을 다루는 애플리케이션에 매우 중요합니다. 불이 꺼질 때 하나의 주문을 잃고 싶지 않습니다.
NoSQL 데이터베이스는 일반적으로 오버 헤드를 크게 줄이는 대가로 ACID 속성의 일부 또는 전체를 희생합니다. 많은 응용 분야에서 이것은 괜찮습니다. 불이 꺼질 때 몇 개의 "굴착기"가 사라지면 별 문제가 아닙니다.
전자 상거래 사이트의 경우 실제로 필요한 것이 무엇인지 스스로에게 물어봐야합니다.
- RDBMS가 제공 할 수없는 수준의 성능이 정말로 필요합니까?
- RDBMS가 제공하는 안정성이 필요합니까?
솔직히 2 번에 대한 대답은 대부분의 NoSQL 솔루션을 배제하는 "예"일 것입니다. 그리고 amazon.com에 필적하는 트래픽 수준을 다루지 않는 한 RDBM은 보통의 하드웨어에서도 성능 요구 사항을 잘 충족 할 것입니다. 특히 간단한 쿼리로 제한하고 적절하게 인덱싱하는 경우 더욱 그렇습니다. 이것은 # 1에 대한 답을 "아니오"로 만듭니다.
당신은 할 수 있지만, 트랜잭션 데이터에 대한 RDBMS를 사용하는 것을 고려하고, NoSQL에 등 제품 페이지, 사용자 리뷰, 같은 중요하지 않은 데이터에 대한 데이터베이스하지만 당신은 설치하는 많은 데이터 저장소 소프트웨어로 두 번있는 것, 그리고 사이의 관계 두 데이터 저장소의 데이터는 코드로 관리해야합니다. RDBMS에 대해 NoSQL 데이터베이스를 조인 할 필요가 없습니다. 이로 인해 불필요한 수준의 복잡성이 발생할 수 있습니다.
결국, RDBMS가 안정성을 위해 갖추어야하는 기능을 제공하고 경험하게 될 부하에 대해 허용 가능한 성능을 제공한다면 RDBMS가 가장 좋은 방법 일 것입니다.
재무 정보 처리는 SQL이 실제로 작업에 적합한 도구 인 영역 중 하나입니다. 대부분의 NOSQL 시스템은 더 높은 데이터 손실 또는 불일치를 수용하여 확장 성을 향상 시키도록 설계되었습니다. 또한 일반적인 대규모 웹 사이트에서는 단일 레코드를 찾고 표시하는 데 충분한 데이터 만 인덱스에 필요하기 때문에 모든 레코드에 대해 보고서를 실행할 수있는 기능이 제한되는 경향이 있습니다. 나머지는 찾고있는 레코드를 알 때까지 완전히 액세스 할 수 없습니다. 에 대한.
돈을 다룰 때 데이터 불일치가 큰 문제이며 단일 SQL 서버가 제공 할 수있는 것보다 더 많은 확장 성이 필요한 경우 SQL 확장 비용을 감당할 수있는 충분한 돈이 있습니다. 또한 SQL에서 사용할 수있는 임시보고 기능은 SQL을 사용하지 않으면 놓칠 수있는 것입니다. 판매 내역에 대해 원하는 거의 모든 정보는 SQL에서 가져 오기가 쉽지 않지만 잠재적으로 개체 기반의 복잡한 사용자 지정 코드가 필요할 수 있습니다. 저장.
보안이 관계형 데이터베이스와 NoSQL 데이터베이스에서 다를 것이라고 생각하지 않습니다. 결국 보안은 데이터가 실제로 저장되는 방식에 대한 직교적인 질문입니다. 게다가 네트워킹 관점에서 비즈니스 계층 서버를 제외하고는 데이터베이스에 대한 액세스를 허용하는 것과는 다릅니다.
백업의 경우, 내가 아는 대부분의 NoSQL 데이터베이스는 일반 데이터베이스와 마찬가지로 핫 백업을 허용합니다.
진짜 질문 인 IMO는 NoSQL 데이터베이스가 부과하는 제한, 특히 임시 쿼리의 일반적인 부족을 감수 할 수 있는지 여부입니다. 예를 들어, 제품 "X"를 구입 한 모든 사람들을 알고 싶다면 데이터 액세스 계층에 첫날부터 카운터를 구축해야합니다 (또는 모든 과거에 대해 매우 값 비싼 직렬 조회를 실행해야합니다). 트랜잭션). 일반 SQL 데이터베이스에서는 인덱스를 추가하고 쿼리를 수행하면됩니다 (또는 일회성 인 경우 인덱스를 추가하지 않음). 또는 최신 버전이 나오기 전에 제품 "Y"를 구입 한 모든 사람들을 찾고 싶을 수도 있습니다 (그러면 업그레이드 알림을 보낼 수 있습니다). 다시 한번, NoSQL 데이터베이스로 미리 계획해야하지만 관계형 데이터베이스에서는 사소합니다.
I think it makes sense when you can plan your schema and your usage pattern ahead of time, and where the occasional re-scan of records to add some new field or metric is acceptable. But for an e-commerce website, I think ad-hoc queries are just too valuable a feature to lose. Of course, that's just my opinion, and there's certainly no reason why you couldn't mix-n-match parts of the application between the two databases. I'd personally choose a relational database with memcached in between for added performance, though...
You guys should check this out:
Replication Acknowledgement via getlasterror
MongoDB is on the verge of providing durable writes. I think that is the main issue with people discuss this topic w.r.t. money. The transactional part is less important due to the nested document features.
Gilt.com uses Voldemort to handle basket / inventory under huge load. See this presentation from London QCon 2010 on the details - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe
I'd also reiterate the fact that "NoSQL" does not mean "No SQL", but "Not Only SQL", and that instead of looking at any technology for a complete rip/replace of any other you should be looking at the best tool for the job. NoSQL data stores don't make very good data warehouses, and probably aren't appropriate for storing user transactions, but they are very good in certain niche areas - see the Gilt Groupe example above.
Another prominent example is the BBC homepage - not transactional, but interesting nonetheless. They use CouchDB to store user preferences. Unfortunately, they appear to have crashed under the load.
[UPDATE: I can also confirm that ASOS Marketplace uses some NoSQL components - http://bagcheck.com/bag/9206-asos-marketplace-technology ]
Here are a bunch of commercial web applications that use MongoDB, which is one of the more popular NoSQL databases.
http://www.mongodb.org/display/DOCS/Production+Deployments
That's not exactly e-commerce sites per se, but many are NoSQL-powered aspects that the businesses depend upon. I can confirm that ChatPast is entirely done on MongoDB. We do e-commerce but that is off-loaded to Chargify due to security / processing concerns rather than being afraid of doing commerce on MongoDB.
Yes, http://myestoreapp.com uses MongoDB for everything. Check it out; feel free to shoot over any questions.
'Nice programing' 카테고리의 다른 글
| 정규식 자바 스크립트에서 물음표 이스케이프 (0) | 2020.10.18 |
|---|---|
| SPAN의 높이 속성을 설정하는 방법 (0) | 2020.10.18 |
| has_and_belongs_to_many 대 has_many through (0) | 2020.10.18 |
| jQuery-DIV로 커서 따라 가기 (0) | 2020.10.18 |
| 프로그램 종료 전에 작업 수행 (0) | 2020.10.18 |