Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

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

Ответ 2

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

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

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

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

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

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

Ограничения исключения PostgreSQL 9.0 должны обеспечивать новые способы организации временных данных, например. транзакция и действительное время. ПЕРИОДЫ не должны перекрываться для одного и того же кортежа.

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

Ответ 9

Кроме того, "что нового можно сделать с ним", может быть полезно рассмотреть "какие старые вещи объединяются?". Временная база данных представляет собой конкретное обобщение "нормальной" базы данных SQL. Таким образом, это может дать вам единое решение проблем, которые ранее не были связаны. Например:

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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