[Postgres] Moeilijke query: stelling v pythagoras binnen DB

[kramer65]

Hallo,

Om te beginnen. Ik ben een keer gebanned van het forum omdat ik mijn vragen te weinig uitlegde. Ik heb dit nooit expres gedaan, mijn redenatie was eerder om mijn vragen compact te houden zonder zaken erbij die mij niet relevant leken. Gezien dit dus echter niet op prijs wordt gesteld zal ik proberen mijn vraag zo duidelijk mogelijk uit te leggen.

Op dit moment ben ik bezig om met behulp van een PostgreSQL database een aantal patronen op de futures-markten te bewijzen. Hiervoor heb ik een database van alle historische future-prijzen per minuut waarvan ik een afgeleide table heb gemaakt waar alle procentuele stijgingen en dalingen van minuut tot minuut in staan. Van daaruit heb ik weer een nieuwe table gemaakt waarin ik de gemiddelde winsten per minuut en per “aanhoudtijd” heb berekend.
Ik heb nu dus de gemiddelde winst voor wanneer je elke dag om 09:00:00 kocht, 1 minuut aanhield en toen weer om 09:01:00 verkocht. Hetzelfde voor 09:00:00 kopen, 2 minuten aanhouden, en weer om 09:02:00 verkopen. Het ziet er dus zo uit:

code:

koop_tijdstip | aanhoudtijd | winst
---------------------------------------------
09:01:00      | 1           |  4
09:02:00      | 1           | -3
09:03:00      | 1           |  8
09:04:00      | 1           | -1
etc.
09:01:00      | 2           |  2
09:02:00      | 2           | -1
09:03:00      | 2           |  0
09:04:00      | 2           | 12
etc.
09:01:00      | 3           | -6
09:02:00      | 3           |  2
09:03:00      | 3           |  6
etc..

Ik heb dit vervolgens schematisch weergegeven in een grafiek waarin de x-as de tijd is, de y-as de aanhoudtijd, en de kleur van de pixel de winst weer geeft; wit is winst, zwart is verlies.
Nou zie je in de grafiek witte vlekken (ik heb er twee aangestreept) waarin dus gemiddeld gezien winst wordt behaald over de volledige historie van de future. Wat ik nou wil is een soort van “robuustheid” berekenen voor alle witte punten. Robuustheid wil hier zeggen: "hoe afhankelijk is de winst van kleine verschillen in de onderliggende variabelen (x-as en y-as)". Hiervoor wil ik dus voor elk wit punt berekenen wat de afstand is tot het dichtstbijzijnde zwarte punt. Dit wilde ik doen mbv de stelling van Pythagoras:

(verschil op de x-as)² x (verschil op de y-as)² = afstand tussen twee punten²

Ik heb er een tijdje mee lopen stoeien maar ik kom er maar niet uit. Wat ik zelf had bedacht was een query die er ongeveer zo uit zou moeten zien:

SQL:

