[MSSQL] Full-text search,anders dan MS full-text search

[Verwijderd]

Ik ben benieuwd naar de ervaringen met andere software dan de Microsoft full-text search engine.

Op zich is de functionaliteit van bovenstaande enorm, maar vreemd uitgevoerd. Je kunt door middel van containstable en freetext verschillende modussen activeren. Beide met hun eigen performance hit, resultaten maar ook wijze van zoeken.

Je kunt bijvoorbeeld stemming activeren (in beiden), AND OR AND NOT constructies gebruiken, met wildcards werken, maar het belangrijkste nadeel van de search is dat je niet vooraf de zoekresultaten kunt beperken dmv een filter.

Je activeerd de search op een column, maar naast die column kun je geen additionele data specificeren als bijvoorbeeld een categorie, een datetime stamp, etc. De enige mogelijkheid om een filter tijdens het zoeken toe te passen is deze in de te doorzoeken column opnemen welke meestal van het type text is.

Wil je dus een filter toepassen op je zoekresultaten, alla where datetimestamp = mydate dan zit je al snel vast. Dit resulteerd erin dat je eerst een zoekactie moet uitvoeren en deze in een temporary table plaatsen. Op deze resultaten moet je vervolgens je filter loslaten, maar dat betekend wel dat je zoekactie ondertussen je hele catalogue heeft doorzocht.

Met enorme lappen content zorgt dit voor een overbodige performancehit, je wil namelijk eerst je zoekgebied verkleinen, en dan pas in dat zoekgebied zoeken. Ik wil bijvoorbeeld 6 categorieën selecteren, waarbij de artikelen niet ouder zijn dan 1 maand. Dat kan ik pas toen zodra ik de temporary table gevuld heb na de zoekactie, of relationele data ga opnemen in het text veld wat dus niet zo een geweldig idee is. Een ander issue die je hierbij tevens krijgt is het berekenen van de score van de content, deze wordt initieel gezet bij het zoeken. Na je filtering is deze ook natuurlijk incorrect.

Dus, zijn er goede alternatieven beschikbaar die bij voorkeur makkelijk geintegreerd kunnen worden met MS SQL Server 2000? Heb je ervaringen met deze producten, en wat waren de voordelen, nadelen, relevantie van de zoekresultaten, etc.

[EfBe]

