NoSQL & AdHoc Queries - Миллионы строк

Question

В настоящее время у меня есть веб-сайт на базе MySQL, где пользователи продвигают рекламные объявления и получают доход каждый раз, когда кто-то их завершает.Мы ведем журнал каждый раз, когда кто-то просматривает объявление («показ»), каждый раз, когда пользователь нажимает кнопку «добавить» («клик»), и каждый раз, когда кто-либо завершает показ объявления («лидирует»).

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

МыВы хотите отойти от MySQL и перейти к хранилищу значений ключей или что-то в этом роде.Нам нужно что-то, что позволит нам хранить все эти миллионы строк, запрашивать их в миллисекундах и, что самое важное, использовать специальные запросы, где мы можем запросить любой отдельный столбец, чтобы мы могли делать такие вещи, как:

ОТ отведений ГДЕстрана = 'US' И user_id = 501 (очевидно, эквивалент NoSQL)

ОТ кликов ГДЕ ad_id = 1952 И user_id = 200 И страна = "ГБ"

и т. д.

У кого-нибудь есть хорошие предложения?Я рассматривал MongoDB или CouchDB, но я не уверен, смогут ли они обрабатывать запросы миллионов записей несколько раз в секунду и какой тип запросов adhoc нам нужен.

Спасибо!

Answer 1

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

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

Answer 2

Большинство людей, вероятно, по уважительным причинам рекомендуют MongoDB для такой системы отслеживания / анализа.Вам следует прочитать главу «MongoDB для аналитики в реальном времени» из книги «Подробное руководство MongoDB».В зависимости от размера ваших данных и потребностей в масштабировании вы можете получить все функции производительности, хранилища без схемы и специальные запросы.Вам нужно будет решить для себя, являются ли проблемы с долговечностью и непредсказуемостью системы рискованными для вас или нет.

Для более простой системы отслеживания Redis будет очень хорошим выбором, предлагаябогатая функциональность, невероятная скорость и долговечность.Чтобы понять, как такая система будет реализована в Redis, см. this gist .Недостатком является то, что вам нужно определить все «индексы» самостоятельно, а не получить их «бесплатно», как в случае с MongoDB.Тем не менее, бесплатного обеда не существует, и индексы MongoDB определенно не являются бесплатным обедом.

Я думаю, вам следует изучить, как ElasticSearch может включить вас:

• Сверкающая скорость
• Хранилище без схемы
• Архитектура с разделением и распределением
• Мощные аналитические примитивы в виде граней
• Простая реализация типа «скользящего окна» для хранения данных с индексными псевдонимами

Это сердце «полнотекстовой поисковой системы», но не запутайтесь в этом.Прочитайте статью «Визуализация данных с ElasticSearch и Protovis» , в которой вы найдете пример применения ElasticSearch в качестве движка для интеллектуального анализа данных.

Посмотрите на эти слайды для реальногосценарий использования в мире для сценария «скользящее окно».

Для ElasticSearch доступно множество клиентских библиотек, таких как Tire для Ruby, поэтому с помощью прототипа легко начать работу.

Для записи (при всем моем уважении к @jhs :), исходя из моего опыта, я не могу представить реализацию, в которой Couchdb является выполнимой и полезной опцией.Это было бы отличное хранилище резервных копий для ваших данных.

Answer 3

CouchDB отображает / уменьшает добавочный , что означает, что он обрабатывает документ только один раз и сохраняет результаты.

Предположим на мгновение, что CouchDB - самая медленная база данных в мире,Ваш первый запрос с миллионами строк занимает, может быть, 20 часов.Это звучит ужасно.Однако ваш второй запрос, ваш третий запрос, ваш четвертый запрос и ваш сотый запрос займут 50 миллисекунд, возможно 100, включая HTTP и задержку в сети.

Вы могли бы сказать, что CouchDB не проходит тесты, но получает отличные результаты в школе.жестких ударов.

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

Все ваши примеры возможны с CouchDB.Так называемое merge-join (множество условий равенства) не является проблемой.Однако CouchDB не может поддерживать несколько запросов неравенства одновременно.Вы не можете запросить CouchDB в одном запросе для пользователей в возрасте от 18 до 40 лет, которые также нажали менее 10 раз.

Приятная вещь в HTTP и Javascript интерфейсе CouchDB заключается в том, что можно легко провести быстрое технико-экономическое обоснование.,Я предлагаю вам попробовать!

Answer 4

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

Вам также необходимо вспомнить теорему CAP: большинство баз данных NoSQL в конечном итоге становятся согласованными (CP или AP), тогда как традиционными реляционными СУБД являются CA. Это повлияет на то, как вы обрабатываете данные и создаете определенные вещи, например, генерация ключей может оказаться хитрой.

Также помните, что в некоторых системах, таких как HBase, нет концепции индексирования. Все ваши индексы должны быть построены с помощью логики вашего приложения, и любые обновления и удаления должны будут управляться как таковые. С Mongo вы можете создавать индексы на полях и запрашивать их относительно быстро, также есть возможность интегрировать Solr с Mongo. Вам не нужно просто выполнять запрос по идентификатору в Mongo, как в HBase, который является семейством столбцов (то есть базой данных в стиле Google BigTable), где у вас по существу есть вложенные пары ключ-значение.

Итак, еще раз речь идет о ваших данных, о том, что вы хотите сохранить, как вы планируете их хранить и, что наиболее важно, как вы хотите получить к ним доступ. Проект Lily выглядит очень многообещающе. В работе, с которой я работаю, мы берем большое количество данных из Интернета и храним их, анализируем, анализируем, анализируем, анализируем, транслируем, обновляем и т. Д. И т. Д. Мы не просто используем одну систему, но много которые лучше всего подходят для работы под рукой. Для этого процесса мы используем разные системы на разных этапах, поскольку он дает нам быстрый доступ туда, где он нам нужен, предоставляет возможность потоковой передачи и анализа данных в режиме реального времени и, что важно, отслеживает все по ходу работы (как потеря данных в продуктовой среде). система это большое дело). Я использую Hadoop, HBase, Hive, MongoDB, Solr, MySQL и даже старые добрые текстовые файлы. Помните, что производить систему с использованием этих технологий немного сложнее, чем устанавливать MySQL на сервер, некоторые выпуски не так стабильны, и вам действительно нужно сначала провести тестирование. В конце концов, это действительно зависит от уровня сопротивления бизнеса и критического характера вашей системы.

Еще один путь, который до сих пор никто не упоминал, - это NewSQL, то есть горизонтально масштабируемые СУБД ... Есть несколько таких, как кластер MySQL (я думаю) и VoltDB, которые могут подойти вам.

Опять же, речь идет о понимании ваших данных и схем доступа, системы NoSQL также не являются нереляционными, то есть не являются реляционными и лучше подходят для нереляционных наборов данных. Если ваши данные по своей природе являются реляционными, и вам нужны некоторые функции SQL-запросов, которые действительно должны выполнять такие вещи, как декартовы продукты (также называемые объединениями), тогда вам лучше придерживаться Oracle и тратить некоторое время на индексацию, сегментирование и настройку производительности.

Мой совет - поэкспериментировать с несколькими разными системами. Однако для вашего случая использования я думаю, что база данных семейства столбцов может быть лучшим решением, я думаю, что есть несколько мест, где реализованы аналогичные решения для очень похожих проблем (я думаю, что NYTimes использует HBase для отслеживания кликов на странице пользователя). Еще один замечательный пример - Facebook, и они используют HBase для этого. Здесь есть действительно хорошая статья, которая может помочь вам в дальнейшем и более подробно объяснить некоторые моменты выше. http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html

Конечным моментом будет то, что системы NoSQL не являются всем и заканчивают все. Помещение ваших данных в базу данных NoSQL не означает, что они будут работать лучше, чем MySQL, Oracle или даже текстовые файлы ... Например, см. Этот пост в блоге: http://mysqldba.blogspot.com/2010/03/cassandra-is-my-nosql-solution-but.html

Я бы посмотрел;

MongoDB - документ - CP

CouchDB - документ - AP

Redis - значение ключа в памяти (не семейство столбцов) - CP

Cassandra - семейство столбцов - доступно и допустимо для разделов (AP)

HBase - семейство столбцов - согласовано и разделеноТолерантный (CP)

Hadoop / Hive - Также обратите внимание на потоковую передачу Hadoop ...

Hypertable - Другая база данных CF CP.

VoltDB - действительно красивый продукт, база данных отношений, которая распространяется и может работать для вашего случая (это может быть проще).Похоже, что они также предоставляют корпоративную поддержку, которая может больше подходить для продуктивной среды (т. Е. Дать бизнес-пользователям чувство безопасности).

Любой способ, который мой 2c.Игра с системами - действительно единственный способ узнать, что действительно работает для вашего случая.

Answer 5

Если ваш рабочий набор может поместиться в памяти, и вы проиндексировали правильные поля в документе, все будет готово.Ваш вопрос не является чем-то очень типичным, и я уверен, что при правильном оборудовании, правильном дизайне коллекции (денормализация!) И индексации вы должны быть в порядке.Читайте о запросах Монго и используйте explain() для проверки запросов.Держитесь подальше от пунктов IN и NOT IN, которые были бы моим предложением.