Могу ли я ожидать значительного повышения производительности за счет переноса большого хранилища значений ключей из MySQL в базу данных NoSQL?

Я разрабатываю базу данных, в которой хранятся большие наборы научных данных. Типичный сценарий использования состоит в том, что порядка 5 ГБ новых данных будет записываться в базу данных каждый день; 5 ГБ также будут удаляться каждый день. Общий размер базы данных составит около 50 ГБ. Сервер, на котором я работаю, не сможет сохранить весь набор данных в памяти.

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

Запросы обычно содержат около 100 последовательных значений, например. SELECT Value WHERE ID BETWEEN 7000000 AND 7000100;

В настоящее время я использую MySQL / MyISAM, и эти запросы занимают порядка 0,1 - 0,3 секунды, но недавно я понял, что MySQL, вероятно, не оптимальное решение для того, что в основном представляет собой большое хранилище ключей / значений.

Прежде чем я начну выполнять большую работу по установке нового программного обеспечения и переписыванию всей базы данных, я хотел получить приблизительное представление о том, увижу ли я значительное повышение производительности при использовании базы данных NoSQL (например, Tokyo Tyrant, Cassandra, MongoDB) вместо MySQL для этих типов поисков.

Спасибо


mysql nosql cassandra tokyo-cabinet
person Pete W    schedule 06.08.2010    source источник
comment
Прежде чем отказываться от СУБД, я бы хотел профилировать MySQL / Innodb и postgresql. Я также хотел бы быть уверен, что у меня есть соответствующие индексы в таблице.   -  person tpdi    schedule 06.08.2010
comment
Re: Индексы, Моя таблица имеет два столбца: ID BIGINT; Значение FLOAT; и у меня есть ID в качестве первичного ключа, так как мои запросы всегда используют where ID между ...   -  person Pete W    schedule 06.08.2010
comment
Вау! 50 ГБ данных в таблице из двух столбцов. Я думаю, что в данных обстоятельствах не стоит чихать от 0,1 до 0,3 секунды. Если это какое-то из наших дел, возможно, вы могли бы рассказать нам, что вы храните в таблице, которая должна быть почти рекордной?   -  person Brian Hooper    schedule 06.08.2010
comment
Если вы перейдете на Mongodb, вы можете сегментировать свою базу данных на нескольких машинах, и весь набор данных поместится в памяти, это сделает его очень быстрым. Шардинг в MongoDB может обрабатывать запросы диапазона. Конечно, эти дополнительные машины стоят денег, решать вам. Вы также можете попробовать использовать SSD.   -  person TTT    schedule 07.08.2010
comment
Брайан: Я должен был сказать, что в настоящее время я не работаю с полным набором данных, поэтому мои извлечения 0,1–0,3 с применимы только к общему размеру таблицы чуть более 5 ГБ (но в конечном итоге он будет 50 ГБ), NB. у моего текущего сервера всего 512 МБ ОЗУ (!). Данные представляют собой набор геофизических спутниковых данных. ТТТ: Хорошее замечание по поводу шардинга. Это определенно вариант.   -  person Pete W    schedule 07.08.2010
comment
Любой ключ / значение nosql db должен вам подойти. Особенно, если у вас есть другие машины, с которыми вы можете создать кластер.   -  person Zanson    schedule 08.08.2010

Ответы (3)


arrow_upward
2
arrow_downward

Я использую MongoDB в производстве для операций с интенсивной записью, где я преуспеваю по сравнению со скоростью, о которой вы говорите для операций WRITE и READ, размер базы данных составляет около 90 ГБ, а один экземпляр (amazon m1.xlarge) выполняет 100QPS. сообщают вам, что типичный запрос типа ключ-> значение занимает около 1-15 мс в базе данных с 150 миллионами записей, а время запроса достигает 30-50 мсек при большой нагрузке. в любом случае 200 мс - это слишком много для хранилища ключей / значений.

Если вы используете только один товарный сервер, я бы посоветовал mongoDB, поскольку он достаточно эффективен и прост в освоении, если вы ищете распределенное решение, вы можете попробовать любой клон Dynamo: Cassandra (Facebook) или Project Volemort (LinkedIn) являются самыми популярными. имейте в виду, что поиск сильной согласованности несколько замедляет работу этих систем.

person Asaf    schedule 09.08.2010
comment
Спасибо, я запустил несколько тестов с MongoDB, Tokyo Tyrant и Cassandra. Я определенно вижу значительное улучшение времени выполнения запросов. Однако массовые вставки fyi оказываются не такими быстрыми (по сравнению с MySQL LOAD INFILE). - person Pete W; 27.08.2010

arrow_upward
3
arrow_downward

Также обратите внимание на OrientDB. Он использует индексы с алгоритмом RB + Tree. В моих тестах со 100 ГБ базы данных чтение 100 элементов заняло 0,001-0,015 секунды на моем ноутбуке, но это зависит от того, как ключ / значение распределяются внутри индекса.

На то, чтобы сделать свой собственный тест, потребуется менее 1 часа.

Плохая новость заключается в том, что OrientDB еще не поддерживает кластерную конфигурацию (запланировано на сентябрь 2010 г.).

person Lvca    schedule 12.08.2010

arrow_upward
2
arrow_downward

Я ожидал, что Cassandra будет лучше работать там, где набор данных не помещается в памяти, чем система на основе b-дерева, такая как TC, MySQL или MongoDB. Конечно, Cassandra также спроектирована таким образом, что, если вам нужна более высокая производительность, легко добавить больше машин для поддержки вашей рабочей нагрузки.

person jbellis    schedule 08.08.2010