Apache Ignite Zero 배포: 정말 Zero인가요?

우리는 소매 네트워크의 기술 개발 부서입니다. 어느 날 경영진은 MSSQL과 함께 Apache Ignite를 사용하여 대규모 계산 속도를 높이는 작업을 설정하고 아름다운 그림과 Java 코드 예제가 포함된 웹 사이트를 보여주었습니다. 나는 즉시 사이트를 좋아했습니다. 제로 배포, 기적을 약속하는 설명: 그리드의 각 노드에 Java 또는 Scala 코드를 수동으로 배포하고 변경될 때마다 다시 배포할 필요가 없습니다. 작업이 진행되면서 Zero 배포에는 특정한 용도가 있다는 사실이 밝혀졌고, 그 기능을 공유하고 싶습니다. 컷 아래에는 생각과 구현 세부 사항이 있습니다.

1. 문제 진술

문제의 본질은 다음과 같습니다. SalesPoint 판매 지점 디렉토리와 Sku(재고 유지 단위) 제품 디렉토리가 있습니다. POS(Point of Sale)에는 '소형' 및 '대형' 값을 갖는 '매장 유형' 속성이 있습니다. 각 판매점에 어소트먼트(판매시점의 상품목록)가 연결되어(DBMS에서 로딩), 지정일로부터 지정상품이
구색에서 제외되거나 구색에 추가되었습니다.

분할된 POS 캐시를 구성하고 한 달 전에 연결된 제품에 대한 정보를 저장해야 합니다. 전투 시스템과의 호환성을 위해서는 Ignite 클라이언트 노드가 데이터를 로드하고 양식의 집계(상점 유형, 제품 코드, 날짜, 판매_포인트_수)를 계산하고 이를 다시 DBMS에 업로드해야 합니다.

2. 문학 연구

아직 경험이 없어서 난로 위에서 춤을 추기 시작했어요. 즉, 출판물 검토에서 나온 것입니다.

기사 2016 Apache Ignite 소개: 첫 번째 단계 Apache Ignite 프로젝트 문서에 대한 링크와 동시에 이 문서의 모호함에 대한 비난이 포함되어 있습니다. 몇 번 다시 읽어도 명확성이 나오지 않습니다. 공식 튜토리얼을 참고하겠습니다 시작하기어느
낙관적으로 약속합니다. “곧 바로 실행될 것입니다!” 두 개의 Apache Ignite Essentials 비디오를 시청하면서 환경 변수 설정을 파악하고 있지만 특정 작업에는 그다지 유용하지 않았습니다. 표준 파일 “example-ignite.xml”을 사용하여 명령줄에서 Ignite를 성공적으로 실행하여 첫 번째 애플리케이션을 구축했습니다. 컴퓨팅 애플리케이션 메이븐을 사용하여. 응용 프로그램이 작동하고 Zero 배포를 사용합니다. 정말 아름답습니다!

더 자세히 읽어보니 예제에서는 즉시 AffinityKey(이전에 SQL 쿼리를 통해 생성됨)를 사용하고 신비한 BinaryObject도 사용합니다.

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

읽다 약간: 바이너리 형식 - 리플렉션과 같은 것으로, 이름으로 개체의 필드에 액세스합니다. 객체를 완전히 역직렬화하지 않고도(메모리 절약) 필드 값을 읽을 수 있습니다. 그런데 제로 배포가 있는데 왜 Person 대신 BinaryObject가 사용됩니까? IgniteCache를 사용하는 이유 IgniteCache로 전송됨 ? 아직 명확하지 않습니다.

제 경우에 맞게 Compute 애플리케이션을 다시 만들고 있습니다. MSSQL에서 POS 디렉토리의 기본 키는 [id] [int] NOT NULL로 정의됩니다. 비유를 통해 캐시를 생성합니다.

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

XML 구성에서 캐시가 분할되었음을 나타냅니다.

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

판매 시점별 분할에서는 사용 가능한 salesPointCache 레코드에 대해 각 클러스터 노드에 필요한 집계가 구축된 후 클라이언트 노드가 최종 합계를 수행한다고 가정합니다.

튜토리얼을 읽고 있어요 최초의 컴퓨팅 애플리케이션 점화, 나는 비유로 그것을합니다. 각 클러스터 노드에서 다음과 같이 IgniteRunnable()을 실행합니다.

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

