В настоящее время я разрабатываю обновление нашего текущего медиа-хранилища (для хранения видео/аудио/метаданных) для системы наблюдения, и я перепроектирую структуру записи в более надежное решение.
Мне нужно создать некоторые данные индекса данных, хранящихся в файлах данных, поэтому я создаю структуру индексных файлов, но я беспокоюсь о сбоях жестких дисков (представьте, будет ли питание отключено во время записи индекса файл, он станет corrup, поскольку данные, скорее всего, будут наполовину записаны). Я уже разработал, как будет храниться индекс, но моя озабоченность связана с повреждением данных при сбое питания или сбое диска.
Итак, кто-нибудь знает методы, чтобы избежать повреждения данных при написании?
Я уже немного искал и не нашел хороших решений, одним из решений было создание журнала всего, что записано в файл, но тогда у меня будет еще много операций ввода-вывода в секунду (я заинтересован в размере I/O в секунду, система должна выполнять как можно меньше).
То, что я придумал, - это дублировать конфиденциальные данные в файле индекса вместе с полями временной метки и контрольной суммы. Например:
Поле1 Поле2 Поле3 Контрольная сумма времени
Поле1 Поле2 Поле3 Контрольная сумма времени
Итак, у меня есть данные, записанные дважды, если при чтении файла первый набор полей поврежден (Checksum не соответствует), у меня есть второй набор полей, которые должны быть в порядке. Я считаю, что corrupion случается, когда написание, если оно остановлено посередине, так, например, когда программное обеспечение набирает первый набор полей и сбой питания, второй набор по-прежнему остается нетронутым... если сбой питания во время второго набор записывается, первый из них уже не поврежден.
Что вы, ребята, думаете об этом решении? Предотвращает ли это повреждение данных?
Кстати, я не могу использовать любую базу данных для такого типа хранилища или транзакционной NTFS из-за ограничений на развертывание системы с транзакционной NTFS
Любые идеи приветствуются, спасибо!
Игнорирование части вашего вопроса вокруг невозможности использования базы данных:)
Вы можете найти интересующие файлы SQL Server 2012. Вы можете хранить файлы за пределами базы данных в папке, но при этом обращаться к файлам так, как если бы они находились внутри базы данных. Вы можете использовать базу данных для вставки новых файлов в этот каталог или просто скопировать файл в папку. Ваша база данных не будет очень толстой с видеофайлами. Они также не будут доступны, если программное обеспечение сервера db снизилось. Индексирование кадров может быть индивидуальным .jpg файлами (или что-то еще), и к ним также можно обратиться FileTable и индекс через внешний ключ к основному видеофайлу. Тогда таблица индексов кадров очень проста.
Таким образом, вы устраняете накладные расходы БД для записи файла и ведения журнала, чтобы узнать, произошел ли сбой. Если ОС не может записать файл из-за сбоя питания, тогда у базы данных не будет шанса. Вы можете делать сравнения каталогов и использовать надежную утилиту для перемещения файлов вокруг, а не для удаления исходного файла, если какая-либо часть записи не удалась.
Это не предотвращает повреждение данных, так как повреждение может произойти в любом одном или обоих наборах полей.
Я думаю, что вы лучше, не дублируя "конфиденциальные данные", но записывая эти данные в два этапа на первом шаге. Напишите данные с полем "контрольная сумма" пустым, а на втором этапе обновите контрольную сумму с той, которая соответствует данные. Эта контрольная сумма будет использоваться как флаг с транзакцией и обеспечить целостность данных.
Когда вы читаете данные, вы игнорируете все наборы индексов, которые не были зафиксированы, я имею в виду, где контрольная сумма не соответствует.
Затем выполните много испытаний и тонкой настройки, нанесите повреждение данных на каждом шаге процесса, а также сохраните случайные данные. Я лично считаю, что тестирование требует большой работы, поскольку неудача является случайной, поэтому люди рекомендуют вам использовать базы данных, проверенные в течение многих лет.
Обратите внимание, что, хотя он добавляет некоторую защиту от некоторых видов искажения данных, он не идеален, и вы можете добавить другие уровни безопасности для защиты ваших данных, включая репликацию данных, проверки целостности и внешние конфигурации, в том числе без перерывов, периодические резервные копии.
Слишком много теории вокруг "транзакций".
Найдите "алгоритмы атомных транзакций", чтобы получить более подробную информацию.
Пересмотр с использованием базы данных, пересмотр с использованием журнала и даже пересмотр с использованием файловой системы для хранения вашей информации.
Вы можете использовать какую-то логику транзакций. Создайте индекс в маленьких кусках и сначала используйте временный файл. Когда вы закончите один фрагмент (файл), проверьте целостность и скопируйте его как фактический индексный файл, если он пройдет тест. На этом этапе вы можете распространять несколько копий проверенного фрагмента.