Зачем нам нужна временная база данных?

StackOverflow https://stackoverflow.com/questions/800331

  •  03-07-2019
  •  | 
  •  

Вопрос

Я читал о темпоральных базах данных, и кажется, что в них встроены временные аспекты.Интересно, зачем нам такая модель?

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

Поддерживает ли какая-либо из существующих баз данных такую ​​функцию?

Это было полезно?

Решение

Временная база данных эффективно хранит временные ряды данных, обычно имея фиксированную шкалу времени (например, секунды или даже миллисекунды), а затем сохраняя только изменения в измеренных данных.Временная метка в СУБД представляет собой дискретно сохраняемое значение для каждого измерения, что очень неэффективно.Временная база данных часто используется в приложениях мониторинга в реальном времени, таких как SCADA.Хорошо зарекомендовавшей себя системой является база данных PI от OSISoft (http://www.osisoft.com/).

Другие советы

Рассмотрим свой дневник встреч/журнала — он ведется с 1 января по 31 декабря.Теперь мы можем запросить в дневнике встречи/записи журнала в любой день.Этот порядок называется действительное время.Однако встречи/записи обычно вставляются не по порядку.

Предположим, я хотел бы знать, какие встречи/записи были в моем дневнике 4 апреля.То есть все записи, которые существовали в моем дневнике на 4 апреля.Это время транзакции.

Учитывая, что встречи/записи можно создавать, удалять и т. д.Типичная запись имеет время начала и окончания действия, которое охватывает период записи, а также время начала и окончания транзакции, которое указывает период, в течение которого запись появилась в дневнике.

Такое расположение необходимо, когда дневник может подвергнуться исторический пересмотр.Предположим, 5 апреля я осознаю, что встреча, назначенная на 14 февраля, на самом деле произошла 12 февраля, т.е.Я обнаружил ошибку в своем дневнике. Я могу исправить ошибку, чтобы исправить действительную картину времени, но теперь мой запрос о том, что было в дневнике 4 апреля, будет неправильным, ЕСЛИ только время транзакций для встреч/записей не будет также хранится.В этом случае, если я запрошу свой дневник по состоянию на 4 апреля, он покажет, что встреча существовала 14 февраля, но если я сделаю запрос по состоянию на 6 апреля, он покажет встречу на 12 февраля.

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

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

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

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

Временные базы данных часто используются в сфере финансовых услуг.Одна из причин заключается в том, что вам редко (если вообще когда-либо) разрешается удалять какие-либо данные, поэтому поля типа ValidFrom - ValidTo в записях используются для указания того, когда запись была правильной.

Помимо чтения Статья в Википедии?База данных, которая ведет «журнал аудита» или аналогичный журнал транзакций, будет иметь некоторые свойства «временности».Если вам нужны ответы на вопросы о кто что сделал, кому и когда тогда у вас есть хороший кандидат на временную базу данных.

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

Несмотря на это, временные данные обычно просто хранятся в обычной СУБД.PostgreSQL, например, имеет некоторые временные расширения, что делает это немного проще.

На ум приходят две причины:

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

Просто обновление: база данных Temporal появится в SQL Server 2016.

Чтобы развеять все ваши сомнения, почему нужна временная база данных, а не настройка с помощью пользовательских методов, а также то, насколько эффективно и легко SQL Server настраивает ее для вас, посмотрите подробное видео и демонстрацию на Channel9.msdn здесь: https://channel9.msdn.com/Shows/Data-Expose/Temporal-in-SQL-Server-2016

Ссылка MSDN: https://msdn.microsoft.com/en-us/library/dn935015(v=sql.130).aspx

В настоящее время с выпуском CTP2 (бета-версия 2) SQL Server 2016 вы можете поиграть с ним.

Проверять это видео о том, как использовать временные таблицы в SQL Server 2016.

Помимо вопроса «что нового я могу с ним сделать», возможно, было бы полезно подумать о том, «какие старые вещи он объединяет?».Темпоральная база данных представляет собой частное обобщение «обычной» базы данных SQL.Таким образом, он может дать вам единое решение проблем, которые раньше казались несвязанными.Например:

  • Веб-параллелизм Если ваша база данных имеет веб-интерфейс, который позволяет нескольким пользователям выполнять стандартные изменения создания/обновления/удаления (CRUD), вам придется столкнуться с проблема одновременных веб-изменений.По сути, вам необходимо убедиться, что входящая модификация данных не влияет на какие-либо записи, которые изменились с тех пор, как пользователь последний раз видел эти записи.Но если у вас есть временная база данных, вполне возможно, что она уже связывает что-то вроде «идентификатора версии» с каждой записью (из-за сложности создания уникальных и монотонно возрастающих временных меток).Если это так, то это становится естественным, «уже встроенным» механизмом предотвращения уничтожения данных других пользователей во время обновлений базы данных.
  • Юридическая/налоговая отчетность Правовая система (включая налоги) уделяет гораздо больше внимания историческим данным, чем большинство программистов.Таким образом, вы часто будете встречать совет о схемах для счетов и таковых, что предупреждает вас о том, чтобы быть остерегающимся удалять записи или нормализацию естественным образом-что может привести к неспособности ответить на основные юридические вопросы, такие как «Забудьте об их текущем адресу, какой адрес вы отправили этот счет в 2001 году. ? » Благодаря временной структуре базы, все махинации к этим проблемам (обычно на полпути к наличию временной базы данных) исчезают.Вы просто используете наиболее естественную схему и удаляете ее, когда это имеет смысл, зная, что вы всегда можете вернуться и точно ответить на исторические вопросы.

С другой стороны, сама временная модель находится на полпути к завершению контроля версий, что может вдохновить на дальнейшие приложения.Например, предположим, что вы развернули собственное временное средство поверх SQL и разрешили ветвление, как в системах контроля версий.Даже ограниченное ветвление может облегчить создание «песочницы» — возможности свободно экспериментировать с базой данных и изменять ее, не вызывая каких-либо видимых изменений для других пользователей.Это позволяет легко обеспечить реалистичное обучение пользователей работе со сложной базой данных.

Простое ветвление с помощью простой возможности слияния также может упростить некоторые распространенные проблемы рабочего процесса.Например, в некоммерческой организации могут быть волонтеры или низкооплачиваемые работники, выполняющие ввод данных.Предоставление каждому работнику собственной ветки позволит руководителю легко просмотреть его работу или улучшить ее (например, дедупликацию) перед объединением ее с основной веткой, где она станет видна «обычным» пользователям.Филиалы также могут упростить разрешения.Если пользователю предоставлено разрешение только на использование/просмотр своей уникальной ветки, вам не нужно беспокоиться о предотвращении всех возможных нежелательных изменений;вы объедините только те изменения, которые в любом случае имеют смысл.

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

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

Существуют академические базы данных и некоторые коммерческие.У Timecenter есть несколько ссылок.

Еще один пример того, где полезна временная база данных, — это когда данные изменяются с течением времени.Я несколько лет проработал в магазине электроэнергии, где мы хранили показания счетчиков в течение 30-минутных интервалов времени.Эти показания счетчиков могли быть пересмотрены в любой момент, но нам все равно нужно было иметь возможность просмотреть историю изменений показаний.

Таким образом, у нас были последние данные (наше «текущее понимание» потребления за 30 минут), но мы могли оглянуться на наше историческое понимание потребления.Когда у вас есть данные, которые можно настроить таким образом, временные базы данных работают хорошо.

(При этом мы вручную вырезали это в SQL, но это было довольно давно.Сейчас бы не принял такого решения.)

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top