luaPower, я думаю что твоя гипотеза требует какого-то доказательства. У меня нет сомнений в том что выбор слова из базы по порядковому номеру взятому из ГПСЧ будет соовтествовать линейному распределению.
Но у меня есть сомнения в том что все прочие методы дают нужное распределение. И почему мы решили что следующее число за длинным - будет правильным выбором. Может надо взять следующие 2 числа? Или может мы должны анализировать длину найденного числа и вести учёт уже найденных? Или может мы должны делать корректировочный выстрел?
SemenPPP, фантазия у меня богатая. Но я хотел еще увидеть предметную область. И прочие признаки. Которые могут сделать задачу узко-специализированной. Пока-же у тебя идет такая себе сверх-задача. И ты заставляешь нас, участников qna искать сверх-решения.
Кирилл Гусарев, я-бы посчитал накладные расходы на индексы. При 12 Гб файле нам удобно использовать целые числа формата long (64bit) для указания начала слова.
Далее - я бы посчитал среднюю длину слова. Допустим это 11 символов. Пускай слова разделяются переводом строки 0x0D тогда будет 12 байтов на слово. И 8 байтов на элемент индекса.
Считаем число слов 12 Gb == 12884901888 bytes
Или в 1 073 741 824 слов (1 миллиард).
Объем индексного файла будет - 8589934592 bytes ~ примерно 8 Гб.
Примерно подходит под требования автора.
На индексе можно сэкономить если взять скажем не long 64bit а int32 bit
Тогда надо базу слов разбить хотя-бына 3-4 части (одно целое число может адресовать
смещение до 4 млрд).
Или можно поступать с памятью как делает Java c heap. Выровнять слова по границе
параграфа (16 байт) и тогда можно лишние 4 бита с индексного элемента перенестсти
в старшие разряды. И тогда может быть хватит 32х бит. Тут надо посчитать вобщем
потери от такого округления. Вместо 12 Гб файла - может быть в полтора раз больше.
Я могу предположить что лучше создать дочернюю таблицу participants и в нее перенести все partitcipantids.
Но поскольку ты - слабый постановщик задач то и ты тоже можешь ошибаться в своём видении использования этой БД я вангую что это ответ где - то на 60% полезности.
На полное разбирательство с этой БД у нас нет ни времени ни денег. Формат qna предполагает вопрос-ответ а не сопровождение.
Проверяй гипотезы.
-Ты ходишь рандомным образом то на мастер то на slave.
-Ты работаешь в транзакции но забываешь сделать коммит.
-Кроме тебя кто-то еще работает со справочником.
Я-бы подумал сначала в направлении улучшения процесса транскрибции. Там есть паузы и интонация. И их можно использовать как дополнительную информацию. Чтобы не генерировать мешок слов - надо генерировать мешок плюс некие дополнительные символы которые помогут в разметке.
Если на вход идет только мешок - то мы получаем забавные загадки наподобие
"На поле он траву косил" или "Наполеон траву косил..."
По поводу орфографии. Это уже лет 20 как решенный вопрос. Есть всякие Стилусы и Промпты. Покупайте у них библиотеки словари или сервис-API.
luaPower, подожди-подожди. Зачем я буду брать следующее слово? По какому закону или по какой формуле? Автор поставил задачу о случайности. Обычно имеется в виду линейное распределение вероятностей. Это означает что все слова - равновероятны.
Мне тут пока предлагают алгоритмы которые просто нарушают линейную вероятность.
Интересно что никому в голову не пришло просто в хеш-мапу это все загрузить. И решить проблему.
Накладные можно пообсуждать отдельно но в конце концов у любой задачи есть цена разработки
и цена эксплуатации
Может эта задача - одноразовая. Или запускается 1 раз в квартал. Или просто - временное решение.
Озвучь более полную задачу.