2 miliony rekordow dziennie,jak tym zarzadzac?

maYk

unread,

May 20, 2010, 9:16:21 AM5/20/10

to

Witajcie, mam program ktory zapisuje do tabeli w bazie mysql 2 miliony
rekordow dziennie. Problem jest taki ze przy 2 milionach nie da sie
tym zarzadzac, wyszukiwac itd. Od czego zaczac? Czy mysql sie do tego
nadaje? Czy moze sa inne bazy danych dedykowane do tego rodzaju
spraw?

Dzieki
Michal

Marcin

unread,

May 20, 2010, 12:46:37 PM5/20/10

to

On 2010-05-20 15:16, maYk wrote:
> Witajcie, mam program ktory zapisuje do tabeli w bazie mysql 2 miliony
> rekordow dziennie. Problem jest taki ze przy 2 milionach nie da sie
> tym zarzadzac, wyszukiwac itd.

2 mln rekordďż˝w na dzieďż˝ to nie jest jakaďż˝ zawrotna liczba.

> Od czego zaczac?

Od sprecyzowania problemu, bo z tego co napisaďż˝eďż˝ nic nie wynika.

M.

Sławomir Szyszło

unread,

May 20, 2010, 12:48:38 PM5/20/10

to

Dnia Thu, 20 May 2010 06:16:21 -0700 (PDT), maYk <m.gawry...@gmail.com>
wklepaďż˝(-a):

Za maďż˝o informacji podajesz. Podaj strukturďż˝ tej tabeli i do czego ona sďż˝uďż˝y.
Czyli czy jest tylko odczytywana (i jak), czy sďż˝ aktualizacje, czy rekordy sďż˝
usuwane? Czy wszystkie rekordy muszďż˝ byďż˝ dostďż˝pne czy moďż˝e czďż˝ďż˝ moďż˝na przesunaďż˝
do tabeli archiwalnej?

I konkrety - co to znaczy, ďż˝e nie da siďż˝ zarzďż˝dzaďż˝/wyszukiwaďż˝? Jakiego czasu
realizacji zapytania oczekujesz, a jaki jest obecnie?
--
Sďż˝awomir Szyszďż˝o
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?group=pl.comp.bazy-danych

Michał Gruchała

unread,

May 20, 2010, 1:31:45 PM5/20/10

to

> Witajcie, mam program ktory zapisuje do tabeli w bazie mysql 2 miliony

To tylko srednio 23 inserty na sekunde ;)
Jak pisali inni - za malo danych podajesz.
Czy rownie duzo jest "wyszukiwania"?
Czy "wyszukiwanie" ma operowac na aktualnych danych, czy dopuszczasz pewne
opoznienie (na przyklad kilka sekund)

--
Michał /sn1p3r/ Gruchała

maYk

unread,

May 20, 2010, 4:04:01 PM5/20/10

to

On May 20, 12:48 pm, Sławomir Szyszło <slasz...@CIACHTOlist.pl> wrote:

> I konkrety - co to znaczy, że nie da się zarządzać/wyszukiwać? Jakiego czasu

> realizacji zapytania oczekujesz, a jaki jest obecnie?

Dziekuje za odpowiedzi. Oto struktura tabeli:

Field Type Collation Attributes Null Default Extra
source_ip varchar(20) latin1_swedish_ci No None
source_name varchar(250) latin1_swedish_ci No None
date_time varchar(250) latin1_swedish_ci No None
facility varchar(250) latin1_swedish_ci No None
facility_num varchar(250) latin1_swedish_ci No None
severity varchar(250) latin1_swedish_ci No None
severity_num varchar(250) latin1_swedish_ci No None
origin varchar(250) latin1_swedish_ci No None
tag varchar(250) latin1_swedish_ci No None
message longtext latin1_swedish_ci No None
raw_syslog longtext latin1_swedish_ci No None

Problem polega na tym ze kiedy probujemy cos wyszukac w tabeli
uzywajac phpMyAdmina to zapytanie trwa 5h i tak nie zwraca calkowitego
wyniku z powodu timeoutu. Rekordy do bazy sa tylko dodawane, nie ma
aktualizacji. Tabela zawiera logi wypluwane przez serwer. Pomysl byl
takie zeby ta jedna tabele dzielic na kilka mniejszych bo 2miliony
rekordow dziennie to dla nas ogromna ilosc. Jednak oprogramowanie
ktore wypluwa logi nie moze dzielic danych na kilka tabel wiec trzeba
by to robic recznie albo php. Chcielibysmy miec mozliwosc wyszukiwania
okreslonych rekordow na zyczenie klienta. Opoznienie kilku sekund jest
dopuszczalne.

Na tabeli nie ma zadnych indexow, nie wiem od czego zaczac wiec
poczekam na rady starszych.

Michal

geos

unread,

May 20, 2010, 5:13:13 PM5/20/10

to

moďż˝e podaj rďż˝wnieďż˝ przykďż˝adowe zapytania. prawdopodobnie raczej nie
wyjdziesz poza mniej lub bardziej wyrafinowanďż˝ formďż˝ partycjonowania i
indeksowania plus ewentualne usprawnienia zwiďż˝zane z uwzglďż˝dnieniem
rekordďż˝w historycznych, ktďż˝re moďż˝na systematycznie przenosiďż˝ w inne
miejsce. to i tak bďż˝dzie duďż˝y krok wzglďż˝dem pomysďż˝u rďż˝cznej selekcji
danych i tworzenia osobnych tabel.

jeďż˝li wiďż˝kszoďż˝ďż˝ zapytaďż˝ w warunku posiada ograniczenie na datďż˝ to moďż˝esz
rozwaďż˝yďż˝ wstďż˝pne partycjonowanie po jakimďż˝ woluminie czasowym. jeďż˝li
zapytania krďż˝cďż˝ siďż˝ wokďż˝ klienta i jego numeru IP to moďż˝e warto
rozwaďż˝yďż˝ partycjonowanie pierwszego rzďż˝du po fragmentach adresu IP. a
moďż˝e zapytania sďż˝ takie, ďż˝e sprawdzi siďż˝ partycjonowanie haszowe.

moďż˝liwoďż˝ci jest kilka i myďż˝lďż˝, ďż˝e coďż˝ powinno daďż˝ siďż˝ wybraďż˝ w
zaleďż˝noďż˝ci od przykďż˝adowych zapytaďż˝. odradzaďż˝bym wszelkie rďż˝czne
manipulacje.

