К нам приходят люди с очень разным опытом; а задачи, которые они будут решать, так же зависят от опыта. Далеко не все в компании пишут на PHP, есть же еще как-минимум C/C++ и Go.
Так что «выходец из ВК» — это скорее человек, который умеет решать сложные и нетривиальные по нагрузкам и шардированию задачи, а не используемый при этом ЯП.
Понятно, что в случае решения задач основного web'а проекта, это задачи в основном на (K)PHP.
Так что проблема тут скорее — это жесткая привязка к нашим внутренним БД, а не ЯП.
Читал эту книжку, но не возникло такой сильной антипатии к автору. Я воспринимал это скорее как «дорожный роман» про человека без профильного опыта, который решил пожить Там. Что бы он там ни творил (а описал он много ситуаций), это было довольно интересно почитать (кроме части про техпрессу и Ad:Tech), не пытаясь подкопаться к его логике.
Основной сложностью будет правильно классифицировать строки изменений и выявить все их зависимости, не замедлив алгоритм до уровня full diff с двойным обходом кодовой базы.
А, если речь именно про число машин, то да. Я не так понял изначально.
Одной машины (+еще одну хотя бы как можно дальше для отказоустойчивости) вполне может хватить, но тут вопрос по сложности нагрузки читающих запросов. Мы несколько лет назад пробовали эти данные на ELK положить, он не смог на ~20-40 где-то серваках. А тут справляется 1 (+1 реплика) (но там железо разное, нельзя 1к1 сравнивать в штуках).
Как можно говорить про работу с логами не считая их хранение? Не все в мире измеряется быстрой обработкой на проце сразу при появлении данных.
Типичный пример из моей практики: примерно 50 ТБ логов на одной машинке (это несколько месяцев). И часто нужно искать за фиг знает какое число и по какому-то ключу и куче условий быстро, т.к. разработчики не хотят ждать дольше единиц секунд. А легкие запросы — сотни миллисекунд. И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).
Почти 16 секунд на 52 миллиона строк выглядит как-то очень медленно. Тестировали ли вы это на большем объеме? Будет ли оно пропорционально замедляться?
Ну и как я понимаю, весь column-based датасет целиком влезает в память виртуалки (т.е. получаем 16 секунд перелопачивания in-memory данных), а row-based уже нет, и системе приходится читать с диска (что сильно все замедляет).
Так что «выходец из ВК» — это скорее человек, который умеет решать сложные и нетривиальные по нагрузкам и шардированию задачи, а не используемый при этом ЯП.
Понятно, что в случае решения задач основного web'а проекта, это задачи в основном на (K)PHP.
Так что проблема тут скорее — это жесткая привязка к нашим внутренним БД, а не ЯП.
На самом интересном закончилось. Подробностей бы.
:)
Да, более чем :)
А то мне как-то привычнее измерять всё в попугаях на ядро, а не на систему в целом.
Ещё запоминать получается лучше во время ходьбы. Но тут сужу чисто по себе.
Т.е. это где-то по 10к fan-out сообщений на ядро?
Одной машины (+еще одну хотя бы как можно дальше для отказоустойчивости) вполне может хватить, но тут вопрос по сложности нагрузки читающих запросов. Мы несколько лет назад пробовали эти данные на ELK положить, он не смог на ~20-40 где-то серваках. А тут справляется 1 (+1 реплика) (но там железо разное, нельзя 1к1 сравнивать в штуках).
Типичный пример из моей практики: примерно 50 ТБ логов на одной машинке (это несколько месяцев). И часто нужно искать за фиг знает какое число и по какому-то ключу и куче условий быстро, т.к. разработчики не хотят ждать дольше единиц секунд. А легкие запросы — сотни миллисекунд. И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).
Ну и как я понимаю, весь column-based датасет целиком влезает в память виртуалки (т.е. получаем 16 секунд перелопачивания in-memory данных), а row-based уже нет, и системе приходится читать с диска (что сильно все замедляет).