Mysql i miliony rekordów Opcje

[alexwilq]

Witam

Dostalem do robienia projekt który bedzie dosc szybko się rozrastal. Załozenia są takie ze sie nagromadzi ok 18 milionów rekordów w ciągu roku. Struktura bazy jest dosyc prosta. Jedna tabela Userzy i UserzyWpisy z ok 30 kolumnami (integer, date, decimal). Bedze to budować w oparciu o Zenda i Doctrine. Dane bedą potem uzywane do obliczania naleznej kwoty do zaplaty, na podstawie wpisow z calego roku, w trybie tygodniowym czyli dla danego tygodnia 7 wpisów dla jednego usera.

Pytanie jest takie, co lepsze będzie:
Czy 7 osobnych rekordów w tabeli UserzyWpisy, czy 1 dlugi rekord dla jednego usera w UserzyWpisy z kolumnami na kazdy dzien czyli ok 30x7 = 210 kolumn.

wg mnie pierwsze rozwiazanie jest ok, bo mam wiekszą kontrolę nad zmianami, jak np dojdzie jedno pole nowe.
Jak to sie ma do wydajnosci mysqla? Joinow w jedynm zapytaniu bedzie sztuk 1. Złaczenie User i UserWpisy, a jedynymi operacjami będą rozne kalukacje (dodaj, odejmij) na danych w bazie.

Bedą indeksy, będą odpowiednio dobrane typy kolumn, cache w doktrynie. Na co jeszcze zwórcic uwage? nie chcialbym się w ciemny las zapędzic. Proszę o opinie osoby ktore robily takie projekty.

alex

[wookieb]

Lepsze to pierwsze, ponieważ wtedy nie będziesz pobierał danych, których dość często nie potrzebujesz. Poza tym nie opisałeś co to za pola, jakie pełnią funkcje, jak często dane z tych pól używasz

[Mchl]

210 kolumn? A chcesz do tego żyletkę, żeby od razu się pociąć?

Na dobrym serwerze, przy dobrych indeksach będzie działać. Jeśli struktura danych na to pozwala, możesz pobawić się w partycjonowanie. Najbardziej bałbym się, że Doctrine wymyśli jakieś nieszczególnie optymalne zapytania.

[alexwilq]

te kolumny bedą przechowywac dane liczbowe (unsigned 0 .. 10 000 000), oraz walutowe (np 100.25). nie bede robic zadnego szukania w tekstach, tylko pobieranie wszystkich rekrodow za dany okres i przeliczanie i potem wydruk na kwit. tak ze cudow tam nie bedzie.

[Mchl]

Nie cuduj. Tabele 'wąskie i długie' są lepsze niż 'szerokie a krótkie'

[wookieb]

A jeszcze żeby rozwiać wszystkie wątpliwości
http://dev.mysql.com/doc/refman/5.0/en/col...ount-limit.html

[alexwilq]

no i tak zrobie. bedzie 7 rekordow na jeden tydzien dla user_id. kolumn 30 ok wg typow co podalem. Poczytam jeszcze o tym partyucjonowani. dzieki za pomoc.

[Mchl]

4 bajty INT, 8 bajtów DATE, załóżmy 6 bajtów na DECIMAL = 18 bajtów na trzy kolumny
70 * 18 = 1260B < 64kiB - mieści się co nie znaczy, że warto iść tą drogą.

Ten post edytował Mchl 1.03.2010, 15:33:26