Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vollständige Verarbeitung aller vom catcher bereitgestellten Dokumente? #18

Open
guenterh opened this issue Dec 22, 2017 · 1 comment
Assignees

Comments

@guenterh
Copy link
Member

guenterh commented Dec 22, 2017

Es stellte sich die Frage, ob alle Dokumente, die vom catcher bereitgestellt werden, ordnungsgemäss im workflow verarbeitet werden.

Hintergrund:
während im Verarbeitungsdirectory mehr als 500.000 Dokumente anstehen (500.000 ist der threshold für den Stopp des catchers zur Zeit), wurden aber nur ungefähr 370.000 Dokumente indiziert.

swissbib@ub-sbhp01:/swissbib_index/lsbPlatform/data$ ls createFolderTemp | wc -l
505727
swissbib@ub-sbhp01:/swissbib_index/lsbPlatform/data$

number of processed records

(Anmerkung: dies war ein Testlauf auf meinem lokalen Laptop mit einem vor dem Start leeren Index so dass man leicht überprüfen kann, ob alle und wie viele Dokumente verarbeitet werden)

Zur Beantwortung habe ich ein kleines Script geschrieben:
https://github.com/guenterh/pyutil/blob/master/quicktools/countUniqueRecords.py

Hier das Ergebnis:
number of documents in dictionary: 372107

key / count 2 118763
key / count 3 4133
key / count 4 1703
key / count 5 310
key / count 6 37
key / count 7 3

Es müssten also 372.107 Dokumente indiziert worden sein. Tatsächlich sind es aber nur 372.013

Mögliche Ursache für die Differenz: #17
Das muss man noch genauer abklären
In der Tendenz scheint das Ergebnis aber ok zu sein

@guenterh
Copy link
Member Author

Interessant an dieser Überprüfung ist auch, wie viele Dokumente innnerhalb kurzer Zeit (wohl während des laufenden Verarbeitungsprozesses auf CBS) doppelt vom pusher zum catcher geschickt werden.

Dieses Thema sollte man bei einem alternativen Deduplizierungs / Clusterverfahren berücksichtigen

@guenterh guenterh added this to the production_ready milestone Dec 22, 2017
@guenterh guenterh self-assigned this Dec 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant