Я создаю систему, которая отслеживает и проверяет показы объявлений и клики. Это означает, что есть много команд вставки (около 90 секунд в секунду, максимум 250) и некоторых операций чтения, но основное внимание уделяется производительности и делает его быстрым.
В настоящее время система находится на MongoDB, но с тех пор меня познакомили с Cassandra и Redis. Было бы неплохо пойти на одно из этих двух решений, а не остаться на MongoDB? Почему или почему нет?
Спасибо
Для такого вида уборки я бы рекомендовал многоэтапный подход. Редис хорошо разбирается в режиме реального времени. Redis разработан как хранилище ключей/значений в памяти и наследует некоторые очень приятные преимущества в качестве базы данных памяти: операции O (1). До тех пор, пока на сервере имеется ОЗУ, Redis не будет замедлять нажатие до конца ваших списков, что хорошо, когда вам нужно вставлять элементы с такой высокой скоростью. К сожалению, Redis не может работать с наборами данных, превышающими объем оперативной памяти (он записывает только на диск, чтение для перезапуска сервера или в случае сбоя системы), а масштабирование должно выполняться вами и вашим приложением, (Обычный способ заключается в распространении ключей на многочисленных серверах, который реализуется некоторыми драйверами Redis, особенно для Ruby on Rails.) Redis также поддерживает простой публикацию/подписку, которая может быть полезна и в то же время.
В этом случае Redis является "первой стадией". Для каждого конкретного типа события вы создаете список в Redis с уникальным именем; например, у нас есть "просмотр страницы" и "ссылка нажата". Для простоты мы хотим убедиться, что данные в каждом списке одинаковы; ссылка на клик может иметь токен пользователя, имя ссылки и URL-адрес, в то время как просматриваемая страница может содержать только токен пользователя и URL-адрес. Ваша первая проблема заключается в том, чтобы просто получить тот факт, что это произошло, и любые абсолютно необходимые данные, которые вам нужны, толкаются.
Затем у нас есть несколько простых обработчиков, которые берут эту отчаянную информацию из рук Редиса, прося ее взять элемент с конца списка и передать его. Работник может выполнять любые корректировки/дедупликацию/идентификационные запросы, необходимые для правильного заполнения данных и передачи их на более постоянный сайт хранения. Запускайте столько рабочих, сколько нужно, чтобы сохранить нагрузку на память Redis. Вы можете написать работникам все, что пожелаете (Node.js, С#, Java,...), если у него есть драйвер Redis (теперь большинство веб-языков) и один для вашего желаемого хранилища (SQL, Mongo, и др.)
MongoDB хорошо подходит для хранения документов. В отличие от Redis, он может иметь дело с базами данных, большими, чем оперативная память, и поддерживает собственные функции sharding/replication. Преимущество MongoDB над SQL-настройками заключается в том, что вам не нужно иметь заранее определенную схему, вы можете изменить способ хранения данных, но вы хотите в любое время.
Я бы предложил Redis или Mongo для этапа "первого шага" хранения данных для обработки и использования традиционной настройки SQL (возможно, Postgres или MSSQL) для хранения данных, обработанных после обработки. Отслеживание поведения клиента звучит как реляционные данные для меня, так как вы можете захотеть "показать всем, кто просматривает эту страницу" или "Сколько страниц просматривал этот человек в этот день" или "В какой день было больше всего зрителей?". Могут быть еще более сложные объединения или запросы для аналитических целей, которые вы придумали, и зрелые SQL-решения могут сделать для вас большую часть этой фильтрации; NoSQL (специально для Mongo или Redis) не может выполнять объединения или сложные запросы для разных наборов данных.
В настоящее время я работаю в очень большой рекламной сети, и мы пишем в плоские файлы:)
Я лично являюсь монгольским фанатом, но, честно говоря, Редис и Кассандра вряд ли будут действовать лучше или хуже. Я имею в виду, что все, что вы делаете, это бросать материал в память, а затем сбрасывать на диск в фоновом режиме (как Монго, так и Redis делают это).
Если вы ищете невероятную скорость, другой вариант состоит в том, чтобы сохранить несколько показов в локальной памяти, а затем очистить их каждый раз в минуту. Конечно, это в основном то, что Монго и Редис делают для вас. Не настоящая веская причина двигаться.
Все три решения (четыре, если вы считаете плоские файлы) дадут вам яркие быстрые записи. Не реляционные (nosql) решения позволят вам настроить отказоустойчивость, а также в целях аварийного восстановления.
В терминах масштаба наша тестовая среда с тремя узлами MongoDB может обрабатывать 2-3k смешанных транзакций в секунду. На 8 узлах мы можем обрабатывать смешанные транзакции 12k-15k в секунду. Кассандра может масштабироваться еще выше. 250 чтения (или должно быть) не проблема.
Более важный вопрос: что вы хотите делать с этими данными? Операционная отчетность? Анализ временных рядов? Анализ ad-hoc-шаблонов? отчеты в режиме реального времени?
MongoDB - хороший вариант, если вы хотите иметь возможность проводить ad-hoc-анализ на основе нескольких атрибутов в коллекции. Вы можете установить до 40 индексов в коллекции, хотя индексы будут храниться в памяти, поэтому следите за размером. Но результат - гибкое аналитическое решение.
Кассандра - это хранилище ключей. Вы определяете статический столбец или набор столбцов, которые будут действовать в качестве основного индекса прямо вверх. Все запросы, запускаемые против Cassandra, должны быть настроены на этот индекс. Вы можете поставить на него вторичное, но это касается того, насколько это возможно. Разумеется, вы можете использовать MapReduce для сканирования хранилища для не-ключевой атрибуции, но это будет именно так: последовательное сканирование через хранилище. Кассандра также не имеет понятия "как" или регулярных выражений на узлах сервера. Если вы хотите найти всех клиентов, где первое имя начинается с "Alex", вам придется сканировать всю коллекцию, вытащить первое имя для каждой записи и запустить его через клиентское регулярное выражение.
Я не достаточно хорошо знаком с Редисом, чтобы говорить об этом разумно. К сожалению.
Если вы оцениваете нереляционные платформы, вы также можете рассмотреть CouchDB и Riak.
Надеюсь, что это поможет.
Только что нашел это: http://blog.axant.it/archives/236
Цитата из наиболее интересной части:
Этот второй график посвящен Redis RPUSH против Mongo $PUSH и Mongo insert, и я считаю, что этот график действительно интересен. До 5000 записей mongodb $push быстрее даже по сравнению с Redis RPUSH, тогда он становится невероятно медленным, вероятно, тип массива mongodb имеет линейное время вставки, и поэтому он становится медленнее и медленнее. mongodb может получить немного производительности, подвергая постоянному типу списка вставки времени, но даже с линейным типом массива времени (который может гарантировать постоянный поиск по времени) он имеет свои приложения для небольших наборов данных.
Я думаю, все зависит как минимум от типа данных и объема. Лучшим советом, вероятно, было бы сравнение с вашим типичным набором данных и увидеть себя.
В соответствии с базовыми базами данных NoSQL для бенчмаркинга (скачать здесь)
Я рекомендую Кассандру.
Если у вас есть выбор (и вам нужно уйти от плоских бойцов), я бы пошел с Редисом. Его невероятно быстро, удобно справится с нагрузкой, о которой вы говорите, но что более важно, вам не придется управлять кодом очистки/ввода-вывода. Я понимаю его довольно прямой, но меньше кода для управления лучше, чем больше.
Вы также получите варианты масштабирования по горизонтали с помощью Redis, которые вы не можете получить с кэшированием на основе файлов.
Проблема со вставками в базы данных заключается в том, что они обычно требуют записи в случайный блок на диске для каждой вставки. То, что вы хотите, это то, что только записывает на диск каждые 10 вставок или около того, в идеале, в последовательные блоки.
Плоские файлы хороши. Сводные статистические данные (например, итоговые удары на страницу) могут быть получены из плоских файлов масштабируемым образом с использованием алгоритмов типа слияния с уменьшением количества слияния. Это не слишком сложно катить.
SQLite теперь поддерживает запись в журнале записи, которая также может обеспечить адекватную производительность.
Я могу получить около 30 тыс. вставки/сек с помощью MongoDB на простой $350 Dell. Если вам нужно всего около 2 тыс. Вставок в секунду, я бы придерживался MongoDB и масштабировал его для масштабируемости. Возможно, вы также изучите что-то с Node.js или что-то подобное, чтобы сделать вещи более асинхронными.
У меня есть практический опыт работы с mongodb, couchdb и cassandra. Я преобразовал много файлов в строку base64 и вставлял эту строку в nosql.
mongodb является самым быстрым. Кассандра медленнее. couchdb тоже медленный.
Я думаю, что mysql будет намного быстрее, чем все из них, но я еще не пробовал mysql для моего тестового примера.