pozdrawiam,
geos

Bolo

unread,

May 21, 2010, 3:06:08 AM5/21/10

to

> Na tabeli nie ma zadnych indexow, nie wiem od czego zaczac wiec
> poczekam na rady starszych.
>
> Michal

1.
Zacznij od tego, zeby jedna zalozyc indeksy na polach po ktorych
wyszukujesz!
5h zapytanie - a czego sie spodziewasz, skoro nie ma indeksow?! Baza
musi byc "recznie" przejrzana przez serwer, rekord po rekordzie.

2. nie wiem jak mysql ale dla MSSQL'a to nie jest jakas ogromna liczba
- potraf zarzadzac znacznie wiekszymi zbiorami danych, wiec moze warto
sie mu przyjrzec

3. sproboj zrobic dodatkowa tabele, "historyczna" gdzie beda
przechowywane dane np. od poprzedniego miesaica wstecz
logi niech leca do bazy do ktorej ida, a po miesiacu sa z niej
przenososzne do innej tabeli.
oczywiscie - muisz uwzglednic zapytania, jakie wykonujecie - jak
daleko wstecz siegacie, czy mozna podzielic zapytania na "aktualny
miesiac" + "cala reszta' czy tez nie, ew. przebudowac zapytanie, zeby
sparwdzalo jezeli podana data jest w aktualnym miesiacu to nie tykam
histori inaczej leci po wszystkim (teoretyzuje teraz)

pozdrawiam
Bolo

geos

unread,

May 21, 2010, 3:33:11 AM5/21/10

to

Bolo wrote:
>> Na tabeli nie ma zadnych indexow, nie wiem od czego zaczac wiec
>> poczekam na rady starszych.
>>
>> Michal
>
> 1.
> Zacznij od tego, zeby jedna zalozyc indeksy na polach po ktorych
> wyszukujesz!
> 5h zapytanie - a czego sie spodziewasz, skoro nie ma indeksow?! Baza
> musi byc "recznie" przejrzana przez serwer, rekord po rekordzie.

tam sďż˝ dwa miliony rekordďż˝w dziennie, tabela prawdopodobnie nie jest
spartycjonowana, caďż˝y czas sďż˝ wstawiane dane, 23 inserty na sekundďż˝,
indeks musiaďż˝by byďż˝ caďż˝y czas przebudowywany w trakcie takich operacji.
do tego dochodzďż˝ odczyty i nie wiesz jeszcze jak selektywne sďż˝ ich
zapytania, byďż˝ moďż˝e indeks nie byďż˝by w ogďż˝le wykorzystywany. indeksy nie
sďż˝ remedium na wszystko i ich zastosowanie powinno byďż˝ poprzedzone
znacznie powaďż˝niejszďż˝ analizďż˝.

tak jak napisaďż˝ Sďż˝awomir Szyszďż˝o: niech wďż˝tkotwďż˝rca poda oprďż˝cz
struktury logicznej tabeli jej bieďż˝ďż˝cďż˝ strukturďż˝ fizycznďż˝ i kilka innych
informacji. dodatkowo przykďż˝adowe zapytania. byďż˝ moďż˝e indeksy siďż˝
przydadzďż˝, ale wczeďż˝niej naleďż˝y to przeanalizowaďż˝.

geos

Zlecony

unread,

May 20, 2010, 2:09:24 PM5/20/10

to

W dniu 2010-05-20 15:16, maYk pisze:

Jakie dane przechowuje tabela?
Co w niej chcesz wyszukiwać?

W

Michał Gruchała

unread,

May 21, 2010, 10:55:19 AM5/21/10

to

> Field Type Collation Attributes Null Default Extra
> source_ip varchar(20) latin1_swedish_ci No None
> source_name varchar(250) latin1_swedish_ci No None

powtarza sie Xset razy, proponuje wyniesc do odzielnej tabelki

> date_time varchar(250) latin1_swedish_ci No None

czemu varchar?

> facility varchar(250) latin1_swedish_ci No None
> facility_num varchar(250) latin1_swedish_ci No None

analogicznie - do oddzielnej tabelki , nie jako tekst

> severity varchar(250) latin1_swedish_ci No None
> severity_num varchar(250) latin1_swedish_ci No None

zapewne tez - do odzielnej tabelki i nie jako tekst

> origin varchar(250) latin1_swedish_ci No None
> tag varchar(250) latin1_swedish_ci No None
> message longtext latin1_swedish_ci No None
> raw_syslog longtext latin1_swedish_ci No None

> Problem polega na tym ze kiedy probujemy cos wyszukac w tabeli
> uzywajac phpMyAdmina to zapytanie trwa 5h i tak nie zwraca calkowitego
> wyniku z powodu timeoutu. Rekordy do bazy sa tylko dodawane, nie ma
> aktualizacji. Tabela zawiera logi wypluwane przez serwer. Pomysl byl
> takie zeby ta jedna tabele dzielic na kilka mniejszych bo 2miliony
> rekordow dziennie to dla nas ogromna ilosc. Jednak oprogramowanie

przy pewnej skali zawsze dobym pomyslem jest shardowanie.
zrob kilka klastrow powiedzmy X, maszyny rozrzucasz na te klastry i juz.

> Na tabeli nie ma zadnych indexow, nie wiem od czego zaczac wiec
> poczekam na rady starszych.

indeksy dodaj na to po czym szukasz ...
ale uwazaj, im wiecej indeksow, tym szybciej sie "czyta" po nich ale tym
wolniej sie zapisuje, bo indeks musi byc przebudowany.

--
Michał /sn1p3r/ Gruchała

Michał Gruchała

unread,

May 21, 2010, 10:56:24 AM5/21/10

to

>> 5h zapytanie - a czego sie spodziewasz, skoro nie ma indeksow?! Baza
>> musi byc "recznie" przejrzana przez serwer, rekord po rekordzie.

true, full scan musi machanc ;/

> tam są dwa miliony rekordów dziennie, tabela prawdopodobnie nie jest
> spartycjonowana, cały czas są wstawiane dane, 23 inserty na sekundę,
> indeks musiałby być cały czas przebudowywany w trakcie takich operacji.

23 przebudowania indeksow na sekunde, to nie jest hardcore.
tam sa same pola typu tekst - tam nawet nie ma jak sensownie indeksow
zrobic, zeby bylo ok ;/

