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

Question

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

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

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

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

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

Спасибо

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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