Forum Debian Users Gang

Huk · 2012-05-17 22:51:21

Witam.

Tak się zastanawiam co może być wydajniejsze, tak generalnie patrząc.

Np. mam 150 pól do pojazdu, mogę albo wrzucić to w jedną wielką tabelę, albo podzielić na kilka średnich, albo na kilkanaście mniejszych - wszystko oczywiście spięte relacjami. Ciekaw jestem jak z wydajnością zapytań typu select w przypadku:

1. Kiedy spora ilość danych będzie nullami.
2. Kiedy większość pól będzie wypełniana.
3. Kiedy będzie pół na pół.

Przy okazji pytanko do bardziej doświadczonych osób, co lepiej stosować biorąc pod uwagę jeszcze inne aspekty (np. wielkość danych po dodaniu rekordu).

Jakbyście mieli linki do jakichś fajnych artykułów o tym co wpływa na wydajność zapytań SQL (po polsku lub angielsku) to z chęcią poczytam :)

Z góry dzięki i pozdrawiam,

Ostatnio edytowany przez Huk (2012-05-17 22:54:12)

life · 2012-05-18 12:55:34

Zapewne zależy od zapytanie ile warunków oraz ważne jak zindeksowane i dobrane pola do przechowywanych danych.
Podstawa to normalizacja tabeli przynajmniej do 1N.

A co do wydajności to zależy wiele od silnika (MySQL, PostgreSQL), w samym MySQL jest też kilka mechanizmów składowani: InnoDB, MyISAM, BerkleyDB itp. wszytkie mają swoje zalety i wady. Najszybszy (w większości przypadków) jest MyISAM ale nie wspiera transakcji, co niekiedy jest kluczowe.

Ostatnio edytowany przez life (2012-05-18 13:00:19)

Huk · 2012-05-21 07:30:29

@life:

A czy orientujesz się czy ilość tabeli w bazie ma jakiś wpływ na wydajność? Obecnie pisze sobie pewien programik i w ramach optymalizacji zrobiłem sobie od czorta tabel - razem blisko tysiąc tabel (a będzie jeszcze więcej), chodziło mi o to żeby jak najmniej wpisów było w pojedynczej tabelce aby jak najszybciej dało się wyszukiwać - nie wiem tylko czy to dobre rozwiązania, czy też sama ilość tabel ma jakiś wpływ na zapytania na jakiejś konkretnej tabeli z tego zbioru?

kamikaze · 2012-05-21 08:49:04

Możesz zdradzić co robi ten programik? Skoro potrzebuje tysiąca tabel., to umieram z ciekawości ;]

Huk · 2012-05-21 09:18:56

A ma to być taki mini translatorek do własnego użytku - w ramach optymalizacji zapytań obecnie zrobiłem tak że dla każdej litery z alfabetu języka wejściowego jest litera z alfabetu języka wyjściowego + tabele pośrednie (czyli jest np A_PL, A_EN + tabele łącząca A_PL_2_A_EN, A_PL_2_B_EN itd.) stąd tyle tego - tylko nie wiem czy sama ilość nie wpływa źle na zapytania, stąd pytanie ;]

Pozdro.

czadman · 2012-05-21 15:04:33

