+1 peer. unrelated to this - do we support multiple URI's?
On Thu, Jun 11, 2020 at 2:51 PM Subbu Subramaniam <[email protected]> wrote: > Hey Ting, > > I like the URI in metadata as "peer:///segmentName". This way, the URI > remains parsable and we can use the scheme to check for a segment fetcher, > > thanks > > -Subbu > > On 2020/06/10 01:09:25, TING CHEN <[email protected]> wrote: > > As part of the deep store by-passing > > < > https://cwiki.apache.org/confluence/display/PINOT/By-passing+deep-store+requirement+for+Realtime+segment+completion > > > > project, a server is allowed to download segments from peer Pinot servers > > during Low Level Consumer (LLC) instead of deep segment stores. To enable > > this feature, we plan to add a new URI format for the field > > *segment.realtime.download.url > > *in LLCRealtimeSegmentZKMetadata. > > > > The new URI format serves the purpose of instructing a Pinot server to > find > > and download the segment from a peer server. Controller writes it to > Helix > > in case of segment upload failure or no deep store configured at all. We > > proposed the following format options and want to hear your feedback: > > > > 1. peer:///segmentName; (my preference) > > 2. simply an empty string *''* > > > > Both are in essence specially markers to indicate that the segment is not > > found in deep store and servers have to download them from peer servers. > > (1) has the benefit of better readability than (2) for debugging > purposes. > > > > Please let me know what you think. > > > > Ting Chen > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
