Czy MySQL to dobry =?ISO-8859-2?Q?wyb=F3r?=
Sebastian Bialy - 21-08-2007 00:07
Czy MySQL to dobry =?ISO-8859-2?Q?wyb=F3r?=
Witam!
Muszę gromadzić dużą ilość danych. Są to dane pomiarowe.
Trudno mi dzisiaj oszacować ilość tych danych, ale myślę, że będzie to
około miliona krótkich danych tekstowych po paru miesiącach pracy.
Budowa bazy jest następująca:
a) wiele małych tabel po max. pare tysiecy wpisów, ale w większość
znacznie mniej. To częśc bazy tworzącej szkielet raportowania: co,
gdzie, kiedy.
b) jedna tabela z milionem wpisów, jednak bardzo prosta, id, pole
liczbowe (będące referencją do małej tableki) i dwa pola tekstowe (o
ustalonej długości).
Co musze mieć i dlaczego MySQL:
a) olewam transakcje. Nie mam potrzeby ich stosowania. Nigdy nie będą mi
potrzebne (baza jest _wyłacznie_ przyrostowa - to zasadnicze założenie).
b) musze mieć wielodostęp przez sieć.
c) musze mieć dostęp jednocześnie z Javy (zbieranie i raportowanie), C++
(diagnostyka danych) i PHP/JSP (prezentacja danych).
d) musze mieć bazę danych pracującą na Unixie (prawdpodobnie Linux)
e) muszę mieć szybkie wyszukanie typu SELECT FROM wielka_tabla WHERE
pole_liczbowe = 10 zakładając że ten select bedzie pomykał po milionie
wierszy. Szybkie to oznacza responsywnośc GUI na zadowalającym poziomie
f) musze mieć dodawanie nowych wierszy do tej wielkiej tableli w czasie
O(1) w sensie statystycznym. Zależy od tego jakość wyników pomiarowych i
nie mogę mieć problemów z nagłym zwolnieniem niektórych INSERTów.
g) zależy mi na mozliwości zdumpowania bazy do pliku tekstowego (na
razie nie dyskutujmy o jego wielkości, to nie ma znaczenia).
h) Licencja możliwie darmowa do zastosowań komercyjnych.
i) "odpalanie bez instalacji". Zadnych setupów zmieniających pół systemu
i rozsypujących pliki w połowie root fs. Baza-i-pliki-w-jednym-miejscu.
Potrzebne to do łatwości przenoszenia bazy wraz z mechanizmami na (być
może) inne maszyny.
j) olewam bezpieczeństwo - całośc będzie pracować w hermetycznej sieci
bez dostępu z zewnatrz.
Nie wybrałem MySQL na razie ze względu na jakieś merytoryczne powody.
Chwilowo MySQL w podobnym zastosowaniu po prostu sprawdza się dobrze,
jednak teraz ilośc danych gwałtownie wzrośnie. I mam wątpliwość: czy ta
baza do dobry wybór zakładając tabelkę z milionem wpisów? Jeśli nie, to
czy coś innego znajdzie się? Postulat e (szybkośc szukania) i f
(przewidywalny czas wstawiania) są najważniejsze.
PS. Zakładam, że filesystem na którym pracuje nie ma problemów z
wielkością plików, pewnie będzie to ext3 ale jeśli ma to znaczenie to
nie jest to krytyczne.
cienki_bolek - 21-08-2007 00:07
Sebastian Bialy pisze:
> Witam!
>
> Muszę gromadzić dużą ilość danych. Są to dane pomiarowe.
>
> Trudno mi dzisiaj oszacować ilość tych danych, ale myślę, że będzie to
> około miliona krótkich danych tekstowych po paru miesiącach pracy.
>
> Budowa bazy jest następująca:
>
> a) wiele małych tabel po max. pare tysiecy wpisów, ale w większość
> znacznie mniej. To częśc bazy tworzącej szkielet raportowania: co,
> gdzie, kiedy.
> b) jedna tabela z milionem wpisów, jednak bardzo prosta, id, pole
> liczbowe (będące referencją do małej tableki) i dwa pola tekstowe (o
> ustalonej długości).
>
> Co musze mieć i dlaczego MySQL:
>
> a) olewam transakcje. Nie mam potrzeby ich stosowania. Nigdy nie będą mi
> potrzebne (baza jest _wyłacznie_ przyrostowa - to zasadnicze założenie).
>
> b) musze mieć wielodostęp przez sieć.
>
> c) musze mieć dostęp jednocześnie z Javy (zbieranie i raportowanie), C++
> (diagnostyka danych) i PHP/JSP (prezentacja danych).
>
> d) musze mieć bazę danych pracującą na Unixie (prawdpodobnie Linux)
>
> e) muszę mieć szybkie wyszukanie typu SELECT FROM wielka_tabla WHERE
> pole_liczbowe = 10 zakładając że ten select bedzie pomykał po milionie
> wierszy. Szybkie to oznacza responsywnośc GUI na zadowalającym poziomie
>
> f) musze mieć dodawanie nowych wierszy do tej wielkiej tableli w czasie
> O(1) w sensie statystycznym. Zależy od tego jakość wyników pomiarowych i
> nie mogę mieć problemów z nagłym zwolnieniem niektórych INSERTów.
>
> g) zależy mi na mozliwości zdumpowania bazy do pliku tekstowego (na
> razie nie dyskutujmy o jego wielkości, to nie ma znaczenia).
>
> h) Licencja możliwie darmowa do zastosowań komercyjnych.
>
> i) "odpalanie bez instalacji". Zadnych setupów zmieniających pół systemu
> i rozsypujących pliki w połowie root fs. Baza-i-pliki-w-jednym-miejscu.
> Potrzebne to do łatwości przenoszenia bazy wraz z mechanizmami na (być
> może) inne maszyny.
>
> j) olewam bezpieczeństwo - całośc będzie pracować w hermetycznej sieci
> bez dostępu z zewnatrz.
>
> Nie wybrałem MySQL na razie ze względu na jakieś merytoryczne powody.
> Chwilowo MySQL w podobnym zastosowaniu po prostu sprawdza się dobrze,
> jednak teraz ilośc danych gwałtownie wzrośnie. I mam wątpliwość: czy ta
> baza do dobry wybór zakładając tabelkę z milionem wpisów? Jeśli nie, to
> czy coś innego znajdzie się? Postulat e (szybkośc szukania) i f
> (przewidywalny czas wstawiania) są najważniejsze.
>
> PS. Zakładam, że filesystem na którym pracuje nie ma problemów z
> wielkością plików, pewnie będzie to ext3 ale jeśli ma to znaczenie to
> nie jest to krytyczne.
to raczej polecam postgresa, chocby ze wzgledu na partycjonowanie.
Sebastian Bialy - 21-08-2007 00:07
cienki_bolek wrote:
> to raczej polecam postgresa, chocby ze wzgledu na partycjonowanie.
W czym to może pomóc? W statystycznie stałym czasie INSERTa?
Mikolaj Rydzewski - 21-08-2007 00:07
Sebastian Bialy <heby@poczta.onet.pl> wrote:
> a) olewam transakcje. Nie mam potrzeby ich stosowania. Nigdy nie będą mi
> potrzebne (baza jest _wyłacznie_ przyrostowa - to zasadnicze założenie).
Ze niby przy insertach nie uzywa sie transakcji?
Z podanej struktury bazy wynika ze uzywasz relacji. Wiec inserty zawarte
w transakcji pozwola na zachowanie integralnosci danych.
--
Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/
PGP KeyID: 8b12ab02
There are three kinds of people: men, women, and unix.
Sebastian Bialy - 21-08-2007 00:07
Mikolaj Rydzewski wrote:
> Z podanej struktury bazy wynika ze uzywasz relacji. Wiec inserty zawarte
> w transakcji pozwola na zachowanie integralnosci danych.
Nie, nie muszę ich używać przy insertach. Baza danych bez względu na
moment jest spójna. Po prostu taką ma budowę. Nie wiem czy ma ten
projekt jakąś nazwę fachową, ale jest stabilny bez transakcji (poniekąd
ze względu na prostotę).
Z resztą MySQL ma możliwość stosowania transakcji, jednak dzisiaj na 99%
jestem pewny, że nie będę ich stosował - baza danych jest skończona pod
kątem projektu i się sprawdza do tej pory.
=?UTF-8?B?RmlsaXAgUmVtYmlhxYJrb3dza2k=?= - 21-08-2007 00:07
Sebastian Bialy wrote at 20 VIII 2007 16:26:
> Nie wybrałem MySQL na razie ze względu na jakieś merytoryczne powody.
> Chwilowo MySQL w podobnym zastosowaniu po prostu sprawdza się dobrze,
> jednak teraz ilośc danych gwałtownie wzrośnie. I mam wątpliwość: czy ta
> baza do dobry wybór zakładając tabelkę z milionem wpisów?
przy tak prostym schemacie jak opisałeś zrobienie testów nie powinno być problemem... wygeneruj sobie 5 milionów
rekordów i przetestuj wydajność. być może niekonieczne będzie przechodzenie na inną bazę.
Sebastian Bialy - 21-08-2007 00:07
Filip Rembiałkowski wrote:
> przy tak prostym schemacie jak opisałeś zrobienie testów nie powinno być problemem... wygeneruj sobie 5 milionów
> rekordów i przetestuj wydajność. być może niekonieczne będzie przechodzenie na inną bazę.
Nie wiem na ile będę w stanie zasymulować prawdziwe warunki pracy, np:
rzeczywistą fragmentację fs czy wielodostęp. Bardziej mnie interesuje
opinia typu: "MySQL jest 10x wolniejszy od XXX przy dużych tabelach" i
tym podobne. Jesli róznice w wydajności nie są duże to nie mam o co
walczyć, chodzi o jakieś poważniejsze problemy które mogą wystąpić.
dap997 - 21-08-2007 00:07
Zobacz tutaj:
http://www-it.mysql.com/customers/?dataWarehouse
i tutaj
http://forums.mysql.com/list.php?32
Z tego co goscie pisza to mysql powinno sie sprawdzic u Ciebie. Dla
danych archiwalnych polecam kompresje tabel - bardzo fajna sprawa
znacznie skraca backupy.
dap
=?UTF-8?B?RmlsaXAgUmVtYmlhxYJrb3dza2k=?= - 22-08-2007 00:02
Sebastian Bialy wrote at 20 VIII 2007 18:41:
> Filip Rembiałkowski wrote:
>> przy tak prostym schemacie jak opisałeś zrobienie testów nie powinno
>> być problemem... wygeneruj sobie 5 milionów
>> rekordów i przetestuj wydajność. być może niekonieczne będzie
>> przechodzenie na inną bazę.
>
> Nie wiem na ile będę w stanie zasymulować prawdziwe warunki pracy, np:
> rzeczywistą fragmentację fs
mówiłeś że "append only" więc fragmentacja fs nie będzie miała znaczenia (zakładam że to dedykowany serwer)
> czy wielodostęp.
to można zasymulować - wcale nie tak trudno.
> Bardziej mnie interesuje
> opinia typu: "MySQL jest 10x wolniejszy od XXX przy dużych tabelach"
takich opinii ja bym nie słuchał jeśli nie są poparte realnymi wynikami testów.
może się np. okazać że na "wąskiej" tabeli mysql zachowuje się inaczej niż na "szerokiej"... itp itd.
Sebastian Bialy - 22-08-2007 00:02
Filip Rembiałkowski wrote:
> mówiłeś że "append only" więc fragmentacja fs nie będzie miała znaczenia (zakładam że to dedykowany serwer)
Możliwe. Z ciekawości zastanawiam się na ile trzeba robić seek na pliku
bazy danych aby dodać rekord. I czy wybór systemu plików może mieć
znaczenie dla takiej operacji. Bo samo powiększanie pliku mnie nie
martwi, raczej ilość operacji przed włożeniem typu wytworzenie nowego
bloku (partycji?) dla danych, rezerwacja miejsca w pliku, przeliczenie
indeksów itd. Jeśli te operacje są intensywne to może spory narzut
pojawi się w systemie plików. Zapewne wyjdzie w praniu.
>>czy wielodostęp.
> to można zasymulować - wcale nie tak trudno.
No ok można :) Ale jeśli dostane dane rózniące się o 5% od
konkurencyjnej to to jest żadna różnica i nie wiem czy warto poświęcić
masę czasu na implementację testu z którego może nic nie wyniknąć.
> takich opinii ja bym nie słuchał jeśli nie są poparte realnymi wynikami testów.
Ale mogą naprowadzić na jakieś artykuły o bebechach engine co pozwoli
ocenić czy się nada.
> może się np. okazać że na "wąskiej" tabeli mysql zachowuje się inaczej niż na "szerokiej"... itp itd.
Owszem, przypuszczam że mam na tyle nietypowy wygląda bazy, że gotowców
nie znajdę i pozostanie test ręczny.
Dawid Kuroczko - 22-08-2007 00:37
Sebastian Bialy <heby@poczta.onet.pl> wrote:
> cienki_bolek wrote:
>> to raczej polecam postgresa, chocby ze wzgledu na partycjonowanie.
> W czym to może pomóc? W statystycznie stałym czasie INSERTa?
Teoretycznie... [Zakładam InnoDB] W MySQL będziesz mieć jedną dużą
tabelę, która będzie starała się utrzymywać porządek klucza
prymarnego. Jeśli danych jest dużo, wraz ze wzrostem wielkości
tabli, wrzucanie wiersza wg moich obserwacji będzie się wydłużało
(ile? ciężko powiedzieć, zależy od sprzętu, rodzaju danych itp.).
Nawet jeśli nie założysz klucza prymarnego, MySQL założy niejawny
klucz prymarny.
W przypadku PostgreSQL-a, dane w tabeli nie są ułożone wg klucza,
po prostu przyrastają. Jeśli tabela jest poindeksowana, to oczywiście
wraz ze wzrostem tabeli, trzeba aktualizować B-drzewa (zysk: potrzeba
tylko dodawać klucze do indeksu, nie trzymać całej tabeli w drzewie).
Jeśli taką tabelę spartycjonujesz, np. po dacie, nowe wpisy dodawane
są do jednego, znacznie mniejszego niż dane historyczne, B-drzewa
(zysk: mniejsze B-drzewo, aktywnie modyfikowane dane dotyczą jednego
regionu dysku (jednej tabeli), więc łatwiej je cache'ować), ponadto
wywalenie/archiwizowanie danych archiwalnych się upraszcza (DROP
zamiast DELETE'a).
Pozdrawiam,
Dawid
--
zastępcza
Mikolaj Rydzewski - 23-08-2007 00:02
Dawid Kuroczko <qnex.news@atlantis.knm.org.pl> wrote:
> tabelę, która będzie starała się utrzymywać porządek klucza
> prymarnego.
^^^^^^^^^^^^^
No ja pierd* Cóż to za nowomowa?
--
Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/
PGP KeyID: 8b12ab02
There are three kinds of people: men, women, and unix.
Dawid Kuroczko - 28-08-2007 00:08
Mikolaj Rydzewski <miki@ceti.pl> wrote:
> Dawid Kuroczko <qnex.news@atlantis.knm.org.pl> wrote:
>> tabelę, która będzie starała się utrzymywać porządek klucza
>> prymarnego.
> ^^^^^^^^^^^^^
> No ja pierd* Cóż to za nowomowa?
Klucza głównego. Przyjmuję, brzydko napisałem; nie będę się
usprawiedliwiał, bo wyjdzie dziecinnie, ale przyznaję masz rację.
Pozdrawiam,
Dawid
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Gdzie MySQL 4.1, a gdzie 5.0?
[MS SQL] "set names" (mySQL) w MS SQL
oracle -> oracle lub oracle -> mysql replikacja - programy
[mysql 4.0] SELECT t1.id, t1.foo FROM t1 oraz COUNT t2 w jednym zapytaniu.
[MySQL] Zwrot tego, co pasuje i nie pasuje :-/
[pgsql] Dostosowanie składni MySQL 5.0 -> PGSQL 8.1
[mysql] galeria zdjec - numerowanie zdjec
[MySQL] Zapytanie z pliku , wynik do pliku
[mysql] CONCAT agregujący, ale nie GROUP_CONCAT()
mysql data 0000-00-00 na koniec
zanotowane.pldoc.pisz.plpdf.pisz.pldirtyboys.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
