재고 관리 시스템 용 SQL과 NoSQL

Question

JAVA 기반 웹 응용 프로그램을 개발 중입니다. 주요 목적은 채널이라고하는 여러 웹 사이트에서 판매되는 제품에 대한 인벤토리를 확보하는 것입니다. 우리는이 모든 채널의 관리자 역할을 수행 할 것입니다. 우리가 필요로하는 것 :

1. 큐는 각 채널에 대한 인벤토리 업데이트를 관리합니다.
2. 각 채널에 할당의 올바른 스냅 샷이있는 인벤토리 테이블.
3. 세션 ID 및 기타 빠른 액세스 데이터를 캐시에 보관.
4. 대시 보드 (XMPP)와 같은 페이스 북을 제공하여 판매자를 최대한 빨리 업데이트합니다.

내가 바라는 해결책은 Cassandra, Redis, CouchDB 및 MongoDB와 같은 NoSQL 솔루션 인 Postgres (동기식 복제 모드까지 지금까지 db)입니다.

내 제약 조건은 다음과 같습니다

1. 재고 업데이트가 손실 될 수 없습니다.
2. 작업 대기열은 순서대로 실행되어야하며, 바람직하게는 결코 손실되지 않아야합니다.
3. 쉽고 빠른 개발 및 향후 유지 관리.

나는 어떤 제안이 있어도 열어 본다. 미리 감사드립니다.

Answer 1

NoSQL이이 애플리케이션에 적합하지 않습니다.

제 말은 확실히 사용할 수 있지만 결국 SQL이 제공하는 많은 것을 다시 구현하게됩니다. 예를 들어 저는 거기에 많은 관계가 있음을 봅니다. 일부 NoSQL 솔루션이 제공하고 있지만 ACID도 필요합니다.

관계형 데이터를 관계형 데이터베이스에 보관하고 키/값 저장 소에 비 관계형 데이터를 둘 다 사용할 수있는 이유는 없습니다.

Answer 2

주소 제약 조건은 :

1. 대부분의 NoSQL이 솔루션은 당신에게 성능 대 일관성의 구성 트레이드 오프를 제공합니다. 예를 들어, MongoDB에서는 쓰기가 얼마나 오래 지속될 지 결정할 수 있습니다. 원하는 경우 모든 복제 세트 서버에서 쓰기를 강제로 fsync로 설정할 수 있습니다. 다른 극단에서는 명령을 보내도록 선택할 수 있으며 서버의 응답을 기다리지 않습니다.

2. 순서대로 작업 대기열을 실행하는 것이 응용 프로그램 코드 문제 인 것 같습니다. DB의 타임 스탬프와 대부분의 응용 프로그램에서 수행해야하는 order by 쿼리 유형을 말합니다. 여러 응용 프로그램 서버가 있고 대기열이 완벽해야하는 경우 주문을 제공하는 truly distributed algorithm을 사용해야하지만 이는 일반적인 요구 사항은 아니며 실제로 매우 까다 롭습니다.

3. 우리는 MongoDB를 오랫동안 사용 해왔고, 이것이 앱 개발 속도를 크게 높일 것으로 확신합니다. 유지 보수에는 큰 차이가 없으며, 데이터 유지는 어느 쪽의 방법 으로든 고통스런 일입니다. 스키마가 없으면 유연성이 향상되지만 (게으른 마이그레이션), 더 정교하고 약간의주의가 필요합니다.

요약하면 나는 두 가지 방법으로 모두 할 수 있다고 말하고 싶습니다.NoSQL은 더 많은 코드로 구동되며, 트랜잭션과 관계형 무결성은 대부분 코드에 의해 관리됩니다. 당신이 불편하다면, 관계형 DB를 찾으십시오.

그러나 데이터가 커지면 10B 행 데이터베이스에서 실시간 조인을 원하지 않기 때문에 수동으로이 논리 중 일부를 코딩해야합니다. 그래도 SQL을 사용하여 구현할 수 있습니다.

다른 데이터베이스의 경계를 찾는 좋은 방법은 캐시 할 수있는 것을 고려하는 것입니다. 언제든지 캐시하고 재구성 할 수있는 데이터는 큰 위험이 없으므로 새 레이어를 도입하기에 좋은 방법입니다. 또한 캐시 된 데이터는 대개 관계를 유지하지 않으므로 여기서 일관성을 유지해야합니다.

Answer 3

1. 큐는 각 채널에 대한 인벤토리 업데이트를 관리합니다.

이것은 반드시 데이터베이스 문제는 아닙니다. 당신은 (예를 들어. RabbitMQ) 각 채널에 할당의 정확한 스냅 샷을 가지고

