MySQL Trigger performance
6 отговора
0 прегледа
MySQL Trigger performance
Привет на всички.
Имам следния казус и бих помолил за някой друг съвет.
Уеб апликация, MySQL 5.0 .
Имам информационен обект, който се образува от данни, разпръснати в колко 7-8 табели, всяка с между 100 000 и 600 000 реда. Целта е бързо четене на информацията, по възможност и бърз запис/промяна.
Едно от решенията, които обмислям е създаване на една ненормализирана табела, където да се съхраняват най-важните данни от всичи останали, което би ми позволило достъп с единичен селект (разбира се за сметка на редундантно съхранение на информация и повече памет).
При това положение, промяна в ненормализираната табела трябва да се отчете и в останалите 7-8.
Оттази гледна точка удачно ли е ъпдейтите към останалите 7-8 табели да се сложат в триггер или да се изпълняват поеденично от апликацията?
Имам следния казус и бих помолил за някой друг съвет.
Уеб апликация, MySQL 5.0 .
Имам информационен обект, който се образува от данни, разпръснати в колко 7-8 табели, всяка с между 100 000 и 600 000 реда. Целта е бързо четене на информацията, по възможност и бърз запис/промяна.
Едно от решенията, които обмислям е създаване на една ненормализирана табела, където да се съхраняват най-важните данни от всичи останали, което би ми позволило достъп с единичен селект (разбира се за сметка на редундантно съхранение на информация и повече памет).
При това положение, промяна в ненормализираната табела трябва да се отчете и в останалите 7-8.
Оттази гледна точка удачно ли е ъпдейтите към останалите 7-8 табели да се сложат в триггер или да се изпълняват поеденично от апликацията?
Re: MySQL Trigger performance
Без значение е дали при промяна в необикновената маса ще разчитате на спусък да разхвърля промените из греблата на останалите маси или поединично ще ги променяте масите от заявлението.
cheers,
</wqw>
Речник на безумните думи:
table = маса
denormalized = необикновена
row = гребло
trigger = спусък
application = заявление
[линк]
cheers,
</wqw>
Речник на безумните думи:
table = маса
denormalized = необикновена
row = гребло
trigger = спусък
application = заявление
[линк]
Re: MySQL Trigger performance
Имай предвид че ако в ненормализираната таблица трябва да търсиш по фул текст индекс и да сортираш по дадена колона ще изгориш. Това са 2 различни типа индекси и не могат да се мърждант, дб-то ще избере фул текст индекса винаги и предполагам ще имаш дистинкт тогажа ще се появи тмп файл + файл сорт в експлейн-а което бави.
Според мен просто трябва да направиш инсертите от кода. И когато е нужен апдейт да апдаеитваш отделнтие таблици като се испълнява тригер върху смесената. А не обратното както го мислиш ти.
Кажи какви са енжините на таблците и какви сърчове и инсерти и апдейти ще има. И колко често ще има делете.
Според мен просто трябва да направиш инсертите от кода. И когато е нужен апдейт да апдаеитваш отделнтие таблици като се испълнява тригер върху смесената. А не обратното както го мислиш ти.
Кажи какви са енжините на таблците и какви сърчове и инсерти и апдейти ще има. И колко често ще има делете.
Re: MySQL Trigger performance
"Според мен просто трябва да направиш инсертите от кода. И когато е нужен апдейт да апдаеитваш отделнтие таблици като се испълнява тригер върху смесената. А не обратното както го мислиш ти. " - Абсолютно. До същото заключение стигнах днес. Най-сигурният начин да дъража данните в конзистентно състояние, още повече, че други функции също могат да ъпдейтнат въпросните 7-8 табели.
Всички 'подобекти' в смесената табела(маса, да ползвам речника предоставен от wqw
) ще бъдат представлявани и от съответно ID, по което ще става сърча. Реално търсенето/филтрирането е друга история, но от нея излизат въпросните ID-та.
При инсъртване на нов рекорд, първо ще се създава 'празен' сет в смесената таблица, който в последствие ще се ъпдейтва от тригерите.
Табелите са InnoDB.
Всички 'подобекти' в смесената табела(маса, да ползвам речника предоставен от wqw
) ще бъдат представлявани и от съответно ID, по което ще става сърча. Реално търсенето/филтрирането е друга история, но от нея излизат въпросните ID-та.
При инсъртване на нов рекорд, първо ще се създава 'празен' сет в смесената таблица, който в последствие ще се ъпдейтва от тригерите.
Табелите са InnoDB.
Re: MySQL Trigger performance
Не че, е чак толкова важно ама за близо 25-те години откакто използвам бази данни навсякъде установеният термин е Таблица.
Това е и логичният превод на английската дума "table", която има много значения - маса, равнина, плоскост, повърхност, подставка ...
В какъв контекст българската дума "табела" отговаря на въпросната структура от данни (която в теорията се нарича Релация между другото)?
salle.online.bg/sig
Това е и логичният превод на английската дума "table", която има много значения - маса, равнина, плоскост, повърхност, подставка ...
В какъв контекст българската дума "табела" отговаря на въпросната структура от данни (която в теорията се нарича Релация между другото)?
salle.online.bg/sig
Re: MySQL Trigger performance
По основния въпрос за денормализираната таблица:
Първо тя би могла да е VIEW с което се решава проблема за по-прости SELECT заявки. Промените се правят по оригиналните 7-8 таблици.
Недостатъкът в случая е, че може заявката да е много бавна и съответно всеки SELECT ще отнема много време.
Второто решение е с емулация на "материализиран изглед" какъвто MySQL не поддържа т.е. "истинска" таблица която се обновява в реално време от тригери в съответните основни таблици.
И третото решение е това до което ти си стигнал - основна таблица с тригери която да променя в реално време останалите 7-8. Въпросът тогава е защо изобщо ти трябват останалите таблици?
И трите варианта си имат предимства и недостатъци. Всичко опира до това кое се изпълнява по-често. Заявките или промените?
Ако имаш примерно една SELECT заявка на 10000 промени (INSERT/UPDATE/DELETE) вариантът с VIEW е за предпочитане. Да SELECT-ът ще е по-бавен, но няма да губиш време при промените.
Ако съотношението е обратното — много често четене, рядко писане тогава тригерите са за предпочитане.
Изобщо както винаги отговорът е Зависи
Пробвай на тестов сървър.
salle.online.bg/sig
Първо тя би могла да е VIEW с което се решава проблема за по-прости SELECT заявки. Промените се правят по оригиналните 7-8 таблици.
Недостатъкът в случая е, че може заявката да е много бавна и съответно всеки SELECT ще отнема много време.
Второто решение е с емулация на "материализиран изглед" какъвто MySQL не поддържа т.е. "истинска" таблица която се обновява в реално време от тригери в съответните основни таблици.
И третото решение е това до което ти си стигнал - основна таблица с тригери която да променя в реално време останалите 7-8. Въпросът тогава е защо изобщо ти трябват останалите таблици?
И трите варианта си имат предимства и недостатъци. Всичко опира до това кое се изпълнява по-често. Заявките или промените?
Ако имаш примерно една SELECT заявка на 10000 промени (INSERT/UPDATE/DELETE) вариантът с VIEW е за предпочитане. Да SELECT-ът ще е по-бавен, но няма да губиш време при промените.
Ако съотношението е обратното — много често четене, рядко писане тогава тригерите са за предпочитане.
Изобщо както винаги отговорът е Зависи
Пробвай на тестов сървър.
salle.online.bg/sig
Редактирано от salle на
Re: MySQL Trigger performance
Хах, приемам забележките за ползваните изразни средства - таблици .
Идеята с VIEW-та по-опитни от мен колеги, с които също се консултирах, сметнаха за не много подходяща, тъй като били сравнително бавни.
За сега се спирам на вариант с ненормализирана таблица, която да се ъпдейтва от тригери в основните, накъдето пък се насочва информацията при запис/промяна. При нов запис бая тригер стават, това всъщност е нещото, което ме притеснява. Има много зависимости и изчисления, които реално бих могъл по-лесно да имплементирам в апликацията. Отдруга страна пък с тригер спестявам няколко request-а. При ъпдейт пък има голяма вероятност само част от табелите да се променят, което пък ще задейства само част от тригерите... както и да е, да не се отплесвам.
Другият проблем е, че в общи линии, колкото ще се чете, толкова и ще се записва/променя - много и непрекъснато.
Дам, това правя тази седмица, тествам възможни варианти.
.
Идеята с VIEW-та по-опитни от мен колеги, с които също се консултирах, сметнаха за не много подходяща, тъй като били сравнително бавни.
За сега се спирам на вариант с ненормализирана таблица, която да се ъпдейтва от тригери в основните, накъдето пък се насочва информацията при запис/промяна. При нов запис бая тригер стават, това всъщност е нещото, което ме притеснява. Има много зависимости и изчисления, които реално бих могъл по-лесно да имплементирам в апликацията. Отдруга страна пък с тригер спестявам няколко request-а. При ъпдейт пък има голяма вероятност само част от табелите да се променят, което пък ще задейства само част от тригерите... както и да е, да не се отплесвам.
Другият проблем е, че в общи линии, колкото ще се чете, толкова и ще се записва/променя - много и непрекъснато.
Дам, това правя тази седмица, тествам възможни варианти.