Full text search gebruikt indexserver. Dus het is niet zo vreemd hoe de query eigenlijk verloopt. (eerst id's ophalen in indexserver en dan die gebruiken voor query op table).

Heb je het getest, de performance of neem je aan dat het traag is? Immers, als je middels een subquery de search doet, en de category filter in de main query zal hij IMHO wel degelijk het goed optimaliseren (join met self is overigens beter)

[ Voor 28% gewijzigd door EfBe op 23-03-2004 23:09 ]

[_Thanatos_]

Full text search gebruikt indexserver

Je bedoelt de Indexing Service? Dan ben je in de war met de search-mogelijkheden binnen IIS. De Full-text Search engine van MSSQL is echt een apart ding.

Maar om de TS een beetje te helpen: ik heb het zelf nog nooit geprobeerd, maar is het niet mogelijk om een fulltext-search query los te laten op een derived table? En ik dacht dat MSSQL 2000 indexed views ondersteunt, misschien ook fulltext indices op een view?

[EfBe]

_Thanatos_ schreef op 24 maart 2004 @ 01:39:
[...]

Je bedoelt de Indexing Service? Dan ben je in de war met de search-mogelijkheden binnen IIS. De Full-text Search engine van MSSQL is echt een apart ding.

Nee het heeft niets met IIS te maken. Full text search werkt niet wanneer je MS Search service uitzet. Dat is dezelfde service die je laat zoeken indexes van indexserver. Index server heette het vroeger, dat is tegenwoordig gewijzigd, maar het is nog steeds dezelfde techniek met dezelfde query syntax.

Maar om de TS een beetje te helpen: ik heb het zelf nog nooit geprobeerd, maar is het niet mogelijk om een fulltext-search query los te laten op een derived table? En ik dacht dat MSSQL 2000 indexed views ondersteunt, misschien ook fulltext indices op een view?

Full text search werkt niet in de DB engine. Het voert de texten aan index server die er wordlists van maakt, een catalog van bakt en waar je middels ms search service in zoekt (maar in dit geval dan dus indirect via sqlserver). Vandaar ook dat je niet een simpele select uitvoert op de table maar dat het via nogal wat schijven loopt. DAT is het probleem van de topicstarter.

[_Thanatos_]

EfBe, wat bazel je nou man? We hebben het over de full-text search enigne van MSSQL 2000, niet over de Indexing service die je bij windows krijgt.

[P_de_B]

_Thanatos_ schreef op 24 maart 2004 @ 13:05:
EfBe, wat bazel je nou man? We hebben het over de full-text search enigne van MSSQL 2000, niet over de Indexing service die je bij windows krijgt.

Full Text Indexing service van SQL Server gebruikt Microsoft Search (oftwel Indexing Service). eFBe heeft gelijk in dit geval.

edit: linkje naar MSDN

[ Voor 15% gewijzigd door P_de_B op 24-03-2004 13:13 ]

[Verwijderd]

EfBe schreef op 23 maart 2004 @ 23:07:
Immers, als je middels een subquery de search doet, en de category filter in de main query zal hij IMHO wel degelijk het goed optimaliseren (join met self is overigens beter)

Op het moment dat je die actie start, ga je al door je hele catalogue heen.

[cameodski]

P_de_B schreef op 24 maart 2004 @ 13:09:
Full Text Indexing service van SQL Server gebruikt Microsoft Search (oftwel Indexing Service). eFBe heeft gelijk in dit geval.

De Indexing Service lijkt qua functionaliteit op de Full-text search, maar is toch wel anders.
Ik kan de Indexing service ook rustig stoppen en dan blijft de full-text search gewoon werken.

De full-text search van Microsoft bouwt inderdaad een catalogus die bij zoekacties volledig wordt doorzocht. Eventueel kun je het zoeken wel beperken tot één kolom.
Als je bijvoorbeeld een forum oid hebt met tien jaar historie en je wilt alleen zoeken in artikelen van afgelopen week wordt dus altijd de hele catalogus doorzocht. Je kunt dit vervolgens wel filteren, maar de full-text search zoekt altijd in alle records.
Het enige wat over het algemeen als oplossing aangedragen wordt, is om data die nodig is om te filteren, op te nemen in de kolom die opgenomen wordt in de full-text catalogus. Wil je echter zoeken op alles van de afgelopen maand dan moet je elke dag afzonderlijk opnemen in de zoekstring en dat klinkt ook niet erg efficiënt.

Verder is het ook niet mogelijk om de full-text catalog te backuppen en restoren, zodat bij een eventuele crash de catalogus volledig opnieuw gegenereerd moet worden. En dat is bij veel data een nogal tijdrovende klus. In Yukon komt trouwens wel een backup/restore faciliteit en ook het opnieuw genereren schijnt daar stukken sneller te gaan.

[Verwijderd]

"maar de full-text search zoekt altijd in alle records"

Klopt en dat wil je dus echt niet hebben met een enorme database met content.

[Skaah]

Met enorme lappen content zorgt dit voor een overbodige performancehit, je wil namelijk eerst je zoekgebied verkleinen, en dan pas in dat zoekgebied zoeken. Ik wil bijvoorbeeld 6 categorieën selecteren, waarbij de artikelen niet ouder zijn dan 1 maand. Dat kan ik pas toen zodra ik de temporary table gevuld heb na de zoekactie, of relationele data ga opnemen in het text veld wat dus niet zo een geweldig idee is. Een ander issue die je hierbij tevens krijgt is het berekenen van de score van de content, deze wordt initieel gezet bij het zoeken. Na je filtering is deze ook natuurlijk incorrect

* Skaah denkt misschien te simpel, maar, kun je niet een tmptabel maken die aan alle voorwaarden voldoet en die dan doorzoeken?

[Verwijderd]

De onderliggende service is MS-Search. Deze wordt vanuit verschillende andere MS diensten aangesproken (Indexing, SQL, Sharepoint).

[EfBe]

cameodski schreef op 24 maart 2004 @ 13:34:
[...]

De Indexing Service lijkt qua functionaliteit op de Full-text search, maar is toch wel anders.
Ik kan de Indexing service ook rustig stoppen en dan blijft de full-text search gewoon werken.

Dit begint vermoeiend te worden.
Disable de MS Search service maar en probeer dan maar eens een full text search query te runnen op je catalog of een table te indexeren voor full text search.

De indexing service is een service die bepaalde code gebruikt om texten te indexeren. Full text search gebruikt dezelfde code, zelfs dezelfde query language.

De full-text search van Microsoft bouwt inderdaad een catalogus die bij zoekacties volledig wordt doorzocht. Eventueel kun je het zoeken wel beperken tot één kolom.

Mja, maar dit zoeken gebeurt op keyword, dus het is volkomen anders dan een select * from query op een table.

Als je bijvoorbeeld een forum oid hebt met tien jaar historie en je wilt alleen zoeken in artikelen van afgelopen week wordt dus altijd de hele catalogus doorzocht. Je kunt dit vervolgens wel filteren, maar de full-text search zoekt altijd in alle records.

NEE, hij zoekt in de wordlists voor de keywords. Vind hij een match dan heeft hij een ID voor een record dat voldoet aan de keyword. Met die id gaat de full text search van sqlserver dan de bij behorende rows filteren.

Ergo: er worden helemaal geen records doorzocht.

[cameodski]

EfBe schreef op 24 maart 2004 @ 16:31:
Dit begint vermoeiend te worden.
Disable de MS Search service maar en probeer dan maar eens een full text search query te runnen op je catalog of een table te indexeren voor full text search.

De indexing service is een service die bepaalde code gebruikt om texten te indexeren. Full text search gebruikt dezelfde code, zelfs dezelfde query language.

MS Search moet je natuurlijk niet disablen. Ik had het over de Indexing Service.

Mja, maar dit zoeken gebeurt op keyword, dus het is volkomen anders dan een select * from query op een table.

Ja, gelukkig wel. Anders moet je helemaal verschrikkelijk veel geduld hebben.

NEE, hij zoekt in de wordlists voor de keywords. Vind hij een match dan heeft hij een ID voor een record dat voldoet aan de keyword. Met die id gaat de full text search van sqlserver dan de bij behorende rows filteren.

Ergo: er worden helemaal geen records doorzocht.

Je hebt gelijk: ik heb het wat krom geformuleerd.
Wat ik bedoel is, dat MS Search bij veel voorkomende zoekwoorden een enorme hoeveelheid ID's teruggeeft, terwijl je door een filter die erna komt er uiteindelijk maar een paar over houdt.
En al die onnodige ID's eruit filteren is slecht voor de performance.

P.S. Ik heb het nu trouwens over de CONTAINSTABLE en FREETEXTTABLE varianten.

Skaah schreef op 24 maart 2004 @ 16:13:
* Skaah denkt misschien te simpel, maar, kun je niet een tmptabel maken die aan alle voorwaarden voldoet en die dan doorzoeken?

Ik denk dat dat inderdaad te simpel is. Je zou dan bij elke zoekactie een heleboel tekst in een temp table moet zetten en deze vervolgens door MS Search laten indexeren. Tegen de tijd dat MS Search dat allemaal gedaan heeft, is het geduld van de gebruiker allang op.

[ Voor 16% gewijzigd door cameodski op 24-03-2004 17:18 ]

[Annie]

cameodski schreef op 24 maart 2004 @ 17:15:
Ik denk dat dat inderdaad te simpel is. Je zou dan bij elke zoekactie een heleboel tekst in een temp table moet zetten en deze vervolgens door MS Search laten indexeren. Tegen de tijd dat MS Search dat allemaal gedaan heeft, is het geduld van de gebruiker allang op.

Tenzij de filters natuurlijk (redelijk) vast liggen en het aantal mogelijke filters ook niet al te groot is. Je kan dan meerdere temptables aanmaken, (periodiek) laten bijwerken en deze laten indexeren. Optimaal is het niet natuurlijk.

[Verwijderd]

Annie schreef op 24 maart 2004 @ 22:00:
[...]

Tenzij de filters natuurlijk (redelijk) vast liggen en het aantal mogelijke filters ook niet al te groot is. Je kan dan meerdere temptables aanmaken, (periodiek) laten bijwerken en deze laten indexeren. Optimaal is het niet natuurlijk.

Nee inderdaad, en je zou niet verwachten dat al deze rompslomp bij een dergelijk uitgebreid produkt nodig is. Je kunt echt overal op zoeken, mogelijkheden legio, maar een filtering aanbrengen om overbodig zoekgedrag te voorkomen ho maar.

[EfBe]

Verwijderd schreef op 24 maart 2004 @ 22:19:
Nee inderdaad, en je zou niet verwachten dat al deze rompslomp bij een dergelijk uitgebreid produkt nodig is. Je kunt echt overal op zoeken, mogelijkheden legio, maar een filtering aanbrengen om overbodig zoekgedrag te voorkomen ho maar.

Maar.. heb je het nou al getest? In theorie wat pruttelen dat het allemaal niet echt slim gedaan is is leuk voor aan de tap in een verschaald cafe maar je hebt er geen r**t aan.

Het opzetten van full text search is heel simpel en kost je niet veel tijd, je kunt dan in query analyzer wat queries uitvoeren en kijken of het traag is of niet.

[Verwijderd]

EfBe schreef op 24 maart 2004 @ 23:07:
[...]

Maar.. heb je het nou al getest? In theorie wat pruttelen dat het allemaal niet echt slim gedaan is is leuk voor aan de tap in een verschaald cafe maar je hebt er geen r**t aan.

Het opzetten van full text search is heel simpel en kost je niet veel tijd, je kunt dan in query analyzer wat queries uitvoeren en kijken of het traag is of niet.

Ik kan wel eens een test voor je uitvoeren door lomp veel data in de db te gaan zetten, maar het is niet zo vreemd om te concluderen dat het filteren van bijv. miljoenen records meer tijd in beslag neemt dan 1000 records

[EfBe]

Verwijderd schreef op 25 maart 2004 @ 08:27:
Ik kan wel eens een test voor je uitvoeren door lomp veel data in de db te gaan zetten, maar het is niet zo vreemd om te concluderen dat het filteren van bijv. miljoenen records meer tijd in beslag neemt dan 1000 records

Je weet niet hoe full text search in de sqlserver engine geintegreerd is, wellicht is die query optimizer stukken slimmer dan jij denkt dat hij is

[whoami]

Verwijderd schreef op 25 maart 2004 @ 08:27:
[...]


Ik kan wel eens een test voor je uitvoeren door lomp veel data in de db te gaan zetten, maar het is niet zo vreemd om te concluderen dat het filteren van bijv. miljoenen records meer tijd in beslag neemt dan 1000 records

Dat zou niet mogen (mits je indexen gebruikt).
Zoektijd in een DB (mbhv indexen) is niet lineair, maar zal eerder logaritmisch zijn.

[cameodski]

EfBe schreef op 24 maart 2004 @ 23:07:
Het opzetten van full text search is heel simpel en kost je niet veel tijd, je kunt dan in query analyzer wat queries uitvoeren en kijken of het traag is of niet.

Het opzetten van full-text search kost inderdaad niet veel tijd, maar een catalog vullen wel.
Ik heb als test een tabel gevuld met 10 mln records en in elk record een korte tekst opgenomen en daarna een full population gestart. Maar dat population process duurt verschrikkelijk lang (in ieder geval een aantal dagen).

EfBe schreef op 25 maart 2004 @ 09:59:
Je weet niet hoe full text search in de sqlserver engine geintegreerd is, wellicht is die query optimizer stukken slimmer dan jij denkt dat hij is

Tja, maar als je dit artikel leest, zou je toch denken dat die query optimizer slimheid op dit vlak een beetje tegenvalt: http://www.sql-server-per...b_search_optimization.asp

whoami schreef op 25 maart 2004 @ 10:09:
Dat zou niet mogen (mits je indexen gebruikt).
Zoektijd in een DB (mbhv indexen) is niet lineair, maar zal eerder logaritmisch zijn.

Het zoeken mbv een index zal inderdaad niet lineair zijn, maar MS Search geeft een soort temp table terug en dan heb je niet echt veel aan je indexen.

[Verwijderd]

Bovendien zegt Books online het volgende

If you are full-text indexing tables that have less than a million rows, very little performance tuning is required. If you full-text index large SQL Server tables that contain millions of rows that create large full-text catalogs, this will sustain heavy read and write activity, so you must configure SQL Server and the full-text catalogs to maximize disk I/O performance by load balancing across multiple hard disk drives. You will also need to consider hardware configurations, Microsoft Windows® 2000 or Windows NT® 4.0 system configurations, and SQL Server 2000 configurations, as well the actual location of the full-text catalogs and database files.

Dit geeft toch wel aan dat er een groot verschil ontstaat in performance bij veel records.

http://www.sql-server-per...b_search_optimization.asp

En dat is precies mijn punt En dan met name

SELECT PropertyID, Type, SubString(description, 9, 9 - LEN(description)) AS description
FROM properties p
INNER JOIN containstable(properties,'"TYPEFLAT" and "bath"',10) t
ON p.PropertyID = t.[key]
WHERE p.type = 'flat'

In this example only 10 rows will be returned the Query Optimizer, so performance should ROCK!

Obviously you will need to maintain the text code in the full-text column by using triggers, however the overhead in doing so should be minimal when compared to the speed performance gained.

[ Voor 31% gewijzigd door Verwijderd op 26-03-2004 11:33 ]

[ACM]

Zal ik nou heel hard Xapian roepen?

Jammer, voor je, dat het niet voldoet aan de "integreert goed met MSSQL", hoewel het weer wel goed te integreren is in applicatiecode (c/c++ binding is native, php, perl, java, python binding "in de maak" of al af) en het presteert prima. Maar heeft uiteraard wel e.e.a. aan een zwaar systeem met veel geheugen, verwachten dat een zeer zware i/o-app als een search engine goed presteert op een willekeurige doos is een beetje onverstandig.
Verwachten dat het goed draait op een zware databasedoos mag imho wel

Anyway, toch zie ik niet zo in waarom de filtering perse van te voren gedaan moet worden. Dat is, iig wat ik van xapian weet, heus niet perse de beste oplossing. Als je filter 10.000 records beslaat en je keywords 1.000, dan is eerst je query toepassen en dan je filter handiger... Je keywords worden tenslotte ook (en bij Xapian zelfs in dezelfde als de filters) index opgezocht.

[EfBe]

Dan gebruik je toch iets anders als dit niet performt?

Wat wil je nou? Je wilt megaveel content kunnen doorzoeken in een flits en het mag niet veel performance vreten noch memory noch diskspace en het moet wel mega flexibel zijn.

Het flexibel doorzoeken van texten ala ms search vereist wordlists met daaraan gekoppeld de elements waarin de matches zijn terug te vinden. Als je de engine NIET zelf bouwt, kun je niet eisen dat de engine andersom werkt dan je eigenlijk zou willen. Immers jij wilt EERST de elements filteren waarin gezocht moet worden en dan pas zoeken. Maar dat werkt niet wanneer je wordlists gebruikt, want je moet dan eerst gaan filteren welke woorden uit die wordlists moeten worden geknikkerd. Dat gaat ook mega veel performance kosten.

Als het setje records wat overblijft voor het zoeken klein is, kun je net zo goed LIKE gebruiken.

[Verwijderd]

EfBe schreef op 26 maart 2004 @ 11:35:
Dan gebruik je toch iets anders als dit niet performt?

Wat wil je nou? Je wilt megaveel content kunnen doorzoeken in een flits en het mag niet veel performance vreten noch memory noch diskspace en het moet wel mega flexibel zijn.

Ook goedemorgen, ochtendhumeurtje? De hele discussie gaat er om of er betere alternatieven beschikbaar zijn. Zijn die er niet, dan is dat zo

En ja, tuurlijk wil je veel content kunnen doorzoeken in een flits, en ja het mag niet veel performance vreten en ja zo weinig mogelijk memory, en ja zo weinig mogelijk diskspace en ja zo flexibel mogelijk.. anders had ik wel fulltext search van databecker gekocht, en had jij bij wijze van nog steeds je applicaties in qbasic geschreven

[ Voor 7% gewijzigd door Verwijderd op 26-03-2004 11:42 ]

[EfBe]

ACM schreef op 26 maart 2004 @ 11:32:
Anyway, toch zie ik niet zo in waarom de filtering perse van te voren gedaan moet worden. Dat is, iig wat ik van xapian weet, heus niet perse de beste oplossing. Als je filter 10.000 records beslaat en je keywords 1.000, dan is eerst je query toepassen en dan je filter handiger... Je keywords worden tenslotte ook (en bij Xapian zelfs in dezelfde als de filters) index opgezocht.

Volgens mij begrijp je de setup niet helemaal. Je hebt een text column met daarin veel text per row. Je wilt daarin zoeken en de rows met matches terughebben, echter je wilt DIE set met rows OOK nog aan een bepaalde predicate laten voldoen, zeg CategoryID=2. Die categoryID wordt niet meegenomen met de filter.

Stel, je hebt 10.000 rows met texten. 20 daarvan zijn van category 2. Je zult dus hooguit 20 rows terugkrijgen. Zoeken in die 20 is veel sneller dan zoeken in die 10.000 rows, althans zo redeneert men hierboven. In theorie is dat aardig, maar het punt is dat de zoekengine dan eerst zn wordlists moet updaten met het hebben van slechts 20 rows om in te zoeken. M.a.w.: de wordlists moeten worden opgeschoond zodat alleen de words die voorkomen in de 20 rows als basis voor de query worden genomen.

Nou, dat gaat niet zomaar.

Een eigen simpele wordlist table kan dan wellicht uitkomst bieden. Maar men wil wel de flexibiliteit van full text search (met near capabilities etc.) dus ook dat idee kan men laten varen.

Sommige dingen kosten nu eenmaal iets.

[EfBe]

Verwijderd schreef op 26 maart 2004 @ 11:41:
Ook goedemorgen, ochtendhumeurtje? De hele discussie gaat er om of er betere alternatieven beschikbaar zijn. Zijn die er niet, dan is dat zo

Alternatieven zoeken is prima, maar wensen deponeren als een manager zonder enige kennis lijkt me meer iets voor een ander forum dan dit.

En ja, tuurlijk wil je veel content kunnen doorzoeken in een flits, en ja het mag niet veel performance vreten en ja zo weinig mogelijk memory, en ja zo weinig mogelijk diskspace en ja zo flexibel mogelijk.. anders had ik wel fulltext search van databecker gekocht, en had jij bij wijze van nog steeds je applicaties in qbasic geschreven

Maar zoals ik al eerder zei: je hebt de real-life performance niet getest. Je weet niet hoe goed full text search is. M.a.w: je zoekt naar alternatieven op basis van aannames die helemaal niet terecht zijn.

[ACM]

EfBe schreef op 26 maart 2004 @ 11:43:
Volgens mij begrijp je de setup niet helemaal.

Jahoor, na jouw uitleg gelezen te hebben gok ik dat ik hem wel voldoende begreep

Stel, je hebt 10.000 rows met texten. 20 daarvan zijn van category 2. Je zult dus hooguit 20 rows terugkrijgen. Zoeken in die 20 is veel sneller dan zoeken in die 10.000 rows, althans zo redeneert men hierboven. In theorie is dat aardig, maar het punt is dat de zoekengine dan eerst zn wordlists moet updaten met het hebben van slechts 20 rows om in te zoeken. M.a.w.: de wordlists moeten worden opgeschoond zodat alleen de words die voorkomen in de 20 rows als basis voor de query worden genomen.

Uit ervaring weet ik dat het niet eens zo heel veel meer tijd kost om 1000 of 100000 records te doorzoeken in Xapian, ik mag hopen dat ook MSSQL's full text zoektijden niet lineair met de dataset stijgt (ja, pas als je phrase/near searches doet zul je het goed merken)?

't Punt wat ik in die reply probeerde te maken is gewoon hetzelfde wat jij zegt hoor
Wie zegt dat het zo slecht performed? Er zijn ook zat FTI-queries in Xapian waarvan ik dacht dat ze vreselijk traag zouden zijn en dat helemaal niet zijn (helaas ook omgekeerd, maarja, thats life)

[curry684]

Verwijderd schreef op 26 maart 2004 @ 11:41:
[...]

Ook goedemorgen, ochtendhumeurtje? De hele discussie gaat er om of er betere alternatieven beschikbaar zijn. Zijn die er niet, dan is dat zo

Dat gaat deze discussie al een 10-20 posts niet meer, die waren alleen ongefundeerd roepen dat MSSQL full-text search trage onbruikbare troep is. Diverse malen de vraag 'test het dan' werden niet opgevolgd.

Ik ken de performance van de full-text search op enkele gigabytes aan MSDN Library, en weet dat die near-to-immediate is, terwijl ik hier op GoT met Xapian met een vergelijkbare dataset nog best wel eens timeouts krijg op 15 seconden. Ik vraag me dus af in hoeverre je claim inderdaad correct is dat SQL Server zo slecht zou performen op grote searches, en vooral of er concurrerende produkten zijn die dat (relevant) beter kunnen.

Zolang we dus weer verder gaan met het vergelijken van alternatieven op basis van feiten: leef je uit Maar gaarne allemaal stoppen met loos roepen en niet onderbouwen okee?

[ACM]

curry684 schreef op 26 maart 2004 @ 11:59:
Ik ken de performance van de full-text search op enkele gigabytes aan MSDN Library, en weet dat die near-to-immediate is, terwijl ik hier op GoT met Xapian met een vergelijkbare dataset nog best wel eens timeouts krijg op 15 seconden. Ik vraag me dus af in hoeverre je claim inderdaad correct is dat SQL Server zo slecht zou performen op grote searches, en vooral of er concurrerende produkten zijn die dat (relevant) beter kunnen.

Nou ben ik weer benieuwd naar welke queries dat zijn natuurlijk en hoeveel concurrent gebruikers op die MSSQL-db zaten? Maar ik kan het wel raden; je gebruikte (impliciet) phrase-queries op veelvoorkomende subdelen, dat is de grootste performance-drukker van Xapian atm
En blijkbaar gaat SQL Server daar anders (handiger of minder flexibel) mee om dan Xapian?
Ik gok er op dat SQL Server woorden als e-mail (en complexere varianten) als 1 woord indexeert ipv als losse delen (kan je dat es nagaan voor me?) -> minder flexibel, veel meer performance.

[curry684]

ACM schreef op 26 maart 2004 @ 12:17:
[...]

Nou ben ik weer benieuwd naar welke queries dat zijn natuurlijk en hoeveel concurrent gebruikers op die MSSQL-db zaten? Maar ik kan het wel raden; je gebruikte (impliciet) phrase-queries op veelvoorkomende subdelen, dat is de grootste performance-drukker van Xapian atm

Ik had het toevallig gisteren nog toen ik een zinsdeel opzocht met aanhalingstekens

En blijkbaar gaat SQL Server daar anders (handiger of minder flexibel) mee om dan Xapian?
Ik gok er op dat SQL Server woorden als e-mail (en complexere varianten) als 1 woord indexeert ipv als losse delen (kan je dat es nagaan voor me?) -> minder flexibel, veel meer performance.

Ik heb geen idee, maar m'n "SQL Server 2000 Bible" heeft een heel hoofdstuk gewijd aan de full-text search dat ik dit weekend nog eens zal proberen door te spitten

[cameodski]

cameodski schreef op 26 maart 2004 @ 11:16:
Het opzetten van full-text search kost inderdaad niet veel tijd, maar een catalog vullen wel.
Ik heb als test een tabel gevuld met 10 mln records en in elk record een korte tekst opgenomen en daarna een full population gestart. Maar dat population process duurt verschrikkelijk lang (in ieder geval een aantal dagen).

Ik heb het opbouwen van de catalog maar gestopt, aangezien het hele gebeuren minstens een week leek te gaan duren.
Vervolgens een iets minder heftige test uitgevoerd waarvan hier de resultaten.

Database 1: tabel met 100.000 records
Database 2: tabel met 1.000.000 records (tien keer de 100.000 records uit database 1)

Vervolgens een full-text catalog laten genereren en uiteindelijk wat queries uitgevoerd.

M.b.v. CONTAINSTABLE gezocht op het woord "informatie". Dit woord komt in de eerste database 20.000 keer voor en in de tweede database 200.000 keer.
Vervolgens een filter op de primary key (die dus ook in de catalog is opgenomen), waarin ik aangeef dat ik alleen de eerste 100.000 records wil doorzoeken.

Van het resultaat een COUNT (*) gedaan en ook het execution plan bestudeerd om er zeker van te zijn, dat de optimizer ze op exact dezelfde wijze uitvoert.

Wat blijkt het geval te zijn: in de tweede database duurt het zoeken zo'n tien keer zo lang.

[curry684]

Ik heb overigens dat hoofdstuk nog even bijgelezen, en SQL Server met MS Search indexeert in ieder geval de database zo dat near-searches, looks-like-searches e.d. allemaal mogelijk zijn. Tevens heeft SQL Server geen probleem met lazy incremental updates (hoi ACM ), oftewel dat toevoegingen aan indexed tables automatisch zodra de server tijd heeft de catalog updaten. Geen gekut dus met nachtelijke updates

[Verwijderd]

curry684 schreef op 29 maart 2004 @ 23:53:
Ik heb overigens dat hoofdstuk nog even bijgelezen, en SQL Server met MS Search indexeert in ieder geval de database zo dat near-searches, looks-like-searches e.d. allemaal mogelijk zijn. Tevens heeft SQL Server geen probleem met lazy incremental updates (hoi ACM ), oftewel dat toevoegingen aan indexed tables automatisch zodra de server tijd heeft de catalog updaten. Geen gekut dus met nachtelijke updates

Dat klopt, maar dat moet ook wel als je ziet dat het opbouwen van een catalog zo veel tijd kost. Er zijn wel methodes om handmatig een full text catalog te backuppen.

[ACM]

curry684 schreef op 29 maart 2004 @ 23:53:
Tevens heeft SQL Server geen probleem met lazy incremental updates (hoi ACM ), oftewel dat toevoegingen aan indexed tables automatisch zodra de server tijd heeft de catalog updaten. Geen gekut dus met nachtelijke updates

Dat is om performanceredenen gedaan. Doordat we maar 1x per dag indexeren kunnen we na die indexrun de index "comprimeren", waar ie 40% kleiner van wordt en in de zgn "revision 0"-modus kan worden uitgelezen (er hoeft dan geen rekening gehouden te worden met blocks die van een andere transactie zijn) wat beide de searchperformance flink verbeterd.
En daarbij komt nog het voordeel dat de database niet veranderd voor het grootste deel van de dag, dus je ook veel efficienter database-pages enzo kan cachen.

Als we bij elke willekeurige wijziging van een topic die opnieuw de index in willen gooien kan dat hoor. Doen we alleen niet
Ik weet alleen niet of onze huidige searchdoos dat wel lekker aankan en zolang het niet strict noodzakelijk is laten we het lekker zo

Overigens kost het compleet opnieuw indexeren van de 13M messages hier op GoT zo'n 2 dagen en met de komende Xapian versie waarschijnlijk nog maar 1 dag, MSSQL beat that

[ Voor 9% gewijzigd door ACM op 30-03-2004 12:00 ]

[Verwijderd]

ACM schreef op 30 maart 2004 @ 11:58:
[...]
Overigens kost het compleet opnieuw indexeren van de 13M messages hier op GoT zo'n 2 dagen en met de komende Xapian versie waarschijnlijk nog maar 1 dag, MSSQL beat that

Hebben we meteen een antwoord op de topicstart MSSQL heeft er denk ik 2 weken voor nodig

[curry684]

ACM schreef op 30 maart 2004 @ 11:58:
Overigens kost het compleet opnieuw indexeren van de 13M messages hier op GoT zo'n 2 dagen en met de komende Xapian versie waarschijnlijk nog maar 1 dag, MSSQL beat that

Ik vermoed dat Gordijnstok het niet op een dual Xeon 2.8Ghz met 4Gb RAM doet

[cameodski]

curry684 schreef op 30 maart 2004 @ 14:03:
[...]

Ik vermoed dat Gordijnstok het niet op een dual Xeon 2.8Ghz met 4Gb RAM doet

Ik denk het ook niet. Zou wel heel erg toevallig zijn.
Maar gezien de gigantische hoeveelheid reads en writes is het grootste probleem disk I/O.
Microsoft belooft trouwens dat het indexeren in Yukon een aantal keren sneller zal gaan, dus misschien dat we dan nog eens moeten vergelijken.

[ACM]

curry684 schreef op 30 maart 2004 @ 14:03:
Ik vermoed dat Gordijnstok het niet op een dual Xeon 2.8Ghz met 4Gb RAM doet

Maar op mijn athlon 850+512MB ram en ide-disks duurt het ook geen weken (1 of 1.5 week oid, al een tijdje niet gedaan, de index downloaden gaat sneller) En dat slome doosje gaat nog veel meer profiteren van de verbeteringen aan Xapian in de komende versie.
Als onze searchserver niet actief gebruikt zou worden tijdens het indexeren zou ie waarsch ook nog wel wat sneller de boel kunnen indexeren dan die 2 dagen

_{Ik geloof dat dit allemaal wel een beetje off-topic is}

[cameodski]

Laat ik ook nog eens een niet off-topic reactie geven.

Ik kwam een interessant overzicht tegen met allemaal full-text search engines:
http://www.searchtools.com/info/database-search.html

Afgezien van MS Search heb ik met geen van alle ervaring. Maar deze zag er wel heel interessant uit:
http://www.sql-server-per..._index_manager_review.asp