быстрый индексный формат для «постоянной базы данных»

Я занимаюсь программированием на linux и сталкивался с проблемой, которая требует чрезвычайно быстрой скорости поиска.быстрый индексный формат для «постоянной базы данных»

Если таблица, как обычная таблица MySQL, выглядит следующим образом:

ID name age sex score_a score_b score_c date

и это постоянная, что означает, когда эта таблица была создана, и никаких обновлений не были разрешено. Он служит только для чтения. Поскольку он был постоянным, поэтому я предполагаю, что должен быть лучший индексный формат для более быстрого поиска по условиям (например, возраст, оценки и т. Д.), А не «индекс дерева B», реализованный в большинстве баз данных для индекса.

источник

2012-03-13 Mickey Shine

Выглядит хэш, будет единственным способом. – PasteBT

@PasteBT hash не может поддерживать фильтрацию, я думаю, это не возможно для меня –

Мне нужно больше информации. Что вы подразумеваете под «быстрым» и «недостаточно быстрым»? какие запросы вы используете, и насколько сложны ваши фильтры? Вы повторяете одни и те же запросы снова или снова, или они сильно переменны? –

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

Большинство современных СУБД поддерживают некоторую форму кэширования запросов. Если у вас этого нет, вы можете кэшировать результат своих запросов в виде memcached. Генерация кеша будет медленной, но если поиск в кеше будет локальным, он будет очень быстрым по сравнению с поиском индексов - обычно O (1).

источник

2012-03-13 05:21:48

«быстрый» означает быстрее, чем большинство индексов базы данных (например, MySQL) с кешем запросов –

Мне нужно что-то более конкретное, чем это. Каковы ваши критерии приема? Какая большая проблема, которая вызывает нынешняя «медлительность»? –

Вы собираетесь проводить поиск по диапазонам («возраст от 10 до 12, 13 и 15 и т. Д.», «Оценка от 40 до 60, 61 и 70 и т. Д.») Или поиск одиночного значения (' имя Квентин Смит ') или оба? Для поиска по одному значению хэш является подходящим и быстрым; в частности, для поиска по диапазону, B-tree и его варианты имеют тенденцию быть лучшими.

Вы ищете где-то в области 50 байт в строке для исходных данных, поэтому вы будете иметь дело с данными от 1 ГБ до 15 ГБ. Если он находится в верхнем конце этого диапазона, вам понадобится большая машина, чтобы хранить простые данные в памяти, не говоря уже об индексах на ней. В нижнем конце диапазона он находится в пределах допустимости. Вероятно, ваши индексы занимают немного больше места, чем необработанные данные (возможно, на 50% больше), предполагая, что вы индексируете каждый из столбцов. Конечно, индекс имени будет самым большим. В столбце ID может не понадобиться индекс, если вы можете использовать его в качестве индекса в массиве записей, но, вероятно, есть пробелы в данных, поэтому, вероятно, лучше всего его индексировать.

источник

2012-03-13 05:40:50

Существует множество постоянных баз данных на основе файлов, которые также могут быть рассмотрены. поиск 'постоянной базы данных' в StackOverflow или Google или Bing и вы найдете некоторые, как:

MCDB https://github.com/gstrauss/mcdb/ (для которого я являюсь автором)

Кабинет Токио http://fallabs.com/tokyocabinet/

hamsterdb http://www.hamsterdb.com

... и другие.

источник

2012-11-16 05:05:27 gstrauss