Suddividere un feed significa suddividerlo in più sottoinsiemi non intersecanti. A seconda dei sistemi di backend, dei tipi di flotta e delle dimensioni, lo sharding potrebbe essere necessario.
Quando eseguire lo sharding
Se le dimensioni del feed sono troppo grandi (superiori a 50 MB), in quanto ciò può causare problemi di prestazioni quando il partner tenta di rispettare i requisiti di aggiornamento dei dati.
Il sistema di backend del partner presenta difficoltà tecniche nella combinazione delle informazioni sulla flotta tra sistemi in paesi diversi.
Per evitare che lo sharding comprometta le prestazioni del sistema, ti consigliamo quanto segue per ogni sistema di micromobilità:
Senza aggancio: ti consigliamo di ridurre al minimo il numero di shard e di rendere ogni shard il più grande possibile. Ogni shard deve coprire un'area di servizio geografica almeno delle dimensioni di un'area metropolitana o più grande.
Agganciato: lo sharding è consentito e i partner sono invitati a suddividere il feed per aree metropolitane.
Regole generali
Ogni shard deve contenere un insieme completo di file GBFS che possono descrivere completamente il sistema e possono essere utilizzati in modo indipendente.
Tutte le informazioni pertinenti devono essere contenute in un unico shard e non è consentito il riferimento incrociato con altri shard. Ad esempio, un veicolo senza stazione nello shard A non può fare riferimento a un piano tariffario di sistema dello shard B. Il suo piano tariffario deve essere definito all'interno dello shard A.
Tutti gli shard devono essere non intersecanti. Nel caso in cui un veicolo senza base o una stazione con base venga presentato in due shard diversi, viene trattato come due entità separate e le informazioni duplicate verranno presentate agli utenti.
I recinti virtuali definiti in uno shard non devono sovrapporsi a quelli definiti in uno shard separato.
I recinti virtuali non devono utilizzare una disposizione antioraria che fa riferimento ad aree al di fuori del poligono.