Является ли bigint достаточно большим для таблицы журнала событий?

Question

Теперь я знаю, что bigint равен 2 ^ 64; то есть больше атомов, чем в известной вселенной. Я не должен волноваться, поскольку мой простой человеческий мозг просто не может обойти чудовищность этого числа.

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

Answer 1

Даже если каждая из ваших записей имеет только 1 байт, 2 ^ 64 записи будут занимать около 18000000 ТБ на вашем жестком диске, поэтому я думаю, вам не стоит об этом беспокоиться.

Answer 2

Если ваше приложение добавляет запись в таблицу раз в миллионную секунду, оно будет работать более пятисот тысяч лет, прежде чем у него кончатся ключи.

Answer 3

"Насколько большой я должен позволить таблице журнала событий получить, прежде чем я начну архивировать / очищать ее?"

Никогда не очищайте журналы событий - информация имеет большое значение.

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

Стоимость хранения стремительно падает. Ваше время лучше потратить на НИЧЕГО, кроме очистки записей журнала.

Итог: у вас есть разрешение прекратить ломать руки. Все хорошо. Вы не делаете фундаментальную ошибку.

Answer 4

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

Answer 5

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

У нас также есть разные таблицы журналов, но только две основные.