А, если речь именно про число машин, то да. Я не так понял изначально.
Одной машины (+еще одну хотя бы как можно дальше для отказоустойчивости) вполне может хватить, но тут вопрос по сложности нагрузки читающих запросов. Мы несколько лет назад пробовали эти данные на ELK положить, он не смог на ~20-40 где-то серваках. А тут справляется 1 (+1 реплика) (но там железо разное, нельзя 1к1 сравнивать в штуках).
Как можно говорить про работу с логами не считая их хранение? Не все в мире измеряется быстрой обработкой на проце сразу при появлении данных.
Типичный пример из моей практики: примерно 50 ТБ логов на одной машинке (это несколько месяцев). И часто нужно искать за фиг знает какое число и по какому-то ключу и куче условий быстро, т.к. разработчики не хотят ждать дольше единиц секунд. А легкие запросы — сотни миллисекунд. И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).
Почти 16 секунд на 52 миллиона строк выглядит как-то очень медленно. Тестировали ли вы это на большем объеме? Будет ли оно пропорционально замедляться?
Ну и как я понимаю, весь column-based датасет целиком влезает в память виртуалки (т.е. получаем 16 секунд перелопачивания in-memory данных), а row-based уже нет, и системе приходится читать с диска (что сильно все замедляет).
А нужно?
Есть про m.habr.com/ru/company/vk/blog/430168
В обозримом будущем появится про наш kive для трансляций.
Сейчас еще тестим image proxy/resize, тоже будет публично, как выложим.
А кучу внутренних вещей имеет ли смысл описывать?
Еще был от меня на GoWayFest прошлогоднем доклад на эту тему: youtu.be/Llmpfv8PIt4
В прод сторонние решения сложно встраивать + у нас сильная команда сишников.
Если что стороннее и применяется (а такое есть), то только в специфичных случаях.
Казалось бы, как раз таки на Go писать много логики проще и надежнее, чем на Python.
Вот для небольшой и выразительной математики да, лучше Python, из-за его сишных библиотек и особенностей синтаксиса. Но что-то большое и сложное на нем писать странно.
Да, более чем :)
А то мне как-то привычнее измерять всё в попугаях на ядро, а не на систему в целом.
Ещё запоминать получается лучше во время ходьбы. Но тут сужу чисто по себе.
Т.е. это где-то по 10к fan-out сообщений на ядро?
Одной машины (+еще одну хотя бы как можно дальше для отказоустойчивости) вполне может хватить, но тут вопрос по сложности нагрузки читающих запросов. Мы несколько лет назад пробовали эти данные на ELK положить, он не смог на ~20-40 где-то серваках. А тут справляется 1 (+1 реплика) (но там железо разное, нельзя 1к1 сравнивать в штуках).
Типичный пример из моей практики: примерно 50 ТБ логов на одной машинке (это несколько месяцев). И часто нужно искать за фиг знает какое число и по какому-то ключу и куче условий быстро, т.к. разработчики не хотят ждать дольше единиц секунд. А легкие запросы — сотни миллисекунд. И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).
Ну и как я понимаю, весь column-based датасет целиком влезает в память виртуалки (т.е. получаем 16 секунд перелопачивания in-memory данных), а row-based уже нет, и системе приходится читать с диска (что сильно все замедляет).
Есть про m.habr.com/ru/company/vk/blog/430168
В обозримом будущем появится про наш kive для трансляций.
Сейчас еще тестим image proxy/resize, тоже будет публично, как выложим.
А кучу внутренних вещей имеет ли смысл описывать?
Еще был от меня на GoWayFest прошлогоднем доклад на эту тему:
youtu.be/Llmpfv8PIt4
Будет ли специализация на около Java тематике, или это все же общая конференция без предпочтений?
Смена типа поля скорее не возможна, чем широко практикуется. Добавляется поле, да.
Если что стороннее и применяется (а такое есть), то только в специфичных случаях.
Вот для небольшой и выразительной математики да, лучше Python, из-за его сишных библиотек и особенностей синтаксиса. Но что-то большое и сложное на нем писать странно.