SELECT MIN(SQRT(((n2.koop_tijdstip - n1.koop_tijdstip)^2 + (n2.aanhoudtijd - n1.aanhoudtijd)^2)) as afstand
FROM winst_table n1
JOIN winst_table n2
ON ...............?
WHERE n1.winst > 0
AND n2.winst < 0
ORDER BY afstand DESC

Ik begrijp alleen niet waarop ik die JOIN nou zou moeten doen zodat elk (witte) winst-punt met elk (zwarte) verlies-punt wordt vergeleken.

Heeft iemand enig idee hoe ik dit op zou kunnen lossen? Alle tips zijn welkom!

[RobIII]

Hoe werken joins?

Verder vraag ik me ten zeerste af waarom je hier in hemelsnaam een RDBMS voor gebruikt; voor 't verwerken van dit soort rauwe data gebruik je gewoon arrays, matrices of anderssoortige manieren van opslag van data binnen je applicatie. Een RDBMS gebruik je in dit soort gevallen hooguit als persistance layer voor de oorspronkelijke data en eventuele resultaten die daaruit berekend zijn.

Met wat creatief SQL-en is er vast wat van te bakken/knutselen maar ik zou hier persoonlijk geen tijd meer in steken als ik jou was en me focussen op andere manieren om dit op te lossen.

[ Voor 17% gewijzigd door RobIII op 03-11-2011 20:30 ]

[kramer65]

Ik moet erbij zeggen dat ik alles behalve een pro ben. Ik weet nu wel redelijk wat dingen (denk ik) maar het is voor mij een blijvende leerschool.

Ik moet eerlijk zeggen dat ik nog niet had bedacht dat het eventueel ook buiten de DB om kan. Eerder raadden allerhande mensen mij aan om van MySQL naar PostgreSQL te wisselen om een handvol redenen (consistenter, en meer opties zoals bv windowing), dus dat heb ik toen gedaan.
Ik ga het zeker onderzoeken hoe ik dit mbv arrays kan doen. Ik ben daar echter wel een stuk minder goed in, dus dat is een beetje een grote volgende stap. Ik ben nu erg ver in Postgres (ben na anderhalve maand werk bijna waar ik wil wezen) dus ik wil het nu eigenlijk hierin afmaken.

Ik ben nu pas sinds een tijdje bezig met JOINs en heb er al redelijk wat over zitten lezen, maar de CROSS JOIN had ik nog niet bekeken. Ik probeer het nu dus daarmee en dat lukt wel een beetje, maar het resultaat was in de eerste instantie vreemd. Op zich logisch, aangezien ik een tijd in het kwadraat wil doen, wat natuurlijk niet kan. Ik moest dus eerst de tijd omzetten in een soort van cijfer (09:00:00 = 0, 09:01:00 = 1, 09:02:00 = 2 etc.) zodat ik ermee kan rekenen in termen van "afstand". Ik weet dat dit kan mbv windowing. Zodoende dat ik nu de volgende query in elkaar heb geknutseld:

SQL:

SELECT ((rank() OVER (PARTITION BY verlies_table.aanhoudtijd ORDER BY verlies_table.koop_tijdstip ASC)) - (rank() OVER (PARTITION BY winst_table.aanhoudtijd ORDER BY winst_table.koop_tijdstip ASC))) as tijdverschil,
((verlies_table.aanhoudtijd - winst_table.aanhoudtijd)^2) as aanhoudtijd_verschil
FROM winst as winst_table CROSS JOIN winst as verlies_table
WHERE winst_table.winst > 0
AND verlies_table.winst < 0
GROUP BY verlies_table.koop_tijdstip, verlies_table.aanhoudtijd, winst_table.koop_tijdstip, winst_table.aanhoudtijd
ORDER BY tijdverschil
LIMIT 10

Ik heb nu echter een onvoorzien probleem. Wanneer de query loopt (duurt een minuut of 5) dan loopt het gebruik van mijn harde schijf ook op. Net zolang totdat mijn harde schijf vol is (10GB in een virtualbox Ubuntu installatie) en dan geeft hij een foutmelding: ERROR: could not write block 649509 of temporary file: Geen ruimte meer over op apparaat

Ik wist niet dat een DB voor queries de harde schijf gebruikt. En vooral wist ik niet dat dat zo ver kan oplopen. Is dit ook de reden dat je suggereert arrays te gebruiken? Of heb ik misschien een grove fout in mijn query waardoor hij een soort van "lek" is?

[Gomez12]

Hoeveel records heb je in je winst_table db?

Want als je dbase server geen memory meer vindt, dan gaat er gewoon een temp-table gemaakt worden naar disk.
Categorisch product over je winst_table kan aardig oplopen als je daar wat rijen in hebt zitten.

Maar als ik het dus goed begrijp wil je enkel met het huidige en het vorige resultaat een bewerking uitvoeren, dan zou ik zeggen : Voer een query uit die de data ophaalt in de meest simpele vorm (dus geen self-join) en onthou dan in je scripting-taal de hele tijd het vorige record terwijl je over je recordset heenloopt.

Je query is afhankelijk van het exacte execution plan misschien wel iets te verbeteren door je where condities naar join-condities om te zetten (maar ik verwacht dat postgresql dit automatisch doet bij deze query)
Maar ik vermoed dat het grote probleem zit in je self-join op een tabel met veel records. Dat vereist gewoon een temp-table met onnoemelijk veel records.

Als het execution plan verkeerd is dan krijg je eigenlijk dat elk record uit de winst tabel met elk record uit de winst tabel naar een nieuw record gezet moet worden (reken zelf maar uit hoeveel records dit zijn) en daarna moeten er nog 2 condities over die nieuw-onstane recordset heen.
Bij een tabel met 100 records wordt er dus een temp-table gecreëerd met 10.000 records... Dat kost memory/ruimte.Heb je 1000 records dan wordt de temp-table 1.000.000 records.

Order by over een berekend resultaat is nou ook niet echt bevorderlijk, hij kan dan geen shortcuts pakken, hij moet eerst alles in memory (/temp-table) uitrekenen voordat hij ook maar kan beginnen met sorteren.

Het zijn allemaal leuke dingetjes om te doen met kleine datasets, maar echt grote datasets (zoals ik vermoed dat er in je temp-table staat) wil je toch echt benaderen via indexen etc en niet via berekende resultaten.

[kramer65]

Maar als ik het dus goed begrijp wil je enkel met het huidige en het vorige resultaat een bewerking uitvoeren

Helaas niet. Ik wil niet elke record met de vorige vergelijken. Wat ik wil is dit:

Voor de records waar de winst positief is wil ik berekenen waar de "dichtstbijzijnde" record zit met verlies.

Hoeveel "stapjes" (gerekend in minuten van koop_tijdstip en/of aanhoudtijd) dat record met verlies zeg maar van het huidige "winst record" af zit. Ik moet elk "winst record" dus wel vergelijke met àlle "verlies records". Om die reden heb ik nu voor een CROSS JOIN gekozen.
Gezien er zo'n 110.000 records in die table staan komt dat idd neer op een cross table met zo'n 12 miljard records (tjonge das idd wel veel). Bovendien zal deze table in de toekomst misschien nog wel groter worden (met uitgebreidenere analyses).

Ik zou die virtualbox-installatie natuurlijk gewoon groter kunnen maken, maar op de lange termijn is een CROSS JOIN dus niet echt mogelijk begrijp ik. Gezien ik records dus niet simpelweg met "de vorige" wil vergelijken weet ik nu niet of ik er met alleen WHERE condities zou kunnen komen. Zie jij (of iemand anders) daar mogelijkheden voor?

In principe hoef je het natuurlijk niet èlk winst-record met èlk verlies-record te vergelijken. Je zou eventueel éérst kunnen beginnen met de records die ernaast staan (plus en min één minuut). Daarna die daarnaast staan, etc. Net zolang totdat je een record met verlies tegenkomt. Ik zou echter niet weten hoe je zoiets moet scripten..

Iemand anders misschien wel?

[ Voor 12% gewijzigd door kramer65 op 04-11-2011 12:32 ]

[_js_]

Heb je voor je robuustheid waardes nodig die groter zijn dan bijv. 10? Zo niet, dan kun je daar een beperking opleggen, dan heb je ineens niet 12 miljard records maar 35 miljoen die je moet doorzoeken.

Maar het lijkt me inderdaad dat SQL niet de beste oplossing is, gewoon die winst/verlies grafiek die je eerder in een plaatje hebt gestopt als array ofzo gebruiken in dan rondom elk winstpunt gaan zoeken naar het dichtstbijzijnde verliespunt.

[voodooless]

Je hebt al een 2D representatie gemaakt van je probleem. Je zou dat ook zo in postgres kunnen opslaan in als geometrisch punt. Vervolgens kun je door middel van KNNGIST indexen een nearest neighbor search doen. Zie http://archives.postgresq...kers/2009-11/msg01547.php .

Verder moet je dan een default postgres configuratie niet verwachten dat de performance goed zal zijn. Er is veel winst te halen door wat parameters te tunen (of ben lui en gebruik pgtune)

[ Voor 25% gewijzigd door voodooless op 04-11-2011 23:32 ]

[Gomez12]

kramer65 schreef op vrijdag 04 november 2011 @ 07:26:
[...]
Gezien er zo'n 110.000 records in die table staan komt dat idd neer op een cross table met zo'n 12 miljard records (tjonge das idd wel veel). Bovendien zal deze table in de toekomst misschien nog wel groter worden (met uitgebreidenere analyses).

Het is wel een worst case scenario (er vindt dan totaal geen optimalisatie plaats)

Ik zou die virtualbox-installatie natuurlijk gewoon groter kunnen maken, maar op de lange termijn is een CROSS JOIN dus niet echt mogelijk begrijp ik. Gezien ik records dus niet simpelweg met "de vorige" wil vergelijken weet ik nu niet of ik er met alleen WHERE condities zou kunnen komen. Zie jij (of iemand anders) daar mogelijkheden voor?

Ik begrijp niet helemaal wat je wilt dus daadwerkelijk helpen kan ik je niet. Maar je moet die tussenresultaten omlaag krijgen of je moet het voor je dbase simpeler maken door een basis-set op te halen en die in scripting ver uitwerken.
Het hangt er voornamelijk vanaf of dit je einddoel is of dat je nog meer met die gegevens wilt doen.
Is dit je einddoel dan zou je kunnen overwegen om bijv met cronjobs je basistabel uit te splitsen naar gespecialiseerdere tabellen (bijv een losse winst tabel en een losse verlies tabel met daarin alles waarop je groepeert / order by etc doet voorgerekend) dan ben je echter weer afhankelijk van hoevaak je cronjob draait, maar dat is een kwestie van bescheen en kijken wat je echt wilt.

Enkel bedenk dan wel goed dat je een hele db-structuur gaat opzetten voor 1 resultaat, is dit het wel waard of kan je het niet beter doen via scripting.

In principe hoef je het natuurlijk niet èlk winst-record met èlk verlies-record te vergelijken. Je zou eventueel éérst kunnen beginnen met de records die ernaast staan (plus en min één minuut). Daarna die daarnaast staan, etc. Net zolang totdat je een record met verlies tegenkomt. Ik zou echter niet weten hoe je zoiets moet scripten..

Hangt er een beetje vanaf hoe definitief die minuten zijn. Zijn dat harde grenzen die echt blokjes van data weergeven dan zou je iets kunnen bedenken als :
- in sql haal je het op gesorteerd op tijd.
- In scripting loop je over de resultaten heen totdat je resultaten voor 3 minuten in je scripting taal hebt staan, dan voer je over die array je functies uit en daarna gooi je je array leeg en loop je verder over de resultset heen.

Dan hoeft je sql maar 110.000 records op te halen (mits er een index op tijd staat, gaat het sorteren ook nog eens snel)
En je scripting hoeft maar 40.000 keer die functie uit te voeren.
Dit vs je huidige implementatie die van je sql server vraagt om 12 miljard keer een functie uit te voeren.

Het is een afweging, want het overhalen van resultaten naar je scripting kost ook weer tijd, je moet ook weer niet in de standaard val lopen om in elke loop een nieuwe query uit te voeren (elke sql query kost weer verbindingstijd / processtijd etc )

Standaard methodiek is om zoveel mogelijk in je sql-server te laten gebeuren (is het snelste) maar dit concept is volgens mij zo anti-sql met je huidige dbase structuur. Dat je of je hele db-structuur om moet gaan gooien of je moet simpelweg alles naar scripting gaan halen en het daar afhandelen met middelen die beter gericht zijn op dit soort toepassingen.

[Gomez12]

voodooless schreef op vrijdag 04 november 2011 @ 23:28:
Je hebt al een 2D representatie gemaakt van je probleem. Je zou dat ook zo in postgres kunnen opslaan in als geometrisch punt. Vervolgens kun je door middel van KNNGIST indexen een nearest neighbor search doen. Zie http://archives.postgresq...kers/2009-11/msg01547.php .

Hij doet ook nog andere dingen met die tabel afaik (grafiek maken etc)

Het in een andere structuur opslaan kan er weer toe leiden dat er ergens anders performance problemen ontstaan, het is maar net de vraag of je dat wilt voor 1 resultaat...

Verder moet je dan een default postgres configuratie niet verwachten dat de performance goed zal zijn. Er is veel winst te halen door wat parameters te tunen (of ben lui en gebruik pgtune)

Handmatig parameters tunen kan ook desastreus uitpakken en aangezien TS al aangeeft enkel op aanraden van anderen bij postgreSQL te zijn uitgekomen gok ik zomaar even dat het voor hem heel moeilijk wordt om te tunen.
pgtune ed zou ik ook geen wonderen van verwachten als ik het gebruik zo inschat. Ik gok zomaar dat het een db is die 1x per minuut een insect query krijgt en dan 1x per dag oid die weergave query. Ik schat zomaar in dat door het "scheve" gebruik pgtune er niet goed uit gaat komen (alhoewel het misschien wel een verbetering kan opleveren)

[voodooless]

Gomez12 schreef op vrijdag 04 november 2011 @ 23:43:
Het in een andere structuur opslaan kan er weer toe leiden dat er ergens anders performance problemen ontstaan, het is maar net de vraag of je dat wilt voor 1 resultaat...

Je kunt natuurlijk beide representaties opnemen in je tabel. En misschien is het enkel nodig om points te gebruiken in je index, dan is er helemaal niks aan het handje.

Handmatig parameters tunen kan ook desastreus uitpakken

Mwah, als je een beetje leest wat die params doen is het al snel beter dan de default.

[KopjeThee]

kramer65 schreef op donderdag 03 november 2011 @ 19:23:
Robuustheid wil hier zeggen: "hoe afhankelijk is de winst van kleine verschillen in de onderliggende variabelen (x-as en y-as)". Hiervoor wil ik dus voor elk wit punt berekenen wat de afstand is tot het dichtstbijzijnde zwarte punt.

Dat zou ik niet zo doen. Misschien vind je door erg veel pech wel 1 punt vlakbij die verlies geeft, terwijl de hele omgeving verder wit is. Dan zou je zo'n punt toch erg onbetrouwbaar gaan vinden, wat mij onterecht lijkt. Bovendien is dat hard omklappen wat wit naar zwart erg gevoelig bij kleine winsten en kleine verliezen.

Kan je niet beter een gewogen gemiddelde winst over alle punten in de omgeving nemen, inclusief het punt zelf? Gewogen zodat punten die verder weg zijn minder mee tellen. Je kunt dan een tweede plaatje maken met die gemiddelde waarden voor alle punten. Die zal erg lijken op het eerste plaatje, maar dan wat afgevlakt. Dan zou ik als betrouwbaarheid van een punt het verschil tussen het eerste en tweede plaatje nemen. Punten met een groot verschil zijn echte uitschieters, en die zou ik minder betrouwbaar vinden.

En eigenlijk zoek je gewoon uit dat tweede plaatje de punten met de hoogste winst. Want bij die punten is de hele omgeving gemiddeld hoog.

In code volgens mij zoiets, als ik het ongewogen doe met een bepaalde maximum afstand. Ik weet niet of dit helemaal goed gaat, maar:

code:

select
  avg(t2.winst) as winst,
  t1.koop_tijdstip,
  t1.aanhoudtijd
from table t1 join table t2
on 
  sqrt((t2.koop_tijdstip - t1.koop_tijdstip)^2 + (t2.aanhoudtijd - t1.aanhoudtijd)^2) <= 'een of andere tijd'
group by
  t1.koop_tijdstip,
  t1.aanhoudtijd;

Verder is het in de afstandsbepaling nog even de vraag of aankooptijd en aanhoudtijd even zwaar mee moeten tellen.

[ Voor 25% gewijzigd door KopjeThee op 05-11-2011 08:00 ]

[kramer65]

Maar het lijkt me inderdaad dat SQL niet de beste oplossing is, gewoon die winst/verlies grafiek die je eerder in een plaatje hebt gestopt als array ofzo gebruiken in dan rondom elk winstpunt gaan zoeken naar het dichtstbijzijnde verliespunt.

Standaard methodiek is om zoveel mogelijk in je sql-server te laten gebeuren (is het snelste) maar dit concept is volgens mij zo anti-sql met je huidige dbase structuur. Dat je of je hele db-structuur om moet gaan gooien of je moet simpelweg alles naar scripting gaan halen en het daar afhandelen met middelen die beter gericht zijn op dit soort toepassingen.

@ _js_ en Gomez12
In de eerste reactie in dit topic suggereerde RobIII inderdaad ook al dat ik mijn berekeningen mbv arrays moest doen. Ik moet zeggen dat dat een volledig nieuwe tak van sport voor mij zou zijn. Maar begrijp ik het goed dat jullie bedoelen dat ik de volledige table in een (multi-dimensionaal) php-array zou kunnen laden en daar dan mee zou kunnen rekenen? In dat geval zou toch ook alles vanuit de DB in het geheugen van mijn pc geladen moeten worden? Dat is met tables van meer dan 30GB op mijn PCtje met 4GB geheugen echter niet echt mogelijk.. Of heb ik dat mis?

Hangt er een beetje vanaf hoe definitief die minuten zijn. Zijn dat harde grenzen die echt blokjes van data weergeven dan zou je iets kunnen bedenken als :
- in sql haal je het op gesorteerd op tijd.
- In scripting loop je over de resultaten heen totdat je resultaten voor 3 minuten in je scripting taal hebt staan, dan voer je over die array je functies uit en daarna gooi je je array leeg en loop je verder over de resultset heen.

De minuten hebben inderdaad harde grenzen. Ik heb alleen de prijs van de Futures op elke 0-de seconden van elke minuut. Dus van 09:16:00 en 09:17:00 en 09:18:00 etc. De stapjes in tijd zijn dus inderdaad elke keer precies 1 minuut. Als ik je goed begrijp bedoel dus dat ik een SELECT moet doen om alle winst-records op te halen. Vervolgens nog een query waarbij alle records worden opgehaald die 3 minuten vóór en 3 minuten ná elk "winst-record" zit, dat inladen in een php-array, en dan kijken of er in die 3 minuten vóór en ná elke winst record een verlies zit. Heb ik het zo ongeveer goed?

Dat zou ik niet zo doen [Robuustheid berekenen. red]. Misschien vind je door erg veel pech wel 1 punt vlakbij die verlies geeft, terwijl de hele omgeving verder wit is. Dan zou je zo'n punt toch erg onbetrouwbaar gaan vinden, wat mij onterecht lijkt. Bovendien is dat hard omklappen wat wit naar zwart erg gevoelig bij kleine winsten en kleine verliezen.

@KopjeThee
Het klopt inderdaad dat het vreemd zou zijn als alles wit (dus winstgevend) is, en maar 1 puntje zwart. Aangezien er echter wel een heleboel punten zijn die winst geven, zoek ik liever het punt wat het verste verwijdert is van een verliespunt, dit om zoveel mogelijk risico uit te sluiten in geval van investering.

Kan je niet beter een gewogen gemiddelde winst over alle punten in de omgeving nemen, inclusief het punt zelf? Gewogen zodat punten die verder weg zijn minder mee tellen. Je kunt dan een tweede plaatje maken met die gemiddelde waarden voor alle punten. Die zal erg lijken op het eerste plaatje, maar dan wat afgevlakt. Dan zou ik als betrouwbaarheid van een punt het verschil tussen het eerste en tweede plaatje nemen. Punten met een groot verschil zijn echte uitschieters, en die zou ik minder betrouwbaar vinden.

En eigenlijk zoek je gewoon uit dat tweede plaatje de punten met de hoogste winst. Want bij die punten is de hele omgeving gemiddeld hoog.

Dit is inderdaad wel een redelijk briljant idee. Ik heb je code nog niet geprobeerd, maar ik ga er zéker eens mee aan de slag.


In het algemeen
Naar aanleiding van de reacties over het gebruik van arrays ipv SQL heb ik de afgelopen dagen heel veel zitten lezen over multi-dimensionaal modelleren. Ik begrijp het allemaal nog mondjesmaat, maar vind het razend interessant om over te lezen.
Naar ik nu begrijp is een klassiek RDBMS inderdaad niet de optimale oplossing voor mijn analyses. Inlezen in een multi-dimensionaal array zou geloof ik inderdaad wel een oplossing zijn. Alleen heb ik nul ervaring in wiskunde en statistiek mbv arrays. Bovendien weet ik dus niet of je (in het geval van php-arrays) de volledige database niet moet inladen in het geheugen, wat zoals gezegd dus niet echt mogelijk is. Dit is dus nog zéker een uitdaging.

Een andere oplossing zou zijn om geen RDBMS maar een NoSQL oplossing te proberen. Naar ik nu begrijp zou ik daarvoor een oplossing als Hbase kunnen gebruiken. Na het lezen van google's BigTable paper duizelt me het een beetje, maar begrijp ik er langzaamaan meer van. Het klinkt allemaal wel interessant, maar het zou betekenen dat ik in plaats van SQL een nieuwe DB-querytaal zou moeten leren om de gegevens in en uit een Hbase DB te halen, en bovendien zou moeten rekenen met Java, wat ik ook niet beheers.

Ik weet niet of er hier iemand ervaring heeft met wiskunde/statistiek in arrays en/of Hbase-achtige databases. Wat zouden jullie adviseren, gezien mijn context van analyse?

Alle tips/commentaar is welkom!

[silentsnake]

Laat ik beginnen te zeggen dat het is wellicht niet de bedoeling om een oud topic omhoog te schoppen, dus gooi hem maar op slot als dat zo is.

Naast HBase zelf lijkt OpenTSDB een oplossing voor jouw probleem. Dat gebruikt HBase voor de opslag van z'n metrics en het enige wat jij hoeft te doen is metrics aan te bieden aan een zogenoemde collector die de boel naar de TSD stuurt. Daarvoor kan je de tcollector gebruiken.

Heb je überhaupt je probleem opgelost ondertussen?

[epic007]

kramer65 schreef op maandag 07 november 2011 @ 14:39:
..In dat geval zou toch ook alles vanuit de DB in het geheugen van mijn pc geladen moeten worden? Dat is met tables van meer dan 30GB op mijn PCtje met 4GB geheugen echter niet echt mogelijk.. Of heb ik dat mis?

Even uitgaande van je tabel:

code:

koop_tijdstip | aanhoudtijd | winst
---------------------------------------------
09:01:00      | 1           |  4
09:02:00      | 1           | -3
09:03:00      | 1           |  8

Ik verwacht dat deze kolommen allemaal 32bits zijn, 12 bytes per record dus. Bij 110000 records wordt dit +- 1.2 MB (1320000 bytes). Als je dit in een beetje efficiënte programmeertaal inleest heb je aan 4GB dus zat. (C++ of C# lijkt me dan beter dan PHP, python is misschien een optie).

SQL lijkt mij ook niet de methode om ingewikkelde berekeningen te doen, volgens mij is het oorspronkelijk bedoeld om data in en uit een database te halen.