> do tego dochodzą odczyty i nie wiesz jeszcze jak selektywne są ich
> zapytania, być może indeks nie byłby w ogóle wykorzystywany. indeksy nie
> są remedium na wszystko i ich zastosowanie powinno być poprzedzone
> znacznie poważniejszą analizą.

nie sa ale odpowiednio uzyte czynia cuda.
nagle zapytanie, ktore trwalo 5h moze trwac 10 sekund

--
Michał /sn1p3r/ Gruchała

Michał Gruchała

unread,

May 21, 2010, 10:57:59 AM5/21/10

to

maYk wrote:

> On May 20, 12:48 pm, Sławomir Szyszło <slasz...@CIACHTOlist.pl> wrote:
>
>> I konkrety - co to znaczy, że nie da się zarządzać/wyszukiwać? Jakiego
>> czasu realizacji zapytania oczekujesz, a jaki jest obecnie?
>
>
> Dziekuje za odpowiedzi. Oto struktura tabeli:

[...]
generalnie: proponuje znormalizowac baze.
Bedzie zajmowac mniej miejsca, bedzie szybciej.

--
Michał /sn1p3r/ Gruchała

Michał Gruchała

unread,

May 21, 2010, 10:58:51 AM5/21/10

to

> 2. nie wiem jak mysql ale dla MSSQL'a to nie jest jakas ogromna liczba
> - potraf zarzadzac znacznie wiekszymi zbiorami danych, wiec moze warto
> sie mu przyjrzec

nie jest nie jest, mysql spokojnie daje rade z takimi bazami.
zle zaprojektowana baza polozy i mysql i mssql a zapewne najszybciej oracle
hehe

--
Michał /sn1p3r/ Gruchała

Michał Gruchała

unread,

May 21, 2010, 11:01:51 AM5/21/10

to

> Problem polega na tym ze kiedy probujemy cos wyszukac w tabeli
> uzywajac phpMyAdmina to zapytanie trwa 5h i tak nie zwraca calkowitego
> wyniku z powodu timeoutu. Rekordy do bazy sa tylko dodawane, nie ma
> aktualizacji. Tabela zawiera logi wypluwane przez serwer. Pomysl byl
> takie zeby ta jedna tabele dzielic na kilka mniejszych bo 2miliony
> rekordow dziennie to dla nas ogromna ilosc. Jednak oprogramowanie
> ktore wypluwa logi nie moze dzielic danych na kilka tabel wiec trzeba

co to za soft?
czy nie sa to logi sysloga?

> by to robic recznie albo php. Chcielibysmy miec mozliwosc wyszukiwania
> okreslonych rekordow na zyczenie klienta. Opoznienie kilku sekund jest
> dopuszczalne.

Jesli jest dopuszczalne, to proponuje do tej bazy podlaczyc baze slave.
Na bazie master nie dajesz indeksow - zapisy beda mozliwie szybkie.
Na bazie slave (pamietaj, tylko do odczytu!!) dajesz indeksy na to, co Cie
interesuje i na niej robisz wyszukiwanie (ktore nie obciaza bazy master,
wiec logi jak lecialy, tak leca).
Conajwyzej po zadaniu zapytania na bazie slave opozni sie replikacja danych
i nie beda zsyncowane (trzeb abedzie poczekac az baza slave "nadgoni").

Bazy sie replikuja asynchronicznie, wiec baza slave moze miec obiazenie.

--
Michał /sn1p3r/ Gruchała

maYk

unread,

May 21, 2010, 11:31:10 AM5/21/10

to

On May 21, 11:01 am, Michał Gruchała <mic...@gruchala.info> wrote:

> co to za soft?
> czy nie sa to logi sysloga?

Tak

> Jesli jest dopuszczalne, to proponuje do tej bazy podlaczyc baze slave.
> Na bazie master nie dajesz indeksow - zapisy beda mozliwie szybkie.
> Na bazie slave (pamietaj, tylko do odczytu!!) dajesz indeksy na to, co Cie
> interesuje i na niej robisz wyszukiwanie (ktore nie obciaza bazy master,
> wiec logi jak lecialy, tak leca).
> Conajwyzej po zadaniu zapytania na bazie slave opozni sie replikacja danych
> i nie beda zsyncowane (trzeb abedzie poczekac az baza slave "nadgoni").

Bede musial sie troche doksztalcic w tym kierunku, bo nigdy nie mialem
stycznosci z tego rodzaju operacjami. Jednak wydaje sie to byc dobrym
pomyslem. Do tej pory dzialalo to tak:

Niektore wartosci "message" zaczynaja sie od stringu PROCESSED, i w
zasadzie te rekordy sa dla nas najwazniejsze. Jesli zaczynaja sie od
czegos innego to tego typu rekordy moga byc potrzebne jesli zwykly
rekord z "PROCESSED" jest niewystarczajacy. A wiec, ktos tu napisal
skrypt w PHP ktory wyszukuje 5000 pierwszych rekordow ktorych message
zaczyna sie od "PROCESSED" i przerzuca je do innej tabeli. Do nowej
tabeli zabieramy tylko pola: source_ip, date_time, tag,message.

Czy jest to dobre rozwiazanie? Czy opierac dalej wszystko na skrypcie
PHP?

Dziekuje za pomoc
Michal

maYk

unread,

May 21, 2010, 2:02:57 PM5/21/10

to

On May 20, 9:16 am, maYk <m.gawrychow...@gmail.com> wrote:
> Witajcie, mam program ktory zapisuje do tabeli w bazie mysql 2 miliony

Maly update. Obecnie w tabeli mam 39 milionow rekordow. Zakladam index
na poszczegolne pola i kazda operacja trwa kilkanascie minut.

Pozdrawiam
M.

Sławomir Szyszło

unread,

May 21, 2010, 2:27:00 PM5/21/10

to

Dnia Fri, 21 May 2010 11:02:57 -0700 (PDT), maYk <m.gawry...@gmail.com>
wklepaďż˝(-a):

>Maly update. Obecnie w tabeli mam 39 milionow rekordow. Zakladam index

>na poszczegolne pola i kazda operacja trwa kilkanascie minut.

Ale nadal nie podaďż˝eďż˝ jak wyglďż˝daja zapytania, ktďż˝re wykonujesz. Przecieďż˝ nikt
tu nie bďż˝dzie zgadywaďż˝.

maYk

unread,

May 21, 2010, 3:55:03 PM5/21/10

