База данных в реальном времени

База данных реального времени имеет два значения. Наиболее распространенное использование этого термина относится к системе баз данных , которая использует технологии потоковой передачи для обработки рабочих нагрузок, состояние которых постоянно меняется. Это отличается от традиционных баз данных, содержащих постоянные данные , в основном не подверженные влиянию времени. Применительно к потоковым технологиям обработка в реальном времени означает, что транзакция обрабатывается достаточно быстро, чтобы результат мог вернуться и немедленно принять меры. Такие базы данных в режиме реального времени полезны для помощи платформам социальных сетей в удалении фейковых новостей, камер наблюдения в магазинах, позволяющих идентифицировать потенциальных воров по их поведению/движениям и т. д.

Второе значение термина «база данных реального времени» соответствует более строгому определению реального времени, соответствующему вычислениям в реальном времени . Системы баз данных жесткого реального времени работают с операционной системой реального времени, чтобы гарантировать временную достоверность данных за счет соблюдения сроков транзакций базы данных и включают в себя механизм (например, политики планирования транзакций), позволяющий максимизировать количество успешно совершенных транзакций и минимизировать количество откатных транзакций. В то время как показателем производительности для большинства систем баз данных является пропускная способность или число транзакций в секунду, показателем производительности системы баз данных жесткого реального времени является соотношение зафиксированных и прерванных транзакций. Этот коэффициент показывает, насколько эффективна политика планирования транзакций с конечной целью соблюдения сроков в 100% случаев. Базы данных жесткого реального времени за счет соблюдения сроков не позволяют транзакциям задерживаться (превышать срок).

Обзор

Базы данных реального времени — это традиционные базы данных, которые используют расширение, предоставляющее дополнительные возможности для получения надежных ответов. Они используют временные ограничения, представляющие определенный диапазон значений, для которых действительны данные. Этот диапазон называется временной действительностью. Обычная база данных не может работать в таких условиях, поскольку несоответствия между объектами реального мира и данными, которые их представляют, слишком серьезны для простых модификаций. Эффективная система должна иметь возможность обрабатывать запросы, чувствительные ко времени, возвращать только действительные во времени данные и поддерживать планирование приоритетов. Чтобы ввести данные в записи, часто датчик или устройство ввода отслеживает состояние физической системы и обновляет базу данных новой информацией для более точного отражения физической системы. реального времени При проектировании системы базы данных следует учитывать, как представлять действительное время, как факты связаны с системой реального времени . Также подумайте, как представлять значения атрибутов в базе данных, чтобы транзакции обработки и согласованность данных не имели нарушений.

При проектировании системы важно учитывать, что система должна делать, если сроки не соблюдаются. Например, система управления воздушным движением постоянно отслеживает сотни самолетов, принимает решения о приближающихся траекториях полета и определяет порядок, в котором самолеты должны приземлиться, на основе таких данных, как количество топлива, высота и скорость. Если какая-либо информация запоздает, результат может быть разрушительным. Чтобы решить проблемы устаревших данных, отметка времени может поддерживать транзакции, предоставляя четкие ссылки на время.

Сохранение согласованности данных

Хотя система баз данных реального времени может показаться простой системой, при перегрузке возникают проблемы, когда двум или более транзакциям базы данных требуется доступ к одной и той же части базы данных. Транзакция . обычно является результатом выполнения программы, которая обращается к базе данных или изменяет ее содержимое Транзакция отличается от потока, поскольку поток допускает только операции только для чтения, а транзакции могут выполнять операции как чтения, так и записи. Это означает, что в потоке несколько пользователей могут читать один и тот же фрагмент данных, но они не могут оба его изменять. База данных должна позволять выполнять только одну транзакцию одновременно, чтобы сохранить согласованность данных . Например, если два ученика требуют занять оставшееся место для раздела класса и одновременно нажимают «Отправить», только один ученик сможет зарегистрироваться для этого.

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

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

Самый ранний срок

PT = DT — Стоимость транзакции не важна. Примером может служить группа людей, звонящих, чтобы заказать товар.

Высшая ценность

ПТ = 1/VT — Срок не важен. Некоторые транзакции должны поступать в ЦП исходя из критичности, а не справедливости. Это пример наименьшего расслабления, которое может ждать наименьшее количество времени. Если телефонные коммутаторы были перегружены, люди, позвонившие в службу 911, должны иметь приоритет.

