Агрегация данных mongodb vs mysql

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

C.

Answer 3

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

Answer 4

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