> монгу
Смотрите на поехавшего.
Родина, блядь, дала rrdtools, дала statsd, дала collectd, дала graphite, да чего только блядь не дала — пользуйся. Нет, хочу мильярд рядов в мускуле заменить мильярд документов в монге.
Если понятно что хочется считать — ну так считайте, блядь, сразу, нахуй вам сырое говно-то? А если вы там ебнулись и хотите статистику, но сами не знаете какую - не выебывайтесь, логируйтей в сислог. Когда поймете хуле вы бетмены, тогда и распарсите ретроспективно.
Реально, шило на мыло. Только одно шило старое, а другое новое и инстаграмами старбаксовского смуззи пахнет.
ващето сначала бы сказал какого вида данные
>ороче есть пиздулина, которая вешается на сайт и собирает с него статистику о действиях пользователя. В день логируется несколько миллионов записей с перспективой адского роста в ближайшее
касандра
>Хочу заменить mysql на монгу
сольёшся
>Подкиньте что-нибудь почитать по этому поводу.
касандра планет
-----------------------
да и сразу готовь мозги к денормолизации, в касандре ненормализированые данные это норма.
Да не нужна ему кассандра, ну наверняка же. Все шансы за то что надо тупо не пытаться высрать тугой поток логоблевотины выше всех разумных IOPSов, что его только распределенная хуйлоадная кластерная пиздопроебина только и сумеет принять в себя, а считать все на ходу и тут же отбрасывать бессмысленное сырое говно.
>считать все на ходу и тут же отбрасывать бессмысленное сырое говно
define всё
Не ко мне вопрос а к ОПу.
Но так, вообще говоря — все что ебет ОПа. Количество, частота, длина, толщина. Минимумы, максимумы, средние, производные, прогнозы и интервалы, да что надо то и пусть считает, хуле.
Или дефолтная ганглия (rrdt) или ебись с эластиксерчем (но хуй знает, потянет ли такой хайлоад) -- самое простое для новичков. В обоих случаях сначала читай орейли-парашу, затем so вдоль и поперек, потом максимально много ебись со всем вот этим вот. Готовых рецептов "под ключ" тебе никто не даст.
>эластиксерчем
>хранить данные
Хуле тут такого, если это логи
Вон есть логстеш с кибаной для подобной хуйни- графики даже сам рисует
ОП в треде. Я видимо плохо объяснил суть проекта. Компания делает какой-то ИННОВАЦИОННЫЙ ПОЛЬЗОВАТЕЛЕОРИЕНТИРОВАНЫЙ онлайн-консультант. Мы отдаем клиенту ссылочку на js файл, которую тот устанавливает у себя на сайте. Активность пользователей на этом сайте мы и логируем. Такой специфичный google analytics ЧаТиК))))) edition.
И еще один веселый факт: бэкэнд проекта написан на PHP.
Пока непонятно, какую статистику продаваны хотят показывать владельцу интернет-магазина тульских унитазов, поэтому логируется все подряд.
Спасибо, попробую почитать.
А почему Кассандра подходит для этой задачи больше, чем монга ?
Cпасибо, ананасы.
Сам до сих пор охуеваю от того, куда я попал. Никакого computer science бэкграунда у меня нет, зато есть целый год эталонного пхп-макакинга. С данными работал на уровне "ТАааК СЮДА ПАРУ ДЖОИНОВ, ЗДЕСЬ ГРУП БАЙ, НО ЕСЛИ У НАС ТУТ ПОДЗАПРОС БУДЕТ ТАААААК ПАДАЖЖИ ЕБАНА".
К понедельнику нужно предоставить примерный план действия, по изменению способа хранения данных, пока продажники слишком много не на продавали. Ох лол, надеюсь, меня не уволят через неделю.
И еще один веселый факт: бэкэнд проекта написан на PHP.
Пока непонятно, какую статистику продаваны хотят показывать владельцу интернет-магазина тульских унитазов, поэтому логируется все подряд.
Спасибо, попробую почитать.
А почему Кассандра подходит для этой задачи больше, чем монга ?
Cпасибо, ананасы.
Сам до сих пор охуеваю от того, куда я попал. Никакого computer science бэкграунда у меня нет, зато есть целый год эталонного пхп-макакинга. С данными работал на уровне "ТАааК СЮДА ПАРУ ДЖОИНОВ, ЗДЕСЬ ГРУП БАЙ, НО ЕСЛИ У НАС ТУТ ПОДЗАПРОС БУДЕТ ТАААААК ПАДАЖЖИ ЕБАНА".
К понедельнику нужно предоставить примерный план действия, по изменению способа хранения данных, пока продажники слишком много не на продавали. Ох лол, надеюсь, меня не уволят через неделю.
> Пока непонятно, какую статистику продаваны хотят
Съебывай оттуда нахуй с этого убийцы Google Analytics, вот тебе примерный план действия.
Когда контора продает нечто, не имея даже внятного понимания что именно — это привлекает огромную летающую жопу. Сейчас она постепенно набирает скорость и в недалеком (если продаваны продолжат так ее призывать) будущем прилетит и опустится на вас так, что вы окажетесь там, куда не светит солнце. Начнутся авралы, мозгоебли, клоуныды. "Надо эту метрику вот прямо вчера еще, мы пообещали, очень важный клиент", "а чего у нас страничка с вот этим грузится по две минуты" и прочая пизда. Плохой знак, короче, это.
Но если вдрег решишь остаться — не заебывайся, лучшее хранилище что ты можешь придумать — реально, самые обычные файлы, структурированные не глубже блобов отдельных записей. Т.е., например, даже тупо текстовый файл с JSON-документами, не содержащими "\n", по одному на строчку. Если одна машина не тянет писать файл — шардинг, когда ты раскидываешь по машинам, желательно (если это реально) группируя потоки так, чтобы потом данные сайта унитазов не пришлось собирать со всех нод.
На все это сразу же строй статистику как оно живет. Чтобы ты у себя имел дашборд где четко показано сколько записей и октетов в секунду молотит каждая машина, какая нагрузка на проц (в процентах и попугаях LA), сколько места на дисках, сколько этого всего было по сравнению с неделей (месяцем, тремя) назад, какой прогноз на эту хуйню. Чтобы не попасть в стуацию "шеф, пизда пришла, мы больше не можем работать, сервера-то усираются неделю назад, сейчас заметили" или "шеф, шардинг обосрался, данные с сайта унитазов занимают 70% полосы, storage03 винты издрочил докрасна, а раскидывать не можем, софт у нас еще не готов к такому."
Плюс деплоймент всего этого говна строго не руками, а автоматически. Чтобы — особенно если не приведи случай что-то ебнется, отвалится или вообще сгорит нахуй — еще новые машины вводились не упорной содомией в трое суток, а двумя командами и 5 минутами ожидания пока идет деплоймент. Puppet, Chef, Facter, Ansible, самопальные скрипты — на твой вкус и опыт. Даже разработку лучше вести именно так, ни меняя самому на хостах ничего, только через систему управления конфигурациями и автоматизированные апдейты/редеплойменты. На Vagrant, опять же, можно посмотреть, для тестирования, но это уже совсем опционально. Я просто нажрался такого говна вдоволь, базарю, больше не хочу, теперь с нагруженными распределенными системами (телеком, но суть не меняется), ёб которых сулит хуевые ощущения в заду — только так, "щас в манифесте поправлю и форсированно запущу применение конфигурации" и никакого "щас зайду на хост и файлик поправлю, там хуйня, я быстро, а потом..." Вот и тебе сильно советую.
Почему чем тупее хранилище тем лучше — потому что с любой БД ты получишь лишние IOPSы, а они тебе нахуй не нужны. Индекс построить, хуё, моё, это дополнительные данные, дополнительное дрочево дисков. Учитывая что один хуй не известно чего вы будете считать — ну никакого смысла в них нет. А простейшее индексирование уровня "данные сайта A отдельно от данных сайта B" решается тупо файловой системой. Она пиздатое key-value хранилище, не забывай про это. Некий плюс БД может быть, конечно, в проверках целостности, но никакой WAL для задачи "хранить сырое говно" тебе — вот честно — нахуй не нужен, а цепочку хэшей (типа как journald делает, не к ночи будь помянут) ты можешь и в текстовый файл прекрасно высрать.
Ну разве что может текстовый файл может быть не лучшее решение из-за избыточности сериализации. Может лучше срать каким-нибудь MsgPack'ом или еще чем-то покомпактнее. Или строки жать (zlib, snappy, сам пробуй). Только чтобы формат был self-healing, если вдруг посреди файла случится какой факап (которого вроде и не должно бы никогда быть, но случай бывает всякий) — чтобы было легко найти где пошли снова нормальные данные. У того же текстового файла это тупо поиск следующего "\n" и попытка читать дальше от него. У компактных бинарных логов это может быть сложнее.
Так вот. А когда придумаете что считать и что показывать — пишете обработчик, который оно считает на лету, беря данные из потока, и пишет в удобно структуриованную и подходящую БД (монга для time series это ебаный цирк) уже посчитанную-сагрегированную стату. И этот демон-обработчик кормите смесью свежепоступающего говна и постепенно подсасывающихся старых архивов. Ну, точнее, у вас что-то уже придумано наверняка (ну какая-то совсем простая стата типа хитов-уников), так что зайчаток этого самого обработчика появляться может уже сразу же.
И, еще, последнее. Не покупайся на петушиный хайп, а особенно не перепродавай его сам. В частности, не подписывайтся на "вот так сделаем и будет хорошо, монгу используют компании-лидеры в своей отрасли, все пишем теперь в нее", поясняй "вроде решение подходящее, из всего что я видел выглядит лучше всего, но пока на стенде не соберем и не оттестим сами, для своего случая — я за это поручаться не стану."
Судя по твоему описанию тебе подходит ELK, особого хайлоада у тебя не будет, только действия юзера на сайте.
Сходу советую выкинуть говноподелие на php И заменить его чем-то вменяемым на C#/java/py, C++ в самом крайнем случае. Проблема не в том, что php плохой язык, а в том, что поддержку интеграции этого дела с переферией будет осуществлять крайне сложно (PHP<-> java/c++) и тебе нужно нечто не страдающее собственными болезнями вида "я уже слишком давно работаю, пора бы меня перезапустить, а то память скоро кончится".
Вот этот шарит, правда с хранением в файлах он тебя наебал - заебешься синхронизировать все это богатство по времени, лучше использовать агентированную систему (хватит простого сислог-форматтера на в том самом js файлике, который вы отдаете).
Ну и главное во всем этом деле - сходу раздели деплойные потоки данных и собственные дебажные. Самая жопа у вас начнется с первым деплоем, когда пытливый юзер начнет пихать функционал вашего клиента куда не попадя, а то и дебажить его своими силами (владелец сайта с вероятностью 99% просто наймет фрилансера или передаст админу-васе).
Ну для начала забудь о пхп и прочем говне, и пиши сразу распределённую хуйню на http://akka.io/ , и чтобы никаких блокировок и прочего говна. Дальше уже можешь подумать о компактности данных, но тут уже надо знать конкретику.
>А почему Кассандра подходит для этой задачи больше, чем монга ?
монга ляжет от больших данных
http://blog.markedup.com/2013/03/cassandra-real-time-analytics/
http://blog.markedup.com/2013/04/cassandra-real-time-analytics-part-2/
Ловите наркомана
>что поддержку интеграции этого дела с переферией
>интеграция с переферией
Пиздец, пр сбурище кукаретников. Нахуя ему вся параша целиком на си? Почему бы не катннуть демона как во вменяемых местах аостальную часть оставить на пыхе. Он заебется это поддерживать
> заебешься синхронизировать все это богатство по времени
Не осознал предъявы, поясни. Мое представление такое, что во-первых клиентский браузер добавляет свою метку времени (но мы ей нихуя не верим, мало ли что у него с часами, она нам так, раз можно собрать то собираем, хуле тут, может какой часовой завод будет ебать у многих ли клиентов часы правильно идут, бгг), во-вторых, коллектор добавляет свою, по которой мы и ориентируемся. И, да, на каждой машине ntpd выдрачивает часы, это без оговорок даже. Что именно после этого синхронизировать заебешься?
Если ты про то, что вливая архивы в агрегатор данные с разных шардов пойдут out-of-order, то синхронизатор там нифига не сложный, учитывая что внутри файлов-то все как раз упорядочено. Это же в чистом виде multithreading_laba2, про семафоры и условия, когда потоки вразнобой срут нарастающую последовательность и надо выдать одну совмещенную упорядоченную портянку.
> параша целиком на си
В глаза ебешься? Где он сишку-то советовал?
> Нахуя ему вся параша целиком на си?
Готовая параша на нем во многом написана, а из пхп сложнее тягать си, чем из нормальных языков: C#/Py/Java/etc. Я это имел ввиду.
>ntpd выдрачивает часы
Не всегда выполнимо: дебаг, падение сегментов сети, ретроспективный анализ, попадение двух ntpd демонов с разным конфигом на одну машину, да мало-ли что. Поэтому проще иметь автономную структуру с таймстемпами, которая засинхранизирует все за тебя.
>Если ты про то, что вливая архивы в агрегатор данные с разных шардов пойдут out-of-order
Ну, это тривиально только если они у тебя действительно внутри упорядочены (а на самом деле они у тебя упорядочены до момента сбоя, после момента сбоя, но в момент сбоя там будет набор рандомных стемпов) и идут от множества серверов к одному: но ведь так редко бывает, обычно это иерархия из множества машин и угадать что тебе насортировали предыдущие -- не особо тривиально.
Erlang + Mnesia и можешь забыть о всей хуйне.
/thread
Ну же, синьоры, все ждут ваших прохладных советов за хайлоад, рабочий день начался
> Не всегда выполнимо
Ок, согласен.
> но в момент сбоя там будет набор рандомных стемпов
Дык, это самое, вызовы write нам гарантируют порядок, а битые таймстампы выявлять просто — MAC не сойдется и запись дропнем в хуй как битую. А если уж хэш какой надо значит можно смело считать записано правильно. Учитывая что задача однозначно IO-bound, считать на логописалках хэши записей (причем, как я уже писал, связанные, как в git/journald/...) — хуйня вопрос, проц один хуй будет почти все время курить в ожидании прерываний.
Всякие там охуительные коллизии и перекосоебы барьеров VFS/RAID — не, ну бывает, очереди могут рассыпаться, в теории-то, но это дохуя редкость в такую лотерею выиграть чтобы о подобных факапах серьезно думать. А если уж сорвешь джекпот — ну, главное чтобы было замечено, оповещалка кукарекнула, и там останов фабрички и ручное разгребание говен, хуле поделать.
Не, не можно, тут, конечно, сказать что это будет без redundancy, и если нода проебла свой кусок лога то данные реально проебаны, но если еще на избыточность замахиваться то это и правда пахнет кластером кассандр всяких надо, а что-то мне кажется, это нихуя не уровень ОПовской конторы. Поуходит народ, будут сменного петухана искать — заебутся еще находить знающих. А текстовые файлики любой сменный индус расхуячит на коленке за отзiв. И даже не испортит. Наверное.
Поэтому же, да, жабина, причем без всяких изъебов типа акки, а не эрланги с мнезиями.
В ком-то веки интересный тред в pr, бамп
И чего тут интересного? Если так задуматься-то — стоит петушиная задача по перекладыванию байтиков, лог записать да метрики посчитать. Задача пиздиллион раз уже решенная и еще пиздиллион раз еще будет перерешенная. Ибо пик стронгли рилейтед.
И все что тут есть это еблево с инструментами обычное и обход их неумений и недостатков. Там учти, здесь сообрази, тут не напорись — и никакой души, в общем-то. Такое же, в общем-то, тухлое байтоложество как и шлепанье крудопараши. Ну разве что более редко встречающееся и от того чуть менее разящее потом и говном.
Серьезно. И печально, да. Я на это говно десяток лет жизни угробил, а нахуя...
>стоит петушиная задача по перекладыванию байтиков, лог записать да метрики посчитать. Задача пиздиллион раз уже решенная и еще пиздиллион раз еще будет перерешенная. Ибо пик стронгли рилейтед.
Описал 99% программирования.
>Я на это говно десяток лет жизни угробил, а нахуя...
Просто ты обычный наследственный дебил.
ебать мои регистры это же велосипед из граблей
символичненько
Вот! Во-о-о-т, блядь! В том-то и дело.
Двачую этих господ .
Обработка реалтаймовая с бесконечным числом вариантов запросов и транзакционная точность, какую обеспечивают SQL базы, вам не нужна. Это только лишний оверхед.
1. Собрайте в структурированные файлы, хоть даже в текстовики.
2. Обрабатывайте батчами на COBOL,
3. регулярно получайте результаты,
4. сохраняйте,
5. показывайте пользователям.
6. Profit!
Если количество транзакций реально большое, то купите (или возьмите у IBM в аренду) вместо x86_64 сервер на Power в варианте с IBM i. Там DB2 в комплекте поставки, туда можно скидывать обработанную статистику для удобства.
Если совсем прижмёт производительность, то перейдёте на IBM z без потерь (и код на COBOL, и DB2 спокойно перенести можно).
> COBOL
Люто двачую! Главный плюс - если начнет проседать производительность - всегда можно докупить еще ртутных колб в память, или пару банок с регистрами. И никакой ебучий stl или .net так не сможет.
если начнёт проседать производительность, то он просто добавит ещё одну машину под батчи, или перейдёт на IBM z.
> докупить еще ртутных колб в память, или пару банок с регистрами
Lol. Скажи это CIO крупнейших банков по всему миру, включая Сбер, и всяким там РЖД, РАО ЕЭС, и прочим Роснефтям.
> докупить еще ртутных колб в память, или пару банок с регистрами
Lol. Скажи это CIO крупнейших банков по всему миру, включая Сбер, и всяким там РЖД, РАО ЕЭС, и прочим Роснефтям.
здесь тебе нужны МЭЙНФРЕЙМЫ HLASM
Ты походу досаморазвивался пиздоглазыми мультиками.
Солью немного инфы со своего проекта. Используется bacon-сервера, mr-jobs (hadoop), amazon simple storage (aws, s3), amazon redshift. Цепочки местами витееватые и не совсем понятные, но Амазон делает свое дело, как и куча bacon-серверов.
нагрузка какая? какие данные? сколько каких машин?
ПОСОНЫ, я тут мимо проходил и вообще не шарю. Но разве у ОПа не типичная задача сбора логов под logstash + elasticsearch? Или тупое хуйло прост))?
ОП снова врывается в свой тред. А тем временем градус старбаксовости в нашей компании все увеличивается и увеличивается. Нам нужно асинхронно выполнять запросы, чтобы динамически генерируемый скрипт, который мы отдаем клиенту не затормаживал сайт. Чтобы не положить сервер, решили сделать некое подобие очереди запросов, которая будет очищаться с заданным интервалом времени. Хотим впиндюрить на машину с базой данных node.js и на нем уже эту балалайку написать, но у меня есть ощущение, что мы или изобретаем велосипед или делаем абсолютно нерелевантную задачам хуйню.
Так вот аноны, как можно запросики гонять из php, чтобы не нужно было дожидаться ответа о успешном выполнении.
Так вот аноны, как можно запросики гонять из php, чтобы не нужно было дожидаться ответа о успешном выполнении.
RabbitMQ.
AMQP или тупой список в Redis.
а нахуя вам дожидаться ответа на стороне клиента? хуйнули запрос серверу и забили
сега приклеелась
По описанию лютая хуета какая-то. Если вы меняете синхронные вызовы на асинхронные на клиенте, то как это влияет на структуру сервера? Определитесь с архитектурой системы в целом для начала, пока что судя по косвенным признакам - вы косячите уже там.
Опять мое косноязычие меня подводит. Так и менеджерские позиции в будущем могут мимо пролететь.
Короче есть автоматически генерируемый джаваскрипт-файлик, ссылку на который хозяин магазина с дилдоками ставит на свой сайт. После того, как на сайт заходит новый посетитель, мы на бэкенде при генерации(на самом деле тут уже просто файл из кэша тащим) собираем данные о пользователе и обрабатываем их каким-то ебанутым образом. Сейчас файл до конца не загружается, пока все запросы в mysql базу не будут выполнены, а это тормозит загрузку скрипта и сайта с дилдами. Позднее выполнение запросов никак не функциональнось не влияет, необходимо лишь, чтобы этот запрос был рано или поздно выполнен.
Да я так и хочу сделать, только пхп(на котором мы генерим js файлик) такого не умеет.
Т.е. js делает msql запросы? Так делать нельзя. Сделайте простейшее апи, выбрасывающее нужные данные в одном коротком сообщении вида json/protobuff и обрабатывайте msql на сервере. Почему нельзя делать из js? Во первых никакой асинхрон производительность не пофиксит, во вторых вы не застрахованы от того, что ваш клиент решит ваш же сервис подебажить, в третьих реально скрипт выполняется в js-engine на клиентской стороне, а там подобные финты могут быть запрещены конфигом, что вы естественно не предусмсотрите и последствия будут непредсказуемы. Поэтому - апи и атомарные запросы.
>>Т.е. js делает msql запросы?
Неее, мы отдаем ссылочку вида MoyaStrannayaRabota.xxx/sdelatPizdato.js . Путь на нашем серваке подменяется и выполняется пхп-скрипт, в котором генерируется клиентский js код и выполняется несколько запросиков к mysql. А потом наш код отправляет нужный http заголовок и сгенерированный клиентский js. С клиентского кода ничего никуда не отправляется, чтобы какой-нибудь доморощенный ХаКиРРРР своими ручищами нам какого-нибудь говна вроде pdf-ки "Хаскель для чайников" на сервак не отправил.
Я нихуя не понял.
Значит, у вас есть пхп скрипт, который идёт в базу, собирает там данные о человеке и потом на их основе динамически генерит js-файлик который вы выплёвываете в ответ, так?
Именно, ты все правильно понял. Кроме этого в пхп-скрипте есть несколько запросов запросов на запись в базу о том, откуда пользователь пришел, его айпишник, устройство, сколько он на сайте пробыл, всю простенькую информацию. Вот эти запросы я бы и хотел асинхронно выполнять, все-равно они никак на генерацию js-файла не виляют.
А, ну так сохраняй данные в Redis. Там настроишь репликацию из RAM на диск как тебе удобно. Очереди я так понял тебе не нужны.
Скрипты - в кеш, можно nginx воткнуть, часть нагрузки по вычислению при желании перекинуть на его модули.
Асинхронно выполнять любые запросы зло в коде, отдаваемом непосредственно клиенту. Причина - может конфликтовать с уже имеющимися на сайте скриптами. То что ты написал - стоит одним запросом посылать на закрытии сессии, во-первых избежишь ложных срабатываний от всякой iframe-параши и мутных устройств, во-вторых не будешь заспамливать лишним трешем.
>С какой стороны подойти к этой задаче, ребята?
Со стороны очередей. Через ZMQ, например, расшвыриваешь свои события на пачку бэкендов, которые уже пишут в базу. Заранее продумав схему шардинга, естественно. Отказываться от MySQL в данном случае особо незачем - на крайняк заюзай HandlerSocket, превращающий старый добрый мускуль в NoSQL-базу, но вообще оно тебе незачем. Хайлоад - это не про некие мифические сверхмощные инструменты, а про архитектуры в первую очередь.
>что-нибудь почитать
Доку к тому же ZMQ - просто для осознания того, какие архитектуры можно строить с подобными инструментами.
А как вы собираете статистику о действиях клиента? Все равно вам что то посылается из клиентского сайта. И в этот момент юный хацкер сможет вам подкинуть свою пдфку?
Оп треда in da house. Что-то совсем забыл про этот тред, хотя ровно две недели назад в развитии проекта случился переломный момент. Меня оттуда выгнали с формулировкой "за низкую производительность труда". За неделю до меня ушел реально крутой фронденщик.
Оглядываясь назад, могу сказать, что конторка была действительно странноватая. Посреди рабочего дня продаваны иногда сидели на кухне и жарили пельмешки. Один раз они целый день играли в настольный тенис.
В один из дней у меня с владельцем стартапа(я думал, что это продаван) случилась словесная перепалка, когда я взял с его стола wi-fi свисток.
За две недели, что я там проработал, мне так и не дали доступа к коду проекта. Даже отдельные куски тим-лид не хотел присылать мне на почту. В некоторые дни тим-лид не приходил на работу или приходил ночью, когда уже все уходили.
Все, чем я занимался целыми днями - это чтение тематических статей и попытки написать прототип будущей системы. Особо никаких поручений не было, пару раз просили написать хитровыебанный sql-запрос или регулярочку. Никто особо не давал мне поручений или даже плана действий. Все, что у меня было - это оооочень приблизительное представление устройства продукта и не более ясное видение того, как продукт должен работать в будущем.
Как итог, или действительно не очень проактивный и самостоятельный программист, или менеджеры - мудаки не способные организовать рабочий процесс.
>Как итог, или действительно не очень проактивный и самостоятельный программист, или менеджеры - мудаки не способные организовать рабочий процесс.
Успокойся, никакого продукта, и тем более – процесса там попросту нет. Типикал такой ололостартап, который проест деньги, полученные на сид стадии и благополучно закроется.
Качай скилл, двигайся дальше. Судя по треду, тащемта, ты не совсем долбоеб.
Добра.
Ох блять, ну и ебанутая конторка, хорошо что ты, там всего лишь 2 недели проработал. Видимо они таким образом создают видимость деятельности, чтобы было что показать инвесторам. И да, использовать php на бекэнде для такого нагруженного проекта - это заведомый фейл.
Алсоу, ответь на этот вопрос
> не заебывайся, лучшее хранилище что ты можешь придумать — реально, самые обычные файлы, структурированные не глубже блобов отдельных записей. Т.е., например, даже тупо текстовый файл с JSON-документами, не содержащими "\n", по одному на строчку. Если одна машина не тянет писать файл — шардинг, когда ты раскидываешь по машинам, желательно (если это реально) группируя потоки так, чтобы потом данные сайта унитазов не пришлось собирать со всех нод.
Ты сейчас только что Hadoop
Hadoop что? Инбифо: только что.
Тот колобок толи по незнанию, то ли для ТРАЛЛИНГА предложил ОПу написать с нуля свой аналог Hadoop.
Теперь это хайлоадопроблем тред.
Дорогие покорители 15000 req/s, поясните за такую вещь.
Вот есть у меня приложение, допустим интернет-магазин, только очень сложный, когда данные кастомеров могут быть взаимосвязаны друг с другом.
Каким образом организовать горизонтальное масштабирование этой штуки? Ведь как ни крути а все так или иначе упирается в общую базу (данные шарятся) а базу масштабировать можно только шардингом, а с шардингом много еботы.
Как делают high availability и горизонтальное масштабирование в таких случаях?
Дорогие покорители 15000 req/s, поясните за такую вещь.
Вот есть у меня приложение, допустим интернет-магазин, только очень сложный, когда данные кастомеров могут быть взаимосвязаны друг с другом.
Каким образом организовать горизонтальное масштабирование этой штуки? Ведь как ни крути а все так или иначе упирается в общую базу (данные шарятся) а базу масштабировать можно только шардингом, а с шардингом много еботы.
Как делают high availability и горизонтальное масштабирование в таких случаях?
Либо тюниш базу, либо берёшь nosql и связи ебашишь ручками, либо как твиттер берёшь 750 Гб шаред оперативы и всё кидаешь туда.
Архивировано: http://arhivach.org/thread/48375/
Ладно.
Второй вопрос.
У этих наших покупателей есть сохраненный список товаров, который они купили. И вот он может быть очень большим (десятки тысяч купленных товаров).
Есть набор правил который определяет по уже купленным товарам что можно этому клиенту предложить еще.
Как бы так получше организовать такую проверку?
Правила вида "если клиент купил чайник розового цвета то предложить ему розовую скатерть". Самих правил очень много. Сохраненный список товаров находится в базе данных.
Сейчас мы просто подгружаем все данные в память, есть движок который прогоняет правила через них и выдает результат. Это работет пока товаров немного, но очень плохо работает если много.
Какие есть варианты? Я смутно подозреваю что тут подойдет MapReduce (Hadoop?) но не уверен насчет его производительности.
Мне нужен апи который очень быстро будет выдавать результаты для покупателя.
Ваши идеи?
Сделать метки прикрепленные к пользователю. Типа, он купил розовый чайник: ставим метку "розовое_говно". Ну и для товаров сделать масив меток. Если у товара есть метка "розовое_говно", то мы ему можем это говно предложить. Я бы вообще на такую хуйовини болт забил бы и хуярил рандомом.
Условия могут быть сложнее. Например. Если пользователь купил розовый чайник и зеленую кофеварку но не покупал кофейную кружку больше чем год то предложить ему кофейный сервиз.
Кроме того правила могут изменяться и добавляться в больших объемах.
Поэтому тег розовое_говно не прокатит, хотя если идею видоизменить то может быть что-то получится.
Рандомом хуярить нельзя смысл как раз в том что правила заданы и должны выполняться жестко.
>Условия могут быть сложнее. Например. Если пользователь купил розовый чайник и зеленую кофеварку но не покупал кофейную кружку больше чем год то предложить ему кофейный сервиз.
>Кроме того правила могут изменяться и добавляться в больших объемах.
>Поэтому тег розовое_говно не прокатит, хотя если идею видоизменить то может быть что-то получится.
А ты еще докинь дату последнего попадания в тег (когда последний раз купил розовое говно) и количество попаданий в него (может раньше еще купил розовый заварник). Если будет много уточнющих тегов, то будет легче. Вообще тебе нужно из этой горы правил вывести минимальные необоходимые данные в метках пользователя, по которым ему всучивать другое говно. А там уже потом про логику будешь думать. Она еще и расширяться как пить дать будет.
Что делать если появилось новое правило? Нужно переиндексировать всех пользователей.
Спасибо, но это немного не то. У меня набор правил большой и они жестко заданы, т.е. мне не надо придумывать рекомендательную логику, она у меня уже есть.
>Что делать если появилось новое правило? Нужно переиндексировать всех пользователей.
Нихуя. Метками ты задаешь связь пользователя с какой-то абстрактной категорией товаров. У тебя будет много-много связей. А у тебя уже должен быть какой-то кусок логики, который разгребает это гавно и дает то что нужно исходя из этих связей. Правила ты будешь добавлять в логический модуль. Проблемы начнуться когда нужно будет расширить какие-то своейства меток.
Хорошо, а если мне нужно еще и количество указывать?
Например "если пользователь купил два самовара на 30 литров то предложить ему пару сапог кирзовых и один ватник"?
И это правило появляется уже после того как мы продали ему самовары.
Я же уже говорил. Делаешь теги, количество попаданий в конкретный тег и дату последнего попадания. И на каждый товар должно быть максимум меток: чайник, 30 литров, розовый, Сатурн, с_подсветкой, фаза_луны, хуйня, малафья. Логика по идее должна быть отдельно от всего этого. Или вообще пушечно будет разработать что-то типа метахуйни, чтобы твои правила хранились в базе. Пропускаешь правило через один (условно) метод, а оно его распарсивает, находит метки, находит связи и делает предложение.
Типа таблица
хуйня, 5, YEAR_AGO, CATEGORY, малафья
Типа чувак пять раз купил товар с меткой хуйня за год, то ему предложат товар из из категории малафья. Если формализуешь все правила в таком виде, то вообще пушка будет. Можно будет потом довинтить простой интерфейс, чтобы пидорасы, которые это придумали могли их сами набивать правила. Пиздец я придумал...
Лол оно щас примерно так и работает.
Проблема в том что надо оперировать большим количеством данных которые нужно держать в памяти и это плохо масштабируется (упираемся в базу).
ЛОЛ. Если оно не может работать на одном мощном сервере, то придется лепить какой-то хипстерский кластер. Как по мне задача вполне вкладывается в map-reduce. Первый этап подготовка всех данных, второй - обработка логики и выдача результата.
Ну-ка, хайлоадобоги, кто использовал что-нибудь из Netflix OSS?
купите кто-нибудь и вбросьте в паблик
плиз
>либо как твиттер берёшь 750 Гб шаред оперативы и всё кидаешь туда.
можно детальнее?
Книжка, кстати, пошагово описывает именно то, что надо ОПу — убийцу(клон) Google Analytics
вот бы ее где взять еще
не можешь сделать все на 1 машине - делай на нескольких.
Короче есть пиздулина, которая вешается на сайт и собирает с него статистику о действиях пользователя. В день логируется несколько миллионов записей с перспективой адского роста в ближайшее время. Сейчас все это записывается в обычный mysql.
Хочу заменить mysql на монгу. Тимлид говорит, что данные раз в день нужно архивировать, чтобы с увеличением размера таблиц скорость выборки не уменьшалась. Я пока не очень представляют, как это все реализовать.
С какой стороны подойти к этой задаче, ребята ? Подкиньте что-нибудь почитать по этому поводу.