Нет. Не надо на столбики раскладывать.

Вообще Война и Мир это текстовый файл длиной где-то 5 мегабайт и в нем поиск любого слова идет
достаточно быстро для современного процессора и памяти. Ты в текстовом редакторе там найдешь
все что надо.

Тоесть это - неудачный пример.

Может у тебя есть другой источник данных который больше этой книги раз в ..... на 6 порядков?

Ведь мы говорили о тера* суффиксе. А это 12 нулей. Мегабайт - порядка 6 нулей.

БАК - это та штука которая "разгоняет и сталкивает" частицы?

Я даже боюсь себе представить что порождает БАК. Характеристики частиц?

Помните числовую оценку?

1Тб диск будет занят полностью нашим вектором если структура == 1байт.

Если вы положите туда такую структуру




То нам понадобиться 4 + 8 = 12 байтная структура. Тоесть 12 терабайтный диск.

Иднекс по БД обычно несет в себе оверхед порядка 75% полезного места. Это только для ключей.
И для ROW_ID + данных надо посчитать. Но мне щас как-то лень. Проще прикинуть на глаз.
Наверное более чем в 2 раза.

Вобщем я вангую грубо 24 терабайтное хранилище для Алексеевских экспериментов в случае Index-Organized table.

Для раздельного индексирования value и fvalue нам уже понадобиться 3 объекта. Таблица и два индекса.

Давайте просто накинем 3 раза. 72 терабайт.

Просто любой эксперимент должен иметь какие-то числовые предварительные оценки.

Автор ищет алгоритмы и структуры данных. Но должен быть стенд и макет.

Круглый нас это не беспокоит.

Sql.ru - это дискуссионный клуб. Мы тут ... как видишь и без автора подискутировали.

P.S. Подсудимого не было но суд состоялся.

Да ладно. Пиши.

Как там ты Толстого под Досом индексировал...

Кажется в Беркли поддерживал несколько двигателей хранения. Там и дисковая хеш-табличка была и дерево.
И вообще я думаю этот беркли создавали в эпоху дискет. Тоесть... не всё могли учесть.

Как верно подметили Колобок, используя технологии распределённого поиска, мы можем безо всяких
индексов просто подняв копии этого файла в памяти на 20 физических инстанциях искать в 20 раз
быстрее. Разумеется файл при этом будет равномерно порезан как колбаса на 20 хеш-чанков.

Вот тебе первое коробочное решение проблемы. И если ты искал несколько (сколько? Допустим 5 секунд)
то после такого distibuted-search-improovement, я вангую 5 сек / 20 = 1/4 = 0.25 секунды.

Хорошее время. Согласно Амдалу в конце этого процесса будет join результатов поиска. Но если
этих результатов мало - то и процесс джойна нам ничего не будет стоить. Просто подожём финала 20 процессов.
Тут важно чтобы они работали равномерно. И не было среди них 1 доходяги который еще ползет.

Как тебе такое решение?