Properties.contains("Hell*orld");

[ixanos]

Hallo zusammen

Ich habe ein Properties-Objekt welches mehrere einträge beinhaltet (za 3.000.000) und möchte in der Lage sein schnell zu testen ob gewisse Property-Keys eine vorgegebene Regular Expression oder eine Wildcard-Suche entsprechen. Da ist die contains-methode des Properties-Objektes nicht wirklich hilfreich, da diese den gesammten Key-checkt.

Hat jemand von euch eine Idee wie man sowass handhabt?

Gruss
Ioannis

 

[tuxedo]

Key-Iterator holen und jeden Key mit einem RegEx behandeln..
Wäre meine erste Idee.. Ob die gut ist, ist ne andere Frage.

- Alex

 

[ixanos]

das hilft nicht wirklich, da ich ja dann 3.000.000 sclüssel prüfen müsste.

 

[SlaterB]

man kann sich entsprechende Strukturen aufbauen, die 3 Mio. Strings z.B. in einen Baum ablegen der nach 1., 2., 3. Buchstaben verzweigt usw.,
oder für bestimmte markante Bestandteile im Voraus Teillisten/ Quer-Indexe anlegen,
(z.B. Buchstabenpaare, drillinge)

um aber ohne Einschränkung beliebige RegEx zu prüfen, z.B. .*huh(u|a)+.*,
da scheinen mir andere Wege als sequentiellen Durchlauf unmöglich

was nicht heißen muss, dass es sie nicht gibt

siehe z.B.
http://lucene.apache.org/java/docs/

Apache Lucene is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform.

 

[tuxedo]

das hilft nicht wirklich, da ich ja dann 3.000.000 sclüssel prüfen müsste.

Egal wie du's anstellst, 3Mio Schlüssel müssen so oder so durchsucht werden. Es gibt keine magische Blackbox auf der steht "Hier geschieht ein Wunder" und die möglichst keine Eingabe (also keine 3Mio Schlüssel, nur der Suchbegriff) hat und eine Ausgabe produziert, die auf deinen Suchbefehl passt.

Du musst nur eben effizient die Suche angehen.. Vorschläge hast du ja schon.

Auf der anderen Seite:

Wenn du dir Sorgen bzgl. der Effizienz machst: Ist es effizient Property-Objekte mit 3Mio Einträgen zu haben?

- Alex

 

[SlaterB]

also bei der normalen Hashmap muss man nur den Hashcode berechnen,
nicht 3 Mio. Strings durchforsten

das geht allgemein schon wenn man sich nur genau genug festlegt,
was bei beliebigen RegEx eben umso schwerer wird,
das widerspricht sich, ist gegenläufig oder was man da so sagt

 

[tuxedo]

Jo, also kommt er nicht drum rum... ;-)

 

[bygones]

das hilft nicht wirklich, da ich ja dann 3.000.000 sclüssel prüfen müsste.

Egal wie du's anstellst, 3Mio Schlüssel müssen so oder so durchsucht werden. Es gibt keine magische Blackbox auf der steht "Hier geschieht ein Wunder" und die möglichst keine Eingabe (also keine 3Mio Schlüssel, nur der Suchbegriff) hat und eine Ausgabe produziert, die auf deinen Suchbefehl passt.

nicht ganz - heuristische oder sonstig intelligente suchsysteme koennen schon anhand ihrer struktur den suchraum einengen, d.h. dass man eben nicht die 3Mio durchsuchen muss, sondern nur einen Teil davon....

 

[tuxedo]

Ja, jetzt reitet halt drauf rum ;-) Viele Wege führen nach Rom. Es gibt kurze und beschwerliche Wege über die Alpen (3Mio Strings abklappern), oder lange und schnelle Wege mit einem Raumschiff das unterwegs am Mars vorbei kommt (heuristische oder sonstige intelligente Suchsysteme).

Ich würd glaube ich, solche Daten gleich in ein System stecken, das sich schnell und effizient durchsuchen lässt (Datenbanksystem oder sowas in der Art) als ein Property.

Aber das hilft unserem Hilfesuchenden auch nicht weiter.

-Alex

 

[byte]

@alex0801: Hör mal bitte auf den Threadersteller mit Deiner offensichtlichen Unwissenheit auf diesem Gebiet zu verwirren.

 

[Wildcard]

Was spricht denn gegen Lucene? IMO genau das richtige für diese Datenmenge, zumal Wildcard Queries damit möglich sind.

 

[SlaterB]

ixanos hat sich seitdem noch nicht wieder gemeldet,
wahrscheinlich ist er/ sie so begeistert davon

 

[Wildcard]

Zu recht. Lucene ist echt spitze. :wink:

 

[Lucene !]

Hallo zusammen

Ich habe eigentlich Lucene schon benutzt und auch Kontakt zu Otis Gospodnetic aufgenommen um nachzuvoillziehen warum Lucene keine direkten Updates erlaubt. Wenn man mit Lucene die gleiche Datei 2 mal indiziert dann hat man duplikate. Das ist nicht gut für meine Anwendung. aus diesem Grund habe ich meine eigene "Lucene " suchmaschine gebaut. Diese garantiert dass es eben keine Duplikate gibt auch wenn das gleiche Dokument 2 oder X-mal indiziert wird.

Zur Zeit besteht das Problem dass ich noch keinen effektiven Weg gefunden habe um 3mil oder mehr auf wildcards zu suchen. Es müssen jetzt nicht unbedingt beliebige Regular Expressions überprüfbar sein. Es reicht auch einfache wildcards zu prüfen.

Man könnte z.B. folgende Suchquery absetzen:

+filename:readme.txt +contents:ixanos +location:"c:\mydocume*"

Meine Problem bei dieser query ist zur Zeit das letzte Teil : +location:"c:\mydocume*"


Man könnte antürlich die dokumente einschrenken durch die ersten 2 queries und dan wäre das alles nicht so tragisch. Dann wiederrum kann es aber sein dass im "c:\mydocume*"-Baum 100.000 Dateien drin sind oder 5 GB von Daten!!

Ein anderer Gedanke wäre anstatt Strings zu vergleichen eine von "String" abgeleitete Klasse zu bauen wo die
equals-Methode nur auf die länge des kleinsten Strings prüft:

Beispiel: Token = "c:\mydocume*"
Pfad zur Überüfen = "c:\mydocuments\test\"

Die equals prüft alle Strings bis zur Länge = 11 = "c:\mydocume".length() und gibt für alle true zurück.
Das obige bitte nur als "Brainstorming" betrachten, den ich weis noch nicht wie ixh das am effektivsten einbauen kann.


Gruss
Ioannis

 

[ixanos]

Obige Nachricht ist von mir (habe den Benutzernamen vergessen gehabt)