Vitruvius Geplaatst: 12 januari 2015 Delen Geplaatst: 12 januari 2015 Ik heb een databank met 250 miljoen record, 6 velden. In slechts 2 van die velden zal er ooit gezocht worden. Die twee velden zijn numeriek. De zoekopdracht zal altijd een range binnen veld 1 EN range een range binnen veld 2 zijn. Hoe kan ik een zoekopdracht versnellen/optimaliseren? Het resultaat van de zoekopdracht gaat naar een tweede tabel voor cvs export. Quote Link naar reactie
0 menno Geplaatst: 12 januari 2015 Delen Geplaatst: 12 januari 2015 Wat soms wil helpen is eerst zoeken op geïndexeerde velden en eventueel slechts altijd op één veld tegelijk en vervolgens te zoeken (ook weer één veld per opdracht) met "constrain found set". Ik zeg soms, omdat dit iets is wat je zult moeten testen en of dit voor jou in jouw situatie zinvol is. Ergens tussen 250.000 en 2.000.000 records is er een kantelpunt (mijn collega Jos weet denk ik precies waar) dat Filemaker trager gaat zoeken. Quote Link naar reactie
0 Felix Geplaatst: 12 januari 2015 Delen Geplaatst: 12 januari 2015 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 Vitruvius Geplaatst: 13 januari 2015 Auteur Delen Geplaatst: 13 januari 2015 Een zoekopdracht duurt nu inderdaad een aantal minuten. Ergens lijkt me dit ook normaal voor zo'n grote dataset. Maar dan vraag ik me ook af of er efficiëntere zoekopdrachten zijn. wat is sneller? range min ... max >min en zoeken in één veld en dan een volgende opdracht in een beperkte set Dat ga ik uittesten, daarom dat ik graag de verschillende zoekstrategieën zou willen kennen die mogelijk zijn. 10% winst op een aantal minuten scheelt toch al wat. De meest voorkomende range bestaat helaas niet, elke zoekopdracht zal uniek zijn. Quote Link naar reactie
0 menno Geplaatst: 13 januari 2015 Delen Geplaatst: 13 januari 2015 Mocht de zoekopdracht argumenten bevatten zonder range, dan zou ik die argumenten eerst op de db loslaten (mits geïndexeerd) en daarna de range(s) voor een beperkte set. Laat nog even weten wat de bevindingen zijn ... altijd nieuwsgierig hé Quote Link naar reactie
0 Vitruvius Geplaatst: 13 januari 2015 Auteur Delen Geplaatst: 13 januari 2015 Een argument zonder range gaat niet echt lukken. Er is wel een veld (naam van de geïmporteerde blok van XY-data) waar je op zou kunnen selecteren, maar het probleem is dat je range over verschillende blokken kan zitten. Ik zou dat wel kunnen implementeren en de aangrenzende blokken van het centrale blok meenemen als eerste argument, en dan een zoekopdracht naar de range uitvoeren. Moet ik nog wel bij elk blok (zo'n 170 blokken) zetten wat de aangrenzende blokken zijn, want dat is slechts gedeeltelijk logisch. Quote Link naar reactie
0 Felix Geplaatst: 13 januari 2015 Delen Geplaatst: 13 januari 2015 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 Vitruvius Geplaatst: 13 januari 2015 Auteur Delen Geplaatst: 13 januari 2015 Het gaat om geo-data. Een X en een Y veld voor de locatie en daarbij de nodige info voor dat punt in een derde en vierde veld. Zou het helpen om de X en Y waarden in grote blokken te steken? vb in veld X staat de X waarde: getal tussen 1 en een paar 100.000 en nog verder na de komma is het zinvol om een veld te maken waarin het 1.000-blok staat wanneer ik dan zoek naar een X waarde tussen de 28.255 en de 29.625, is het dan zinvol om eerst te zoeken naar het 28.000 en 29.000 blok en daarbinnen dan verder te verfijnen of maakt dat niet veel uit omdat je toch record per record moet afgaan of het record behoort tot het 28.000 of 29.000 blok. indexeren helpt bij zoeken, maar niet als alle data per record zo goed als uniek is. Bij de 1.000 blokken is dat véél minder uniek. Quote Link naar reactie
0 Felix Geplaatst: 14 januari 2015 Delen Geplaatst: 14 januari 2015 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 Vitruvius Geplaatst: 14 januari 2015 Auteur Delen Geplaatst: 14 januari 2015 Ik merk iets zeer raars op wanneer ik in een script mijn range invoer in een zoekopdracht $Xmin...$Xmax duurt het zoeken zéér lang Doe ik dat manueel, dan gaat alles véél sneller hoe kan dit? edit: probleem opgelost, dom foutje Quote Link naar reactie
0 Felix Geplaatst: 14 januari 2015 Delen Geplaatst: 14 januari 2015 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 menno Geplaatst: 15 januari 2015 Delen Geplaatst: 15 januari 2015 Ik heb eens getest met het bijgevoegde bestandje met platte coördinaten van bijna 200 * 10^6 records (wordt ruim 11Gb). De range van de lengtegraden is van 2.8 tot 20.8 in stappen van 0.001 (18000 waarden) en die van de breedtegraden is van 40.5 tot 51.6 ook in stappen van 0.001 (11100 waarden). (er zit een scriptje in om de records te genereren, duurt wel even ...) Het totaal gekke fenomeen dat bij mijn optreedt is dat wanneer ik zoek op bijvoorbeeld 42...47 in de kolom "Lat" het resultaat er vrijwel meteen staat terwijl zo'n zelfde soort zoek in de kolom "Long" op bijvoorbeeld 3...4 er ruim 20 seconden over doet en het maakt daarbij niet uit of zoek in alle records of dat ik eerst een subset records heb en daarna met "Constrain found set" daarin zoek. De snelheid is kennelijk afhankelijk van de volgorde waarin je gegevens staan, dus als de data kris kras door elkaar staat in je DB, dan zal iedere zoek gewoon ruim 20 seconden duren. Ik denk wel dat indexeren zin heeft, want anders duurt het zoeken nog langer lijkt me, maar dat moet ik met dit bestand nog eens testen. Wat ik ook nog zou moeten testen is hoe dit zich gedraagt met een op een FMServer gedeeld bestand. Search_GeoData.zip Quote Link naar reactie
0 Felix Geplaatst: 15 januari 2015 Delen Geplaatst: 15 januari 2015 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 Vitruvius Geplaatst: 15 januari 2015 Auteur Delen Geplaatst: 15 januari 2015 Dus dan zou je best eerst sorteren vooraleer je zoekt, als het sorteren natuurlijk niet meer tijd in beslag neemt dan die 20 sec in het voorbeeld. Wat ik ondertussen wel heb gedaan is van elke blok het minimum en maximum van X en Y in een tabel heb gegoten en dus eerst kijk in welk(e) blok(ken) mijn range zit. Vervolgens zoek ik dan eerst het/de blok(ken) op en zoek daarin. Gaat in elk geval sneller, want er moet in minder records een range gezocht worden. Quote Link naar reactie
0 Felix Geplaatst: 15 januari 2015 Delen Geplaatst: 15 januari 2015 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 SuperWimmie Geplaatst: 18 januari 2015 Delen Geplaatst: 18 januari 2015 Als ik de opmerking van Menno zo lees, zou dan het splitsen van de tabel een optie zijn? Zodat je twee aparte tabellen krijgt met elk zoekveld er in? Via de relatiestructuur haal je er dan wel de overige gegevens bij, zodat de export hetzelfde beeld kan geven. Quote Link naar reactie
0 menno Geplaatst: 18 januari 2015 Delen Geplaatst: 18 januari 2015 Daar heb ik ook aan gedacht en als de data statisch is, dan is dat mogelijk ook wel een optie ..... 250M records sorteren en dan exporteren is ff werk heb dat nog niet geprobeerd. Als je heel veel van zo'n statische tabel gebruik zou maken, is het misschien wel de moeite waard. Zodra je er in (in de gerangschikt opgeslagen gegevens) gaat muteren wordt het waarschijnlijk niks. Ik weet ook niet of het zin heeft wanneer je in beide kolommen zou zoeken en dan de gecombineerde gegevens uit een derde kolom zou willen hebben. Wanneer dat laatste niet sneller zou gaan, dan is het verloren moeite. Dus Vitruvius, we horen graag jouw test-bevindingen Quote Link naar reactie
0 hans erik Geplaatst: 18 januari 2015 Delen Geplaatst: 18 januari 2015 Wat soms wil helpen is eerst zoeken op geïndexeerde velden en eventueel slechts altijd op één veld tegelijk en vervolgens te zoeken (ook weer één veld per opdracht) met "constrain found set". Ik zeg soms, omdat dit iets is wat je zult moeten testen en of dit voor jou in jouw situatie zinvol is. Ergens tussen 250.000 en 2.000.000 records is er een kantelpunt (mijn collega Jos weet denk ik precies waar) dat Filemaker trager gaat zoeken. En als je dan de tabel opsplitst in meerdere 'kleine' tabellen die elk onder die kritische grens blijven? Het maakt de Het qua scripting wel wat complexer, natuurlijk. Quote Link naar reactie
0 menno Geplaatst: 20 januari 2015 Delen Geplaatst: 20 januari 2015 En als je dan de tabel opsplitst in meerdere 'kleine' tabellen die elk onder die kritische grens blijven? Het maakt de Het qua scripting wel wat complexer, natuurlijk. Als ik eerlijk ben, dan vind ik dat zulke grote tabellen best ergens anders mogen worden ondergebracht. Filemaker werkt helemaal super als je tabellen niet al te groot zijn zo tot pak 'm beet 1M records en dan gaat bijvoorbeeld rapportages maken lekker snel (mits je de complexiteit van de gegevens binnen de perken houdt en deze grens is maar een willekeurig getal natuurlijk). Dit voorbeeld van 250M records is er duidelijk 1 van een maatje te groot voor FM ... als nou de sets die je er uit opvraagt niet groter zouden worden dan bijvoorbeeld 25K, waarom gebruik je dan niet bijvoorbeeld Oracle of MsSQL met ESS of eventueel direct via ODCB-import (dan kan je eigenlijk alles waar ODBC-drivers voor bestaan gebruiken)? Die databases zijn misschien beter geoptimaliseerd om grote aantallen records snel te doorzoeken, alleen hebben die niet zo'n mooie flexibele interface zoals FM, maar daar kan je FM weer voor inzetten toch? Quote Link naar reactie
0 Vitruvius Geplaatst: 22 januari 2015 Auteur Delen Geplaatst: 22 januari 2015 De databank extern plaatsen zou een optie kunnen zijn. Die 250M records zijn statisch, daar zal niets meer aan veranderen. Ik zou kunnen opdelen in kleinere tabellen die onder de grens van de nog snelle zoeksnelheid liggen. Dan zou ik uitkomen op één tabel per "blok" met de data, één tabel waar in staat wat de range is van elke van die "blok" tabellen en één exporttabel. De zoekopdracht zou er dan eerst in bestaan om te kijken in welke tabel mijn gezochte range valt (max 4 tabellen) en dan in elk van die tabellen zoeken om dan al die info in de exporttabel te zetten. Klink haalbaar. Quote Link naar reactie
0 SuperWimmie Geplaatst: 22 januari 2015 Delen Geplaatst: 22 januari 2015 Zoeken in die grote database is één actie, maar hoeveel gevonden resultaten krijg je maximaal? Als het weer een klus wordt om 1 miljoen gevonden records bij elkaar te harken, schiet je er (mogelijk) nog niets mee op. Dat kan een groot nadeel zijn van tabellen extern plaatsen. Quote Link naar reactie
0 Vitruvius Geplaatst: 22 januari 2015 Auteur Delen Geplaatst: 22 januari 2015 Dat valt reuze mee, een 50.000. Export van records is geen probleem, kwestie van een paar seconden. Het is enkel het zoeken dat traag gaat. Quote Link naar reactie
Vraag
Vitruvius
Ik heb een databank met 250 miljoen record, 6 velden.
In slechts 2 van die velden zal er ooit gezocht worden. Die twee velden zijn numeriek.
De zoekopdracht zal altijd een range binnen veld 1 EN range een range binnen veld 2 zijn.
Hoe kan ik een zoekopdracht versnellen/optimaliseren?
Het resultaat van de zoekopdracht gaat naar een tweede tabel voor cvs export.
Link naar reactie
21 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.