to

On May 21, 2:27 pm, Sławomir Szyszło <slasz...@CIACHTOlist.pl> wrote:

> Ale nadal nie podałeś jak wyglądaja zapytania, które wykonujesz. Przecież nikt
> tu nie będzie zgadywał.

Na przyklad tak:

SELECT * FROM syslog WHERE
message LIKE "PROCESSED%domain.com%"
AND date_time between X and Y

Pozdrawiam
M.

Michał Gruchała

unread,

May 21, 2010, 4:02:38 PM5/21/10

to

> SELECT * FROM syslog WHERE
> message LIKE "PROCESSED%domain.com%"

Panie, ten like to bez indeksow to zajedzie wszystko ;/
czy te wiadomosci z PROCESSED na poczatku charakteryzuje jakies inne
severity?
odpal sobie explain SELECT * FROM syslog WHERE message LIKE ....
i zobacz co Ci mowi - mowi duzo ;)

--
Michał /sn1p3r/ Gruchała

Michał Gruchała

unread,

May 21, 2010, 4:03:11 PM5/21/10

to

maYk wrote:

na ktore zalozyles?

--
Michał /sn1p3r/ Gruchała

Sławomir Szyszło

unread,

May 21, 2010, 4:44:50 PM5/21/10

to

Dnia Fri, 21 May 2010 12:55:03 -0700 (PDT), maYk <m.gawry...@gmail.com>
wklepaďż˝(-a):

>Na przyklad tak:

>
>SELECT * FROM syslog WHERE
>message LIKE "PROCESSED%domain.com%"
>AND date_time between X and Y

Tak jak Michaďż˝ pisaďż˝ - najpierw doprowadďż˝ tabelďż˝ do porzďż˝dku (normalizacja).
Przede wszystkim daty trzymamy w dedykowanym typie pola a nie VARCHAR.
Myďż˝laďż˝em, ďż˝e to tylko taki straszak w rďż˝nych artykuďż˝ach czy ksiďż˝ďż˝kach, ale
niestety zdarza siďż˝ to w rzeczywistoďż˝ci.

maYk

unread,

May 21, 2010, 4:52:31 PM5/21/10

to

On May 21, 4:03 pm, Michał Gruchała <mic...@gruchala.info> wrote:

> na ktore zalozyles?

Zmienilem typ date_time to datetime i zalozylem index

source_ip - zalozylem index

message - zazwyczaj jest dosc krotki wiec wlasnie zmieniam type z
longtext na text, nie wiem czy to duzo pomoze ale sprobuje. Potem bede
chcial dodac index na message

Po zalozeniu indexu na te dwa powyzsze, sortowanie smiga bardzo
szybko. Jeszcze tylko message...

Dziekuje
M.

geos

unread,

May 21, 2010, 4:59:23 PM5/21/10

to

maYk wrote:
> Na przyklad tak:
>
> SELECT * FROM syslog WHERE
> message LIKE "PROCESSED%domain.com%"
> AND date_time between X and Y

zastanďż˝w siďż˝, czy nie warto rozdzieliďż˝ przedrostkďż˝w i nazwy domen. jeďż˝li
domeny majďż˝ rďż˝ne przedrostki tak, ďż˝e kaďż˝dy z nich stanowi rozsďż˝dny
fragment wszystkich rekordďż˝w to zastanawiaďż˝bym siďż˝ kilkoma partycjami po
przedrostku. baza sama dbaďż˝aby o przydzielenie rekordu do partycji a
zapytania odwoďż˝ywaďż˝oby siďż˝ tylko do jednej partycji, tu np. PROCESSED.

dodatkowo separujďż˝c przedrostek od domeny moďż˝esz zaďż˝oďż˝yďż˝ indeks na
kolumnie z domenďż˝ i w zapytaniu uďż˝ywaďż˝ rďż˝wnoďż˝ci zamiast like.
prawdopodobnie byďż˝by to indeks doďż˝ďż˝ selektywny chociaďż˝ nie znam
rozproszenia nazw domen w tym syslogu.

jeďż˝li PROCESSED stanowi bardzo licznďż˝ grupďż˝ wszystkich rekordďż˝w to
partycjonowanie po przedrostku moďż˝e nie mieďż˝ sensu.

nie jestem pewny, czy indeks byďż˝by uďż˝ywany gdy to pole jest varcharem i
czy nie naleďż˝aďż˝oby ustaliďż˝ pola o staďż˝ym rozmiarze.

drugi warunek w zapytaniu rďż˝wnieďż˝ jest podatny na partycjonowanie, ale
pole manewru jest wiďż˝ksze. w zaleďż˝noďż˝ci od natury between X and Y moďż˝esz
rozwaďż˝yďż˝ rozdzielenie date_time na czeďż˝ďż˝ daty i czasu, i partycjonowaďż˝
po woluminie "datowym" a w ramach tego po odpowiednio dobranym woluminie
czasowym. przeanalizuj czy warunek between X and Y daje siďż˝ zapisaďż˝ tak,
aby baza mogďż˝a wykorzystaďż˝ ewentualne partycje.

to tyle na szybko.
geos

maYk

unread,

May 21, 2010, 4:59:35 PM5/21/10

to

On May 21, 4:44 pm, Sławomir Szyszło <slasz...@CIACHTOlist.pl> wrote:

> Tak jak Michał pisał - najpierw doprowadź tabelę do porządku (normalizacja).

> Przede wszystkim daty trzymamy w dedykowanym typie pola a nie VARCHAR.

> Myślałem, że to tylko taki straszak w różnych artykułach czy książkach, ale
> niestety zdarza się to w rzeczywistości.

Z poczatku nie zauwazylem ze date trzymaja w varchar, to juz
zmienione. Co oznacza pojecie normalizacji?

Dziekuje
M.

maYk

unread,

May 21, 2010, 5:01:46 PM5/21/10

to

On May 21, 4:02 pm, Michał Gruchała <mic...@gruchala.info> wrote:

> Panie, ten like to bez indeksow to zajedzie wszystko ;/
> czy te wiadomosci z PROCESSED na poczatku charakteryzuje jakies inne
> severity?

Jeszcze nie wiem. Kazde polecenie zajmuje okolo 30 minut :(

> odpal sobie explain SELECT * FROM syslog WHERE message LIKE ....
> i zobacz co Ci mowi - mowi duzo ;)

