Практически каждая основная база данных имеет функцию вычисления контрольных сумм на страницу, сектор или запись.
Теперь для БД, которая полностью восстанавливается после любого сбоя, например PostgreSQL, нужна ли контрольная сумма? Пока xlog в порядке, потери данных не будет, независимо от того, какое повреждение произошло с самими данными, поскольку журнал повторов воспроизводится, каждая зафиксированная транзакция будет восстановлена. Таким образом, контрольные суммы при восстановлении бесполезны.
Не хранит ли файловая система или диск контрольные суммы для обнаружения повреждений? Так что, если контрольная сумма не указана для каждой записи, все, что он делает, это говорит вам, что есть повреждение - на что ОС должна кричать на вас в ту минуту, когда вы пытаетесь его прочитать - так бесполезно в работе?
Я не могу представить, как контрольная сумма может быть полезна в любой разумной базе данных, но поскольку все они ее используют, я бы сказал, что это просто провал воображения с моей стороны. Так чем это полезно?
Контрольные суммы важны и полезны по разным причинам. Вероятно, самые верхние включают:
Дело в том, что только часть популярных файловых систем несут контрольные суммы фактического содержимого файлов. [статья в Википедии]. Что касается жестких дисков, их показатели надежности никогда не догоняли стремительно растущие емкости, поэтому при достаточном количестве данных и / или пропускной способности вы гарантированно будете время от времени получать необнаруженные ошибки. [Исследование ЦЕРН]. То есть, если у вас недостаточно контрольных сумм для их обнаружения, что на данном этапе требует проверки на уровне приложения.
Поскольку большинство файловых систем не хранят контрольные суммы (заметным исключением является ZFS), контрольная сумма в базе данных все равно будет полезна.
В PostgreSQL контрольная сумма суммируется для записей WAL, но не для страниц данных, поэтому вы не сможете определить, уничтожили ли ваши данные ОС или оборудование. Реализация контрольной суммы для страниц данных - запланированная функция в PostgreSQL, но есть несколько очень сложных проблем с реализацией, если параллелизм должен поддерживаться. Поищите "crc уровня блока postgresql" или что-то в этом роде, чтобы узнать больше (или полностью запутаться).