Tamkovich.com: Телеком/VoIP блог » MySQL

MySQL: о пользе вложенных запросов

Сергей Тамкович — Sun, 28 Nov 2010 09:38:08 +0000

Не так давно, начиная с версии MySQL 4.1 – СУБД MySQL получила поддержку так называемых вложенных запросов. Большинство вложенных запросов могут быть переписаны с помощью стандартного join. Например вот такой вложенный запрос:

SELECT a, b FROM t1 WHERE c IN (SELECT d FROM t2);

Можно безболезненно заменить эквивалентом без вложенного запроса:

SELECT t1.a, t1.b FROM t1, t2 WHERE t1.c=t2.d;

Однако, существует масса задач, решение которых без использования вложенных запросов – крайне уродливо или же его нет вообще. Приведу пример, близкий любителям Asterisk.

Задача не особо экзотическая – имея таблицу CDR с записями о состоявшихся звонках оценить загрузку сотрудников отвечающих на телефон, по дням недели. Сотрудники, чью загрузку будем оценивать, имеют внутренние номера 102 и 117. По этому, критерием отбора CDR записей будет поле dstchannel начинающиеся с ‘SIP/102′ или с ‘SIP/117′. В первую очередь, нам необходимо просуммировать звонки по дням что бы получить суточные данные о количестве и длительность звонков, делается это тривиальным запросом

SELECT DATE(calldate) AS dt, SUM(billsec)/3600 AS hours, COUNT(billsec) AS calls
FROM cdr 
WHERE calldate>'2010-10-01 00:00:00' AND calldate<'2010-11-01 00:00:00' 
AND (dstchannel LIKE 'SIP/102%' OR dstchannel LIKE 'SIP/117%') 
GROUP BY DATE(calldate);

В этом запросе будут выбраны: дата, длительность звонков преведенная к часам и количество звонков за указазнную дату. Суть вложенных SQL запросов, заключается в том, что результаты одного запроса можно использовать как таблицу для другого. Имея распределение звонков и их длительности по датам мы можем посчитать загрузку сотрудников по дням недели. Для этого нам понадобится функция DAYNAME() которая вычесляет название дня недели по дате. В результате мы имеем SQL запрос который с помощью функции AVG() считает среднее количество и среднюю длительность звонков за сутки, группируя данные по дням недели:

SELECT DAYNAME(dt), AVG(hours), AVG(calls) 
FROM (
    SELECT DATE(calldate) AS dt, SUM(billsec)/3600 AS hours, COUNT(billsec) AS calls 
    FROM cdr
    WHERE calldate>'2010-10-01 00:00:00' AND calldate<'2010-11-01 00:00:00' 
    AND (dstchannel LIKE 'SIP/102%' OR dstchannel LIKE 'SIP/117%') 
    GROUP BY DATE(calldate)
) AS t1 
GROUP BY DAYNAME(dt);

На выходе получаем интересующий нас результат:

+-------------+------------+------------+
| DAYNAME(dt) | AVG(hours) | AVG(calls) |
+-------------+------------+------------+
| Friday      | 2.89125000 |    96.0000 |
| Monday      | 4.06492500 |   139.0000 |
| Saturday    | 4.36542500 |   170.5000 |
| Sunday      | 2.72717500 |    98.0000 |
| Thursday    | 2.80562500 |    90.5000 |
| Tuesday     | 3.93172500 |   118.2500 |
| Wednesday   | 3.01332500 |    99.7500 |
+-------------+------------+------------+

Kamailio: загружаем много данных с помощью db_mysql

Сергей Тамкович — Wed, 20 Oct 2010 09:42:38 +0000

В Kamailio/OpenSIPS, как в любом взрослом проекте, имеется некоторое количество «прокладочных» интерфейсов. Задача этих интерфейсов – унификация. Например, с помощью mem/mem.h унифицирована работа с памятью. Интерфейс предоставляет набор вызовов pkg_malloc/pkg_free для работы с обычной памятью и shm_malloc/shm_free для работы с разделяемой памятью. Благодаря унификации работы с памятью – Kamailio портирован на множество различных платформ. Другим интерфейсом-прокладкой является интерфейс работы с базами данных DB API. Базовая работа с этим интерфейсом хорошо описана в KAMAILIO (OPENSER) Devel Guide.