Срок завышения стоимости

PT = DT/VT — придает равный вес сроку и значениям, основанным на расписании. Примером может служить регистрация на занятия, когда студент выбирает блок занятий, которые он хочет пройти, и нажимает кнопку «Отправить». В этом сценарии более высокие приоритеты часто имеют приоритет. Система регистрации в школах, вероятно, использует этот метод, когда сервер получает две регистрационные транзакции. Если у одного студента было 22 кредита, а у другого — 100 кредитов, приоритет будет иметь человек со 100 кредитами (планирование на основе стоимости).

Временные ограничения и сроки

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

Дополнительным способом разрешения конфликтов в системе баз данных реального времени, помимо сроков, является метод политики ожидания. Этот процесс помогает обеспечить наличие самой последней информации в системах, критичных ко времени. Эта политика позволяет избежать конфликтов, предлагая всем не запрашивающим блокам подождать, пока не будет обработан наиболее важный блок данных. Хотя исследования в лабораториях показали, что политика, основанная на сроках предоставления данных, не приводит к значительному повышению производительности, политика принудительного ожидания может повысить производительность на 50 процентов. Политика принудительного ожидания может включать ожидание обработки транзакций с более высоким приоритетом, чтобы предотвратить взаимоблокировку. Другой пример того, когда данные могут быть задержаны, — это когда срок действия блока данных скоро истечет. Политика принудительного ожидания задерживает обработку до тех пор, пока данные не будут обновлены с использованием новых входных данных. Последний метод помогает повысить точность системы и сократить количество необходимых прерываемых процессов. Как правило, полагаться на политики ожидания неоптимально.

Необходимо обсудить формирование сроков. Сроки — это ограничения для данных, которые скоро будут заменены, к которым обращается транзакция. Сроки могут быть наблюдательными или прогнозируемыми. В системе с соблюдением сроков все незавершенные транзакции проверяются, и процессор определяет, уложилась ли какая-либо из них в срок. В этом методе возникают проблемы из-за изменений, вызванных изменениями времени поиска, управлением буфером и ошибками страниц . Более стабильный способ организации сроков — прогнозный метод. Он строит график-кандидат и определяет, не пропустит ли транзакция крайний срок, указанный в графике.

Тип реакции на пропущенный срок зависит от того, является ли срок жестким, мягким или твердым. Жесткие сроки требуют, чтобы каждый пакет данных достиг места назначения до истечения срока действия пакета, а в противном случае процесс может быть потерян, что приведет к возможной проблеме. Подобные проблемы встречаются не очень часто, поскольку для определения наихудшего сценария требуется всемогущество системы, прежде чем назначать сроки. Это очень сложно сделать, и если с системой произойдет что-то неожиданное, например, небольшой аппаратный сбой, данные могут быть потеряны. При мягких или жестких сроках пропуск может привести к снижению производительности, но не к катастрофе. Мягкий дедлайн соответствует как можно большему числу дедлайнов. Однако не существует никакой гарантии, что система сможет уложиться во все сроки. Если транзакция не соответствует установленному сроку, система становится более гибкой, и важность транзакции может возрасти. Ниже приводится описание этих ответов:

Жесткий срок

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

Твердый срок

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

Мягкий дедлайн

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

Процессы с жесткими сроками прерывают транзакции, прошедшие через крайний срок, улучшая систему за счет устранения беспорядка, который необходимо обработать. Процессы могут удалять не только транзакции с истекшими сроками, но и транзакции с самыми длительными сроками, предполагая, что, достигнув процессора, они станут устаревшими. Это означает, что другие транзакции должны иметь более высокий приоритет. Кроме того, система может удалять наименее критичные транзакции. Когда я предварительно выбирал классы в период высокого трафика, поле в базе данных могло быть настолько занято запросами на регистрацию, что какое-то время было недоступно, и результатом моей транзакции было отображение отправленного SQL-запроса и сообщения там сказано, что данные в настоящее время недоступны. Эта ошибка вызвана проверкой — механизмом, проверяющим состояние правил и правила, которое произошло до него.

