Организация хранения хронологических данных в базах данных систем мониторинга и прогнозирования
Обеспечение оптимизации часто выполняемых типовых запросов. Построение математических моделей их организации и способов хранения хронологических данных в системах мониторинга и прогнозирования. Методика разделения массивов данных в различные таблицы.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | статья |
| Язык | русский |
| Дата добавления | 29.04.2017 |
| Размер файла | 21,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
ОРГАНИЗАЦИЯ ХРАНЕНИЯ ХРОНОЛОГИЧЕСКИХ ДАННЫХ В БАЗАХ ДАННЫХ СИСТЕМ МОНИТОРИНГА И ПРОГНОЗИРОВАНИЯ
Фишер Антон Владиславович, аспирант
ООО «СофтПро», Краснодар, Россия
Дьяченко Роман Александрович, к.т.н
Кубанский государственный технологический университет, Краснодар, Россия
Лоба Инна Сергеевна, аспирант
Армавирский государственный педагогический университет, Краснодар, Россия
1. Постановка задачи
В процессе проектирования информационных систем сбора информации, мониторинга и прогнозирования возникает проблема организации хранения хронологических данных, где показания, полученные с датчиков необходимо сохранить, дополнив информацией о времени их поступления. В большинстве случаев для решения указанной проблемы используются различные приемы при проектировании базы данных.
С течением времени могут возникнуть проблемы снижения быстродействия информационной системы по причине большого количества хронологических данных (например, может увеличиться время выполнения запросов, использующих сортировку). По этой причине задача рациональной организации хранения хронологических данных с обеспечением допустимого уровня быстродействия информационной системы является актуальной. Целью данной работы является поиск наилучшего способа хранения хронологических данных среди типизированных решений.
2. Варианты решения
Для формализации поставленной задачи далее будем считать, что данные поступающие в систему мониторинга и прогнозирования представляют набор пар “значение - дата создания”.
Возможными решениями задачи хранения хронологической информации являются:
Ѓ Использование одной таблицы (вся информация хранится в одной таблице);
Ѓ Разбиение таблицы на архивные периоды с использованием дополнительного поля;
Для представления реляционной базы данных используется математическая модель.
Первый вариант решения имеет вид:
S1=<A1:D1;A2:D2;A3:D3;>, (1)
где A1 - атрибут “уникальный номер”,
D1 - множество целых чисел,
A2 - атрибут “значение”,
D2 - множество действительных чисел,
A3 - атрибут “дата создания”,
D3 - домен “дата-время”.
Второй вариант решения:
S1=<A1:D1;A2:D2;A3:D3;A4:D4;>, (2)
где A1 - атрибут “уникальный номер”,
D1 - множество целых чисел,
A2 - атрибут “значение”,
D2 - множество действительных чисел,
A3 - атрибут “дата создания”,
D3 - домен “дата-время”,
A4 - атрибут “период”,
D4 - множество целых чисел.
Как видно из описанных моделей с накоплением данных будет увеличиваться объем таблицы, следовательно, для их обработки потребуется больше ресурсов.
Во втором варианте дополнительно вводится поле “период”, что позволяет упростить запросы выборок наборов данных по определенному периоду, используя индекс по этому атрибуту. В качестве периода используется наиболее пригодный период для построения будущих запросов к базе.
Оба описанных варианта имеют общий недостаток - это растущий размер одной используемой таблицы. Что создает проблемы при работе с ней, кроме того это создает дополнительные проблемы при создании полных резервных копий.
Тривиальным способом хранения хронологических данных является использование одной таблицы. Но в большинстве случаев данные полученные от системы мониторинга обрабатываются определенными периодами, на основе чего возможно оптимизировать способ их хранения. В качестве одного из решений по организации и хранению хронологических данных можно предложить вариант использования объектно-ориентированных возможностей современных баз данных - “разбиение” и “наследование” таблиц.
Разбиение таблиц можно реализовать с помощью использования встроенного механизма наследования и специальных триггеров.
Механизм наследования таблиц позволяет создавать копии таблицы-шаблона одинаковые по структуре. Таблицы-наследники могут иметь общий первичный ключ (в СУБД Postgresql реализуется с помощью последовательностей), что гарантирует совокупную уникальность записей хранимых в них. Наследование в СУБД позволяет выполнять запросы как к отдельной таблице-наследнику, при этом получая данные содержащиеся непосредственно в ней, так и к таблице-шаблону. При обращении к таблице-шаблону будут обработаны данные содержащиеся во всех таблицах-наследниках. Следовательно, если разделить таблицы таким образом, что для наиболее частых запросов выполняемых в вычислительной системе будет достаточным обратиться к одной таблице-наследнику, можно затратить меньшее количество ресурсов, следовательно, получит выигрыш производительности всей системы в целом.
Для организации распределения данных по таблицам-потомкам при вставке используются триггеры (в Postgresql триггерные функции). Все запросы вставки данных используют таблицу-шаблон, а триггерные функции в соответствии с принятым периодом разделения данных записывают данные в нужную таблицу-потомка. По истечению периода эти функции обновляются, меняя при этом правило записи. Модель имеет вид (1).
В качестве примера реализации рассмотрим случай простого разделения данных по временным периодам, где длина периода равна календарному месяцу.
3. Техническая реализация по этапам
3.1 Этап 1. Создание таблиц (шаблонов)
На первом этапе создается таблица-шаблон согласно модели 3 (реализация на Postgresql см. листинг 1):
CREATE TABLE "table_c"
(
"id" bigserial NOT NULL,
"value" double precision NOT NULL,
"time" timestamp with time zone NOT NULL DEFAULT now(),
CONSTRAINT "table_c_pkey" PRIMARY KEY ("id")
);
Листинг 1. Пример скрипта создающего таблицу шаблон.
3.2 Этап 2. Создание таблиц наследников
На основе таблицы созданной скриптом (листинг 1) можно создавать таблицы-наследники. Так как ограничение первичного ключа (table_c_1_pkey) не наследуется, то его необходимо явно указать в скрипте создания таблицы (листинг 2).
CREATE TABLE table_c_1
(
CONSTRAINT table_c_1_pkey PRIMARY KEY (id)
)
INHERITS (table_c);
Листинг 2. Пример скрипта, создающего таблицу-наследника.
Для обеспечения целостности первичного ключа в СУБД Postgresql применяются последовательности.
Последовательность объектов (также называется последовательностью генераторов или просто последовательностью) являются специальной однорядной таблицей, созданной с помощью команды CREATE SEQUENCE. Последовательность объектов обычно используется для генерации уникальных идентификаторов для строк таблицы. Например, если в создаваемой таблице будет указанно поле с типом serial (bigserial), то последовательность будет создана автоматически (вида ИмяТаблицы_ИмяПоля_seq). При вставке данных в эту таблицу, каждая новая запись будет уникальное значение из последовательности возвращаемое функцией nextval('ИмяПоследовательности'). Для просмотра текущего значения последовательности можно использовать код листинга 3 (в приведенном запросе используется встроенная функция получения значения последовательности).
SELECT currval(`ИмяПоследовательности');
Листинг 3. Пример скрипта получения текущего значения последовательности.
В таблице созданной в листинге 2 все наследуемые таблицы будут использовать одну последовательность в качестве первичного ключа (table_c_id_seq), что гарантирует сквозную уникальность его значения (каждая таблица-наследник хранит уникальные данные).
3.3 Этап 3. Реализация функции создания нового периода
Данная функция необходима для создания нового периода (новой таблицы-наследника и создания триггерной функции отвечающей за перенаправление записи данных в новую таблицу, при этом запись в таблицу предыдущего периода блокируется).
Пример функции представлен на листинге 4.
CREATE OR REPLACE FUNCTION create_period()
RETURNS void AS
$BODY$
DECLARE
now_date Date;
now_year char(4);
now_month char(2);
BEGIN
RAISE NOTICE 'create_period(): start';
now_date = now();
now_year := to_char(now_date, 'YYYY');
now_month := to_char(now_date, 'MM');
-- create new table
RAISE NOTICE 'create_period(): create new table';
EXECUTE '
CREATE TABLE "table_c_' || now_year || '_' || now_month || '" '
|| '(PRIMARY KEY ("id")) '
|| 'INHERITS ("table_c")';
-- create trigger function
RAISE NOTICE 'create_period(): create trigger function';
EXECUTE '
CREATE OR REPLACE FUNCTION table_c_i_trigger_function() '
|| 'RETURNS TRIGGER AS $$
BEGIN
INSERT INTO "table_c_' || now_year || '_' || now_month || '" VALUES (NEW.*);
RETURN NULL;
END; '
|| '$$ LANGUAGE plpgsql;';
RAISE NOTICE 'create_period(): end';
END;
$BODY$
LANGUAGE plpgsql;
Листинг 4. Скрипт, реализующий функцию создания нового периода
3.4 Этап 4. Реализация триггера на событие INSERT
Созданную функцию необходимо вызвать для создания первого периода, после чего будет создана триггерная функция, которую нужно вызвать в триггере таблицы-родителя, пример вызова представлен в листинге 5. хранение хронологический данные мониторинг
SELECT create_period();
CREATE TRIGGER table_c_i_trigger BEFORE INSERT
ON "table_c" FOR EACH ROW EXECUTE PROCEDURE table_c_i_trigger_function();
Листинг 5. Скрипт вызова функции создания первого периода и создания триггера на событие INSERT
4. Результаты работы
1. Вставка данных в первый созданный период (используется таблица table_c):
# INSERT INTO table_c(value) VALUES (1),(2),(3);
# SELECT * FROM table_c;
Результат представлен в таблице 1.
Таблица 1 - данные первого периода, таблица table_c
|
id |
value |
time |
|
|
1 |
1 |
2011-09-11 21:06:03.621682+04 |
|
|
2 |
2 |
2011-09-11 21:06:04.621682+04 |
|
|
3 |
3 |
2011-09-11 21:06:05.621682+04 |
2. Создание второго периода:
# SELECT create_period();
Вставка данных во второй период (используется таблица table_c):
# INSERT INTO table_c(value) VALUES (4),(5),(6);
# SELECT * FROM table_c;
Результат представлен в таблице 2.
Таблица 2 - данные первого периода, таблица table_c
|
id |
value |
time |
|
|
1 |
1 |
2011-09-11 21:06:03.621682+04 |
|
|
2 |
2 |
2011-09-11 21:06:04.621682+04 |
|
|
3 |
3 |
2011-09-11 21:06:05.621682+04 |
|
|
4 |
4 |
2011-09-11 21:06:06.621682+04 |
|
|
5 |
5 |
2011-09-11 21:06:07.621682+04 |
|
|
6 |
6 |
2011-09-11 21:06:08.621682+04 |
В таблицах наследниках данные распределены следующим образом:
# SELECT * FROM table_c_2011_09;
Результат представлен в таблице 3.
Таблица 3 - данные хранящиеся в таблица table_c_2011_09
|
id |
value |
time |
|
|
1 |
1 |
2011-09-11 21:06:03.621682+04 |
|
|
2 |
2 |
2011-09-11 21:06:04.621682+04 |
|
|
3 |
3 |
2011-09-11 21:06:05.621682+04 |
# SELECT * FROM table_c_2011_10;
Результат представлен в таблице 4.
Таблица 4 - данные хранящиеся в таблица table_c_2011_10
|
id |
value |
time |
|
|
4 |
4 |
2011-09-11 21:06:06.621682+04 |
|
|
5 |
5 |
2011-09-11 21:06:07.621682+04 |
|
|
6 |
6 |
2011-09-11 21:06:08.621682+04 |
Заключение
В результате исследования были построены математические модели способов хранения хронологических данных, а также предложено решение организации хранения хронологических данных по средствам использования методов разделения массивов данных в различные таблицы. Что позволило оптимизировать типовые запросы, наиболее часто выполняемые в системах мониторинга и прогнозирования.
Литература
1. Дж. Уорсли, Дж. Дрейк, PostgreSQL. Для профессионалов. - Питер, 2003. - 496 стр.
2. www.postgresql.org [электронный ресурс]
3. Simon Riggs, Hannu Krosing, PostgreSQL 9 Admin Cookbook. - PacktPublishing, 2010. - 360 стр.
Приложение
Листинг 6. Пример скрипта для создания одной таблицы с хронологическими данными.
CREATE TABLE "table_a"
(
"id" bigserial NOT NULL,
"value" double precision NOT NULL,
"time" timestamp with time zone NOT NULL DEFAULT now(),
CONSTRAINT "table_a_pkey" PRIMARY KEY ("id")
);
Листинг 7. Пример скрипта для создания таблицы с разбиением на архивные периоды и использованием дополнительного поля. Дополнительное поле хранит порядковый номер периода разбиения.
CREATE TABLE "table_b"
(
"id" bigserial NOT NULL,
"value" double precision NOT NULL,
"time" timestamp with time zone NOT NULL DEFAULT now(),
"period" int NOT NULL,
CONSTRAINT "table_b_pkey" PRIMARY KEY ("id")
);
Аннотации
ОРГАНИЗАЦИЯ ХРАНЕНИЯ ХРОНОЛОГИЧЕСКИХ ДАННЫХ В БАЗАХ ДАННЫХ СИСТЕМ МОНИТОРИНГА И ПРОГНОЗИРОВАНИЯ
Фишер Антон Владиславович, аспирант
ООО «СофтПро», Краснодар, Россия
Дьяченко Роман Александрович, к.т.н
Кубанский государственный технологический университет, Краснодар, Россия
Лоба Инна Сергеевна, аспирант
Армавирский государственный педагогический университет, Краснодар, Россия
В статье рассматриваются различные способы хранения хронологических данных. Построены математические модели каждого из способов. В качестве одного из решения приводится методика организации партицирования данных на конкретной СУБД
Ключевые слова: БАЗА ДАННЫХ, НАСЛЕДОВАНИЕ, ПАРТИЦИРОВАНИЕ, СУБД, ТРИГГЕР, ХРОНОЛОГИЧЕСКИЕ ДАННЫЕ
STORAGE ORGANIZATION OF CHRONOLOGICAL DATA IN DATABASES OF MONITORING AND FORECASTING SYSTEMS
Fisher Anton Vladislavovich, graduate student
SoftPro, Krasnodar, Russia
Dyachenko Roman Aleksandrovich, Cand.Tech.Sci.
Kuban State Technological University, Krasnodar, Russia
Loba Inna Sergeevna, graduate student
Armavir State Pedagogical University, Krasnodar, Russia
The article discusses various ways to store chronological data. The mathematical models were constructed for each method. As one of the solutions is the method of data of organization partitioning of a particular DBMS
Keywords: DATABASE, INHERITANCE, PARTITIONING, DBMS, TRIGGER, CHRONOLOGICAL DATA
Размещено на Allbest.ru
Подобные документы
Сущности и функциональные зависимости базы данных. Атрибуты и связи. Таблицы базы данных. Построение ER-диаграммы. Организация ввода и корректировки данных. Реляционная схема базы данных. Реализация запросов, получение отчетов. Защита базы данных.
курсовая работа [2,4 M], добавлен 06.02.2016Способы мониторинга качества данных. Формирование функциональных требований к системе мониторинга консистентности данных. Документирование требований к системе мониторинга консистентности данных. Написание скриптов проверок для системы мониторинга.
дипломная работа [387,3 K], добавлен 26.08.2017Термины "логический" и "физический" как отражение различия аспектов представления данных. Методы доступа к записям в файлах. Структура систем управления базами данных. Отличительные особенности обработки данных, характерные для файловых систем и СУБД.
лекция [169,7 K], добавлен 19.08.2013Разработка программ на языке Turbo Pascal на основе использования массивов данных. Особенности хранения данных, способы объявления переменных, действия над элементами массивов, их ввод и вывод. Практическое применение одномерных и многомерных массивов.
методичка [17,8 K], добавлен 25.11.2010Построение инфологической, физической и концептуальной моделей данных, создание процедурных ограничений целостности и типичных запросов к базе. Описания занесения данных в таблицы об иерархии кафедр и факультетов, информации о расписании и лекторах.
курсовая работа [2,8 M], добавлен 30.11.2011Построение инфологической концептуальной модели предметной области. Структура базы данных Microsoft Office Access. Формы, запросы и отчеты. Создание форм, запросов и отчетов в базах данных. Схема данных физической и логической сущности в Erwin 4.0.
курсовая работа [5,1 M], добавлен 13.12.2011Определение базы данных и банков данных. Компоненты банка данных. Основные требования к технологии интегрированного хранения и обработки данных. Система управления и модели организации доступа к базам данных. Разработка приложений и администрирование.
презентация [17,1 K], добавлен 19.08.2013Методика расчета арендной платы на предприятии. Описание и документы предметной области, форматы входных и выходных документов. Построение логической модели данных, таблиц базы данных и типовых запросов. Проектирование экранных форм для ввода данных.
дипломная работа [1,2 M], добавлен 19.01.2017Организация хранения мультимедийных данных, основные виды систем управления базами данных и их характеристика. Магнитные и оптические запоминающие устройства. Файловые системы для оптических носителей. Иерархическое управление запоминающими устройствами.
презентация [93,4 K], добавлен 11.10.2013Работа с хранящейся в базах данных информацией. Язык описания данных и язык манипулирования данными. Распространение стандартизованных языков. Структурированный язык запросов SQL. Язык запросов по образцу QBE. Применение основных операторов языка.
презентация [76,2 K], добавлен 14.10.2013
