А есть информация по тому, какой rps и на каком датасете дает оптимальные результаты при работе с NVMe на одном сервере. Объясню, в нашем случае, когда работаем с RAM, мы вообще не паримся с количеством инстансов, ограничение по сути — это слоты оперативной памяти, и мы ни разу не упирались в rps, запас по нагрузке в десятки раз больше, чем есть.
Отличная статья, хорошо, когда коллеги по цеху делятся опытом. Есть пару вопросов:
1. Вы пишите про использование Aerospike на NVMe дисках. У вас при этом гибридная схема хранения? Просто если все в RAM, то не понятно, какой прирост дает NVM?
2. Как синхронизируете Aerospike в разных локациях: родную синхронизацию или еще как?
Тут скорее ответ выглядит так: у кого какой опыт с той или иной базой. Чтобы потестить базу в High Load проектах, нужно с этой базой в реальных условиях пожить 3-5 месяцев, чтобы узнать все плюсы и минусы. Так что HBase выбрали исходя из предыдущего опыта, а Cassandra испытывалась только на локальном компе)
Если Cassandra вместо Spark, то смысла не вижу, тк основное требование у нас — это гибкость обработки и возможность использовать обычный язык программирования. Что бы там не предлагала Кэсси — мы всегда будем зависеть о ее ограничений. Если заметили, мы в реалтайме еще собираем HyperLogLog каждого аудиторного сегмента.
Из баз данных, которые из коробки предлагают все, что нам нужно было в этой задаче — VoltDB. Но я не могу ручаться за то, что с ней не было бы каких-то косяков и ограничений.
Spark далеко не обрезок, и, наоборот, по сравнению с классическим MR предоставляет абсолютный контроль над обработкой данных. Напишите пример задачи обработки, чтобы понять, где Spark будет лажать
Вы в статье упустили важную часть, как раз про описание аудиторий, а также про модель данных (Event). В общем вся суть для чего мы вообще эту архитектуру задумали) Получилось очень сильно про Spark, но мало — какую задачу решает.
Aerospike — хранит уже готовые профили пользователей, например таблица visitor_id; audiences[]. Когда в DSP приходит RTB-запрос, то используется именно Aerospike. Здесь пока ни одна другая база не показывала такие результаты быстродействия, низкий latency, и низкую загрузку процессора.
Mongo — хороша для кодеров, когда нужно сохранить объект в базу. Здесь Mongo со своей документ-ориентированной архитектурой вне конкуренции. Нагрузки практически не держит. В общем эта база только под специфические задачи осталась.
HBase — у нас пришла на смену Mongo, но пока не везде смогла вытеснить ее из-за ограничений. HBase интегрирован в кластер Hadoop и ее реально можно настроить на высокую отказоустойчивость и быстродействие. Также очень важна рандомная запись/чтение, что Mongo ну совсем никак не настроить
FrostNova Кстати а, что здесь Mongo делает, мы вроде ее уже выпилили?
TF-IDF и прочие плюшки больше характерны для задачи классификации страниц. Здесь больше задача про пользователя.
Есть мысли попробовать следующее:
— Индексировать пользователей по LDA-топикам (то есть не все ключевые слова, а только те, что влияют на определение темы страницы)
— Сделать расширенный поиск. Рекламодатель вводит ключевые слова, а поиск осуществляется по тому, в какие топики входят эти слова.
1. Текст вынимается целиком абзацами, фильтруется и сохраняется в Solr. Заботу по поиску он уже берет на себя. Solr поддерживает большое количество операторов поиска.
2. В поиске Google, Yandex, Mail. А как же шифровка referer? Не знаю, посмотрите в GA, увидите там небольшой процент нешифрованного трафика, 3-8%. В рамках тех объемов, что мы получаем количество поисковых запросов достаточно много. В статье мы намеренно опустили, как мы его обрабатываем, т.к. задача это простая, только текст усложнили бы.
— Поставщики по-разному отдают: мы ставим коды (в этом случае в Kafka информация уходит с наших же серверов), присылают по протоколу zeromq, либо http протоколу. В общем маршрут до Kafka проходит в большинстве случаев еще через какие-нибудь сервисы.
— Spark — это VisitorActionReciever. Да не понятно, надо подправить.
— Spark на Java писали. Кстати, в статье есть кусок кода.
— Solr. Прямо скажем, из-за Cloudera. На уровне индекса Solr и ElasticSearch — это все Lucene. Возможно когда-нибудь попробуем ES для этой задачи, но если упремся в производительность Solr. На текущий момент все устраивает.
Я думаю по мотивам этих вопросов лучше статью написать с бенчмарками. Пока стоит на слово поверить, 7 000 rps наш биддер держит, но пришли мы к этому тоже не за один день.
70 запросов / 24 потока (2 процессора по 6 ядер с включенным Hyper Threading) = 3 запроса на 1 поток за мс. Также учитывая, что каждый запрос не выполняется меньше, чем 10 мс, а 2-3 в среднем, то получаем 1 запрос на 1 поток на мс.
1. Вы пишите про использование Aerospike на NVMe дисках. У вас при этом гибридная схема хранения? Просто если все в RAM, то не понятно, какой прирост дает NVM?
2. Как синхронизируете Aerospike в разных локациях: родную синхронизацию или еще как?
Из баз данных, которые из коробки предлагают все, что нам нужно было в этой задаче — VoltDB. Но я не могу ручаться за то, что с ней не было бы каких-то косяков и ограничений.
Mongo — хороша для кодеров, когда нужно сохранить объект в базу. Здесь Mongo со своей документ-ориентированной архитектурой вне конкуренции. Нагрузки практически не держит. В общем эта база только под специфические задачи осталась.
HBase — у нас пришла на смену Mongo, но пока не везде смогла вытеснить ее из-за ограничений. HBase интегрирован в кластер Hadoop и ее реально можно настроить на высокую отказоустойчивость и быстродействие. Также очень важна рандомная запись/чтение, что Mongo ну совсем никак не настроить
FrostNova Кстати а, что здесь Mongo делает, мы вроде ее уже выпилили?
Есть мысли попробовать следующее:
— Индексировать пользователей по LDA-топикам (то есть не все ключевые слова, а только те, что влияют на определение темы страницы)
— Сделать расширенный поиск. Рекламодатель вводит ключевые слова, а поиск осуществляется по тому, в какие топики входят эти слова.
2. В поиске Google, Yandex, Mail. А как же шифровка referer? Не знаю, посмотрите в GA, увидите там небольшой процент нешифрованного трафика, 3-8%. В рамках тех объемов, что мы получаем количество поисковых запросов достаточно много. В статье мы намеренно опустили, как мы его обрабатываем, т.к. задача это простая, только текст усложнили бы.
— Spark — это VisitorActionReciever. Да не понятно, надо подправить.
— Spark на Java писали. Кстати, в статье есть кусок кода.
— Solr. Прямо скажем, из-за Cloudera. На уровне индекса Solr и ElasticSearch — это все Lucene. Возможно когда-нибудь попробуем ES для этой задачи, но если упремся в производительность Solr. На текущий момент все устраивает.
70 запросов / 24 потока (2 процессора по 6 ядер с включенным Hyper Threading) = 3 запроса на 1 поток за мс. Также учитывая, что каждый запрос не выполняется меньше, чем 10 мс, а 2-3 в среднем, то получаем 1 запрос на 1 поток на мс.