관리 납품 네트워크: 도형 데이터베이스 용례

takealot에서전자상거래 플랫폼으로서 우리의 가장 큰 경쟁 우위 중 하나는 우리의 물류 네트워크를 유지하고 확장하는 것이다.이 네트워크는 우리가 고객에게 납품하는 방식과 시간을 통제하고 다른 방면에서takealot를 확보할 수 있도록 한다.com은 남아프리카에서 앞장서는 전자상거래 플랫폼이다.
본고에서 나는takealot의 독특한 문제를 분석할 것이다.com은 고객에게 신뢰할 수 있는 납품을 추진하는 문제와 우리가 도형 데이터베이스를 어떻게 사용하여 고성능과 확장 가능한 해결 방안을 납품하는지에 직면해 있다.

그럼 문제는 뭐예요?

왜 너무 많이 먹냐고 물어볼 수도 있어요.com은 남아프리카의 우편 서비스와 기존의 택배 회사를 이용하지 않습니다.답안은 매우 간단하지만 신뢰성이 부족하다.현지 우편 서비스는 정확한 배달 날짜를 제공할 수 없다.이것은 이 서비스를 우리의 물류 주간으로 사용하면 우리 고객에게 정확한 납품 날짜를 제공할 수 없다는 것을 의미한다.이 밖에 기존 택배 회사는 보험료를 받는데 이는 주로 고객이 부담하는 추가 원가를 증가시킬 것이다.이 관건적인 요소는 우리 자신의 물류 운영을 유지하는 것이 여전히 최선의 행동 방안이라는 것을 의미한다.
그러나 물류 네트워크를 발전시켜 날로 증가하는 국가 전자상거래 플랫폼의 수요를 만족시킬 때 하룻밤 사이에 1에서 11로 성장할 수 없다.따라서 우리는 기존의 제3자 택배회사와 통합을 유지해야 한다.
따라서 이 시스템의 요구 사항은 다음과 같습니다.

어떻게 고객의 주문을 얻을 수 있습니까?

주문서는 언제 고객에게 배달됩니까?

제3자 택배나 우리 자신의 택배 네트워크를 이용하여 납품을 완성할 것인가.

본고의 나머지 부분에서 우리는 제1점을 중점적으로 토론하고 제2점을 토론할 것이다.만약 누군가가 흥미를 느낀다면, 나는 이후의 글에서 두 번째 점을 확장하려고 시도할 것이다.

우리 는 이 배 를 실현시킬 것 이다

takealot에서 고객에게 납품합니다.com 세계는 두 단계로 구성된다.

소포를 창고에서 택배로
손님이것은 여러 개의 분기 점프 패키지와 관련이 있을 수 있다.

소포를 지점에서 고객에게 인도한다.

어쨌든, takealot.com은 주문서가 가장 짧고 경제적인 방식으로 중앙 창고나 제3자 시장 판매자로부터 고객에게 발송되는 것을 확보해야 한다.
이것은 계산shortest path과 관련이 있는데 이것은 전형적인 계산 문제이다.원칙적으로 우리는 지점이 일련의 노드라고 생각한다. 이렇게 표시할 수 있다.

대표 노선의 가장자리로 그것들을 연결하고 도형 검색 알고리즘을 실행할 때, 우리는 시원한 맥주와 하이파이브로 빠르게 축하를 하고 있다.
우리는 pgrouting과Yen's Algorithm를 통해 상술한 기능을 실현하였다.이것이 바로 이 방법의 지연이다.

135ms 내에서 우리는 어떻게 고객에게 도착하는지 알게 될 것이다.고객을 찾으면 시스템 응답 시간은 다음과 같습니다.

510ms 이후에 우리는 어떻게 당신에게 연락하고 언제 당신에게 연락하는지 알게 될 것입니다.성공
그리고 우리는 문제를 확장하고 발견해야 한다.배송망의 그림은 하나의 그림일 뿐임을 나타낸다.모서리 세트로 연결된 노드 세트.이것은 납품 제약의 응용을 의미한다. 예를 들어 우리가 자전거로 냉장고를 납품하지 않을 것을 확보하는 것이post의 도형 밖에서 완성된 것이다.
추가 노선, 택배 기사, 지점이 증가함에 따라 고객은 몇 초의 납품 날짜를 기다리지 않고 납품 능력을 확장할 수 없을 정도로 성능이 떨어졌다.
최종적으로 이것은 제3자 신사가 지속적으로 통합할 수 없다는 것을 의미한다.다른 도전 외에 이 회사는 현재 가격이 합리적인 농촌 택배원을 찾을 수 없다.

구원의 속성도