SELECT * FROM syslog WHERE message LIKE "PROCESSED%" ?? Czy oto
chodzi?

M.

geos

unread,

May 21, 2010, 5:05:19 PM5/21/10

to

geos wrote:
> nie jestem pewny, czy indeks byďż˝by uďż˝ywany gdy to pole jest varcharem i
> czy nie naleďż˝aďż˝oby ustaliďż˝ pola o staďż˝ym rozmiarze.

niedopowiedzenie: przez "to pole jest varcharem" mam na myďż˝li pole
domeny bez przedrostka.

geos

Norbert

unread,

May 21, 2010, 5:28:39 PM5/21/10

to

Dnia Fri, 21 May 2010 13:59:35 -0700 (PDT), maYk napisał(a):

> Co oznacza pojecie normalizacji?

Tylko nie pisz prosze, ze ktos Ci za to wszystko placi :/

--
pozdrawiam
Norbert

geos

unread,

May 21, 2010, 5:31:46 PM5/21/10

to

maYk wrote:
> On May 21, 4:44 pm, Sďż˝awomir Szyszďż˝o <slasz...@CIACHTOlist.pl> wrote:
>
>> Tak jak Michaďż˝ pisaďż˝ - najpierw doprowadďż˝ tabelďż˝ do porzďż˝dku (normalizacja).

>> Przede wszystkim daty trzymamy w dedykowanym typie pola a nie VARCHAR.

>> Myďż˝laďż˝em, ďż˝e to tylko taki straszak w rďż˝nych artykuďż˝ach czy ksiďż˝ďż˝kach, ale
>> niestety zdarza siďż˝ to w rzeczywistoďż˝ci.
>

> Z poczatku nie zauwazylem ze date trzymaja w varchar, to juz
> zmienione. Co oznacza pojecie normalizacji?

tu masz proste przykďż˝ady:
http://www.zie.pg.gda.pl/md/bazy_danych/przyklady_normalizacja.pdf
http://www.drivver.webpark.pl/nbd.htm

a tu teoriďż˝:
http://en.wikipedia.org/wiki/Database_normalization

geos

Michał Gruchała

unread,

May 22, 2010, 4:42:52 AM5/22/10

to

> SELECT * FROM syslog WHERE message LIKE "PROCESSED%" ?? Czy oto
> chodzi?

dodaj explain przed zapytaniem - mysql Ci powie jakby to zapytanie wykonal -
czy uzyje indeksow, czy zrobi filesort i tak dalej

--
Michał /sn1p3r/ Gruchała

Jakub Otrzasek

unread,

May 22, 2010, 6:42:32 AM5/22/10

to

maYk pisze:

Osobiďż˝cie przed zaďż˝oďż˝eniem indeksu na msg przeanalizowaďż˝bym iloďż˝ďż˝
dopuszczalnych rodzajďż˝w msg. Zrobiďż˝bym kolumnďż˝ typu int ktďż˝ra zawieraďż˝a
by id rodzaju komunikatu i zrobiďż˝bym sobie relacje z jakďż˝ďż˝ prostďż˝ tabelďż˝
typďż˝w. Pamiďż˝taj teďż˝ iďż˝ ďż˝le przemyďż˝lany indeks moďż˝e zabiďż˝ bazďż˝.

zapytanie w stylu select * from log where msg_kind= 1
zwrďż˝ciďż˝o by np wystďż˝pienia kernel panic.

Jaroslaw Berezowski

unread,

May 23, 2010, 9:31:40 AM5/23/10

to

Dnia Fri, 21 May 2010 13:52:31 -0700, maYk napisał(a):

> source_ip - zalozylem index
Tu tez zmien typ. Nie wiem jak w mysqlu, ale zazwyczaj na ipki jest albo
specjalizowany typ danych, albo w ostatecznosci ipv4 do 32bit inta mozna
wrzucic.

--
Jaroslaw "jaros" Berezowski

maYk

unread,

May 24, 2010, 9:12:43 AM5/24/10

to

On May 21, 4:59 pm, geos <g...@nowhere.invalid> wrote:

> zastanów się, czy nie warto rozdzielić przedrostków i nazwy domen. jeśli
> domeny mają różne przedrostki tak, że każdy z nich stanowi rozsądny
> fragment wszystkich rekordów to zastanawiałbym się kilkoma partycjami po
> przedrostku. baza sama dbałaby o przydzielenie rekordu do partycji a
> zapytania odwoływałoby się tylko do jednej partycji, tu np. PROCESSED.

A jakbym partycjonowal po source_ip? PO zalozeniu indexu na to pole
cardinality = 14.

> jeśli PROCESSED stanowi bardzo liczną grupę wszystkich rekordów to
> partycjonowanie po przedrostku może nie mieć sensu.

PROCESSED stanowi jakies 10% wszystkich rekordow.

> drugi warunek w zapytaniu również jest podatny na partycjonowanie, ale
> pole manewru jest większe. w zależności od natury between X and Y możesz
> rozważyć rozdzielenie date_time na cześć daty i czasu, i partycjonować

> po woluminie "datowym" a w ramach tego po odpowiednio dobranym woluminie

> czasowym. przeanalizuj czy warunek between X and Y daje się zapisać tak,
> aby baza mogła wykorzystać ewentualne partycje.

Czy jesli bede partycjonowal w ten sposob to przyspieszy to
wyszukiwanie rekordow "PROCESSED%" ?

M.

maYk

unread,

May 24, 2010, 10:26:28 AM5/24/10

to

On May 21, 4:59 pm, geos <g...@nowhere.invalid> wrote:

> zastanów się, czy nie warto rozdzielić przedrostków i nazwy domen. jeśli
> domeny mają różne przedrostki tak, że każdy z nich stanowi rozsądny

> fragment wszystkich rekordów to zastanawiałbym się kilkoma partycjami po
> przedrostku. baza sama dbałaby o przydzielenie rekordu do partycji a
> zapytania odwoływałoby się tylko do jednej partycji, tu np. PROCESSED.

Wcielo mi gdzies odpowiedz ktora do Ciebie napisalem, wiec moze
jeszcze raz:
PROCESSED to tylko jakeis 10% wszystkich rekordow. Myslalem o tym zeby
partycjonowac po IP, ktore po dodaniu indexu cardinality ma 14.

> drugi warunek w zapytaniu również jest podatny na partycjonowanie, ale
> pole manewru jest większe. w zależności od natury between X and Y możesz
> rozważyć rozdzielenie date_time na cześć daty i czasu, i partycjonować

