Maximalgröße bei KeyValueSpreadsheet (WARNING:Map exceeds maximum of 300kB9

Hallo zusammen,


oben genannten Fehler tritt bei mir häufiger bei der Arbeit mit dem KeyValueSpreadsheet auf.

Wenn ich nicht die Möglichkeit habe, die in der Map verwendeten Keys oder Values zu kürzen, lass ich das KeyValue-Map einfach weg und iteriere über den SpreadsheetMapper selbst. Mit einem relativ kleinen Skript kann man sich ja selbst die Funktionalität des KeyValue-Map zusammenbasteln.


Eigentlich präferiere ich das KeyValueSpreadsheet gegenüber der Iteration übers Spreadsheet, da der Code kompakter und einfacher zu lesen ist. Leider wird der Nutzen des KeyValueSpreadsheets durch das Limit auf 300kB stark limitiert.

Dazu kommt, dass das KeyValue-Map vermutlich performanter ist als die Iteration übers Spreadsheet.


Ich nehme an, das ganze läuft auf einen Tradeoff zwischen Arbeitsspeicher und Prozessorlast hinaus. Die Iteration verursacht mehr Prozessorlast, kostet aber weniger Arbeitsspeicher. Wobei ich nicht ganz nachvollziehen kann, wieso es bei dem KeyValueSpreadsheet so ein Limit gibt, während ich mittels der Caching-Funktion ein ganzen Spreadsheet mit hunderten Spalten und tausenden Einträgen speichern kann. Liegen die gecachten Spreadsheets nicht im Arbeitsspeicher, die KeyValue-Map aber doch?


Das Limit wurde ja letztes Jahr erst auf Anfrage verdoppelt. Ich frage mich, ob es überhaupt Sinn macht, hier ein Limit zu setzen? Können große KeyValue-Maps nicht einfach wie gecachte Spreadsheets gehandhabt werden?

Wir nehmen das Thema nochmal mit. Aktuell ist zwar leider keine Zeit, aber wir wollen mal prüfen, ob und welche Wege wir sehen, das zu verbessern. Du beschreibst den Tradeoff schon korrekt. Der Unterschied zwischen einem gecachten Spreadsheet und einer Map ist, dass man bei einem Spreadsheet der Reihe nach die Zeilen ausließt.. unser Cache ist beim Spreadsheet die Festplatte. Bei einer Map will man aber auf einen bestimmten Key zugreifen und dafür ganz schnell den Wert bekommen. Dazu muss das möglichst im RAM sein, damit das schnell geht. Ansonsten würde unter der Haube so eine Iteration wie bei dir passieren, was wir unter allen Umständen vermeiden wollen.


Nachtrag: das KVSpreadsheet wurde eher für kleine KV-Lookups gebaut, wo es eher um kurze IDs geht. Also ähnlich wie ein Mappingset, aber dynamischer im Flow.


Wir melden uns , wenn wir da einen Ansatz sehen. Aber aktuell ist wenig Luft dafür.


Folgendes würde uns aber helfen:

1. für welche Dinge verwendest bzw. würdest du immer KeyValueSpreadsheet verwenden? (was für Daten sind das so? was steht im Key? was im Value?)

2. wieviele Einträge / Zeilen hast du so grob? eher wenige Zeilen, aber große Values ? oder eher viele Zeilen und kurze Values?

3. Wieviele KVSpreadsheets hast du so pro Flow (min, max, avg)?


Das würde uns ein Gefühl geben und am Ende ist die Lösung eine Abwägung der von dir genannten Tradeoffs aus CPU vs. RAM vs. Laufzeit.

War meine Vorstellung des Geschehens unter der Haube also garnicht so falsch.

Zu den Fragen:
1. Die KV-Spreadsheets benutzen wir meistens zum Ergänzen von Daten aus einem Spreadsheet in einem anderen. Der Key ist nahezu immer unsere Artikel-Nr..
Die Value ist beispielsweise die EAN, Preis, Link zu einem Bild oder ein Dateiname.
Einzige Abweichung ist ein Analyticsreporting, in dem wir Länder auf den in dem Land erzielte Traffic-Daten mappen.

2. Irgendwo zwischen 2000-9000 Einträge. Die Keys sind eher kurz, unsere Artikel-Nr. ist z.B. 7-stellig. Die Länge der Values schwankt je nach Anwendung, maximum liegt bei ungefähr 50-100 Zeichen.

3. KV-Spreadsheets benutzen wir in knapp 15% unserer Flows. Meistens benutzen wir nur ein KV-Spreadsheet pro Flow, maximum liegt bei 4.
Die wirklichen Zahlen sind ein bisschen höher, da ich die KV-Spreadsheets aufgrund des Limits nicht immer benutzen kann.



Mein (häufigste) Zielsetzung trifft das folgende Bild sehr gut.

image
Beim Reflektieren fällt mir auch auf, dass ich in vielen Fällen auch durch ein SpreadsheetAppend mit anschließendem Gruppieren nach Artikel-Nr. mein Ziel erreichen würde.

Es gibt sogar einen Fall, wo ich das tue, da ich aus Tabelle B nicht nur eine Spalte übernehme, sondern jenseits von 10 Spalten. Bei dieser Anwendung stört mich aber, dass ich den Mapper zum Gruppieren immer wieder anpassen muss, wenn ich Spalten in Tabelle A oder B ergänze.


Wenn ich so drüber nachdenke, ist mir wahrscheinlich am meisten geholfen, wenn es einen Step gäbe, der die Funktion des obigen Bildes abbildet. Der Screenshot ist übrigens von http://molbiotools.com/twotableoperations.html, vielleicht lasst ihr euch ja von den Konfigurationsmöglichkeiten auf der Seite inspirieren ;).


Das ganze ist offensichtlich kein kritisches Problem. Hab vollstes Verständnis dafür, dass ihr da dringendere Themen habt.

Danke für deinen detaillierten Input. Das hilft das Ganze besser zu bewerten. Wir schauen mal, was wir machen können.