Подход к решению математических задач Д. Полья.

Читая «Совершенный код» Стива Макконнелла нашел заметку о подходе к решению математических задач Д. Полья. Данный подох можно использовать при проектировании ПО.

1. Понимание постановки задачи.

Нужно ясно понять задачу. Что неизвестно? Что дано? В чем состоит условие? Возможно ли удовлетворить условию? Достаточно ли условие для определения неизвестного?

Сделайте чертеж. Введите подходяще обозначения. Разделите условие на части. Постарайтесь записать их.

2. Составление плана решения.

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

Не встречалась ли вам раньше эта задача? Хотя бы несколько в иной форме? Известна ли вам какая-нибудь родственная задача? Не знаете ли  теоремы, которая могла бы оказаться полезной?

Рассмотрите неизвестное! И постарайтесь вспомнить знакомую задачу с тем де или подобным неизвестным. Вот задача, родственная данной и уже решенная. Нельзя ли воспользоваться ею? Нельзя ли применить её результат? Нельзя ли использовать метод её решения? Не следует ли ввести какой-нибудь вспомогательный элемент, что бы стало возможно воспользоваться прежней задачей?

Нельзя ли иначе сформулировать задачу? Еще иначе? Вернитесь к определениям.

Если не удается решить данную задачу, попытайтесь сначала решить сходную. Нельзя ли придумать более доступную сходную задачу? Более общую? Более частную? Аналогичную задачу? Нельзя ли решить часть задачи? Сохраните только часть условия, отбросив остальную часть: насколько определенным окажется тогда неизвестное, как оно может меняться? Нельзя ли извлечь что-то полезное из данных? Нельзя ли придумать другие данные, из которых можно было бы определить неизвестное? Нельзя ли изменить неизвестное, или данные, или, если необходимо, и то и другое так, что бы новое неизвестное и новые данные оказались ближе друг к другу?

Все ли данные вами использованы? Все ли условия? Приняты ли вами во внимание все существующие понятия, содержащиеся в задаче?

3. Осуществление плана.

Нужно осуществить план решения. Осуществляя план решения, контролируйте каждый свой шаг. Ясно ли вам, что предпринятый вами шаг правилен? Сумеете ли доказать, что он правилен?

4. Взгляд назад.

Нужно изучить найденное решение. Нельзя ли проверить результат? Нельзя ли проверить ход решения? Нельзя ли получить тот де результат иначе? Нельзя ли усмотреть его с одного взгляда? Нельзя ли в какой-нибудь другой задаче использовать полученный результат или метод решения?

Схема базы данных, для системы мониторинга

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

Какие функциональные требования относятся к системе мониторинга? Вот некоторая часть этих требований:

  • сбор измерений;
  • обработка измерений и вычисление показателей производительности, эффективности и т.д.;
  • информирование о нарушениях показателей.

data_modelУчаствующие сущности:

  • time_intervals таблица 15 минутных временных интервалов. Определяет период за который производилось наблюдение и за который поступили данные в систему;
  • qosraw.data_snmp таблица соответствующая способу получения измерений или по типу измерений. В данном случае SNMP, но может быть Netflow, CLI(Command Line Interface), ADSL и т.д. Еще это мастер таблица в терминах PostgreSQL;
  • qosraw.data_snmp_yyyy_MM_dd подчиненная таблица в терминах PostgreSQL.

time_intevals

Очень удобно временному интервалу задавать числовой идентификатор, во-первых это удобно, чем оперировать датами, во-вторых происходит привязка данных, рассчитанных показателей к конкретной временной точки, пример такой связи изображен на схеме.

Что дает нам такая связь? Имея ссылочную целостность в СУБД удалив временной интервал, мы удаляем все измерения и рассчитанные показатели за этот период времени.

qosraw.data_snmp

Таблицы с именем qosraw.data_XXX предназначены для хранения измерений по их происхождениям. В data_snmp хранятся метрики получаемые путем опроса объектов наблюдения по SNMP.

Описание полей:

  • time_id идентификатор временного интервала;
  • mid — measurement id идентификатор измерения: количество переданных пакетов, ошибок, нагрузка процессора, температура лазера и т.д.;
  • critid идентификатор критерия. Когда мы хотим отслеживать какую-то характеристику конкретного объекта, мы вешаем критерий и связываем его с типом измерения. К примеру ошибки на сетевом интерфейсе является типом измерения, может измерятся в пакетах или в % от обработанных пактов. В данном типу измерению «ошибки», соответствуют два измерения: ошибки в пакетах и ошибки в %;
  • value само значение.

Эта таблица в PostgreSQL(именно эту СУБД мы используем) является мастер таблицей при реализации партицирования таблиц и поэтому не содержит самих данных.

Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям. Партиционированные или секционированные таблицы призваны улучшить производительность и управляемость базами данных.

qosraw.data_snmp_yyyy_MM_dd

Подчиненная таблица. Собственно она и содержит сами данные. Сделано это для повышение производительности. В одной тестовой зоне у заказчика происходит мониторинг 130 сетевых устройств, каждые 15 минут кладутся порядка 46 000 измерений, в такой дневной таблице получается порядка 4-5 миллионов измерений. Так что если все держать в одной таблице, что через месяц система начнет проседать.

Заключение

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

Для производительности системы мы агрегируем пятнадцатиминутные интервалы в часовые, дневные, недельные и месячные интервалы времени, для истории и дальнейшей аналитики и построения отчетов.

Обновление PostgreSQL с 8.4 до 9.3

За неимением DBA в штате, настройкой и оптимизацией PostgreSQL приходится заниматься самому.

После прочтения книги Работа с PostgreSQL, настройка и масштабирование, заинтересовался что и в каком объеме находится в буферах постгреса. Взял запрос из книги, запустил, и получил ошибки, что нет какой-то функции. Тут я понял, что пришло время, для перехода с не поддерживаемой версии 8.4, до последней 9.3.

Версию 9.3 для Debian 6 была взята с репозитория postgresql.org.

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

Прежде чем заливать дамп, следует не забыть следующее:

  • если использовались расширения(pg_buffercache, pgperl и т.д.) для версии 8.4, следует установить эти же расширения для 9.3, т.к. в дампе присутствуют инструкции по использование этих расширений;
  • если используются триггеры или функции написанные на С/С++, то их следует обновить.