1. 재고 테이블 메시징 시스템을보고 더 나을 수 있습니다.
2. 세션 ID 및 기타 빠른 액세스 데이터를 캐시에 보관.

세션 데이터 아마 (등, 레디 스, 예를 들어, memcached를) 더 작업에 적합한 별도의 데이터베이스에 넣어해야

DB
더 획일적 없다
1. 대시 보드 (XMPP)와 같은 페이스 북을 제공하여 판매자가 가능한 빨리 업데이트되도록합니다.

제한 사항 : 1. 인벤토리 업데이트를 잃어 버릴 수 없습니다. 응용 프로그램에서

1. 이 기능을 제공해야합니다 :

은이 질문에 대답하기 위해 3 가지 방법이 있습니다. 데이터베이스는 잘못된 레코드가 거부되고 롤백되었음을 보장 할 수 있지만 모든 쿼리가 입력 될 것이라고 보장 할 수는 없습니다. 앱이 오류가 발생했을 때이를 인식하고 다시 시도 할만큼 똑똑해야합니다.

일부 DB는 메모리에 레코드를 저장 한 다음 메모리를 디스크로 디스크로 플러시 (peridocally)하며 이로 인해 전원 장애시 데이터가 손실 될 수 있습니다. (예를 들어, Mongo는 저널링을 가능하게하지 않는 한 기본적으로이 방법으로 작동합니다 .CouchDB는 레코드에 플래그를 추가하므로 레코드가 손실됩니다.)

일부 DB는 극도로 지진, 허리케인 또는 기타 자연 재해가 발생하더라도 안정적이며 내구성이 유지됩니다. 이것들은 Cassandra, Hbase, Riak, Hadoop 등을 포함합니다.

어떤 종류의 내구성을 지칭합니까?

1. 작업 대기열 순서대로 실행 바람직 손실되지 않습니다해야합니다.

대부분의 noSQL 솔루션은 병렬로 실행하는 것을 선호합니다. 여기에는 두 가지 옵션이 있습니다. 1. 모든 쿼리에 대해 전체 테이블을 잠그는 DB는 (느리게) 2. 빌드 앱

1. 쉬운/빠른 개발 및 향후 유지 보수 영리 또는 evented (클라이언트 측 연속 대기)합니다.

일반적으로, 당신은 SQL이 처음 개발 속도는 것을 발견 할 것이다, 그러나 변화는 NoSQL에 좀 더 계획이 필요할 수 있습니다 구현하기 어려울 수 있지만, 임시 쿼리 또는 스키마 변경을 할 쉽습니다.

이

1. "나는지도/줄 것을 강렬한 쿼리 나 깊은 분석이 필요 뜻에 더 적합?"

   당신은 아마 자신에게해야 할 질문은 더 같이가

2. "나는 나의 변화 내 스키마 자주?

3. 필요합니다"내 데이터는 매우 관계입니까? 어떤 방법으로? "

4. "DB 선택 내 뒤에 공급 업체 내가 그것을 필요로 할 때 도와 충분한 경험이 있습니까? "

5. "나는 같은 지리 공간 색인, 전체 텍스트 검색으로 특별한 기능이 필요합니다, 등? "

6. "실시간에 얼마나 가까운 거리에 데이터가 필요합니까? 1 초 후까지 최신 기록이 내 검색어에 표시되지 않으면 아플까요? 대기 시간의 어떤 수준이 허용됩니다? "

7. 는"정말 측면에서 무엇을해야합니까 장애 조치 "

8. "내 데이터 얼마나 큰입니까? 기억에 맞을 것인가? 그것은 하나의 컴퓨터에 맞을 것인가? 각 개별 기록은 크거나 작습니까?

9. "내 데이터가 얼마나 자주 변경됩니까?이 파일은 아카이브입니까?"

여러 고객이하려는 경우 (채널?) 자신의 재고 스키마와 각 문서 기반 DB는 그것의 장점을 가지고 있습니다. 재고가있는 전자 상거래 시스템을 한 번 보았는데 거의 235 개의 테이블이있었습니다! 그런 다음 특정 관계형 데이터가있는 경우 SQL 솔루션에 실제로 몇 가지 이점이 있습니다.

주어진 제한 조건을 사용하여 mongo, couch, riak 또는 orientdb를 사용하여 솔루션을 빌드하는 방법을 확실히 알 수 있습니다. 그러나 가장 좋은 것은 무엇입니까? 나는 DB 벤더와 직접 대화를 시도해보고, 아마도 nosql 테이프를 보게 될 것이다.