это навернное самое неинтересное что у нас есть :)
вот толи дело распределенный по всем контитнетам децентрализованный серверный бекенд… это да, крутота. А мысль хранить данные в удобном для обработки виде вместо удобного для сбора — это тривиально.
В самом деле, зачем мне хранить огромное количество сырых данных, если их можно схлопнуть в 2-3 значения важных для бизнеса? Таким образом мегабайты серверных логов превращаются в байты.
ну и понятно что модель эта спроектирована таким образом чтобы можно было лехко осуществлять поиск по нужным полям.
к примеру выбрать всех пользователй которые появлялись вблизи точки 34.23456, 12.232323 не менее 5ти раз, при этом зарегистрировались в мае, и ни разу не оправляли картинки другим пользователям.
это по монгоДб делается в один запрос по набору полей. Быстро, просто, красиво.
опредеделенные данные о пользователе, график его суточной активности по часам и дням недели, взаимоотношения с другими пользователями, набор мест где он преимущественно находится, обращение к разным методам АПИ и т.д. Не пользовался он ни разу за неделю функционалом «сменить скин приложения» мы ему можем взять и выслать сообщение что такой функционал есть.
>>Мы же используем инфраструктуру данных для кампейнинга: выборке пользователей для отправки им персонализированных сообщений. Мы выявляем пользователей, которые не заходили несколько недель на сайт, чтобы рассказать им через email, что интересного у нас появилось, пока их не было. Мы напоминаем игрокам об их Fantasy-команде или турнире прогнозов, которые они забросили. Мы приглашаем болельщиков в тематические форумы по интересам.
так построили бы необходимую вам поведенческую модель юзера и делали бы выборки по ней. У нас поведенческие модели на 600 000 кастомеров хранятся в отдельной базе, занимают весьма мало места и апдейтятся 15 000 000 раз в сутки. Все живет на одном арендованном сервере. Разработка заняла одну неделю. Доделки под текущие бизнесзадачи занимают от 10 минут до дня.
Мы тут доделываем сервис по анализу производительности приложений, с помощью которого можно делать замеры с какой скоростью работают различные куски кода.
И что самое хорошее это все прямо на продакшине можно делать, а не на синтетике. И на любом хостинге, потому что не требует сторонних расширений.
Ну собственно чтобы разрабатывать систему на уровне интерфейсов и абстракций, а не на уровне конкретных реализаций и была заложена такая архитектура. Сейчас центральное место занимает Yii, но ничто нам не мешает начать плавный процесс перехода на другие ЯП или фреймворки, переписывая приложение за приложением и компонент за компонентом, следя чтобы не ломались интерфейсы между ними.
Собственно у нас это сейчас и происходит. Мы планомерно меняем высоконагруженные модули на PHP на серверные демоны на C++ c которыми работаем через Thrift протокол. А часть функциональных приложений прям напрашивается, чтобы их переписали на Erlang, т.к. от них требуется работа на распределенном кластере, высокая надежность и горячее обновление кода.
Email info@thefridge.info
Password thefridge
Это PHP приложение на Yii + MongoDB обслуживающее специфичное приложение на андроиде. Юзеров там пока с десяток человек, поэтому смотрите.
Вобще по сути PRFLR предназначен для получения аналитики на кластерах в десятки машин, но и на одной можно поглядеть.
Только объем отправляемых данных существенно меньше и полностью контролируем со стороны пользователя.
P.S. Скажу честно, проект возник когда нам надоело возиться с пинбой до скрежета зубов.
А что под этим подразумевалось кстати?
Не буду с вами спорить за хайлоад проекты. Каждый владелец волен сам принимать решения что ему использовать, и какие ресурсы на это тратить.
вот толи дело распределенный по всем контитнетам децентрализованный серверный бекенд… это да, крутота. А мысль хранить данные в удобном для обработки виде вместо удобного для сбора — это тривиально.
В самом деле, зачем мне хранить огромное количество сырых данных, если их можно схлопнуть в 2-3 значения важных для бизнеса? Таким образом мегабайты серверных логов превращаются в байты.
к примеру выбрать всех пользователй которые появлялись вблизи точки 34.23456, 12.232323 не менее 5ти раз, при этом зарегистрировались в мае, и ни разу не оправляли картинки другим пользователям.
это по монгоДб делается в один запрос по набору полей. Быстро, просто, красиво.
У нас мобильнео приложение гео-радар. i-am-app.ru
так построили бы необходимую вам поведенческую модель юзера и делали бы выборки по ней. У нас поведенческие модели на 600 000 кастомеров хранятся в отдельной базе, занимают весьма мало места и апдейтятся 15 000 000 раз в сутки. Все живет на одном арендованном сервере. Разработка заняла одну неделю. Доделки под текущие бизнесзадачи занимают от 10 минут до дня.
напишите на info@prflr.org — пришлем данные к аккаунту
p.s. еще рекомендую нажать на «забыли пароль?» :)
Мы тут доделываем сервис по анализу производительности приложений, с помощью которого можно делать замеры с какой скоростью работают различные куски кода.
И что самое хорошее это все прямо на продакшине можно делать, а не на синтетике. И на любом хостинге, потому что не требует сторонних расширений.
prflr.org — вот ссылка.
P.S& Про пинбу знаем, но это на пинбу похоже толко тем что есть слово UDP.
Собственно у нас это сейчас и происходит. Мы планомерно меняем высоконагруженные модули на PHP на серверные демоны на C++ c которыми работаем через Thrift протокол. А часть функциональных приложений прям напрашивается, чтобы их переписали на Erlang, т.к. от них требуется работа на распределенном кластере, высокая надежность и горячее обновление кода.