Cygnus uses the notified fiware-service
and fiware-servicePath
headers to compose the names of the different backend elements. Specifically:
- MySQL
- databases are called as
<fiware-service>
- table names are called as
<fiware-servicePath>_<destination>
- HDFS
- HDFS paths are created as
/user/<your_user>/<fiware-service>/<fiware-servicePath>/<destination>/<destination>.txt
- CKAN
- organizations are called as
<fiware-service>
- packages/datasets are called as
<fiware-servicePath>
- resources are called as
<destination>
By default, <destination>
is equals to <entityId>_<entityType>
. This may lead, as described in the question, to the creation of a MySQL table/HDFS folder/CKAN resource per each notified entity.
Such a default destination generation may be changed by using an advanced feature of Cygnus, the pattern-based grouping; as the name suggests, the feature is based on finding (configured) patterns in the data, in order to group the context data showing the pattern. This feature allows, for instance, all the entities of a certain type are stored within a single MySQL table; or certain entities starting by a prefix are stored together in a HDFS file.
In order to activate this feature, edit the /usr/cygnus/conf/matching_table.conf
file and add as many matching rules as you need; matching rules syntax is described here. Basically, the rules say "once the pattern-based matching is confirmed, use this new <destination>
and this new <fiware-servicePath>
":
<rule_id>|<list_of_fields_to_be_compared>|<regular_expresion>|<new_destination>|<new_fiware-servicePath>
Thus, a "store all the data in a MySQL table called 'my_unique_table'" rule would look like:
<any_unique_number>|<entityId>|.*|unique_table|my_
or:
<any_unique_number>|<entityId>|.*|_table|my_unique
Both rules are valid since MySQL table names are created, as already said, by concatenating <fiware-servicePath>
and <destination>
; in this case table name is equals to "my_"+_+"unique_table" or "my_unique"+"_table".