Агрегация данных Mongodb против MySQL

Question

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

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

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

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

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

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

Я также сделал тест с помощью couchdb, и результаты были намного хуже.

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

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

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

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

Answer 1

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

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

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

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

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

С

Answer 2

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

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

Answer 3

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

Answer 4

Или может быть hadoop (http://hadoop.apache.org/) или hadoopdb (http://db.cs.yale.edu/hadoopdb/hadoopdb.html)?