Хорошая база данных для большой таблицы с простым доступом к ключу

Question

У меня есть несколько больших баз данных, более 100 миллионов записей. Они состоят из следующего:

1. Уникальный ключ.
2. Целочисленное значение, не уникальное, но используемое для сортировки запроса.
3. VARCHAR (200).

Теперь они у меня в таблице mysql isam. Я подумал, эй, я просто настрою индекс покрытия для данных, и он должен вывести достаточно быстро. Запросы имеют вид ...

select valstr,account 
    from datatable 
    where account in (12349809, 987987223,...[etc]) 
    order by orderPriority;

В некоторых тестах это выглядело нормально, но на нашей новой установке это ужасно медленно. Кажется, быстрее вообще не иметь индекса, что кажется странным.

В любом случае, я думаю, может быть, другая база данных? Мы используем базу данных хранилища данных для других частей системы, но она не очень подходит для чего-либо в тексте. Любые бесплатные или довольно дешевые БД являются опцией, если они имеют достаточно полезный доступ к API. SQL необязательно.

Заранее спасибо.

1020 * Кевин *

Answer 1

CouchDB, MongoDB и Riak будут способны быстро найти ключ (учетную запись).

Проблемы, которые у вас возникнут ( с любым решением ), связаны с предложениями "order by" и "account in".

Проблема № 1: учетная запись в

120M записей, вероятно, означают гигабайты данных. У вас, вероятно, есть индекс по концерту. Причина этого заключается в том, что ваше предложение «in» может легко охватывать весь индекс. Если вы ищете учетные записи «0000001» и «9999581», вам, вероятно, потребуется загрузить большой индекс.

Так что просто чтобы найти записи, которые ваша БД сначала должна загрузить, возможно, гигабайт памяти. Затем, чтобы фактически загрузить данные, вы должны снова вернуться на диск. Если ваши «учетные записи» в предложении in не «близки друг к другу», то вы возвращаетесь несколько раз, чтобы получить различные блоки. В какой-то момент может быть быстрее выполнить сканирование таблицы, чем загрузить индекс и таблицу.

Тогда вы попадаете в задачу № 2 ...

Задача № 2: упорядочить по

Если у вас есть много данных, возвращаемых из предложения «in», то order by - это просто еще один уровень медлительности. С «заказом» сервер не может передать вам данные. Вместо этого он должен загрузить все записи в память, затем отсортировать их и затем передать их в потоковом режиме.

Решения:

1. Есть много оперативной памяти. Если ОЗУ не может вместить весь индекс, загрузка будет медленной.
2. Попробуйте ограничить количество входящих элементов. Даже 20 или 30 пунктов в этом пункте могут сделать запрос действительно медленным.
3. Попробуйте базу данных Key-Value?

Я большой поклонник K / V баз данных, но вы должны взглянуть на пункт # 1. Если у вас недостаточно ОЗУ и много данных, система будет работать медленно, независимо от того, какую БД вы используете. Это соотношение размеров ОЗУ и БД действительно важно, если вы хотите добиться хорошей производительности в этих сценариях (небольшие просмотры в больших наборах данных).

Answer 2

Вот пример разумного размера базы данных MySQL, использующей механизм innodb, который использует преимущества кластеризованных индексов в таблице с прибл. 125 миллионов строк и время выполнения запроса 0,021 секунды, что кажется вполне разумным.

Перезапись mysql select для сокращения времени и записи tmp на диск

http://pastie.org/1105206

Другие полезные ссылки:

http://dev.mysql.com/doc/refman/5.0/en/innodb-index-types.html

http://dev.mysql.com/doc/refman/5.0/en/innodb-adaptive-hash.html

Надеюсь, это окажется интересным.

Answer 3

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