> po woluminie "datowym" a w ramach tego po odpowiednio dobranym woluminie

> czasowym. przeanalizuj czy warunek between X and Y daje się zapisać tak,
> aby baza mogła wykorzystać ewentualne partycje.

Data tez wchodzi w gre. Postaram sie znormalizowac tabele jak tylko
sie da i dodam partycjonowanie.

Dziekuje
M

maYk

unread,

May 24, 2010, 10:28:36 AM5/24/10

to

On May 20, 9:16 am, maYk <m.gawrychow...@gmail.com> wrote:

Znow maly updejt, okazalo sie ze podczas moich ostatnich prac,
dodawanie nowych rekordow przez syslog bylo wylaczone. Dzis kiedy
przyszedlem do pracy to wlaczylismy je na nowo. Problem jest taki ze,
to chyba zarzyna caly serwer. Odkad to wlaczylismy, nie moge utrzymac
sie na zdalnym pulpicie przez dluzej niz 5 minut i Phpmyadmin po
prostu sie zamraza podczas prostego przegladania struktury tabel.

M.

maYk

unread,

May 24, 2010, 1:01:55 PM5/24/10

to

On May 21, 5:28 pm, Norbert <nore...@reply.no> wrote:
> Tylko nie pisz prosze, ze ktos Ci za to wszystko placi :/

Haha, pracuje tu za darmo :) Juz wiem, a wiec uzywalem normalizacji
juz od dawna.

Pozdrawiam
M.

maYk

unread,

May 24, 2010, 1:03:38 PM5/24/10

to

On May 22, 4:42 am, Michał Gruchała <mic...@gruchala.info> wrote:
> dodaj explain przed zapytaniem - mysql Ci powie jakby to zapytanie wykonal -
> czy uzyje indeksow, czy zrobi filesort i tak dalej

id select_type table type possible_keys key key_len ref rows
Extra
1 SIMPLE syslog ALL NULL NULL NULL NULL 40126719 Using where

M.

maYk

unread,

May 24, 2010, 1:09:26 PM5/24/10

to

On May 21, 5:31 pm, geos <g...@nowhere.invalid> wrote:
> tu masz proste przykłady:http://www.zie.pg.gda.pl/md/bazy_danych/przyklady_normalizacja.pdfhttp://www.drivver.webpark.pl/nbd.htm
>
> a tu teorię:http://en.wikipedia.org/wiki/Database_normalization
>

Dziekuje, wywalilem z tabeli to co niepotrzebne. Teraz wyglada to tak:

ID source_ip date_time tag message
1 xx.xx.xxx.xxx 2010-05-24 10:39:47 postfix/smtp[1234] Verified:
subject_CN=*.psmtp.com, issuer=VeriSign ...

Indexy sa na wszystkich polach procz tag. Zmienilem typ bazy na
innodb. Zastanawiam sie nad przeniesieniem takich samych wartosci do
osobnych tabel. Adresy IP i tagi powtarzaja sie bardzo czesto ale czy
to ma sens? Czy nie lepiej spartycjonowac wszystko po numerze dnia?
Czyli stworzyc 31 partycji?

Pozdrawiam
M.

geos

unread,

May 24, 2010, 2:50:08 PM5/24/10

to

maYk wrote:
> PROCESSED stanowi jakies 10% wszystkich rekordow.

imho jest to bardzo dobra liczebnoďż˝ďż˝ na partycjďż˝. pozostaďż˝e partycje
moďż˝esz zdefiniowaďż˝ na podstawie kryteriďż˝w zapytaďż˝ dodatkowych dla
klienta odpytujďż˝cych bazďż˝ o rekordy z innymi wartoďż˝ciami tego pola.

> A jakbym partycjonowal po source_ip? PO zalozeniu indexu na to pole
> cardinality = 14.

zrďż˝nicowanie wartoďż˝ci jest raczej niskie. imho nie ma sensu zakďż˝adaďż˝
klasycznego indeksu b-tree. alternatywnie mďż˝gďż˝by byďż˝ indeks
binarny/bitmapowy, ale nie wiem, czy 14 to juďż˝ nie za duďż˝o dla niego.
poszukaj teďż˝ dokďż˝adniejszych informacji o tym indeksie poniewaďż˝ o ile
dobrze pamiďż˝tam stwarza problemy przy insertach, co (jeďż˝li jest prawdďż˝)
przy 23/s ciďż˝gďż˝ych danych moďż˝e byďż˝ problemem. nie wiem teďż˝, czy mysql
obsďż˝uguje ten typ indeksu.

poniewaďż˝ liczebnoďż˝ďż˝ wynosi 14 to bardzo dobrze nadaje siďż˝ do
zdefiniowania dodatkowych kryteriďż˝w i wykorzystaniu ich do utworzenia
partycji drugorzďż˝dnych w ramach podziaďż˝u pierwszego.

>> drugi warunek w zapytaniu rďż˝wnieďż˝ jest podatny na partycjonowanie, ale

>> pole manewru jest wiďż˝ksze. w zaleďż˝noďż˝ci od natury between X and Y moďż˝esz
>> rozwaďż˝yďż˝ rozdzielenie date_time na czeďż˝ďż˝ daty i czasu, i partycjonowaďż˝

>> po woluminie "datowym" a w ramach tego po odpowiednio dobranym woluminie

>> czasowym. przeanalizuj czy warunek between X and Y daje siďż˝ zapisaďż˝ tak,

>> aby baza mogďż˝a wykorzystaďż˝ ewentualne partycje.

>
> Czy jesli bede partycjonowal w ten sposob to przyspieszy to
> wyszukiwanie rekordow "PROCESSED%" ?

partycjonowanie po dacie/czasie bďż˝dzie miaďż˝o wpďż˝yw na drugi z warunkďż˝w.
jednak jak siďż˝ nad nim zastanawiam w kontekďż˝cie sposobu dodawania
rekordďż˝w i samego zapytania to mam nastďż˝pujďż˝ce przemyďż˝lenia. o ile
dobrze zrozumiaďż˝em jest to syslog. rekordy dostarczane do tabeli w
czasie rzeczywistym i umieszczane w niej -- z grubsza -- zgodnie z
datďż˝/czasem wďż˝aďż˝nie. poniewaďż˝ warunek w zapytaniu jest zakresowy
(between X and Y) to rekordy i tak bďż˝dďż˝ odczytywane z tabeli
"ciurkiem-zgodnie-z-czasem" co wiďż˝ďż˝e siďż˝ z niewielkďż˝ liczbďż˝ operacji
I/O. partycjonowanie po dacie/czasie moďż˝e wiďż˝c nie wnieďż˝ďż˝ duďż˝ego zysku.

