Beim Sharding eines Feeds wird der gesamte Feed in mehrere disjunkte Teilmengen aufgeteilt. Abhängig von Ihren Backend-Systemen, Flottentypen und ‑größen kann Sharding erforderlich sein.
Wann sollten Sie Sharding verwenden?
Wenn die Größe des Feeds zu groß ist (mehr als 50 MB), kann dies zu Leistungsproblemen führen, wenn der Partner versucht, die Anforderungen an die Aktualität der Daten zu erfüllen.
Das Backend-System des Partners hat technische Schwierigkeiten, Flotteninformationen aus Systemen in verschiedenen Ländern zu kombinieren.
Damit die Leistung des Systems durch Sharding nicht beeinträchtigt wird, empfehlen wir für jedes Mikromobilitätssystem Folgendes:
Ohne Ladestation: Wir empfehlen, die Anzahl der Shards so gering wie möglich zu halten und jeden Shard so groß wie logisch möglich zu gestalten. Jeder Shard muss ein geografisches Einsatzgebiet abdecken, das mindestens so groß wie eine Metropolregion ist.
Angedockt: Sharding ist zulässig und Partner werden aufgefordert, den Feed nach Metropolregionen aufzuteilen.
Allgemeine Regeln
Jeder Shard muss einen vollständigen Satz von GBFS-Dateien enthalten, die das System vollständig beschreiben und unabhängig voneinander verwendet werden können.
Alle relevanten Informationen müssen in einem einzigen Shard enthalten sein. Es sind keine Querverweise auf andere Shards zulässig. Ein stationsloses Fahrzeug in Shard A kann beispielsweise nicht auf ein Systempreismodell aus Shard B verweisen. Stattdessen muss das Preismodell in Shard A definiert werden.
Alle Shards dürfen sich nicht überschneiden. Wenn ein stationsloses Fahrzeug oder eine Dockingstation in zwei verschiedenen Shards vorhanden ist, wird es als zwei separate Entitäten behandelt und die doppelten Informationen werden den Nutzern angezeigt.
In einem Shard definierte Geofences dürfen sich nicht mit Geofences überschneiden, die in einem separaten Shard definiert sind.
Für Geofences darf keine Anordnung gegen den Uhrzeigersinn verwendet werden, die auf Bereiche außerhalb des Polygons verweist.