[Althalos]

Jag ska spara till databasen en mycket större mängd data än vad jag tidigare att försökt mig på, så jag vill ha lite tips om hur jag kan spara denna data på ett effektivt sätt.

Ändamålet är en applikation där vardera användare har varsin aktieportfölj. Varje minut så uppdaterar jag min databas över aktiernas värde. I efterhand vill jag kunna visa hur aktier/portföljer har utvecklats i snygga grafer. Så jag tänker mig att jag sparar aktiernas värde varje gång.

Säg nu har jag har 100 olika aktier som jag följer, i så fall så får jag 6000 värden att lägga in i databasen varje timma. Efter ett par veckor blir antalet rader i mySQL-databasen helt enormt, om jag väljer att ge varje värde en egen rad.

Alternativ jag har funderat på är att ha en rad per aktie och sedan spara alla historik om den aktien i en json/csv-sträng.

Hur tycker ni att jag ska göra?

mvh

edit: nackdelen med att spara alla värden i en sträng, som jag ser det, är att värdena kommer att behöva hämtas väldigt ofta men det är sällan som jag behöver alla värdena.

[captaindoe]

Vad är det för databas server du använder?

Om du använder MySQL skulle jag rekommendera dig att använda MyISAM/InnoDB beroende på hur du anser på 'row locking' samt 'table locking'.

"Apparently MyISAM is faster than InnoDB. The only advantage InnoDB has over MyISAM is that it supports row locking, while MyISAM only supports table locking. Therefore, if lots of reads and writes are constantly being done to a very large table, it eliminates the constant database errors that using a MyISAM table would cause from the overload. InnoDB would therefore be a tad more reliable when you don't mind taking a small performance hit in exchange for not suffering from table locking issues."

http://www.daniweb.com/web-developme...900#post196900

Jag skulle dock ha använt mig av MyISAM, med antingen smallint, mediumint, float eller decimal på fältet som håller aktievärdet eftersom det borde inte vara så stort. Decimal kan vara bäst eftersom det är avsett för penga värden. Det avrundas dock. Men skulle ändå använda det eftersom det tar bort onödiga värden (såsom en upprepande nummerföljd). Float lär vara snabbare än decimal för att den använder en egen del i din processor. (http://lists.mysql.com/mysql/201704)

Du behöver också indexera de fält som du kommer använda när du söker efter resultat i tabellen.

Om du har en VPS eller dedikerad server skulle jag rekommendera dig till att implementera Memcache så att du kan spara resultaten i ram minnet (vilket går betydligt snabbare att hämta än att köra MySQL queries hela tiden.)
Om du bestämmer dig för att använda memcache skulle jag rekommendera dig att använda denna PHP class för att lätt implementera detta i din site.

http://www.phpclasses.org/package/35...e-servers.html

[coredev]

Ursprungligen postat av Althalos

Ändamålet är en applikation där vardera användare har varsin aktieportfölj. Varje minut så uppdaterar jag min databas över aktiernas värde. I efterhand vill jag kunna visa hur aktier/portföljer har utvecklats i snygga grafer. Så jag tänker mig att jag sparar aktiernas värde varje gång.

Säg nu har jag har 100 olika aktier som jag följer, i så fall så får jag 6000 värden att lägga in i databasen varje timma. Efter ett par veckor blir antalet rader i mySQL-databasen helt enormt, om jag väljer att ge varje värde en egen rad. Alternativ jag har funderat på är att ha en rad per aktie och sedan spara alla historik om den aktien i en json/csv-sträng.

Vad du vill göra är att lägga historiken för aktierna i en egen tabell. I en annan tabell sparar du vilka aktier som finns. I en tredje tabell sparar du kopplingen mot användarna. Till sist joinar du ihop allt när du skall hämta upp statistiken för användaren.

tb_user - id, name, etc - innehåller användare, dvs en rad per användare
tb_stock - id, name, etc - innehåller en lista med alla tillgängliga aktier, dvs en rad per aktie
tb_stock_history - id, stock_id, price, setdate - innehåller aktiernas prisändringar, dvs en rad per prisändring per aktie
tb_user_stock, id, user_id, stock_id - innehåller kopplingen mellan användare och aktie, dvs en rad per aktie som en användare följer

Disclaimer: Med reservation för att jag läste din fråga slarvigt eller för att jag har missförstått något ;-)

[Althalos]

Okej, då ska jag definitivt använda MyISAM.

Det var typ det upplägget som coredev beskriver som jag har tänkt mig, funderade egentligen mest på om det lönade sig att försöka minska antalet rader på något sätt. Men nu kör jag på detta så får vi se hur det blir

