Schema element "`b:shard`"

Defines a physical set of Units, placed on a b:server.

Definitions

<element name="shard" type="b:Shard"
  substitutionGroup="b:native" />

<complexType name="Shard">
  <complexContent>
    <extension base="b:Native">
      <sequence>
		<element name="service" type="b:UnitRef" [0..∞] />
      </sequence>
      <attributeGroup ref="b:selector" />
    </extension>
  </complexContent>
</complexType>

Description

One b:namespace has at least one shard: a location where it can store Units. Shards can "load" and "save", but do not care about what they contain; that's a task for b:index instances.

When a Unit gets updated, it SHOULD be re-evaluted whether is also has to change shard. When the shard selector changes, it may imply that units must be moved between shards as well.

element `service`

The service (ms:Service/*) features which this shard implements. For instance, read, write, or index search.

Examples

Shards included in definitions

One Namespace can carry many storage references, which may be selected with the when or unless attributes. This way, you MAY, for instance, cause large Units to be stored on other physical places than smaller Units. Or, you can differentiate between types of Units, the first letter of the UnitID, the upload date.

<unit id="...">
  <type>ms:Type/Shard</type>
  <shard name="local" when="unit.size &lt; 10k" unitref="#disk" />
  <shard name="redundant" unitref="#on_s3" />
</unit>

Discussion

Typical expressions for shards

Not all storage back-ends support the same features. For instance, some may not support writing, other may not support search. Which storage is used for each task can be configured with when.

Typical selectors for shards:

# First half of the names in this shard
unit.id =~ "^[a-mA-M]"

# Large Units somewhere else
unit.size > 10M

# Introduce a staging server
unit.state unlike 'ms:UnitState/{Published,Deprecated}'

mark@overmeer.net Web-pages generated on 2023-12-19

Schema element "b:shard"