Verwendete Komponenten

• Priorisierer
• Exporter
• Enrichment

Die Komponente übernimmt die gesamte Verwaltung aller verwendeten Features. Dies betrifft soviel die persistente Speicherung, als auch die Erzeugung durch andere Komponenten, sowie die Abfrage, Ersetzung und Löschen der bereits gespeicherten Werte. Da Features auf Bildebene und nicht Kundenebene abgebildet werden ist eine redundanzfreie Speicherung nur möglich, falls Werte kundenübergreifend gespeichert werden. Die eigentlichen Datenbanken der Kunden enthalten dann lediglich Verweise auf die eigentlichen Features.

Um ein Feature vollständig zu beschreiben, sind folgende Werte notwendig:

• Eine eindeutige ID, die ggf. ein Hash der Ressource ist
• Eine globale Beschreibung der Ressource, Bild-URI
• Ein eindeutiger Name, “bobby.convnet”
• Eine Revision wie “2.0”, um parallel verschiedene Versionen zu speichern
• Der Wert des Features als BLOB, da nicht alle Features rein numerisch sind

Da Features nicht längenbegrenzt sind, ist eine kompakte Speicherung und ein effizienter Transfer notwendig. Dafür ist ein generisches Encoding und Decoding notwendig, vergleichbar mit einem “marshal” und “unmarshal”. Die Darstellung eines Objekts als String erlaubt dann eine effiziente Komprimierung.

Die DB hat dabei mehrere Aufgaben. Erstens, bereits berechnete Features ohne Zeitverlust wiederzuverwenden, was ggf. durch eine Replikation noch beschleunigt werden kann. Da die Hauptaufgabe der DB die Beantwortung von *parallelen* Anfragen ist sicherzustellen, dass Daten gegen konkurrierende Zugriffe geschützt sind, ohne dabei die Geschwindigkeit negativ zu beeinflussen. Zweitens, die DB ist verantwortlich dafür Features mit Hilfe von Enrichment-Modulen zu erzeugen und persistent abzuspeichern. Als Beispiel sei eine Anfrage genannt, die ein Enrichment 'tegra.fashnet' auf einer GPU-Komponente benötigt. Anfragen sind stets “get”-Anfragen, die ggf. ein “add” auslösen, falls das Feature nicht in der DB ist. Dazu benötigt die Datenbank eine Liste aller Feature-Services. Services ist dabei abstrakt, da die Services nur über Queues angesprochen werden. Dass heißt, die Datenbank setzt ein Request ab, der in der zuständigen Warteschlange gespeichert wird.

hier wird ein feineres Konzept für Warteschlangen für eine Art Komponente benötigt, also eine Priority-Queue, aus der dann die eigentlichen Systeme befüllt werden.

Falls notwendig, kann ein Kunde modelliert werden, indem alle IDs in einer “Tabelle” zusammengefasst werden.

Ein Feature aus der DB extrahieren

FeatureDB.get(Kunden_ID*, Bild_URI, Feat_Name, Feat_Rev=1.0, Priority=low)