[dAEk]

Ska du bara hantera de svenska börserna eller även utländska?

Hur hanterar du en split om du sparar alla värden som en sträng? Det känns inte helt genomtänkt.

coredevs designförslag är väl ok men jag hade sparat daglig och historisk data i olika tabeller eftersom det borde bli mindre belastning på databasen med tanke på hur ofta indexen behöver uppdateras annars. Daily-tabellen blir liten medan den stora tabellen bara behöver uppdateras en gång per dygn och det är när dagens prisskillnader skyfflas över till historiken.

En kort men viktig kommentar ang. mysql: vill man ha dataintegritet och stöd för transaktioner går myisam bort.

[Clarence]

Ursprungligen postat av captaindoe

"Apparently MyISAM is faster than InnoDB. The only advantage InnoDB has over MyISAM is that it supports row locking, while MyISAM only supports table locking. Therefore, if lots of reads and writes are constantly being done to a very large table, it eliminates the constant database errors that using a MyISAM table would cause from the overload. InnoDB would therefore be a tad more reliable when you don't mind taking a small performance hit in exchange for not suffering from table locking issues."

Denna beskrivning är fel där den började. Skillnaderna är mycket större och vilken som är presterar bäst beror helt på databas och setup. Så länge du strukturerar dina writes och tabeller vettigt så behöver inte tabell-låsningen bli något problem med myisam i ditt usecase.

Det finns en mängd saker som skiljer de två tabelltyperna åt. Med en bra confad server som inte ligger nära 0% writes så är det innodb som kommer hantera last och datamängder mycket bättre än myisam. Det beror t ex på primärnyckels-klustring, buffer poolen, buffrade writes osv osv.

[SEAPelle]

Ursprungligen postat av Althalos

Säg nu har jag har 100 olika aktier som jag följer, i så fall så får jag 6000 värden att lägga in i databasen varje timma. Efter ett par veckor blir antalet rader i mySQL-databasen helt enormt, om jag väljer att ge varje värde en egen rad.

Gör upplägget som Coredev föreslog och indexets rätt. Blir ju inte mer än 4,5 miljoner poster i historiktabellen.
alternativt skapar du tabeller för historik per dag, givetvis scriptat, och skapar en view med union commandot.
En för veckohistorik där du kör union på de 7 senaste dagstabellerna och en månadshistorik som kollar de senaste 30 dagarna.
Genom detta upplägg kan du enkelt spara mycket längre än enbart en månad och ändå bibehålla bra prestanda.

Lite osäker dock på hur mySql hanterar viras, men i MSsql fungerar det supersmidigt.

[emilv]

Du tjänar ingenting alls på att slå ihop flera värden i en kolumn. Kör du MyISAM får du tvärtom stora prestandanackdelar då MyISAM är allra bäst när raderna har fast bredd. Dessutom är det hopplöst att ställa frågor mot datat eftersom SQL inte hanterar sådana sammanslagna typer speciellt bra.

Ursprungligen postat av Clarence

Med en bra confad server som inte ligger nära 0% writes så är det innodb som kommer hantera last och datamängder mycket bättre än myisam. Det beror t ex på primärnyckels-klustring, buffer poolen, buffrade writes osv osv.

För att inte tala om InnoDBs möjlighet att lätt sprida lasten mellan olika diskar (olika datafiler).

[captaindoe]

Absolut Clarence, man kan självklart konfigurera många olika inställningar i MyISAM för att öka prestandan. Du har självklart rätt att det finns otroligt många andra fördelar/nackdelar med varje engine. Jag valde att citera den källan för att jag tyckte den var simplast för ändamålet som TS ville uppnå.

Men min egen erfarenhet med MyISAM med stora tabeller är att laddningstiderna väldigt långa i en tabell med cirka 1.5 miljoner rader.
Då hade jag konfigurerat servern genom att ökade rejält key_buffer_size, sort_buffer_size, tmp_table_size, read_buffer_size, read_rnd_buffer_size, query_cache_size samt table_open_cache.

Det var troligtvis för att det var otroligt många läsningar, och skrivningar. 50/50 säkert. Antalet läsningar och skrivningar var säkerligen uppemot 8 läsningar/skrivningar per sekund.

[emilv]

Ursprungligen postat av captaindoe

50/50 säkert.

Ouch! Det dödar effektivt MySQLs query-cache om inte annat. Då är det dags att börja kika på sharding (till exempel lagra data i flera tabeller, eller på olika servrar), klustring eller kanske en objektscache typ Memcached.