Как обрабатывать и хранить огромное количество tracking-запросов?
Имеется JS скрипт, похожий на Я.Метрику и Google Analytics который клиенты устанавливают на свои сайты. Скрипт отправляет данные о каждом посетителе на мой сервер.
Как с архитектуной точки зрения организовать обработку и хранение потенциального огромного потока данных, например используя средсва Azure?
Интересуют вещи, такие как сам API-обработчик запросов, куда данные непосредственно будут прилетать с JS-трэкера, так и хранилище, куда API будет эти данные складывать.
Данные будут извлекаться веб-приложением а-ля dashboard, поэтому быстрое извлечение и сортировка данных актуальны.
Идеи которому самому приходят в голову:
- Иметь load-balancer который будет распихивать запросы на обработку в API приложения в ближайших к клиенту ДЦ (региону)
- Иметь распределенное хранилище (смотрю в сторону CosmosDB)
sim3x,
Redis для кэширования очереди на вставку или для выборки?
Почему реляционная база и конкретно Postgresql? Мне видется хранилище с широкими таблицами, типа ClickHouse/Cassandra будет лучшим выбором.
Данных сотни миллионов строк, мне даже сложно предсказать сколько, т.к. очень сильно зависит от аткивности пользователей на сайтах клиентов. Скажем, если нашим клиентом станет популярный сайт с миллионами активных пользователей, то RPS может быть очень высоким (>1000)
Если требуется одновременно и отслеживание событий в реальном времени и аналитика на основе исторических данных, то рекомендую посмотреть на Lambda Architecture. В ней выделяются две части: не-реляционная «batch»-часть (на Hadoop, например) и потоковая, называемая «speed».
Если такой необходимости нет, то подойдет и связка из очереди (Kafka, например, или data collector вроде Flume и Fluentd), хранилища (ClickHouse, Cassandra, HBase) и средств аналитики (Spark, Impala, ElasticSearch).
ozket, звучит очень интересно. Быстроe гугление говорит что в Azure есть целый стэк для этого - HDInsight, в котором и Spark, и Hadoop, и Kafka. Надо будет углубленно поизучать.
Смотрю сразу все в облаке, т.к. ресурсов для всей инфранстуктуры и поддержки в команде нет.
Почему постгрес - потому что единственная бесплатная СУБД с открытым кодом
Если у вас есть возможность для експериментов, то пробуйте все решения
Если решить задачу - берите самое надежное
У вас будет 1-10 строк в которых будет храниться агрегированная информация, которая на самом деле требуется
Те кто действительно хотят посчитать все - поймут получение результата в течении часа/суток
Гугл выдает приблизительную статистику по всем срезам
Хотите быть круче гугла - нанимайте инженеров круче ихних
RPS может быть очень высоким (>1000)
1k RPS не много
После 100к начинается зона, где нужно думать
Но не в вашем кейсе
Облако - дорогое удовольствие
Оно вам нужно, когда у вас експоненциальный рост
И рост окупает ваши дикие счета
sim3x, Спасибо за ваше мнение.
Вопрос об open source не стоит. Помимо Postgresql еще тонна других бесплатных баз, как реляционных, так и нет.
Как я уже сказал, облако выбираем т.к. у самих всю инфрастуктуру нет сил и времени настраивать и поддерживать. Для того же Postgresql нужна виртуалка, тюнинг, и т.д., и пока цена за облако меньше зарплаты доп. сотрудников которые бы этим всем занимались, то бизнес выбирает облако.
sim3x, Не вижу связи между нагрузкой и open source.
назовите один
Давайте не будем опускаться в полемику :) - берите да гуглите, помимо тех же ClickHouse, MySQL и его форка MariaDB я уверен найдется с десяток как реляционных, так и нет, просто задачи у всех разные.
Pavel Pikat, мускул и его производные не являются СУБД
Они есть движки для движков СУБД таких как innoDB
И из-за такой компоновки имеют архитектурные проблемы
Это просто адовая дичь какая то с самописными KITTEN/MEOW методами.
Я конечно понимаю что ВК можем сам себе может понаписать какие угодно костыли, но другим это не стоит рекомендовать.
dimonchik2013, намеки в виде ответов это так себе занятие, знаете ли
Может вы бы еще просто ссылку на гугл оставили - "кто ищет, тот всегда найдет".
По факту ClickHouse и так под прицелом, в комментах под вопросом его немного обсудили. Товарищ sim3x вот с опаской на него смотрит, т.к. яндексовская поделка.
Простой
Средний
