klaus1968 schrieb:
Ein EAN Code besteht aus 8 oder 13 Ziffern. ist auf alle Produkte bekannt als Barcode. (https://de.wikipedia.org/wiki/European_Article_Number)
Die Datei mit den 250.000 EAN sieht so aus:
4105850015559
4105250024007
...
Im Beispiel sieht es aus, als käme keine 8stelligen sondern nur 13stellige EANs vor - ist dem so?
Bevor die frage kommt wie schaut die xml Datei aus
Zu spät - ich habe die Frage schon gestellt. ☺
hir die ersten 50 Zeilen:
<?xml version="1.0" encoding="UTF-8"?>
...
Darin finde ich nur 13stellige EANs, in zwei Sorten von xml-Tags. Gibt es nur die 2,
| <sh:Identifier Authority="EAN.UCC">4399902241779</sh:Identifier>
<gln>4049111100007</gln>
|
Gibt es nur die 2 oder noch mehr? Kommen vielleicht 8 oder 13stellige Ziffernfolge, eventuell auch 9 oder 14stellige und längere Nummern vor, die keine EANs sind? Das würde ich, wenn ich es nicht sicher wüsste, einmal testen.
Als es muss wirklich jede Datei geöffnet werden nach den Code gesucht werden, ist der Code vorhanden die Datei in ein Verzeichnis X kopiert werden.
Ja, die Frage ist, ob man die Dateien 250.000 mal öffnen muss bzw. - ich weiß nicht, wie fgrep da arbeitet, um 2.5 Mio. Dateien gegen so eine große Liste zu checken.
Ist das Verzeichnis mit den ca. 2,5 Mio xml-Dateien eigentlich flach, oder ist es ein Verzeichnis mit Unterverzeichnisstrukturen, die erhalten bleiben sollen?
Ich würde wohl den brute-force-Ansatz von seahawk mal 10 Minuten laufen lassen und schauen, wie weit der in 10 Minuten kommt und dann abbrechen und hochrechnen, wie lange es insgesamt dauert. Wenn das in 24h durch ist, wäre das ja wahrscheinlich akzeptabel.
Gibt es eine Schätzung, ob eher 90% oder eher 10% (fast alle/fast keine) der Dateien den Filterungsprozess überleben?
Die Beispiel-xml-Datei hat 5 EANs, 2 davon doppelt, also könnte an 3 Stellen den Filterprozess überleben. Ist das ein typischer Fall, oder sind die xml-Dateien in Realität meist viel größer und enthalten wesentlich mehr EANs?
Eine ad-hoc-Optimierungsstrategie, die mir einfiele, wäre, dass man für jede Datei die EANs einmal ausliest, und die Datei in alle Verzeichnisse kopiert, die mit den ersten X, zum Beispiel den ersten 3 Ziffern beginnt, also für die Beispieldatei:
| egrep "[0-9]{8}" ean-sample.xml
<sh:Identifier Authority="EAN.UCC">4049111100007</sh:Identifier>
<sh:Identifier Authority="EAN.UCC">4399902241779</sh:Identifier>
<gln>4049111100007</gln>
<gln>4002391000009</gln>
<gln>4002391000009</gln>
|
wären das
404, 439 und 400, bzw. sortiert 400, 404 und 439.
Die Liste mit den 250.000 Einträgen könnte man dann zerschneiden in 250 Listen mit je 1000 Einträgen im Schnitt, Gleichverteilung der Zahlenfolgen vorrausgesetzt. Womöglich ist die Verteilung der EANs aber sehr unausgewogen, was die ersten Ziffern, nicht aber was die letzten Ziffern betrifft, so dass man das Ganze lieber von hinten aufzieht, so dass man mit den Ziffern 007, 009 und 779 arbeiten würde. Ziel ist es viele etwa gleichgroße Listen zu haben.
Also käme die xml-Datei in 3 Verzeichnisse, 007, 009 und 779. Die EAN-Liste würde man mit
| rev ean.lst | sort | rev > ean-sorted.lst
|
nach den letzten Ziffern sortieren. Dann würde man nach allen EANs mit der Endung 000 nur im Verzeichnis 000 suchen, dann mit denen mit der Endung 001 im Verzeichnis 001 usw. Man hätte einen großen Programmieraufwand, aber die Laufzeit wäre nur ungefähr 1/1000tel schätze ich. Ob das Programm einen Tag oder 3 Jahre läuft, das wäre den Aufwand wert, aber dafür wäre die Abschätzung gut, wie lange die Brute-Force-Methode braucht. Ob 3 Minuten oder 3000 Minuten - da würde man eher die 3000-Minutenvariante wählen, weil weniger Arbeit und weniger fehleranfällig.
Gematchte Dateien schreibt man in ein Zielverzeichnis. Wird eine Datei mehrfach ins Zielverzeichnis geschrieben ist das kein Thema.
Mit einer richtigen Programmiersprache würde ich das Problem eher so angehen:
EAN-Liste sortieren.
Mit grep ähnlich wie oben alle 2.5 Mio. Dateien durchfortsten, und eine Liste generieren, EAN->Dateiname(n).
| 4049111100007 -> sample.xml
4399902241779 -> sample.xml
|
Die zweite Liste auch nach EANs sortieren.
Dann kann man beide Listen in einer Schleife durchgehen. Angenommen es wäre: #
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | i (hochzählen) Eanliste XML-EAN-Filelist-Map
-------------
...
4049111100004 4049111100004 -
4049111100005 - -
4049111100006 4049111100006 -
4049111100007 - sample.xml
4049111100008 4049111100008 -
4049111100009 -
...
4399902241778 -
4399902241779 4399902241779 sample.xml
4399902241789 -
...
5399902241779 5399902241779 a.xml b.xml u.xml
...
|
Entweder es gibt ein Match, dann gibt man den/die Dateinamen aus bzw. kopiert die Datei(en) ins gute Töpfchen, oder die EAN-Liste enthält i nicht, oder es gibt keine Datei(en) die matchen.
Relativ große Vorbereitung, aber dann werden die Zahlen bis 9.999.9.... nur einmal durchlaufen.
