The Sharded Property

The table sharding feature described earlier can benefit certain high fan-out links. These are links that have a large number of values (thousands to millions). When a high fan-out link points to a sharded table, the link can also be declared as sharded by settings its sharded property to true. Example:

<table name="Address">

<fields>

<field name="Name" type="TEXT"/>

<field name="Messages" type="LINK" inverse="MessageAddress" table="Participant" sharded="true"/>

...

</fields>

</table>

In this example, the Messages link connects each Address object to related Participant objects. Since a participant exists for each sender or recipient of every message, some address objects could be linked to thousands or millions of participant objects. Because the Messages extent table, Address, is declared as sharded, the Messages link can be declared as sharded. That is, only links whose target table is sharded can be declared as sharded.

A sharded link’s values are stored in sharded term vectors similarly as sharded scalar fields. This improves performance for queries that include a selection clause on the link’s owning table and a clause that uses the referenced table’s sharding field. Example:

GET /Msgs/Address/_query?q=Name:dell AND Messages.ReceiptDate=[2013-01-01 TO 2013-01-31]

This query searches for Address objects whose Name contains the term “dell” and that are connected to participants whose ReceiptDate is in January, 2013. In other words, this query lists all addresses that sent or received a message in a specific time frame. Queries that fit this pattern are more efficient for high fan-out links declared as sharded.