База данных в реальном времени - Real-time database

А база данных в реальном времени это система баз данных, которая использует обработка в реальном времени для обработки рабочих нагрузок, состояние которых постоянно меняется.[1] Это отличается от традиционных баз данных, содержащих постоянные данные, в большинстве своем не подверженные влиянию времени. Например, фондовый рынок меняется очень быстро и динамично. Графики различных рынков кажутся очень нестабильными, и все же база данных должна отслеживать текущие значения для всех рынков Нью-Йоркская фондовая биржа.[2] Обработка в режиме реального времени означает, что транзакция обрабатывается достаточно быстро, чтобы результат вернулся и немедленно отреагировал.[3] Базы данных в реальном времени полезны для бухгалтерского учета, банковского дела, права, медицинские записи, мультимедиа, управление процессами, системы бронирования и анализ научных данных.[4]

Обзор

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

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

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

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

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

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

Самый ранний крайний срок
PT = DT - Стоимость сделки не важна. Примером может служить группа людей, звонящих, чтобы заказать товар.
Наивысшая ценность
PT = 1 / VT - Срок не важен. Некоторые транзакции должны попадать в ЦП на основе критичности, а не справедливости. Это пример наименьшего провисания, при котором можно ждать наименьшее количество времени. Если телефонные коммутаторы были перегружены, люди, звонящие в службу 911, должны получить приоритет.[4]
Срок завышения стоимости
PT = DT / VT - Придает одинаковый вес сроку и значениям на основе расписания. Примером может служить регистрация на классы, где студент выбирает блок классов, которые он хочет пройти, и нажимает кнопку «Отправить». В этом сценарии более высокий приоритет часто имеет приоритет. Система регистрации школы, вероятно, использует этот метод, когда сервер получает две транзакции регистрации. Если у одного студента было 22 кредита, а у другого 100 кредитов, приоритет будет иметь человек с 100 кредитами (планирование на основе стоимости).

Ограничения по времени и сроки

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ Бухманн, А. "Системы баз данных в реальном времени". Энциклопедия технологий и приложений баз данных. Эд. Лаура К. Риверо, Хорхе Х. Дорн и Вивиана Э. Феррагжин. Идея Групп, 2005.
  2. ^ Каниткар, Винай и Алекс Делис (1997). "Случай для баз данных клиент-сервер реального времени". Бруклин, Нью-Йорк: Политехнический университет. Получено 13 декабря 2006. Цитировать журнал требует | журнал = (помощь)
  3. ^ Карпрон, Х.Л., Дж. А. Джонсон. Компьютеры: инструменты информационного века. Прентис Холл, 1998. 5-е изд.
  4. ^ а б c (Снодграсс)
  5. ^ а б c d е ж грамм Эббот, Роберт К. и Эктор Гарсиа-Молина. (1992). «Планирование транзакций в реальном времени: оценка производительности» (PDF). Стэнфордский университет и корпорация цифрового оборудования ACM. Дои:10.1145/132271.132276. Получено 13 декабря 2006. Цитировать журнал требует | журнал = (помощь)CS1 maint: несколько имен: список авторов (связь)
  6. ^ Сингхал, Мукеш. Подходы к проектированию систем баз данных реального времени, SIGMOD Record, том 17, вып. 1 марта 1988 г.
  7. ^ а б c d Харица, Дж., Дж. Станкович и М. Сюн. «Протокол контроля параллелизма с учетом состояния для реплицированных баз данных в реальном времени». Университет Вирджинии. Симпозиум IEEE по приложениям реального времени. Получено 13 декабря 2006. Цитировать журнал требует | журнал = (помощь)CS1 maint: несколько имен: список авторов (связь)
  8. ^ Ли, Джухнён (1994). «Алгоритмы управления параллелизмом для систем баз данных реального времени». Дисс. Univ. Вирджинии. Получено 13 декабря 2006. Цитировать журнал требует | журнал = (помощь)
  9. ^ (Свинка)
  10. ^ а б Канг, К. Д., Сон и Дж. Станкович. Определение и управление качеством служб данных в реальном времени. Университет Вирджинии. IEEE TKDE, 2004.
  11. ^ а б Станкович, Джон А., Марко Спури, Крити Рамамритам и Джорджио К. Буттаццо. Планирование крайних сроков для систем реального времени: EDF и связанные алгоритмы. Спрингер, 1998.
  12. ^ (Рамамритам)
  13. ^ а б (О'Нил)
  14. ^ Лам, Кам-Ю и Тей-Вей Куо. Системы баз данных реального времени: архитектура и методы. Спрингер, 2001.

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