Что делать, если 2^32 просто недостаточно?

Question

Что делать, если у вас столько записей в таблице, что 2^32 недостаточно для вашего идентификатора auto_increment в течение определенного периода (день, неделя, месяц, ...)?
Что делать, если самый большой тип данных, предоставляемый MySQL, недостаточно?

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

Как я мог встроить в MySQL (или любую другую систему) неограниченное количество уникальных идентификаторов или хотя бы увеличить его экспоненциально?

В идеале я хотел бы ожидать что-то вроде

> SELECT * FROM table; 

+---+------+ 
| a | b | 
+---+------+ 
| 1 | 1 | 
| 1 | 2 | 
| 1 | 3 | 
|...| .... | 
|...| .... | 
| 1 | 2^32 | 
| 2 | 1 | 
| 2 | 2 | 
+---+------+ 

экспоненциально увеличивает количество записей.

Как вы справляетесь с такими ситуациями?
Помните - требование - иметь уникальный идентификатор для любой записи.

Answer 1

Вы можете использовать BIGINT для первичного ключа. По умолчанию это 64-разрядное число.

Редактировать # 2: По-видимому, я уже говорил об изменении длины байта BIGINT. BIGINT -, установленный на 8-байтовом пределе.

Answer 2

Просто используйте 128-битные ключи. Нет необходимости в неограниченном количестве ключей, так как вы очень быстро допускаете больше строк, чем число атомов во Вселенной. (где-то около 256 бит).

Answer 3

Не используйте автоинкрементом первичный ключ - использовать GUID или аналогичный - из статьи Википедии:

Хотя каждый генерируемой GUID не гарантированно быть уникальным, общее количество уникальных ключей (2^128 или 3.4 × 10^38) настолько велика, что вероятность того, что одно и то же число генерируется дважды, бесконечно мала. . Например, рассмотрим наблюдаемый универсум , который содержит около 5 × 1022 звезды; каждая звезда может , то есть 6.8 × 1015 универсально уникальный GUIDs.

Answer 4

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

Answer 5

Я бы начал с перехода на BIGINT для 2^64. GUID были бы еще одним вариантом, но вам нужно сохранить их самостоятельно в «некоторой форме»

Answer 6

Вы также можете использовать символы/varchars для своих ключевых столбцов и использовать GUID для своих ключей. Я не знаю, будет ли это повлечь за собой штраф за производительность по сравнению с целыми первичными ключами.

Answer 7

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

Как уже говорилось ранее, наилучшим выбором для наборов данных VAST является либо GUID (если ваша RDBMS поддерживает его изначально), либо varchar (16).

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

Answer 8

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

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

Answer 9

Вам не кажется, что BIGINT UNSIGNED будет достаточным? Это диапазон от 0 до 18.446.744.073.709.551.615 или один год с 50.539.024.859.478.223 вводами в день (365 d/y), 2.105.792.702.478.259 записей в час, 35.096.545.041.304 записей в минуту или 584,942,417,355 в секунду.

With assumed 600 writes per second (without any reads) Вы можете писать записи 974.904.028 лет при полной скорости записи. Этого должно быть достаточно.