Die DB bietet ein einfaches HTTP-Interface, um ähnliche Produkte für einen Kunden abzufragen. Angebunden wird es über AF-Unix-Sockets in PHP.
Der Dienst kann über $LILLY_ROOT/bin/lillydb.sh –start gestartet und mit –stop beendet werden. Der Schalter –status dient dazu, anzuzeigen ob die Lilly läuft und unter welcher PID.
Die benötigte Größe der Festplatte hängt von der Größe der Kunden ab. Generell wird eine ausreichende Menge (50GB+) für Metadaten und Features benötigt. Je mehr RAM-Speicher spendiert wird, desto besser. Minimum sind 16 GB RAM, die Tendenz geht klar zu 32 GB. Da Python echtes Multi-Threading nur über parallele Prozesse abbilden kann, sollte die Maschine über mindestens 4 Kerne verfügen, besser 8.
mit folgenden Parametern:
Die Lilly residiert im Ordner “lillydb”. Dort liegen die PY-Dateien. Folgende Ordner werden verwendet und müssen existieren:
Im Ordner mit den Kundendaten sieht es wie folgt aus:
/kunde[921] /meta /data
Jeder Kunde hat ein separates Verzeichnis und darunter liegen getrennt Metadaten und Featuredaten.
Es ist möglich, Features für eine Liste von Produkten direkt aus der Lilly als JSON zu exportieren. Dafür verwendet man als Anfrage 'export.html?uid=189&id_list=id1,id2, …', um für Kunden 189 die Produkte mit der ID id1, id2 zu exportierten.
Weiterhin besteht die Möglichkeit, ganze Kategorien für einen Kunden zu exportieren: export_category.html?uid=189&id_list=Dingenshalter'. Dabei ist zu beachten, dass die Operation rechnungsintensiv sein kann und damit etwas mehr Zeit benötigt.
Obacht: das Interface ist noch NICHT finalisiert und der Code ist veraltet.
Mit curl is es möglich, ein POST mit JSON-Daten zu similieren:
curl -H "Content-Type: application/json" -d "`cat /tmp/out/enrichment.json`" http://localhost:8080/
Die Lilly-DB erwartet dabei als Format genau das, dass auch von pvt-dev erzeugt wird. Beispiel-Anfragen befinden sich im git im 'sample_requests'-Ordner. Bitte darauf achten, dass es jetzt 'ColorDescriptor' heißt, nicht mehr 'ColorExport'.
Ein serialisiertes JSON-Objekt:
{ “category”: […], “num_products”: 970, [optional] “meta”: {“gender”: “Damen”, “price”: “22.99”, “brand”: “Lascana”}, “topk”: 0.0, "6277733"], [0.0, "6982364"], [1.553, "6638555"], [1.89, "6129509"], [2.06, "4605797"],[2.12, "6868285"], [2.135, "6781222"], [2.22, "6993055"], [2.23, "6191728"], [2.251, "6457596", “time”: 0.01618}
Details: Dictionary mit folgenden Paaren.
In den meisten Fällen wird ein 'error' mitgeliefert. Die Wert wird von der API nicht ausgewertet.
Das Interface im Fehlerfall sieht so aus, dass 'topk' nur einen Eintrag enthält und zwar das angefragte Bild selbst: {'topk': [{'id': 0xdeadbeef, 'w'}]}. Die API liefert dann nur einen Wert zurück, als Hinweis, dass keine weiteren Treffer gefunden wurden.
Zwei Arten von Daten werden in der Lilly verwaltet. Die Verwaltung geschieht pro Kunde. Egal welche Art, die Daten sind stets nach Kategorie organisiert. Die Lilly bemerkt automatisch, dass Daten geändert wurden und lädt diese neu.
<HTML><ol></HTML>
meta direkt unter dem Kundenverzeichnis vorgehalten. Sie sind unabhängig von den Feature-Daten und können somit einzeln aktualisiert werdendata und es gibt jeweils eine Datei pro Feature. Als zusätzliche Infos werden die Produkt-IDs pro Kategorie gespeichert, sowie das Mapping Produkt-ID nach Position in Matrix.<HTML></ol></HTML>
Ein manueller Export kann durch folgende Kommandos angestoßen werden. Alle Kommandos sieht direkt in dem Verzeichnis wo der Quellcode der Lilly residiert auszuführen. Es sollte ein ROOT_DIR gesetzt sein (export ROOT_DIR=/home/picalike/pvt-dev/)
python ./export.py –meta 189. Die Ausgabe sollte mit 189: “total runtime A.B” quittiert werden. Ab diesem Zeitpunkt beantwortet die Lilly mit den neuen Daten.python ./export –features 189. Hierbei ist zu beachten, dass ggf. sehr viel RAM-Speicher verwendet wird, da die Gruppierung nach Kategorie im Speicher durchgeführt wird. Bei größeren Kunden bedeutetet dies mehrere GB an Daten.Hinweis: Die Dateien werden erst nach der vollständigen Erzeugung ersetzt, so dass nur in dem Moment des “rename” ein File-Not-Found möglich ist.
Im Normalfall werden die Daten automatisch in die Lilly exportiert und kein manuelles Eingreifen ist notwendig.
Falls die Lilly vollständig zurückgesetzt werden soll, erst einmal die cronjobs anhalten(!). Danach muss das root-Verzeichnis komplett gelöscht und wieder neu angelegt werden.
$ cd /mnt/storage/var
$ mv root root-$DATUM (optional)
$ mkdir root
Falls im FTP-Ordner ein Kunde auftaucht, der noch keinen Ordner in der Lilly hat, wird dieser automatisch erzeugt; manuelle Schritte sind nicht notwendig.
Soll ein Kunde gelöscht werden, reicht das verschieben des Kunden-Ordners aus var/root an eine andere Stelle, bzw. der Ordner kann gelöscht werden. Hierbei ist zu beachten, dass zu dem Zeitpunkt keine Anfragen für den Kunden mehr aktiv sind.
In beiden Fällen erkennt die Lilly, dass ein neuer Kunde angelegt, bzw. ein vorhandener Kunde gelöscht wurde und aktualisiert die internen Strukturen. Dies lässt sich einfach in den Logdateien nachvollziehen
Sobald ein Kunde zur Berechnung neu angestossen wird, laufen in dem FTP-Ordner auf der Lilly-Maschine Daten ein. Verschiedene Kategorien sind möglich:
Als erstes wird der Typ-catInfo erzeugt. Dieser führt dazu, dass die Metadaten des Kunden aktualisiert werden (“.update”-Datei im Kunden-Ordner). Die remove-Datei ist optional und führt zur Löschung der Produkten aus den jeweiligen Matrizen. Es folgen mehrere result-Dateien. Eine Kategorie wird abgeschlossen und aktualisiert, falls der Zähle der Kategorie aus catInfo Null erreicht hat.
Wenn alle Zähler auf Null stehen, ist der Export eines Kunden abgeschlossen. Alle JSON-Dateien werden nach Abarbeitung in den Ordner 'done' im picalike_ftp-Ordner verschoben.
Durchgeführt wird der Export durch folgende cronjobs:
Aus Erfahrung sind folgende Situation möglich, ggf. mit Lösung