Проектирование системы сообщений
Никак не могу разобраться, как спроектировать систему сообщений (диалогов). В частности, на уровне СУБД.
Допустим, у нас есть таблицы:
- dialogs
- dialog_messages
- dialog_users
Со временем в таблице dialog_messages, если, например, там установлен INT AUTO_INCREMENT, а у нас идет в эту таблицу активная запись, мы упираемся в лимит INT или BIGINT. Даже несмотря на то, что число кажется каким-то невероятным (что-то около 9 квинтиллионов или около того), мы рано или поздно упремся в этот лимит. Но сначала мы упремся либо в диск, либо в максимальный размер таблицы. Это можно решить партиционированием и шардированием, понятное дело. Но что будет, когда мы достигнем этого значения (9 квинтиллионов сообщений)?
Хорошо, можно использовать UUID или GUID. Тоже, в целом, вариант, но идентификаторы рано или поздно могут совпасть. Я понимаю, что это настолько маловероятное событие (что-то около 1 из 2,71 x 10 в 18 степени, если мы говорим про UUID v4 122 бита), но всё же не нулевая. А проверять на каждое новое сообщение - не совпадает ли оно с уже имеющимися идентификаторами, как будто такая себе затея.
Можно, конечно, использовать MongoDB (или PostgreSQL с JSONB) и каким-то образом складывать это туда, но я пока не понимаю в каком направлении хотя бы начать смотреть, не то, что двигаться. Подскажите, пожалуйста, кто реализовывал подобное, как вы решали такие задачи и с какими сложностями сталкивались в процессе реализации и в каком направлении стоит вообще двигаться делая что-то подобное, чтобы при росте количества сообщений не было головной боли или хотя бы минимизировать ее на начальном этапе?