집계 및 업로드 논리를 추가하고 테스트 데이터 세트에서 실행합니다. 모든 것이 개발 서버에서 로컬로 작동합니다.

두 개의 CentOs 테스트 서버를 시작하고 default-config.xml에 IP 주소를 지정하고 각각에서 실행합니다.

./bin/ignite.sh config/default-config.xml

두 Ignite 노드가 모두 실행 중이며 서로를 볼 수 있습니다. 클라이언트 애플리케이션의 xml 구성에 필요한 주소를 지정하면 애플리케이션이 시작되고 세 번째 노드가 토폴로지에 추가되며 즉시 두 개의 노드가 다시 생성됩니다. 로그에는 "ClassNotFoundException: model.SalesPoint" 줄이 표시됩니다.

SalesPoint sp=salesPointCache.get(spId);

StackOverflow에 따르면 오류의 원인은 CentOs 서버에 사용자 정의 SalesPoint 클래스가 없기 때문입니다. 우리는 도착했습니다. "각 노드에 Java 코드를 수동으로 배포할 필요가 없습니다" 등은 어떻습니까? 아니면 "귀하의 Java 코드"가 SalesPoint에 관한 것이 아닌가요?

아마도 뭔가를 놓쳤을 것입니다. 다시 검색을 시작하고, 읽고, 다시 검색합니다. 잠시 후, 나는 그 주제에 관한 모든 것을 읽었고 더 이상 새로운 것이 없다는 느낌을 받았습니다. 검색을 하던 중 흥미로운 댓글을 발견했습니다.

발렌틴 쿨리첸코, GridGain Systems의 수석 설계자, 답변 StackOverflow, 2016년 XNUMX월:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

또 다른 권위 있는 의견: 데니스 마그다, GridGain Systems 제품 관리 이사.

하브레에 관한 기사 마이크로서비스에 대해 Denis Magda의 세 가지 기사를 참조합니다. 마이크로서비스 XNUMX부, 마이크로서비스 XNUMX부, 마이크로서비스 XNUMX부 2016-2017. 두 번째 기사에서 Denis는 MaintenanceServiceNodeStartup.jar을 통해 클러스터 노드를 시작할 것을 제안합니다. xml 구성 및 명령줄을 통해 실행을 사용할 수도 있지만 배포된 각 클러스터 노드에 사용자 지정 클래스를 수동으로 배치해야 합니다.

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

실제로 그게 다입니다. 여기서 왜 이 신비한 바이너리 형식이 나오는지 밝혀졌습니다!

3.싱글병

Denis는 내 개인 평가에서 XNUMX위를 차지했습니다. IMHO는 사용 가능한 모든 튜토리얼 중 가장 유용한 튜토리얼입니다. 그의 마이크로서비스예 Github에는 추가 무단 점거 없이 컴파일되는 클러스터 노드 설정에 대한 완전히 준비된 예제가 포함되어 있습니다.

동일한 방식으로 수행하여 명령줄 인수에 따라 "데이터 노드" 또는 "클라이언트 노드"를 시작하는 단일 jar 파일을 얻습니다. 어셈블리가 시작되고 작동합니다. 제로 배포가 패배했습니다.

메가바이트의 테스트 데이터에서 수십 기가바이트의 전투 데이터로의 전환은 바이너리 형식이 존재하는 이유가 있음을 보여주었습니다. 노드의 메모리 소비를 최적화하는 것이 필요했고, 여기서 BinaryObject가 매우 유용하다는 것이 밝혀졌습니다.

4. 결론

Apache Ignite 프로젝트 문서의 모호함에 대한 첫 번째 비난은 공정한 것으로 판명되었으며 2016년 이후 거의 변경되지 않았습니다. 초보자가 웹 사이트 및/또는 저장소를 기반으로 작동하는 프로토타입을 조립하는 것은 쉽지 않습니다.

완료된 작업 결과에 따르면 Zero 배포가 작동하지만 시스템 수준에서만 작동한다는 인상을 받았습니다. 다음과 같습니다. BinaryObject는 원격 클러스터 노드가 사용자 정의 클래스와 작동하도록 가르치는 데 사용됩니다. 제로 배포 - 내부 메커니즘
Apache Ignite는 자체적으로 클러스터 전체에 시스템 개체를 배포합니다.

내 경험이 새로운 Apache Ignite 사용자에게 도움이 되기를 바랍니다.

출처 : habr.com