Ну вы скажите :) на dev-виртуалке просто нет таких дисковых резервов, да меня и скорее теор.предел интересует. Хотя есть и практическое применение.
andylars 05.05.2016 14:05
/ 05.05.2016 14:07
Т.е. хотя бы порядок чисел: что там в seek-адресации "строки" 65535, unsigned int или double?
А методом тыка такие вещи на develop-виртуалке - просто нет таких дисковых резервов, ибо макс.размер файла на ext4 =~ 16 TB
И есть даже вроде разумное применение огромному hashfile =
например большой dump заранее перемешанных (сгенеренных вперемешку) = ID из заданного диапазона.
Предположим мы хотим выдавать не uuid и не sha1, не надеясь на предсказуемость первого, и теор.коллизии второго, для какой-то оч.глобальной системы мы хотим пул-хранилище прегенернных ID с гарантированной уникальностью и (псевдо)случайным порядком их следования в общем пуле.
Если делать это средствами DB, взяв какой нить BIGINT UNSIGNED, и вставляя в него рандомно - то в какой-то момент насыщения, вставка каждого сл.числа будет занимать все более возрастающее время 1) из-за проверки UNIQ ключа, 2) из-за совпадения с уже сущ. плюс 3) огромные накладные расходы вокруг всей DB-обвязки.
Вообще, задача не для парсера, конечно. Т.к. попахивает низкоуровневой работой с байтами, а это не область решений для "веб-фрейморка". Но так, на правах идеи.
