See: Description
| Interface | Description |
|---|---|
| ObjectItemServiceIF |
| Class | Description |
|---|---|
| BfServerConfig | |
| ExpressionResult | |
| ObjectItemService |
Dieser Dienst bietet die Möglichkeiten einer "Suchmaschine" im Kleinen.
|
| OperToken | |
| Selection |
Hält den Zustand einer Session
|
| Spider | Deprecated |
| Startup |
| Enum | Description |
|---|---|
| OperToken.Brace | |
| Selection.Oper |
Jeder benutzt bei der Recherche im Internet die gängigen
Suchmaschinen auf inzwischen selbstverständliche Art und Weise:
Aus der Menge aller Web-Sites möchte ich all die haben,
bei denen die Begriffe "bla" und "blub"
aufgeführt sind, aber es sollen alle weglassen werden, die "blob"
enthalten: "bla blub -blob"
(Das gab
letztens mit Google 227.000
Resultate bei 0.39
Sekunden Suchdauer.)
Daß die Suchmaschinen recht flott Ergebnisse liefern - selbst bei komplizierten Abfragen und großen Datenmengen - wird als selbstverständlich angesehen und ist die Voraussetzung für ihren Erfolg.
Nur wie funktioniert sowas?
Die Aussage "Wird irgendeine große Datenbank sein!" ist
richtig und falsch zu gleich:
Daten in einer Datenbank vorzuhalten
ist immer eine gute Idee;
aber wie sieht das mit dem Zugriff auf
die Daten aus?
Die Überraschung besteht darin, daß für die Formulierung derartiger Such-Abfragen eine relationale Datenbank mit SQL ungeeignet ist, weil viel zu langsam.
Der hier in Java realisierter Suchalgorithmus ist auf Geschwindigkeit optimiert. Jede beliebige Abfrage dauert nicht länger als wenige Millisekunden.
Es können beliebige "Objekte" definiert werden, die mit beliebigen "Eigenschaften" versehen sind.
Auf dieser Basis könne Abfragen bezüglich der "Eigenschaften" formuliert und die Ergebnismenge der "Objekte" wird geliefert.
Welcher Art die Objekte und ihre Eigenschaften dabei sind, bleibt der Phantasie des Anwenders überlassen. Hier ist ein "Objekt" lediglich über eine numerische Object-ID definiert, und eine "Eigenschaft" als eine Zeichenkette von beliebig vielen Zeichen1.
In einem logischen Ausdruck können keine Eigenschaften mit Wildcards eingesetzt werden; also "bl*" für bla, blub, blob etc.
Die Aufeinanderfolge von Eigenschaften ist dem System unbekannt,
es sei denn, es wird eine Eigenschaft entsprechend
definiert:
Eigenschaften dürfen hier auch White Space enthalten:
"Meine Eigenschaft"; auf diese Art können auch beliebte
englische Ausdrücke als Eigenschaft definiert werden: "open
source"
Die Vergleichbarkeit dieser "kleinen" Suchmaschine mit den "großen" endet damit, daß derartig riesige Datenmengen nicht problemlos gehandhabt werden können.
Es wird vermutet, daß mit diesem Algorithmus bis zu 5 Millionen Objekte mit 100.000 Eigenschaften zuverlässig und schnell verarbeitet werden können. Die Datenbank wird dann ca. 3 bis 4 GB umfassen.
Alles was darüber hinaus geht ist eher ein Problem der darunter liegenden Datenbank, sehr große Datenbestände zu handhaben; vor allem die Datenbestände auf mehrere Rechner zu verteilen. Google behauptet 3 Mrd Sites indiziert zu haben; es ist unbekannt, wieviele "Eigenschaften" es dabei gibt (alle Worte aus allen Sprachen dieser Welt!). Das dürfte dann wohl im zweistellig TB-Bereich liegen....
Das Framework wurde bisher mit Postgres getestet; im Kern ist jede Datenbank geeignet, die über die Möglichkeit der Komprimierung verfügt.
1Bei Einsatz von PostgreSQL sind das 1GB