Re: Mehr Speed?

Andreas Gabriel wrote at 2009-4-11 11:56 +0200:
> ...
>> "ManagableIndex" unterstützt nicht automatisch Suchen über einen
>> Anfangsabschnitt eines "Multi-Column-Index".
>
>Würde das nicht "makeAdvancedQuery" machen?

Nein. "makeAdvancedQuery" übersetzt nur von der eingeschränkten
Katalog-Anfragespezifikation in die reichere "AdvancedQuery" Spezifikation.
Es enthält keine allzu große Intelligenz.

Auch "AdvancedQuery" optimiert nur auf der Ebene von "Und/Oder/Nicht",
Indexe werden atomar behandelt. Also auch hier keine automatische
Ausnutzung von "Multi-Column-Index"en.

Wenn man in einem "AdvanceQuery"/"ManagableIndex" etwas ähnliches
Unterstützen wollte, dann würde ein spezieller Indextyp der
natürliche Ansatz.

>> Wenn also beispielsweise ein Index über "A" und "B" definiert ist,
>> dann führt der Index im Normalfall keine Suchen "A=a" sondern nur
>> Suchen "A=a, B=b" aus. Suchen "A=a" können aber mit "Between"-Queries
>> emuliert werden.
>
>Hmm, kannst Du einfach mal ein primitives Konfig-Beispiel im Sinne eines 
>composite index für "review_state, portal_type" incl. Query angeben, z.B.
>
>ManagableIndex -> FieldIndex/KeyWordIndex ?
>
>   review_state: ...
>   portal_type:  ...
>
>AdvancedQuery ... ?

Was ist denn Dein Use-Case für einen solchen Multi-Column Index?


Use-Case 1:
===========
Du möchtest über Paare ("review_state", "portal_type") suchen.
Das geht alternativ auch flexibler über 2 separate Indexe (die man auch für
andere Zwecke verwenden kann) und eine "Und" Subquery.

Du legst einen "Managable FieldIndex" an, fügst 2 "AttributeLookup"s
für "review_state" und "portal_type" hinzu und wählst als
"combine_type" "aggregate".

Suchen sehen so aus: "Eq(index, (review_state, portal_type))".
Wenn man den Index missbrauchen möchte für Suchen nach "review_state",
kann man "Between(index, (review_state, ''), (review_state, 100*'\xff'))"
verwenden.


Use-Case 2:
===========
Du hast Werte, die vielleicht "review_state"s vielleicht aber auch
"portal_types" sein können und möchtest über solche Werte suchen.
Das geht alternativ auch flexibler über 2 separate Indexe (die man auch für
andere Zwecke verwenden kann) und eine "Oder" Subquery.

Du legst einen "Managable KeywordIndex" an, fügst 2
"AttributeLookup"s für "review_state" und "portal_type" hinzu, definierst
für diese "Normalizers" der Form "[value]" und wählst für
den Index als "combine_type" "union".

Suchen sehen dann so aus: "Eq(index, review_state_or_portal_type").

Dieser Use-Case wird von relationalen Multi-Column-Indexen nicht unterstützt
(denn relationale Datenbanksysteme kennen meine "KeywordIndex"e).

>Ich frage mich nur, ob wir von der gleichen Sache sprechen und es sich 
>weiterhin lohnt in CompositeIndex Gehirnschmalz zu investieren.

Nach meinem Verständnis von Multi-Column-Indexen
sind sie eine Optimierung, wenn Du überwiegend nach Tupeln (Use-Case 1 oben)
suchst. Mit einem entsprechenden Multi-Column-Index hast Du einen einzigen
Index-Zugriff -- mit separaten Indexen musst Du die "Und"-Subquery auswerten,
dazu sind n-Indexzugriffe notwendig.



-- 
Dieter


_______________________________________________
zope mailing list
[email protected]
https://mail.dzug.org/mailman/listinfo/zope