Баннерокрутілкі на MySQL

  1. Запити, які виконуються баннерокрутілкой
  2. Блокування таблиць в MySQL
  3. Утиліта тестування продуктивності
  4. Способи оптимізації продуктивності
  5. Використання тимчасової таблиці
  6. Використання нереляційних баз даних
  7. При розробці нових систем

Назвою "баннерокрутілкі на MySQL" озаглавлена ​​замітка, присвячена прикладам некоректного і неефективного використання сервера MySQL. Типовим прикладом системи, робота якої з MySQL часто буває неефективною, є менеджер рекламних банерів.

Як приклад було проведено аналіз програми PHP Ad Manager . Програма була обрана випадково з десятків подібних їй на sourceforge.net.

Основні можливості програми перераховані нижче:

  • Управління рекламними банерами на кількох доменах
  • Підрахунок кількості хітів (показів) і кліків
  • Зберігання статистики в MySQL
  • Онлайн-оновлення статистики

Запити, які виконуються баннерокрутілкой

Нижче наведено скорочений і спрощений перелік запитів, який виконується системою PHP Ad Manager під час кожного показу банера.

Отримання домену, для якого виконується прокручування банера

select * from domains where ...

Отримання списку рекламних блоків, які можна користувачеві на цьому домені показати

select * from ads where active = 'Y' and expiredate> 'ПОТОЧНЕ-ЧАС' and domains LIKE '% ДОМЕН%' order by lastdisplay;

Оновлення інформації про момент останнього показу цієї реклами:

update ads set lastdisplay = 'ПОТОЧНЕ-ЧАС', hits = 'КІЛЬКІСТЬ ХІТІВ' WHERE adid = 'ІДЕНТИФІКАТОР'

Запис інформації в лог

insert into adlog SET adid = 'ВД-БАНЕРА', type = 'hit', remotehost = '....', remoteaddr = '....', site = '.....', entrydate = '. ... ';

Блокування таблиць в MySQL

Для того, щоб розібратися з причинами можливих проблем, необхідно кілька більш детально висвітлити питання роботи з блокуваннями таблиць в MySQL.

Відповідно до документацією до MySQL , MySQL використовує блокування на рівні таблиць для MyISAM, і блокування на рівні рядків для таблиць InnoDB. MySQL підтримує два типи блокувань: на запис і на читання. Блокування на запис мають перевагу перед блокуваннями на читання. Це з одного боку, призводить до того, що запити на вставку / оновлення даних не "зависають" при великій кількості запитів на читання. З іншого боку, при великій кількості запитів на оновлення даних запити на читання можуть чекати своєї черги дуже довго.

Для демонстрації проблеми розглянемо два приклади. Перший приклад наведено на малюнку, представленому нижче. В цьому випадку до сервера MySQL майже одночасно приходить чотири запиту на вибірку (SELECT). Видно, що оскільки запити SELECT мають можливість одночасного виконання, час очікування результату кожного запиту фактично залежить тільки від часу виконання безпосередньо запиту.

У другому випадку схематично представлена ​​ситуація, в якій до однієї і тієї ж таблиці MySQL майже одночасно звертаються 4 запити, з яких два запити - це запити на вибірку, а інші два - запити на оновлення даних. Через те, що запити на оновлення встають в чергу на виконання відповідають життєвим запитам на вибірку, а також тому, що в MyISAM-таблиці вони не можуть виконуватися одночасно з іншими запитами, час очікування результату SELECT-а істотно збільшується.

Додатково потрібно відзначити, що якби перший запит виявився "важким" (з тривалим часом виконання), це ще більш посилило б ситуацію на другому випадку. Якби ні UPDATE, все SELECT-и б виконувалися одночасно, проте наявність одного UPDATE призводить до того, що він розбиває чергу запитів на дві: до себе і після, і SELECT-и на третьому етапі не виконаються до завершення перших двох етапів.

Оцінка кількості заблокованих запитів може бути виконана так:

mysql> SHOW STATUS LIKE 'Table%'; + ----------------------- + --------- + | Variable_name | Value | + ----------------------- + --------- + | Table_locks_immediate | 1151552 | | Table_locks_waited | 15324 | + ----------------------- + --------- +

Перший рядок таблиці виводить кількість запитів на блокування, які були задоволені відразу ж, а другий рядок - кількість запитів, яким довелося чекати перед отриманням необхідного доступу до таблиці.

Утиліта тестування продуктивності

Для тестування продуктивності можна скористатися програмою mysqlslap , Яка входить до складу MySQL 5.1.4 і вище (для lenny доступний в репозиторії dotdeb ).

Способи оптимізації продуктивності

Зниження пріоритету UPDATE

З наведеного вище опису видно, що проблеми виникають в тому числі і з-за того, що пріоритет операцій UPDATE вище пріоритету операцій на вибірку даних. Просте рішення, яке, ймовірно, тимчасово допоможе знизити гостроту проблеми полягає в тому, щоб використовувати замість запиту UPDATE запит UPDATE LOW_PRIORITY. Детальний опис синтаксису команди є в офіційної документації

Використання тимчасової таблиці

У ситуації великої кількості запитів INSERT, які можуть блокувати запити SELECT, розробники MySQL рекомендують використовувати тимчасову таблицю, дані з якої можуть переноситися в основну з певною періодичністю:

mysql> LOCK TABLES real_table WRITE, temp_table WRITE; mysql> INSERT INTO real_table SELECT * FROM temp_table; mysql> DELETE FROM temp_table; mysql> UNLOCK TABLES;

Використання нереляційних баз даних

Нереляційні бази даних (по крайней мере, за заявами їх розробників) більшою мірою підходять для роботи з інформацією в режимі "кількість оновлень можна порівняти з кількістю вибірок", ніж MySQL. Як приклад для такого використання може підійти mongodb .

mongodb вміє виконувати дешеві операції оновлення "in-place" (инкрементирование лічильників і т.п.) без реальної передачі даних по мережі, а також має режим вставки "upsert" (оновити об'єкт, або створити, якщо такий об'єкт ще не знайдене). За подробностяім по використанню цих команд найкраще звернутися до документації .

Нижче наведені два посилання на статті в блозі MongoDB (на англ.):

При розробці нових систем

При розробці нових систем намагайтеся уникати такої архітектури, при якій кількість запитів на оновлення даних можна порівняти з кількістю запитів SELECT. Якщо це неможливо, постарайтеся максимально рознести ці операції в часі, або використовувати інші прийоми, описані вище.

Разделы

» Ваз

» Двигатель

» Не заводится

» Неисправности

» Обзор

» Новости


Календарь

«    Август 2017    »
ПнВтСрЧтПтСбВс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 

Архив

О сайте

Затраты на выполнение норм токсичности автомобилей в США на период до 1974 г.-1975 г произошли существенные изменения. Прежде всего следует отметить изменение характера большинства работ по электромобилям: работы в подавляющем большинстве стали носить чисто утилитарный характер. Большинство созданных в начале 70х годов электромобилей поступили в опытную эксплуатацию. Выпуск электромобилей в размере нескольких десятков штук стал обычным не только для Англии, но и для США, ФРГ, Франции.

ПОПУЛЯРНОЕ

РЕКЛАМА

www.school4mama.ru © 2016. Запчасти для автомобилей Шкода