Есть ли механизм базы данных, который реализует произвольный доступ?

Question

при произвольном доступе i не означает выбор случайной записи,
произвольный доступ возможность извлечения всех записей в одно и то же время,
таким же образом, как значения выбираются из массива.
Из википедии: http://en.wikipedia.org/wiki/Random_access

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

Обычно я использую MySQL, но, похоже, он имеет только типы индексов B-Tree и Hash.

Я не вижу причины, почему это невозможно реализовать.
Индексы будут такими же, как в массиве, начиная с нуля и увеличиваясь на 1.

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

Есть ли решение для этого?

p.s Я не думаю, что это дубликат Контейнер произвольного доступа, который не помещается в памяти?
Потому что в этом вопросе у него есть другие требования, кроме произвольного доступа

Answer 1

Учитывая ваше определение, если вы просто используете SSD для хранения ваших данных, это позволит использовать то, что вы называете произвольным доступом (т. Е. Одинаковая скорость доступа по всему набору данных).Тот факт, что последовательный доступ дешевле, чем случайный, связан с тем, что последовательный доступ к диску намного быстрее, чем случайный (и любая база данных пытается это исправить, кстати).даже доступ к ОЗУ не является равномерным, так как последовательный доступ быстрее из-за кэширования и NUMA .Так что равномерный доступ в любом случае является иллюзией, в связи с чем возникает вопрос, почему вы так настаиваете на том, чтобы иметь его в первую очередь.Т.е. то, что вы думаете, пойдет не так, когда у вас медленный произвольный доступ - это может быть достаточно быстро для вашего варианта использования.

Answer 2

Вы говорите о постоянном времени, но упоминаете уникальный увеличивающийся первичный ключ.

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

Поиск записи по смещению, как правило, не особенно полезен, так как вы обычно хотите найти ее более дружественным методом, который всегда будет включать индекс. Поиск по индексу B-Tree - наихудший случай O (log n), что довольно хорошо.

Если у вас есть только массив строк - сохраните его в файле на диске с записями фиксированной длины и используйте файловую систему для поиска желаемого смещения.

Затем сравните результаты поиска в базе данных.