Я могу ожидать значительное повышение производительности путем перемещения большого хранилища значения ключа от MySQL до DB NoSQL?
Я разрабатываю базу данных, которая содержит большие научные наборы данных. Типичный сценарий использования - то, который на порядке 5 ГБ новых данных будет писаться в базу данных каждый день; 5 ГБ будут также удаляться каждый день. Общий размер базы данных составит приблизительно 50 ГБ. Сервер, на котором я работаю, не сможет сохранить весь набор данных в памяти.
Я структурировал базу данных, таким образом, что основная таблица данных является просто хранилищем ключа/значения, состоящим из уникального идентификатора и Значения.
Запросы обычно приблизительно для 100 последовательных значений, например. SELECT Value WHERE ID BETWEEN 7000000 AND 7000100;
Я в настоящее время использую MySQL / MyISAM, и эти запросы берут порядок 0.1 - 0.3 секунд, но недавно я пришел к пониманию, что MySQL является, вероятно, не оптимальным решением для того, что является в основном большим хранилищем ключа/значения.
Прежде чем я начну делать большую работу, устанавливающую новое программное обеспечение и переписывающую целую базу данных, я хотел получить общее представление о том, буду ли я, вероятно, видеть значительное повышение производительности при использовании DB NoSQL (например, Тиран Токио, Cassandra, MongoDB) вместо MySQL для этих типов извлечений.
Спасибо
3 ответа
Я использую MongoDB в производстве для интенсивных операций записи, где я делаю намного больше, чем скорость, о которой вы говорите, как для операций записи, так и для операций чтения, размер базы данных составляет около 90 ГБ и один экземпляр (amazon m1.xlarge) делает 100QPS Я могу сказать вам, что типичный запрос ключ->значение занимает около 1-15 мс на базе данных с 150M записей, время запроса достигает 30-50 мс при большой нагрузке. В любом случае, 200 мс - это слишком много для хранилища ключей/значений.
Если вы используете только один сервер, я бы посоветовал mongoDB, поскольку она достаточно эффективна и проста в освоении. если вы ищете распределенное решение, вы можете попробовать любой клон Dynamo: Cassandra (Facebook) или Project Volemort (LinkedIn) - самые популярные. Имейте в виду, что поиск сильной согласованности довольно сильно замедляет работу этих систем.
Пожалуйста, рассмотрите также OrientDB. Он использует индексы с алгоритмом RB+Tree. В моих тестах с базой данных 100 ГБ чтение 100 элементов занимало 0.001-0.015 секунды на моем ноутбуке, но это зависит от того, как ключ/значение распределены внутри индекса.
Чтобы сделать собственный тест, потребуется менее 1 часа.
Одна плохая новость - OrientDB пока не поддерживает кластерную конфигурацию (планируется на сентябрь 2010).
Я ожидал, что Cassandra будет лучше работать там, где набор данных не помещается в памяти, чем система на основе b-дерева, такая как TC, MySQL или MongoDB. Конечно, Cassandra также спроектирована таким образом, что, если вам нужна более высокая производительность, легко добавить больше машин для поддержки вашей рабочей нагрузки.