콤보 저장소 및 서비스 버스 란 무엇입니까?

Question

NoSQL 및 특히 DynamoDB에 대해 더 배우고 있습니다. 나는 최근에이 질문을했다 : Mapping database structure from SQL Server to DynamoDB

대답에서 대답에; 응답은 서비스 버스 및 콤보 저장소를 나타냅니다.

Q1) 서비스 버스입니까? (EventListener 클래스 참조) : http://enterprisecraftsmanship.com/2015/05/06/combining-sql-server-and-mongodb-using-nhibernate/

Q2) 콤보 저장소 란 무엇입니까? 그것은 "조합"저장소인가? 즉, 여러 데이터베이스 (SQL Server 및 DynamoDB)와 인터페이스하는 일부 메소드입니다.

나는 일반적으로 답변자에게 질문 할 것이지만, 다른 질문에서 원래 게시물을 회피하기 시작했습니다. 답변자가 이것을 언급했습니다. 그러므로 나는 또 다른 질문을하기로 결심했다. 나는 데이터베이스를 확장하기 위해되는 NoSQL 데이터베이스를 사용하는 방법에 대해 생각하고

Answer 1

는

좋은 생각을 읽습니다. 너 Command Query Responsibility Segregation(CQRS)의 길을 가고있는 것처럼 들린다. NoSql 데이터베이스는 뛰어난 읽기 저장소를 만듭니다. 이것은 내가 '콤보'(결합) 저장소에 의해 의미가 무엇인가 -

link 당신이 참조

는 SQL Server를 결합하고 MongoDB를이 자 NHibernate를 사용하여 업데이트하는 기술에 대해 설명합니다. "콤보 저장소"는 표준 패턴이 아닙니다. 저자 인용 :

물론 이론적으로 모든 데이터를 NoSQL 저장소로 옮길 수는 있지만 관계형 데이터베이스를 완전히 없애지 않으려면 어떻게해야할까요? 은 어떻게 함께을 결합 할 수 있습니까? 추측으로는 데이터 지속성 주위에 매우 일반적인 추상화 계층 인 Polyglot space

Repository Pattern에있을 수 있도록

당신은 Sql-Server과 NoSql 데이터베이스를 모두 원래의 질문을 태그했습니다.

참조한 "결합"링크는 특히 다 대다 관계 (종종 SQL에서 접합 테이블이라고 함)의 문제를 해결하고 그러한 관계가 많을 때 성능에 미치는 영향을 해결합니다.

보다 일반적인 의미에서, NHibernate에서 차단 점을 제공하는 대신에 저장소 패턴을 통해 추상화 된 데이터 액세스를 할 수도 있고하지 않을 수도 있습니다.

public interface IWidgetRepository 
{ 
    Task<Widget> FetchWidget(string widgetKey); 
    Task SaveWidget(Widget toBeSaved); 
} 

가정 해 우리가 이미 SqlRepository 있습니다 :

다음은 C#에서 초 간단 (및 제네릭이 아닌) 저장소 인터페이스의

public class SqlWidgetRepository : IWidgetRepository 
{ 
    public async Task<Widget> FetchWidget(string widgetKey) 
    { 
     ... Code to use Obtain an NHibernate session and retrieve and deserialize Widget 
    } 
    ... Other methods here 
} 

당신은 또한 선택할 수있는 MongoDb 구현을 제공하기 위해

public class MongoWidgetRepository : IWidgetRepository 
{ 
    public async Task<Widget> FetchWidget(string widgetKey) 
    { 
     ... Code to connect to a MongoDb secondary and Find() the 
      widget and deserialiaze into Widget 
    } 
    ... Other methods here 
} 

두 데이터베이스를 동시에 유지 관리하려면 교활한, 여기이 "콤보"저장소 볼 수있는 방법의 예 : 위의 "콤보"저장소가 아니라 단일 시스템의 요구를 충족 할 수

public class ComboWidgetRepository : IWidgetRepository 
{ 
    private readonly IWidgetRepository _repo1; 
    private readonly IWidgetRepository _repo2; 

    public ComboWidgetRepository(IWidgetRepository repo1, IWidgetRepository repo2) 
    { 
      repo1 = repo1; 
      repo1 = repo2; 
    } 

    public async Task<Widget> FetchWidget(string widgetKey) 
    { 
      // Just need the one ... first one wins 
      return await Task.WhenAny(repo1.FetchWidget(widgetKey), 
            repo2.FetchWidget(widgetKey)); 
    } 

    public async Task SaveWidget(Widget toBeSaved) 
    { 
      // Need both to be saved 
      await Task.WhenAll(repo1.SaveWidget(toBeSaved), 
          repo2.SaveWidget(toBeSaved)); 
    } 

(그리고 두 개의 데이터베이스를 유지하는 많은 다른 방법이 있습니다 동기화) .

그러나 CQRS는 엔터프라이즈 급 (즉, 많은 시스템과 많은 데이터베이스가있는 곳)에서 자주 사용됩니다.

Enterprise Service Bus에 대한 내 의견은 기업 전체에 데이터를 배포해야하는 경우에만 의미가 있습니다.

개념은 버스를 통해 (예를 들어, "위젯 추가")

• 명령은 트랜잭션 시스템에 대기하고 간단합니다.
• 시스템 처리 위젯은
• Widget 시스템은 다음 새로운 위젯이 모든 관련 위젯 정보 (추가 된 것을 자세히 버스에 (방송) 메시지를 게시 (예 : 데이터베이스에 위젯을 삽입) 트랜잭션을 수행)
• 위젯에 대한 업데이트에 관심이있는 기업의 다른 시스템은이 메시지를 구독하고 자신의 Read Store 위젯 표현을 업데이트합니다 (예 : NoSql 데이터베이스 또는 캐시 및 가장 이해하기 쉬운 형식으로 업데이트).).
• 사용자가 이러한 다른 시스템에 액세스하고 '위젯'에 대한 화면을 볼 때 시스템은 Widget 시스템 자체에서 데이터를 요청하지 않고 자체 읽기 저장소의 데이터를 제공 할 수 있습니다.