Zastosuj jakiś silnik z [url=http://www.postgresql.org/docs/8.3/static/textsearch.html]pełnotekstowym wyszukiwaniem[/url]. Krocie tabel da odwrotny efekt od zamierzonego.

Contravene · 2012-05-22 13:49:30

Możesz napisać, co ma się znajdować w tych tabelach? Jestem pewien, że wystarczy kilka tabel. Jeśli odczytywane będę cześciej niż aktualizowane, to nałożenie odpowiednich indeksów znacznie przyspieszy wykonywanie zapytań.

Huk · 2012-05-22 20:50:38

Tabele idą na zasadzie:

A_PL, B_PL, C_PL...Z_PL

oraz

A_EN, B_EN, C_EN...Z_EN

plus tabele łącznikowe:

A_PL_2_A_EN, A_PL_2_B_EN, A_PL_2_C_EN itd

W tabelach zwykłych jest tylko ID i wartość w postaci stringa, w łączących, ID i relacje na każdą z tabel.

Myślałem sobie że aby np. wykorzystać coś do smart filtra (podpowiadania jak to na google przy wyszukiwaniu), najlepiej podzielić to na jak najwięcej tabel, aby zamiast szukać w jednej, czy tam kilku, z setkami tysięcy wpisów (oczywiście to jest hipotetyczne wiadomo że obecnie jest tam tylko garstka wpisów, ale chciałem to zrobić przyszłościowo - w końcu ilość tłumaczeń słów z angielskiego na polski i vice versa to są dziesiątki, jak nie setki tysięcy wyrazów...), szukać na zasadzie:

Jeżeli pierwsza litera to A to pobieraj z A, jak B to z B itd. Na "chłopski" rozum to powinna być niezła optymalizacja... tyle że wtedy się zacząłem zastanawiać czy ilość tabeli nie będzie miała wpływu na wydajność zapytań - jak na ironię nigdzie nie mogę znaleźć takiego porównania.

Gdyby to miało być robione na jednej czy dwóch tabelach to widzę to na zasadzie:

FRAZA_PL, FRAZA_EN, FRAZA_PL_2_FRAZA_EN (wiadomo że słowa mogą mieć wiele znaczeń)

Tylko ciekaw jestem jak szybko to będzie przeszukiwane (nawet z indeksami) jeżeli by w takiej tabeli było np 100 000 rekordów... nie mam aż takie dużego doświadczenia z SQL'em stąd pytanko do Was :)

Contravene · 2012-05-23 14:09:59

Moim zdaniem pomysł z mnożeniem tabel nie jest trafiony - w ten sposób już struktura bazy danych będzie przechowywała informacje, a nie strukturę informacji/danych. Poza tym co z polskimi znakami oraz znakami specjalnymi? Czy wszystkie mogą się znaleźć w nazwach tabel?

Musisz także wziąć pod uwagę to, że wyszukiwane informacje mogą zawierać błędy - tak zaprojektowana struktura bazy danych skutecznie utrudni Ci zwrócenie sensownego wyniku lub podpowiedzi dla użytkownika.

Jeśli budujesz coś, co ma być używane, to polecam zapoznanie się z Apache Solr, świetnie uzupełni funkcje translatora. Jeśli chcesz pozostać tylko przy MySQL, to jak czadman radzi, zwróć się w stronę wyszukiwania pełnotekstowego.

qluk · 2012-05-23 22:11:26

Wow pierwsza postac normalna... Toż to nie daje optymalizacji.
Raczej celowałbym w cos obiektowego, a nie relacyjnego.

@life: MySQL czy PostgreSQL same w sobie nie są jakimkolwiek silnikiem, to własnie np. InnoDB jest "silnikiem" bazy.

life · 2012-05-24 11:48:09

Zależnie od silnika bazy, tak np. w MYISAM każda tabela przechowywana jest w trzech plikach (każda tabela ma swój katalog), nie wiem jak wyglądają twoje zapytania i jaką wielkośc będzie zajmowała cała baza. Przy takiej ilości tabel może być problem z IO dysku no chyba że baza nie zajmuje dużo miejsca wówczas można przydzielić sporo RAM dla tabel (cache). Ewentualnie użyć typu mechanimu skłądowania MEMORY (przechowywany w RAM) i na początku ładować całą bazę ze zwykłych tabel do MEMORY.

@qluk: A ja będę się upierał przy tym że MySQL czy Postgre SQL jest "silnikiem" a InnoDB czy MYISAM to mechanizmy składowania danych :)

Huk · 2012-05-28 23:55:58

Moi drodzy, dzięki za info, od razu doprecyzuję - z której obecnie korzysta program to plikowy SQLite, oczywiście można to szybko zmienić.

