Zátěž MySQL

Zdravím,

za několik měsíců mě čeká konec dvouletého vývoje obří aplikace. Zatím jsou v aplikaci testovací data a zajímal by mě názor na následující:

Na portálu funguje vyhledávání s našeptávačem. Našeptávač reaguje na každé onkeyup v inputu a po této události obnovuje našeptávání výsledků. Pokud se jedná o vyhledávání z jedné tabulky, jde to celkem rychle. Našeptávač ale funguje i napříč tabulkami - tzn. našeptává data např. z 1 tisíce tabulek a každá tato tabulka obsahuje stovky záznamů.... Pro našeptávání je použito %like% společně s CONCAT. Výsledky našeptávání jsou velmi dobré, ale nezdá se mi rychlost - načtení napříč tabulkami do našeptávače trvá cca. 3 vteřiny a to jsem v aplikaci jen já sám jako uživatel a zatím tu jsou jen testovací data....

Takže mám několik možností a zajímá mě, co si o tom myslíte:
1. Vyhodit funkci našeptávání napříč tabulkami
2. Nasadit aplikaci na pořádný hardware - otázka pak je, kolik RAM, jaký procesor...

?

Martin Brodecký:
Sice nevím, cos tvořil, ale jsem přesvědčen, žes dva roky pracoval na špatně navržené aplikaci. 1000 tabulek si nedovedu představit ani u sebevětšího portálu. Hledej chybu tam.

Tak to asi ne. Samotná aplikace má celkem minimum tabulek, zde se bavím o tabulkách profilů - je logické, že pokud má profil podniku či uživatele svá specifika, má také svou tabulku. A pokud je profilů např. tisíc, bude i tisíc tabulek...

Samozřejmě by se to dalo nacpat do jedné, ale uvažujte, že máte např. tisíc profilů, každý profil má dvacet různých funkcí a tyto funkce mají své vlastní položky také v tisících... To mi chcete říct, že toto bych měl dát do jedné tabulky?? To by byla totální šílenost a při řešení jakékoli nekonzistence tabulky prakticky nulová šance na vyřešení ... Když má každý profil svou tabulku, je vše velmi pěkně přehledné. Databáze je samozřejmě jen jedna, hovoříme o tabulkách...

Navíc celková velikost databáze nepřesahuje 25MB....

Martin Brodecký:
Ano, data stejné povahy patří do jedné tabulky. Vytvářet tisíce tabulek je špatně, vždy si přece můžeš omezit záznamy pomocí WHERE podmínky. Ale to nesouvisí s našeptávačem.

Další věc je, že našeptávač pomocí %like% prostě musí projít všechny záznamy, kterých říkáš, že jsou tisíce tisíců.
Neměl bys pokládat dotaz při každém onkeyup, ale třeba 250 milisekund poté, co uživatel napíše znak, pokud mezitím nenapíše další.
Můžeš snížit množství dat, která se mají při našeptávání projít, například můžeš vytvořit v tabulce nový sloupec SEARCH, který bude obsahovat jen klíčová slova, která může uživatel chtít vyhledávat.
Dále můžeš vytvořit tabulku se všemi slovy, které v databázi jsou a referencemi, v které tabulce a pod jakým ID lze najít jejich výskyt. Toto řešení je dost brutální implementovat sám, proto...
... Můžeš použít hotové řešení, například ElasticSearch, což je aplikace v Javě, nějako jako databáze, která je určená k ukládání dokumentů a fulltextovému vyhledávání v nich.

Martin Brodecký:
„To mi chcete říct, že toto bych měl dát do jedné tabulky?“
Ano, přesně tak (eventuálně dvou, tří, dle povahy dat, ale ne do tisíce (a tisíců)).

25MB dat není na databázi tolik, i když je like pomalý. Chyba je právě v počtu tabulek, které procházíš. Kdybys měl jednu (dvě, tři) tabulky s těmi samými daty, žádný problém bys nyní neřešil, vše by bylo pravděpodobně nepostřehnutelně rychlé.