Administrace komentářů

Jenže, tohle nikdy nenastavíte správně.

MySQL jsem opustil po napsání této recenze dobré knihy MySQL optimalizace pro vysoký výkon.

Vysvětlím proč. Ty pluginy (engine) vypadají na první pohled jako fajn nápad. Tak jak jsi to popsal, to na papíře vypadá docela dobře. Jenže v praxi narazíš na chování typu:

- Při startu mysql serveru nenajel InnoDB (chyba v konfiguraci jeho parametrů). MySQL ovšem jede (start služby OK), do logu akorát napíše skip-innodb. Nic neindikuje chybu a co hůř, všechno funguje (zejména import obnovené zálohy). Tabulky (které jsou v záloze jako engine=innodb) se bez varování (!!!) vytvoří jako MYISAM. Příkazy jako BEGIN, COMMIT, ROLLBACK se tiše (!!!) ignorují. Data podléhají sillent corruption.

- Replikace fungují pouze s InnoDB, pouze s určitou verzí MySQL a pouze v určitém nastavení InnoDB. Jinak fungují taky, to ano. Jenže data na replice poněkud neodpovídají datům na masteru. Opět, nikde žádná chyba.

Po tomhle všem (a spoustě dalších) si řeknete, že teda dobře nastavíte InnoDB a všechno bude používat pouze tento engine. Jenže ouha, všechny diskové temporary tabulky jsou typu MYISAM. Takže fajné InnoDB, které má nastaveno 666GB paměti a jede rychle, ale jakmile se začně požadovat temporary na disku, tak je výkon zase v hajzlu. Takže začnete řešit MYISAM (kterého jste se nezbavili vs InnoDB). A to už je neřešitelné.

Takže ty engine fungují pouze tehdy, když jde o samostatné tabulky (bez referenčních vazeb, což projistotu opět umí jen InnoDB) a přistupuje k nim jeden uživatel (protože nefungují transakce a hlavně transakční izolace).

Výsledek je, že mnohem raději používám software, který dělá jen jednu věc, ale za to pořádně. To aplikační schéma, které jsi popsal, můžu krásně nahradit: *SQL jako jádro, memcached jako key-value cache a na aplikační logy třeba nějakou dokumentovou DB (podle toho, co s nimi chci dělat).

Výkon vyladím mnohem snadněji a jako bonus si můžu ty služby rozhodit na více HW.