Co do meritum - sorry że będę upierdliwy, ale czy ktoś z Was miał jakieś realne doświadczenie, bądź posiada wiedzę książkową która daje podstawy stwierdzić że duża ilość tabel będzie miała negatywne skutki? Może lepiej połączyć to o czym piszecie z rozdziałem na tabele? Żebyśmy się dobrze zrozumieli - znawca ze mnie wielki nie jest, ale zastanawiam się jak takie google czy inne firmy trzymają dane - aby przy ogromnych ilościach smartfiltry działały w czasie rzeczywistym i wydaje mi się że tam, bez optymalizacji same indeksy rady by nie dały stąd moje wątpliwości, a wlałbym projektować soft od razu jak najlepiej żeby potem jajek nie było (ok, google pewnie zamiast SQL korzysta z NoSQL, albo jeszcze czegoś innego - ale wiadomo o co mi chodzi) ;]

Pozdro.

kamikaze · 2012-05-29 09:07:53

Poczytaj na google, jest masę artykułów o optymalizacji różnych baz danych. Z tego co przejrzałem to dobrze trzymać się zasady jeśli dobrze działa nie optymalizować. I to chyba dobra zasada. Ty chyba zacząłeś optymalizować od razu nie patrząc czy to w ogóle potrzebne. Może warto sprawdzić. Bazy radzą sobie z milionami rekordów w tabelach. Chyba do takich ilości nie dojdziesz robiąc bazę słów w jakimś języku.

djjanek · 2012-05-29 09:14:32

Ze swojego doświadczenia z MySQL wiem:

Ilość tabel ma wpływ na pracę serwera jako maszyny a nie bazy MySQL

Baza MySQL będzie działać wolniej jak:
1) jest duża ilość danych do przeszukania w jednej tabeli
2) zapytanie przeszukuje w kilku tabelach
3) ilość wierszy zwracanych jest duża (nie robić zapytania SELECT * ...)

Własne doświadczenia opieram na pracy z bazami rzedu 10GB

Time (s)	Query
0.00009	SET CHARSET latin2
0.00009	SET NAMES latin2
0.00085	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.137.218.176' WHERE u.id=1
0.00064	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.137.218.176', 1732811521)
0.00047	SELECT * FROM punbb_online WHERE logged<1732811221
0.00051	SELECT topic_id FROM punbb_posts WHERE id=202702
0.00007	SELECT id FROM punbb_posts WHERE topic_id=21262 ORDER BY posted
0.00060	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=21262 AND t.moved_to IS NULL
0.00005	SELECT search_for, replace_with FROM punbb_censoring
0.00099	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=21262 ORDER BY p.id LIMIT 0,25
0.00148	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=21262
Total query time: 0.00584 s

Forum Debian Users Gang

Ogłoszenie

#1 2012-05-17 22:51:21

Huk - Smoleńsk BULWA!

SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#2 2012-05-18 12:55:34

life - Użytkownik

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#3 2012-05-21 07:30:29

Huk - Smoleńsk BULWA!

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#4 2012-05-21 08:49:04

kamikaze - Administrator

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#5 2012-05-21 09:18:56

Huk - Smoleńsk BULWA!

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#6 2012-05-21 15:04:33

czadman - Bicycle repairman

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#7 2012-05-22 13:49:30

Contravene - Użytkownik

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#8 2012-05-22 20:50:38

Huk - Smoleńsk BULWA!

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#9 2012-05-23 14:09:59

Contravene - Użytkownik

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#10 2012-05-23 22:11:26

qluk - Pan inż. Cyc

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#11 2012-05-24 11:48:09

life - Użytkownik

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#12 2012-05-28 23:55:58

Huk - Smoleńsk BULWA!

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#13 2012-05-29 09:07:53

kamikaze - Administrator

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

#14 2012-05-29 09:14:32

djjanek - Użytkownik

Re: SQL - co wydajniejsze: wiele bardzo małych tabel, czy więcej większych

Stopka forum

Informacje debugowania