微服务架构中，每个服务都有自己的独立数据库。
然而现在有个需求，需要生成一张实时的报表，该报表包含两个服务的数据。
如服务A，服务B。B中仅包含A的主键id作为关联。
而此报表的搜索条件包含A服务实体中的字段也包含B服务实体中的字段。
现有方案
1、如果搜索条件中包含A的条件，则先去服务A中搜索，得到所有结果的主键，在服务B中使用where A.id IN （ids） 再次查询
想法：当A.id数量庞大时，这个查询极其缓慢！ 而A.id数量庞大的情况很多
2、使用搜索引擎
想法：感觉杀鸡用牛刀
请教各位大牛有更好的方案吗
迷茫2017-04-18 10:57:55
완하제
온라인 비즈니스 데이터(OLTP)라면 옵션 1이 마이크로서비스의 표준 관행입니다. 이러한 관련 쿼리를 온라인에서 자주 수행해야 한다면 두 서비스(및 해당 두 라이브러리)의 결합이 매우 심각하다는 의미인데 애초에 굳이 분리할 이유가 있을까요?
분석 보고서라면 OLAP 카테고리에 속합니다. 솔루션 2는 정말 바람직한 솔루션입니다. 검색 엔진을 사용하는 것이 과하다고 생각되면 슬레이브 데이터베이스에서 다양한 보고서 분석 작업을 수행해 볼 수도 있습니다. 예를 들어 온라인 A 데이터베이스와 B 데이터베이스를 읽기 전용 데이터베이스에 실시간으로 동기화한 다음 읽기 전용 데이터베이스에서는 JOIN이 한 번에 수행됩니다.
PHP中文网2017-04-18 10:57:55
사실 이런 종류의 문제는 마이크로서비스에서 매우 일반적입니다. 예를 들어 주문과 제품은 각각 두 개의 마이크로서비스에 속해 있습니다. 두 가지 솔루션뿐 아니라 예
데이터 집계를 데이터 웨어하우스에 넣고 A와 B의 데이터를 실시간으로 다른 데이터베이스(mysql일 필요는 없으며 Hbase일 수도 있음)에 집계하면 보고서에서 가져온 데이터를 가져옵니다. 데이터 웨어하우스에서
테이블을 디자인할 때 일부 필드를 중복하는 것이 적절합니다. 말씀하신 것처럼 A의 일부 필드는 B에서 예상대로 중복될 수 있습니다.
방법 1은 매우 치명적인 단점이 있습니다. 일단 페이징이 포함되면 이 방법은 확실히 실현 가능하지 않습니다. 어떤 솔루션을 채택할지는 해당 데이터의 양이 그리 크지 않은 경우에 달려 있습니다. 방법 1을 사용할 수 있습니다. 속도가 느린 경우 스레드를 몇 개 더 열어 해당 데이터를 일괄적으로 검색할 수 있습니다(ID가 너무 많으면 일괄로 가져오며, 일괄 쿼리는 시간 초과와 시간을 줄일 수 있는 효과적인 솔루션입니다). ); 데이터 양이 매우 많은 경우 데이터 웨어하우스를 사용하는 것이 좋습니다. 데이터 웨어하우스 사용의 주요 이점은 집계 테이블을 생성할 수 있기 때문에 기본 데이터베이스에 부담을 주지 않는다는 것입니다. 보고서는 여전히 오프라인 데이터 범주에 속하기 때문에 꼭 필요한 경우 실시간으로 매우 효율적이며 테이블 상태를 동반하는 주문 쿼리처럼 검색 조건이 너무 많습니다. 검색엔진이 좋은 선택이군요
그래서 실제 상황에 맞게 1번 방법과 3번 방법을 사용하시면 됩니다
黄舟2017-04-18 10:57:55
보고서 생성과 같은 요구 사항을 비즈니스 데이터베이스 시스템에 배치하면 안 됩니다. 백엔드에 수달 집계 라이브러리 세트를 만들어 여러 서비스의 데이터를 실시간으로 동기화하면 이 집계 라이브러리에서 원하는 모든 작업을 수행할 수 있습니다. . 게임 방법