podsumowujďż˝c: partycjonowanie po polu "PROCESSED" zmniejszy liczbďż˝
rekordďż˝w poddawanych obrďż˝bce podczas odpytywania do 10% dla podanego
zapytania. jednoczeďż˝nie 90% spďż˝ywajďż˝cych rekordďż˝w baza bďż˝dzie umieszczaďż˝
w ich wďż˝asnych partycjach. partycjonowanie po IP (lub ich grupach) dalej
zmniejszy liczbďż˝ rekordďż˝w jeďż˝li warunek bďż˝dzie teďż˝ na IP.

co do partycjonowania po dacie/czasie zysk moďż˝e nie byďż˝ duďż˝y. byďż˝ moďż˝e
lepiej jest rozdzieliďż˝ timestamp na datďż˝ i czas, i zaďż˝oďż˝yďż˝ klasyczny
indeks na datďż˝. warunek na datďż˝ bďż˝dzie dďż˝ďż˝yďż˝ do statusu bardzo
selektywnego kryterium wraz z zapeďż˝nianiem tabeli. jeďż˝li wiďż˝c warunek
zapytania moďż˝esz przepisaďż˝ na ..and date = X (lub between X and Y) a do
tego dodaďż˝ warunek na czas to byďż˝ moďż˝e tak bďż˝dzie lepiej niďż˝ partycjonowaďż˝.

ogďż˝lnie uwagi chďż˝opakďż˝w z tego wďż˝tku sďż˝ bardzo cenne. nie ma gotowego
przepisu (szczegďż˝lnie tak na odlegďż˝oďż˝ďż˝). czasami jedno rozwiďż˝zanie
sprawdza siďż˝ lepiej o tego, ktďż˝re sprawdzaďż˝o siďż˝ dobrze gdzie indziej.
trzeba trochďż˝ potestowaďż˝. unikaj raczej zakďż˝adania "na paďż˝ďż˝" indeksďż˝w.
przy takiej liczbie danych mogďż˝ bardzo puchnďż˝ďż˝, a poniewaďż˝ sďż˝ to
struktury zwarte moďż˝e wystďż˝piďż˝ konkurowanie o dostďż˝p do nich. indeksy
mogďż˝ rďż˝wnieďż˝ byďż˝ partycjonowane, ale nie wiem czy mysql je obsďż˝uguje.

na tej grupie jest sporo wymiataczy bazodanowych, moďż˝e ktoďż˝ siďż˝ jeszcze
odezwie i doda od siebie uwagi (na co rďż˝wnieďż˝ liczďż˝, trzeba uczyďż˝ siďż˝
caďż˝e ďż˝ycie)

pozdrawiam,
geos

maYk

unread,

May 24, 2010, 3:51:34 PM5/24/10

to

On May 24, 2:50 pm, geos <g...@nowhere.invalid> wrote:
> podsumowując: partycjonowanie po polu "PROCESSED" zmniejszy liczbę
> rekordów poddawanych obróbce podczas odpytywania do 10% dla podanego
> zapytania. jednocześnie 90% spływających rekordów baza będzie umieszczać
> w ich własnych partycjach. partycjonowanie po IP (lub ich grupach) dalej
> zmniejszy liczbę rekordów jeśli warunek będzie też na IP.

A jak dodac partycje na tego rodzaju warunek. Jak dodajemy partycje
tego rodzaju i jakiego typu?

Przykladowy wiersz:

ID source_ip date_time tag message

23 96.xxx.xx.xxx 2010-05-24 10:39:48 coder004s[5360] PROCESSED|encode|
zixnet|FROM:xx@ddd...

> na tej grupie jest sporo wymiataczy bazodanowych, może ktoś się jeszcze
> odezwie i doda od siebie uwagi (na co również liczę, trzeba uczyć się
> całe życie)

Bardzo dziekuje za wyczerpujaca odpowiedz

M.

geos

unread,

May 24, 2010, 4:09:12 PM5/24/10

to

maYk wrote:
> On May 24, 2:50 pm, geos <g...@nowhere.invalid> wrote:

>> podsumowujďż˝c: partycjonowanie po polu "PROCESSED" zmniejszy liczbďż˝

>> rekordďż˝w poddawanych obrďż˝bce podczas odpytywania do 10% dla podanego

>> zapytania. jednoczeďż˝nie 90% spďż˝ywajďż˝cych rekordďż˝w baza bďż˝dzie umieszczaďż˝

>> w ich wďż˝asnych partycjach. partycjonowanie po IP (lub ich grupach) dalej
>> zmniejszy liczbďż˝ rekordďż˝w jeďż˝li warunek bďż˝dzie teďż˝ na IP.

>
> A jak dodac partycje na tego rodzaju warunek. Jak dodajemy partycje
> tego rodzaju i jakiego typu?
>
> Przykladowy wiersz:
>
> ID source_ip date_time tag message
> 23 96.xxx.xx.xxx 2010-05-24 10:39:48 coder004s[5360] PROCESSED|encode|
> zixnet|FROM:xx@ddd...

tutaj znalazďż˝em skďż˝adniďż˝ CREATE TABLE w mysql:

http://dev.mysql.com/doc/refman/5.1/en/create-table.html

do partycjonowania interesuje Ciďż˝ wypeďż˝nienie czďż˝ci PARTITION
BY/SUBPARTITION BY. jeďż˝li siďż˝ zdecydujesz to prawdopodobnie w przypadku
pola "przedrostek" bďż˝dzie to partycjonowanie listowe. tutaj znalazďż˝em
dobrze opisane przykďż˝ady, znajdziesz analogiďż˝ do takiego przypadku,
fajnie jest to opisane z tego co widzďż˝:

http://dev.mysql.com/tech-resources/articles/mysql_5.1_partitions.html

pozdrawiam,
geos

Paweł Muszyński

unread,

May 25, 2010, 4:49:40 AM5/25/10

to

W dniu 2010-05-24 16:28, maYk pisze:

Hmm - a może podejdź do tego od innej strony (ja kiedyś coś takiego
robiłem) - syslog zapisujący normalnie na dysk, do tego co noc logrotate
i po logrotate skrypt parsujący ten archiwlany log i wpisujący go do bazy.

Plusy:
+ Dodajesz rekordy jednym ciągiem - możesz na ten czas wyłączyć indeksy
i włączyć je po całej operacji
+ Duże możliwości optymalizacji na etapie dodawania rekordów - możesz
dodawać tylko wybrane, możesz robić jakieś analizy - ja miałem oddzielną
tabelę ze statystyka dobową, którą mi skrypt zliczał
+ Przez cały dzień baza jest tylko odczytywana

Minusy
- nie masz dostępu do zapisów z bieżącego dnia

Jeśli ten minus jest do zaakceptowania - IMO warto.

Ew. możesz to robić w cyklach godzinowych, a nie dobowych.

--
Paweł Muszyński
Skateshop http://sklep.e-street.pl

Jakub Otrzasek

unread,

May 25, 2010, 6:03:54 AM5/25/10

to

Paweł Muszyński pisze:

Albo wydzielic tabele do której się ładują dane i raz na jakiś czas
(1h,1d) przesuwac do docelowej w sposób opisany powyżej.

Pozdrawiam
J.

ewel

unread,

May 26, 2010, 7:15:44 AM5/26/10

to

>> Zacznij od tego, zeby jedna zalozyc indeksy na polach po ktorych
>> wyszukujesz!

tzn. tych po "select" czy tych po "where" ?

Jaroslaw Berezowski

unread,

May 26, 2010, 2:45:15 PM5/26/10

to

Dnia Mon, 24 May 2010 10:09:26 -0700, maYk napisał(a):

> Indexy sa na wszystkich polach procz tag.

Hmm pisz prosze po naszemu "indeks". To mi zgrzyta w oczach tak jak kotly
na "pellets" Kostrzewy.
A co do tego na czym je zalozyc - odpowiedz sobeio na pytanie, po czym
chcesz filtrowac, ew. agregowac.

> Zmienilem typ bazy na innodb.
> Zastanawiam sie nad przeniesieniem takich samych wartosci do osobnych
> tabel. Adresy IP i tagi powtarzaja sie bardzo czesto ale czy to ma sens?

Jezeli "bardzo czesto" oznacza bardzo czesto, to ma.

--
Jaroslaw "jaros" Berezowski

geos

unread,

May 28, 2010, 5:11:56 AM5/28/10

to

maYk wrote:
> Bardzo dziekuje za wyczerpujaca odpowiedz
>
> M.

napisz proszďż˝ jak finalnie wyglďż˝da implementacja rozwiďż˝zania i jak siďż˝
sprawdza.

pozdrawiam,
geos

maYk

unread,

May 28, 2010, 3:56:30 PM5/28/10

to

On May 28, 5:11 am, geos <g...@nowhere.invalid> wrote:
> napisz proszę jak finalnie wygląda implementacja rozwiązania i jak się
> sprawdza.

Pewnie, dzieki za pomoc.

M.

Piotrpo

unread,

Jun 1, 2010, 8:46:40 AM6/1/10

to

where

Maseł

unread,

Jun 1, 2010, 3:59:18 PM6/1/10

to

Ale mozna zastanowic sie, czy do tego where nie dorzucic paru jego
kumpli z select. Zwlaszcza, jak do kazdego zapytania ida razem...
Przyklad:

select imie, nazwisko
...
where nazwisko= 'Kowalski'

Pozdro

Maseł

geos

unread,

Jun 1, 2010, 4:25:23 PM6/1/10

to

Maseďż˝ wrote:
> Ale mozna zastanowic sie, czy do tego where nie dorzucic paru jego
> kumpli z select. Zwlaszcza, jak do kazdego zapytania ida razem...
> Przyklad:
>
> select imie, nazwisko
> ...
> where nazwisko= 'Kowalski'
>
> Pozdro
>

> Maseďż˝

wreszcie padďż˝a ta sugestia w odpowiedzi na to lekko podchwytliwe pytanie :)

pozdrawiam,
geos

Piotrpo

unread,

Jun 2, 2010, 3:47:08 AM6/2/10

to

On 1 Cze, 22:25, geos <g...@nowhere.invalid> wrote:

> Maseł wrote:
> > Ale mozna zastanowic sie, czy do tego where nie dorzucic paru jego
> > kumpli z select. Zwlaszcza, jak do kazdego zapytania ida razem...
> > Przyklad:
>
> > select imie, nazwisko
> > ...
> > where nazwisko= 'Kowalski'
>
> > Pozdro
>

> > Maseł
>
> wreszcie padła ta sugestia w odpowiedzi na to lekko podchwytliwe pytanie :)
>
> pozdrawiam,
> geos

Jaki ma być sens wrzucania do indeksu pól z klauzuli select?

Message has been deleted

Maseł

unread,

Jun 2, 2010, 5:29:54 AM6/2/10

to

On 2010-06-01 22:25, geos wrote:
> Maseďż˝ wrote:
>> Ale mozna zastanowic sie, czy do tego where nie dorzucic paru jego
>> kumpli z select. Zwlaszcza, jak do kazdego zapytania ida razem...
>> Przyklad:
>>
>> select imie, nazwisko
>> ...
>> where nazwisko= 'Kowalski'

> wreszcie padďż˝a ta sugestia w odpowiedzi na to lekko podchwytliwe pytanie :)

Bo systemy z indeksem na kazdej mozliwej kolumnie juz widzialem...

Pozdro

Maseďż˝

iddqd

unread,

Jun 30, 2010, 8:12:50 AM6/30/10

to

On 20 Maj, 15:16, maYk <m.gawrychow...@gmail.com> wrote:
> Witajcie, mam program ktory zapisuje do tabeli w bazie mysql 2 miliony
> rekordow dziennie. Problem jest taki ze przy 2 milionach nie da sie
> tym zarzadzac, wyszukiwac itd. Od czego zaczac? Czy mysql sie do tego
> nadaje? Czy moze sa inne bazy danych dedykowane do tego rodzaju
> spraw?

Opiekuje się podobną bazą z logami gdzie są miliardy wierszy i działa.
- indeksy muszą mieścić się w pamięci.
- pola tekstowe trzymasz w oddzielnej tabeli
- archiwizujesz dane starsze niż x dni
- do wyszukiwanie po polach tekstowych dodajesz sphinxa,solr, ...