Целью планирования периодов и сроков является обновление транзакций, которые гарантированно завершатся до наступления крайнего срока, таким образом, чтобы рабочая нагрузка была минимальной. При работе с большими базами данных реального времени функции буферизации могут значительно повысить производительность. Буфер — это часть базы данных, которая хранится в основной памяти для сокращения времени ответа на транзакцию. Чтобы уменьшить число транзакций ввода и вывода на диске, следует выделить определенное количество буферов. Иногда мультиверсии сохраняются в буферах, когда блок данных, необходимый для транзакции, в данный момент используется. Позже в базу данных добавляются данные. Различные стратегии выделяют буферы и должны балансировать между использованием чрезмерного объема памяти и размещением в одном буфере всего, что нужно искать. Цель состоит в том, чтобы исключить время поиска и распределить ресурсы между кадрами буфера для быстрого доступа к данным. Диспетчер буферов способен при необходимости выделять больше памяти для улучшения времени отклика. Менеджер буферов может даже определить, должна ли имеющаяся у него транзакция продолжиться. Буферизация может повысить скорость работы систем реального времени.

Будущие системы баз данных

Традиционные базы данных являются постоянными, но не способны работать с динамическими данными, которые постоянно изменяются. Поэтому нужна другая система. Базы данных, работающие в режиме реального времени, можно модифицировать для повышения точности и эффективности, а также во избежание конфликтов, устанавливая крайние сроки и периоды ожидания для обеспечения временной согласованности. Системы баз данных реального времени предлагают способ мониторинга физической системы и представления ее в потоках данных в базу данных. Поток данных, как и память, со временем тускнеет. Чтобы гарантировать запись самой свежей и точной информации, существует ряд способов проверки транзакций, чтобы убедиться, что они выполняются в правильном порядке. Интернет-аукционный дом представляет собой пример быстро меняющейся базы данных.

Сейчас системы баз данных работают быстрее, чем раньше. В будущем мы можем рассчитывать на еще более быстрые системы баз данных. Хотя сейчас у нас есть более быстрые системы, усилия по сокращению промахов и опозданий по-прежнему будут полезны. Способность обрабатывать результаты своевременно и предсказуемо всегда будет важнее быстрой обработки. Неправильно применяемая быстрая обработка бесполезна для систем баз данных реального времени. Транзакции, которые выполняются быстрее, иногда блокируются таким образом, что их приходится прерывать и перезапускать. Фактически, более быстрая обработка вредит некоторым приложениям реального времени, поскольку увеличение скорости приводит к увеличению сложности и увеличению вероятности возникновения проблем, вызванных изменением скорости. Более быстрая обработка затрудняет определение того, какие сроки были успешно соблюдены. Поскольку будущие системы баз данных будут работать еще быстрее, чем когда-либо, необходимо проводить больше исследований, чтобы мы могли продолжать иметь эффективные системы.

Объем исследований по изучению систем баз данных реального времени будет увеличиваться из-за коммерческих приложений, таких как интернет-аукционы, такие как eBay . Все больше развивающихся стран расширяют свои телефонные системы, и число людей с мобильными телефонами в Соединенных Штатах, а также в других местах мира продолжает расти. Также, вероятно, стимулировать исследования в реальном времени будет экспоненциально возрастающая скорость микропроцессора. Это также делает возможным использование новых технологий, таких как веб -видеоконференции и обмен мгновенными сообщениями со звуком и видео высокого разрешения, которые зависят от систем баз данных в реальном времени. Исследования временной согласованности приводят к появлению новых протоколов и временных ограничений с целью более эффективной обработки транзакций в реальном времени.

Дальнейшее чтение

• Озсойоглу, Гюльтекин и Ричард Т. Снодграсс. Базы данных временного и реального времени: обзор . Знания и инженерия данных, 1995. 13 декабря 2006 г.
• Као, Бен; Гарсия-Молина, Гектор (1994). «Обзор систем баз данных реального времени». Вычисления в реальном времени . Берлин, Гейдельберг: Springer Berlin Heidelberg. дои : 10.1007/978-3-642-88049-0_13 . ISBN  978-3-642-88051-3 . ISSN   0258-1248 .
• Линдстрем, Ян. Системы баз данных реального времени . Солид, 2008. 25 марта 2008 г.
• Сивасанкаран, Раджендран М., Джон А. Станкович, Дон Таусли , Бхаскар Пуриметла и Крити Рамамаритам. Назначение приоритетов в активных базах данных реального времени . Университет Массачусетса. Амахерст, Нью-Йорк, 1996 г. 13 декабря 2006 г.
• Стоунбрейкер, Майкл и др. HStore: высокопроизводительная распределенная система обработки транзакций в основной памяти , 2008 г.