사실은 우리가 그림을 필요로 하지 않는다는 것을 증명한다. 우리는 하나를 필요로 한다property graph.간단히 말하면 속성도는 도형 데이터 구조로 그림의 가장자리와 정점에 있는 속성(키, 값 쌍)을 추가했다.앞에서 설명한 그림 모형은 연결된 노드 그룹에서 다음 단계로 발전합니다.

각 모서리/교점에는 다음과 같은 속성이 있습니다.

이것은 우리가 모든 루트 제약 논리를 그림으로 옮길 수 있다는 것을 의미한다.고객에게 어떻게 연락하는지 말하자면 후기 처리가 필요 없다.우리는 JanusGraph을 데이터 층으로 삼아 이 점을 추진하고 TinkerPop & Gremlin을 통해 검색 언어를 추진할 수 있다.이것은 수백 줄의 처리 코드가 간단한 gremlin-scala 조회로 바뀌었다는 것을 의미한다. 다음과 같다.

g.V().has(Keys.Vertex.LOOKUPID, lookupIDTo)
          .inE(LegType.LAST_MILE.toString)
              .has(Keys.Edge.PHYSMINWEIGHT, P.lte(attributes.physWeight))
              .has(Keys.Edge.PHYSMAXWEIGHT, P.gte(attributes.physWeight))
              //More property constraints
          .outV()
            .has(Keys.Vertex.HUBACTIVE, true)
          .repeat(
            _.inE(LegType.LINE_HAUL.toString)
              .has(Keys.Edge.PHYSMINWEIGHT, P.lte(attributes.physWeight))
              .has(Keys.Edge.PHYSMAXWEIGHT, P.gte(attributes.physWeight))
              //More property constraints
            .outV()
              .has(Keys.Vertex.HUBACTIVE, true)
            .simplePath()
            ).until(_.has(Keys.Vertex.LOOKUPID, lookupIDFrom)).limit(10).path

Any gremlin fan reading this will note how we are traversing in reverse. Let's say that edge labels with a better understanding of our degree distribution allowed for further optimisations.

상술한 조회는 우리가 고객에게 어떻게 연락하는지 검사할 뿐만 아니라, 납품 중인 소포의 상세한 정보(예를 들어 무게)를 사용하여 노선을 더욱 신속하게 제거한다.
이제 다음 지연도를 살펴보겠습니다.

P95의 응답 시간은 10ms로 수량 수준이 더 좋습니다.그 외에 무림으로.com은 성능이 떨어지지 않았거나 최소한 떨어지지 않은 집선기와 메시지를 더 많이 추가했다.이것은 우리의 검색 공간이 여전히 우리가 가지고 있는 LINE_HAUL 테두리의 수량에 국한되고 물류 네트워크의 대다수 확장은 LAST_MILE 테두리에서 발생하기 때문이다.property graph의 또 다른 장점은 라벨과 속성을 통해 그림의 구조를 형식적으로 분류하고 층을 나눌 수 있다는 것이다.
이 새로운 property graph 구조는 우리가 구조화되고 반복할 수 있는 방식으로 시간의 제약을 나타낼 수 있도록 허락한다.그러나 고객에게 전달할 때의 계산은 여전히 그림 밖에서 실행된다.도형적으로 더욱 자연스러운 시간 데이터 표시(논리가 아니라)도 이 층에서 최적화할 수 있다.최종 시스템 응답 시간:

150ms의 P95 응답 시간은 더욱 쉽게 받아들일 수 있습니다.내가 말한 바와 같이, 만약 누군가가 본고에 흥미를 느낀다면, 나는 이 그림이 어떻게 우리로 하여금 교부 날짜 계산을 최적화하게 하는지 계속 소개할 것이다.
이런 새로운 속성도 모델은 개선된 관찰성, 더 쉬운 수정 등 성능과 무관한 많은 장점을 제공했다.

그럼, 우리는 배를 만들고 있습니까?

내 생각에 우리는이 시스템은 공급업체의 재고 지연, 엉망인 교통 상황 등 잠재적인 운영 지연을 고려하지 않고 납품 날짜를 더욱 정확하게 예측할 수 있게 한다.배송 노선의 잠재적인 운영 지연을 고려하는 것은 우리가 다음 단계에 노력하여 해결하는 또 다른 도전이 될 수 있다.
property graphs 계산 문제를 해결하는 묘약인가?아니오절대 아니야!플러그를 사용하여 나사를 꺼내지 않듯이 그래픽 데이터베이스를 사용하여 카트를 모델링하지 않습니다.
그러나 이런 새로운 속성도 모델은 여러 차례 토론을 전개하여 고객을 위한 개선을 가져올 수 있다.
우리는 이 기술을 더욱 추진할 수 있어서 매우 기쁘다. 우리가 그것을 이용하여 무엇을 할 수 있는지. 우리는 더 많은 비행선을 만들어야 한다.