В стеке ElasticSearch это всё из коробки будет. Свои велосипеды, напротив, это почти всегда неполноценное решение. Не надо так, учитесь переиспользовать опыт предков.
Чего только не делают люди, лишь бы не читать best practice...
Однопоточное приложение не в состоянии нагрузить больше одного потока нормально написанного логгера.
Поэтому: асинхронный аппендер logback, все параметры блока в MDC, там бинарный сериализатор — и в logstash. Всё, минимум кода, один конфиг.
Оттуда можно или в файлы писать, если месье так нравится, или, что более юзабельно, в ElasticSearch. Опять никакого кода, один лишь конфиг. Если logstash вынести на соседнюю машину, можно ещё и ресурсы главного хоста сэкономить.
Интересно, как автор понял, что он сам в состоянии отделить настоящие новости от фейковых и сформировать обучающую выборку? Можно ли использовать его дар, чтобы методом перебора понять, кто же все-таки сбил малайзийский Боинг?
Для SQL РСУБД само собой подразумевается наличие ACID. С этим у NoSQL все очень плохо, поддержку ACID заявляют только мифический Google Spanner, глюкавый OrientDB и ныне почивший FoundationDB. Языковая обертка совсем не спасает — SQL в NoSQL используют почти исключительно для OLAP.
В другую сторону, для NoSQL часто подразумевается почти линейная масштабируемость и shared-nothing. С этим у классических РСУБД все очень плохо — транзакционный движок это нерасширяемый SPOF, мастер-мастер репликация это безнадежно, универсальное шардирование не совместимо с контролем строгости внешних ключей и т.п.
Забавно, что как сетевики пытаются съехать с IPv4 на IPv6, так и программисты тяготеют к созданию локальных коммьюнити. Выглядит так, будто "narrow waist" это вынужденная мера, от которой при необходимости попытаются избавиться.
Надо ли адаптировать SQL как "narrow waist" в данных, когда там и так справляются многообразием технологий и языков? Получается, вопрос весьма дискуссионный.
"Narrow waist" не надо переводить как "узкое место". "Узкое место" в техническом сленге носит ярко выраженный негативный оттенок, ближайший аналог в английском это "bottleneck". Узкое место — это плохо, его надо или ликвидировать, или обойти.
Автор же имел ввиду скорее позитивное явление, что IP выступает как общее связующее звено для разнообразнейших транспортно-прикладных протоколов и способов организации передачи данных. Это просто закономерный исторический факт, как и то, что все программисты говорят друг с другом на английском.
Выглядит так, будто вы посмотрели на Hadoop v0.20 в 2009ом, после этого впали в кому с кошмарами из маркетингового мусора, а теперь проснулись и озираетесь по сторонам "О-о-о, айфоны!.. О-о-о, спарк!.. О-о-о, паркет...".
Отсутствие проверки значимости делает ваши выводы голословными.
Проваленная проверка будет означать, что наблюдаемый вами эффект — не более, чем статистический шум. Тогда все выводы пойдут в ведро, а следующую статью можно будет не писать.
Попробуйте оценить уровень значимости корреляций.
Так как вы попарно сравниваете 90+ таймлайнов, то надо провести коррекцию на множественное тестирование, например, поправкой Бонферрони.
После этого вполне может оказаться, что ни одной значимой корреляции не осталось.
Такие зубчатые артефакты часто бывают на распределениях дробей. Грубо говоря, получить 50% можно в любом доме с четным числом квартир (1/2, 10/20, 50/100, ...), а 85% только в домах, где число квартир кратно 20 (17/20, 51/60, ...).
В статье есть ссылка: http://blog.builtinnode.com/post/from-java-to-node-the-netflix-story
Они перевели фронтенд на node.js в процессе переделки верстки на SPA. И это, в общем-то, логично.
Под фронтендом я имею ввиду сервера переднего звена, которые генерируют верстку и принимают запросы от пользователя. Переписывать бекенд (нижележащие звенья, всякие микросервисы) на node.js они, конечно, не будут.
Вдруг посетила идея, что, возможно, хайп вызван тем, что в маленьких проектах часто всего одно звено, и его и зовут бекендом. И если разработчики, которые раньше не видели многозвенных приложений, видят модный доклад про переделку верстки на node.js, они могут воспринять это как миграцию всего приложения. И вот тут начинаются статьи на тему того, что Java умирает.
Диаграммы не идентичны. Обратите внимание на бины в районе 1.0. Видно, что функция hist() размещает в единице правую границу бина, ваша же функция размещает его центр. Из-за этого на вашем графике появляется лишний бин, а высота предшествующего ему бина оказывается ниже на один пункт.
Мы говорим о совсем разных вещах, увы.
В прикладном датасаенсе правильная постановка задачи значит много больше, чем сравнительный тест неправильной постановки. Это тоже голая философия.
В стеке ElasticSearch это всё из коробки будет. Свои велосипеды, напротив, это почти всегда неполноценное решение. Не надо так, учитесь переиспользовать опыт предков.
Чего только не делают люди, лишь бы не читать best practice...
Однопоточное приложение не в состоянии нагрузить больше одного потока нормально написанного логгера.
Поэтому: асинхронный аппендер logback, все параметры блока в MDC, там бинарный сериализатор — и в logstash. Всё, минимум кода, один конфиг.
Оттуда можно или в файлы писать, если месье так нравится, или, что более юзабельно, в ElasticSearch. Опять никакого кода, один лишь конфиг. Если logstash вынести на соседнюю машину, можно ещё и ресурсы главного хоста сэкономить.
Интересно, как автор понял, что он сам в состоянии отделить настоящие новости от фейковых и сформировать обучающую выборку? Можно ли использовать его дар, чтобы методом перебора понять, кто же все-таки сбил малайзийский Боинг?
Где DeepFakes?!
А как вы измеряете качество своего прогноза и собираете эталоны для обучения? Проводите ли сравнение с другими метеослужбами?
Для SQL РСУБД само собой подразумевается наличие ACID. С этим у NoSQL все очень плохо, поддержку ACID заявляют только мифический Google Spanner, глюкавый OrientDB и ныне почивший FoundationDB. Языковая обертка совсем не спасает — SQL в NoSQL используют почти исключительно для OLAP.
В другую сторону, для NoSQL часто подразумевается почти линейная масштабируемость и shared-nothing. С этим у классических РСУБД все очень плохо — транзакционный движок это нерасширяемый SPOF, мастер-мастер репликация это безнадежно, универсальное шардирование не совместимо с контролем строгости внешних ключей и т.п.
Забавно, что как сетевики пытаются съехать с IPv4 на IPv6, так и программисты тяготеют к созданию локальных коммьюнити. Выглядит так, будто "narrow waist" это вынужденная мера, от которой при необходимости попытаются избавиться.
Надо ли адаптировать SQL как "narrow waist" в данных, когда там и так справляются многообразием технологий и языков? Получается, вопрос весьма дискуссионный.
"Narrow waist" не надо переводить как "узкое место". "Узкое место" в техническом сленге носит ярко выраженный негативный оттенок, ближайший аналог в английском это "bottleneck". Узкое место — это плохо, его надо или ликвидировать, или обойти.
Автор же имел ввиду скорее позитивное явление, что IP выступает как общее связующее звено для разнообразнейших транспортно-прикладных протоколов и способов организации передачи данных. Это просто закономерный исторический факт, как и то, что все программисты говорят друг с другом на английском.
Выглядит так, будто вы посмотрели на Hadoop v0.20 в 2009ом, после этого впали в кому с кошмарами из маркетингового мусора, а теперь проснулись и озираетесь по сторонам "О-о-о, айфоны!.. О-о-о, спарк!.. О-о-о, паркет...".
Отсутствие проверки значимости делает ваши выводы голословными.
Проваленная проверка будет означать, что наблюдаемый вами эффект — не более, чем статистический шум. Тогда все выводы пойдут в ведро, а следующую статью можно будет не писать.
Попробуйте оценить уровень значимости корреляций.
Так как вы попарно сравниваете 90+ таймлайнов, то надо провести коррекцию на множественное тестирование, например, поправкой Бонферрони.
После этого вполне может оказаться, что ни одной значимой корреляции не осталось.
Функция выживаемости должна быть невозрастающей.
Почему график функции для Степана достигает минимума на 23 сезонах, а дальше возрастает?
Такие зубчатые артефакты часто бывают на распределениях дробей. Грубо говоря, получить 50% можно в любом доме с четным числом квартир (1/2, 10/20, 50/100, ...), а 85% только в домах, где число квартир кратно 20 (17/20, 51/60, ...).
В статье есть ссылка: http://blog.builtinnode.com/post/from-java-to-node-the-netflix-story
Они перевели фронтенд на node.js в процессе переделки верстки на SPA. И это, в общем-то, логично.
Под фронтендом я имею ввиду сервера переднего звена, которые генерируют верстку и принимают запросы от пользователя. Переписывать бекенд (нижележащие звенья, всякие микросервисы) на node.js они, конечно, не будут.
Вдруг посетила идея, что, возможно, хайп вызван тем, что в маленьких проектах часто всего одно звено, и его и зовут бекендом. И если разработчики, которые раньше не видели многозвенных приложений, видят модный доклад про переделку верстки на node.js, они могут воспринять это как миграцию всего приложения. И вот тут начинаются статьи на тему того, что Java умирает.
Много легаси кода это не "занял нишу". Это "пока не до конца выпилили".
Доля новых скриптов на Perl неукоснительно падает и сейчас плещется в районе нуля, по сравнению с лидерством на рынке в начале нулевых.
Расцвет COBOL и Ada я не застал, но сейчас все рассказы про них начинаются с фразы "МНОГО легаси кода".
COBOL? Ada? Perl?
А может, это просто баг? А нода ни при чем?
Диаграммы не идентичны. Обратите внимание на бины в районе
1.0. Видно, что функцияhist()размещает в единице правую границу бина, ваша же функция размещает его центр. Из-за этого на вашем графике появляется лишний бин, а высота предшествующего ему бина оказывается ниже на один пункт.