Агрегирование данных mongodb vs mysql

В настоящее время я изучаю бэкэнд для использования в проекте с требовательными требованиями к агрегации данных. Основные требования к проекту следующие.

  • Храните миллионы записей для каждого пользователя. У пользователей может быть более 1 миллиона записей в год, поэтому даже со 100 пользователями мы говорим о 100 миллионах записей в год.

  • Агрегирование данных по этим записям должно выполняться "на лету". Пользователи должны иметь возможность фильтровать записи на тонну доступных фильтров, а затем представлять резюме (итоговые значения, средние значения e.t.c) и графики результатов. Очевидно, я не могу предсказать какие-либо результаты агрегирования, потому что комбинации фильтров (и, следовательно, множества результатов) огромны.

  • Пользователи получат доступ только к своим собственным данным, но было бы неплохо, если бы анонимные статистические данные могли быть рассчитаны для всех данных.

  • Данные будут проводиться большую часть времени в пакете. например, пользователь будет загружать данные каждый день, и может потребоваться 3000 записей. В более поздней версии могут быть автоматические программы, которые загружаются каждые несколько минут меньшими партиями из 100 элементов, например.

Я сделал простой тест на создание таблицы с 1 миллионом строк и выполнение простой суммы 1 столбца как в mongodb, так и в mysql, и разница в производительности была огромной. Я не помню точные цифры, но это было что-то вроде mysql = 200ms, mongodb = 20 секунд.

Я также провел тест с couchdb и имел гораздо худшие результаты.

То, что кажется многообещающим с точки зрения скорости, - это cassandra, с которым я был очень в восторге, когда впервые обнаружил его. Однако документации недостаточно, и я не нашел твердых примеров того, как выполнять суммы и другие агрегированные функции в данных. Возможно ли это?

Как мне кажется, из моего теста (возможно, я сделал что-то не так), с текущей производительностью невозможно использовать mongodb для такого проекта, хотя автоматическая функция ошпаривания кажется идеально подходящей для этого.

Есть ли у кого-нибудь опыт сбора данных в mongodb или какие-либо сведения, которые могут помочь в реализации проекта?

Спасибо, Димитрис

ОТВЕТЫ

Ответ 1

Я никогда не впечатлял производительность MongoDB в случаях использования, где требуется javascript, например map-reduce-jobs. Может быть, лучше в 1.51. Я не пытался.

Вы также можете попробовать бесплатную версию node Greenplum: http://www.greenplum.com/products/single-node/ и http://www.dbms2.com/2009/10/19/greenplum-free-single-node-edition/

Ответ 2

Если вы ищете высокопроизводительную СУБД и не нуждаетесь в ее реляционной связи, вы можете подумать о Cassandra, хотя ее преимущества только начинают действовать, если у вас есть кластер базы данных, а не один node.

Вы не сказали, какие ограничения существуют в физической архитектуре. Вы упомянули о шраме, который подразумевает кластер. Кластеры IIRC MySQL также поддерживают шрамы.

Также было бы полезно узнать, какой уровень concurrency предназначен для поддержки системы, и как будут добавляться данные (капельная подача или пакетная обработка).

Вы говорите: "Очевидно, я не могу предсказать какие-либо результаты агрегации, потому что комбинации фильтров (и, следовательно, множества результатов) огромны".

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

С.

Ответ 4

Если простая сумма в 1 миллион документов заняла 20 секунд в Монго, у вас, вероятно, недостаточно оперативной памяти. Важно, чтобы с Mongo вы могли сохранить весь набор данных в памяти или производительности. Вы не упомянули, как вы сделали подсчет, возможно, это проблема с вашим кодом сокращения кода? Там слишком мало деталей, чтобы сказать, в чем проблема, но я сделал более сложную карту, уменьшая с порядком больше документов, которые занимали меньше времени только на моем ноутбуке.