Классическая операция получения данных из MySQL выглядит следующим образом:

snprintf(sqlcmd, sizeof(sqlcmd) - 1,
        "select n.id,n.name,n.ip,n.port,n.capacity,COUNT(c.node) 
         from cluster_nodes n left join active_calls c on (n.name=c.node) 
         where online=1 group by n.name");
sql_cmd.s = sqlcmd;
sql_cmd.len = strlen(sqlcmd);
LOG(L_DBG, "Trying to execute SQL: '%s'\n", sqlcmd);
fres = dbf.raw_query(db_handle, &sql_cmd, &res);
if (fres == 0) {
        total = RES_ROW_N(res);
        if (total > 0) {
                for(i = 0; i < total; i++) {
                        node = shm_malloc(sizeof(struct ci_li_node));
                        if (node == NULL) {
                                LM_ERR("Could not allocate shared memory\n");
                                return -1;
                        }
                        node->id = RES_ROWS(res)[i].values[0].val.int_val;
                        node->calls_init = RES_ROWS(res)[i].values[5].val.int_val;
                        node->calls_current = node->calls_init;
                        node->calls_max = RES_ROWS(res)[i].values[4].val.int_val;
                        node->port = RES_ROWS(res)[i].values[3].val.int_val;
                        snprintf(node->name, sizeof(node->name), "%s", 
                                (char*)RES_ROWS(res)[i].values[1].val.str_val.s);
                        snprintf(node->ip, sizeof(node->ip), "%s", 
                                (char*)RES_ROWS(res)[i].values[2].val.str_val.s);
                        node->next = NULL;
 
                        total_max += node->calls_max;
                        if (mylist->last == NULL) {
                                mylist->last = node;
                                mylist->first = node;
                        } else {
                                mylist->last->next = node;
                                mylist->last = node;
                        }
                }
                LOG(L_DBG, "PRELOAD TOTAL: [servers] %d items = %lu bytes.\n", 
                        i, i * sizeof(struct ci_li_node));
                mylist->dt = time(NULL);
        }       
        dbf.free_result(db_handle, res);
}

Как видим из простого примера, получение данных из MySQL сводится к трём действиям:

Отправляем SQL запрос с помощью команды raw_query.
Читаем результаты с помощью макросов RES_ROW_N и RES_ROWS
Подчищаем за собой память с помощью free_result

Пока мы действуем по шаблону – всё отлично работает.

Но стоит нам захотеть чего то большего – и подход придётся менять. Например приведенным выше кодом нельзя загрузить за раз большую таблицу (тысячи записей). Прокладочные интерфейсы БД и памяти – накладываются друг на друга и возникают интересные эффекты. Дело в том, что при попытке загрузить большую таблицу целиком – db_mysql выделяет память под неё – одним куском. С другой стороны, pkg_free не освобождает память моментально, а лишь помечает её как готовую к очистке. Всё это приводит к тому, что загрузка большой таблицы срабатывает 2 раза подряд, а на третий возникает ошибка – недостаточно памяти.

Зачем загружать всю таблицу целиком – спросите вы? Вариантов может быть очень много – самый распространённый, пожалуй, – для того, что бы закешировать данные из БД. На одной СУБД далеко не уедешь, даже на такой быстрой как MySQL. Итак, что же нужно сделать для того, что бы обойти проблемы с памятью? Ответ очень простой: нужно воспользоваться вызовом fetch_result. К сожалению, применение этого вызова не расписано в KAMAILIO (OPENSER) Devel Guide, но, как известно, лучшая документация это исходный код. С практикой применения этого вызова можно ознакомиться в модулях Kamailio:

[root@sipproxy kamailio-3.0.3]# grep -l fetch_result */*/*.c
...
modules_k/dialog/dlg_db_handler.c
modules_k/drouting/dr_load.c
modules_k/htable/ht_db.c
modules_k/pdt/pdt.c
...

Вызов fetch_result позволяет указать сколько строк мы хотим поместить в память. Таким образом, вызывая fetch_result в цикле – мы обработаем все строки возвращённые базой данных по порциям. Если вы планируете использовать fetch_result самостоятельно, необходимо передать NULL в качестве указателя db_res_t** _r у функций raw_query(…) и query(…). Для наглядности, рассмотрим похожий кусок кода, написанный с использованием вызова fetch_result. Параметр ci_preload_chunk задаёт количество строк загружаемых в память за 1 вызов:

snprintf(sqlcmd, sizeof(sqlcmd) - 1,
        "select name,owner from sip where host='dynamic' and owner>0"
);
sql_cmd.s = sqlcmd;
sql_cmd.len = strlen(sqlcmd);
LOG(L_DBG, "Trying to execute SQL: '%s'\n", sqlcmd);
fres = dbf.raw_query(db_handle, &sql_cmd, NULL);
if (fres == 0) {
        LOG(L_DBG, "Trying to fetch first %d items.\n", ci_preload_chunk);
        if (dbf.fetch_result(db_handle, &res, ci_preload_chunk) < 0) {
                LM_ERR("Error while fetching result\n");
                if (res) {
                        dbf.free_result(db_handle, res);
                }
                return 0;
        }       
        total = RES_ROW_N(res);
        LOG(L_DBG, "%d first items fetched.\n", total);
        if (total > 0) {
                do {
                        for(i = 0; i < total; i++) {
                                row = RES_ROWS(res) + i;
                                u = shm_malloc(sizeof(struct ci_li_sipuser));
                                if (u == NULL) {
                                        LM_ERR("Could not allocate shared memory\n");
                                        return -1;
                                }       
                                u->sipaccount = atoi((char*)VAL_STRING(ROW_VALUES(row)));
                                u->customer = VAL_INT(ROW_VALUES(row) + 1);
                                u->next = NULL;
                                if (mylist->last == NULL) {
                                        mylist->last = u;
                                        mylist->first = u;
                                } else {
                                        mylist->last->next = u;
                                        mylist->last = u;
                                }
                                mylist->elements++;
                                cnt++;
                        }
                        if (dbf.fetch_result(db_handle, &res, ci_preload_chunk) < 0) {
                                LM_ERR("Error while fetching result\n");
                                if (res) {
                                        dbf.free_result(db_handle, res);
                                }
                                return 0;
                        }
                        total = RES_ROW_N(res);
                } while (total > 0);
                dbf.free_result(db_handle, res);
        }
}

Asterisk realtime теперь различает NULL и пустые строки

Сергей Тамкович — Sat, 02 Jan 2010 12:16:37 +0000

Новогодние каникулы – отличное время для обновления вашей системы. Есть время подумать, взвесить все «за» и «против» и внимательно накатить необходимые обновления. Не стали исключением и эти праздники.

Неприятный сюрприз ждал меня в модуле res_config_mysql из Asterisk-addons. 4 декабря, в него был добавлен сомнительный патч:

/* Encode NULL values separately from blank values, for the Realtime API */
if (row[i] == NULL) {
    row[i] = "";
} else if (ast_strlen_zero(row[i])) {
    row[i] = " ";
}

Этот гениальный код, означает, что теперь поле, имеющее значение NULL в MySQL, видно в Asterisk, как пустая строка. А пустая строка в MySQL, в Asterisk, волшебным образом превращается в строку с одним пробелом. Представьте, что все ваши пустые строки, превратились в строку с одним пробелом! Т.е. если вы, использовали пустые строки и не использовали NULL – ваши настройки больше невалидны! Проблемы вылезут на каждом углу, например вот такие ошибки, при звонке на Cisco AS5350: SIP/2.0 400 Bad Request – ‘Malformed/Missing FROM: field’. Эта ошибка вызвана тем, что пустые строки в полях fromuser и fromdomain превратились в непустые. В результате заголовок From выглядит вот так:

From: "1000" <SIP: @ >;tag=as3e28b5d2

Остаётся только гадать, как подобный патч мог быть включен в стабильную ветку Asterisk.