Диета за фото-маса Силван Михлеман; блог
Нашите алатки за надзор ја потврдуваат ситуацијата: Нагиос пука во мојот мобилен телефон со СМС-порака како митралез. Сивата крива што го опишува оптоварувањето на серверот во Ганглија е далеку над црвената линија. Морети, нашата алатка за мерење на времето на одговор, известува за неколку секунди за да испорача страница за обложување.
Добро позната ситуација со која се среќаваме одново и одново како и во последните шест години од нашето постоење. Постојат два начина да се справите со оваа ситуација: поголема оптимизација на хардвер или софтвер.
Додавањето хардвер е брзо и лесно решение.
ВНАТРЕШНИТЕ треба да се забрзаат
Во овој случај, ситуацијата е поинаква: погодени се фотографите кои сакаат да додадат фотографии на веб-страницата. А помалку посетителите кои бараат само фотографии. „Додај фотографии“ работи бавно. Затоа, ова се INSERT искази, а не SELECT пребарувања. Додадени се нови фотографии. Значи нови редови на базата на податоци
во прилог:
Бидејќи работиме со репликација, овие редови мора да бидат копирани на сите робови. Едно вметнување по роб. Ако додадеме повеќе сервери на кластерот, ова нема да го реши проблемот, бидејќи овие редови исто така мора да бидат додадени на овие нови сервери. Повеќе сервери не го намалуваат бројот на INSERT на кластерот. Во овој случај, хардверот нема да помогне.
Продолжуваме да гледаме: ИНСЕРТИТЕ предизвикуваат проблеми. ВНАТРЕШНИТЕ се премногу бавни. Што ги прави инсертите бавни? Што е скапо со ВЛЕЗ? Не додавање на податоците, туку пишување на индексите. Индексите се комплексни структури на податоци, дрвја Б, бинарни дрвја кои треба да се проверат за тежина секогаш кога ќе се вметне линија. Индексите се скапи.
Во случај на нашата табела со фотографии, индексите сочинуваат дури и повеќе бајти од податоците (иако нашата структура на податоци е аматерска и полна со вишок)
Непотребни колони и индекси!
Значи, започнавме со индексите на табелата за слики. Боже мој, какви индекси поставивме во својата младешка непромисленост? Практично секоја колона има индекс, иако никогаш не се користи во барање (тест со ОБЈАСИ ИЗБОР). Таму сè уште има колони кои никогаш не се прашуваат. зло!
Чешлајте преку 60.000 редови на код
Значи: Стефан и јас ја започнуваме диетата со табели со слики: Со прегледување на целиот код за обложување, ги проверувам сите повици кон табелата со слики. Кои индекси можеме да ги избришеме? Кои колони повеќе не се потребни?
Резултат: Имаме три колони и пет индекси кои не се користат. Особено задебелениот индекс со полн текст може да биде протеран во посебна табела со вертикално партиционирање. Дали е тоа причина да се биде задоволен, бидејќи најдовме толку многу простор за подобрување? Или треба да се лутиме за нашата пушка во системот?
Не е важно: Во саботата наутро во 01 часот по полноќ, Стефан ги спроведува изјавите АЛТЕР ТАБЕЛА. По два часа траење на барањето, диетата со молња е завршена. Резултатот:
Намалување на датотеката со податоци за 22%. Намалување на индексната датотека за 70%. Ова доведува до побрзи вметнувања, побрзи бекапи и побрза ТАБЕЛА ЗА ПОПРАВКА (што често е проблем со табелите MyISAM).
Вечерва ќе покаже дали на фотографите ќе им биде полесно да ги додадат фотографиите. Љубопитен сум.