Да ладно, чей-то их не рекламируют? В продовольственном магазине конечно нет, а так их вполне пытаются продавать. И вот эта реклама как правило или часто бывает мимо.
Собственно, я уже сразу высказался, что некоторые виды товаров вполне могут так зайти. А мой изначальный комментарий относился вот к этому:
Пользователи больше не удивляются, что их «рекомендуемые товары» на любой e-commerce платформе совпадают с реальностью - покупками, запросами, избранным.
и как видите, тут вообще никаких ограничений нет, как будто все товары одинаковые. А они очевидно все разные. Хотя, например, совпадение рекламы с избранным - вполне может работать, и я на свое избранное регулярно получаю предложения скидок, например. В таком виде это может и сработает - но заметьте, что продукт я уже выбрал, меня лишь пытаются подтолкнуть к реальной покупке. Попытки же продать что-то похожее - скорее всего фигня, потому что сложный товар я как правило выбираю придирчиво, и никакой ИИ всех моих критериев знать не может - ему просто неоткуда, поэтому его предложения и часто ошибочны.
Смотря какие. Если вам выдали музыку, которая вам не попала в настроение - ничего страшного. А у товара есть кучи параметров, которые должны совпадать точно. Вот поэтому скажем рекомендации даже профессиональных магазинов в области инструмента или там спорттоваров очень редко попадают в точку - потому что "похожие" с их точки зрения товары отличаются возможно одним, но очень важным для меня параметров. И в итоге мне не подходят вообще.
Ну то есть, я согласен что есть такие виды "товаров", где такое может работать и работает. Но есть и куча таких, где не работает совсем.
Пользователи больше не удивляются, что их «рекомендуемые товары» на любой e-commerce платформе совпадают с реальностью - покупками, запросами, избранным.
Только маркетологи считают, что это работает. Покупатели как правило так не думают. Либо рекомендации опаздывают - когда покупка уже сделана, либо не попадают в цель. Удачные рекомендации - скорее исключение, чем правило.
Кстати, если копнуть глубже, это эта уязвимость сводится к тому, что если на вход методу, преобразующему XML в json, подсунуть XML с открывающими тэгами очень глубокой вложенности, то будет, сюрприз, stack overflow. Ну т.е. не знаю как где, а в Java это исключение вполне себе можно отловить, и продолжить работу. Даже нужно отловить - потому что приложение, которое не ловит исключения при парсинге XML, ему и так дорога в помойку. То есть это в принципе и на DDoS не очень-то тянет.
2. В Java WebSocket есть ряд уязвимостей, связанных с зависимостями (например, уязвимость Denial of Service).
Хм. А какое вам дело до DDoS, если вы на этом собираетесь тесты писать? Это не означает, что надо было выбрать Java WebSocket, просто это странная мотивация при выборе. Более того, эти уязвимости - они все в определенных версиях, причем довольно старых. Ну так, к примеру:
Основной мой посыл в том, что это число зависит от профиля нагрузки приложения. То есть, если причина ограничения в 5 в производительности HDFS - то зачем мне пять ядер, если у меня в ряде случаев приложение занимается тем, что читает данные миллионами строк из реляционной БД по JDBC, и кладет в кафку? А может у конкретного приложения и HDFS нет вообще.
Нет, у нас скорее как правило меньше. Потому что чтение из БД это наше одно из основных занятий у приложения.
Не увидел с ходу прямой связи. Я не говорил что тут нет кучи разложенных граблей - наоборот, они тут на каждом углу лежат. Я говорил, что расписание может логически быть привязано к какой-то зоне по умолчанию (локальной сервера или UTC), или же к зоне клиента (который мобилен), или к конкретной именованной зоне типа Владивостока. Все варианты, использованные не по назначению, скорее всего приведут к проблемам. То что вы описываете - ну наверное одна из таких потенциальных проблем.
Я хочу показать, что бывают кейсы, когда timestamp имеет смысл.
Строго говоря, расписание может быть как привязано к зоне, так и нет. Сервер как правило никуда не переезжает, поэтому его события - они в локальной зоне, которую можно считать константой (хотя тоже... кто знает) либо в UTC.
Если же это расписание событий клиента - то он просто по определению может быть в любой зоне, причем в течение дня в разных. Так что его расписание должно включать зону.
без должного внимания с любым форматом можно огрести проблемы.
All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the TimeZone configuration parameter before being displayed to the client.
Ну это еще и означает, что скорее всего оно все не совместимо скажем с тем, как сделано в Оракле. Потому что документация Оракла утверждает, что
The TIMESTAMP WITH TIME ZONE data type stores both the time stamp and time zone data.
Ну и кстати насчет отображение - это некоторое упрощение. Есть же to_char, и там можно выбрать много чего (но, нельзя например выбрать формат отображения Europe/Moscow, и из вашего объяснения становится ясно, почему так - потому что оно не хранится). Оракл это умеет.
Про слух про оптимальные 5 ядер я думаю в курсе все, кто использует pyspark :)
Я пишу на Java/Scala, если что, та же фигня :)
Число возможных вариантов далеко не бесконечно, от 1 до числа ядер на узле кластера (минус константа). И где-то там очевидно оптимум есть. И я даже не исключаю, что иногда он равен пяти.
И да, вопрос мониторинга был поднят возможно в первой статье на эту тему, что мне попалась на хабре с год назад.
Только вот зачем?
Тут на самом деле имелось в виду, что мы знаем параметры очереди Yarn (хотя с учетом наследования от родительской очереди определить их далеко не тривиально). И ориентироваться при выборе ресурсов вполне можем на очередь, а не на параметры голого кластера. В зависимости от текущего профиля его нагрузки. Но это сложный вопрос, и у меня нет на него даже примерных ответов.
Да, я не хочу сказать, что 5 ядер вообще смысла не имеют. Я хочу сказать, что конкретно 5 ядер ни на чем не основаны. И еще, если вы увеличиваете число ядер - то вы должны и память на executor практически пропорционально увеличить. А это уже повлечет определенные негативные последствия. То есть, какой-то оптимум тут скорее всего есть, но каков он конкретно - зависит от многих параметров, и в первую очередь от профиля нагрузки - т.е. от того, чем ваше приложение вообще занимается.
Слух про оптимальные 5 ядер - он давно ходит по интернету. И всегда все ссылаются на одну и туже статью, где это основано на утверждении, что если больше 5 ядер выделить, то HDFS будет якобы плохо. Только вот измерений там никаких нет, и в итоге непонятно, каким образом вообще на HDFS может влиять то, сколько ядер выделено на один executor.
Я уже не говорю о том, что в принципе, spark может не работать с HDFS, в частном случае. А например, читать данные из реляционной БД по JDBC, или скажем из HBase, ну или из кафки. В общем, заниматься чем-то другим.
А еще практически все подобные тексты исходят из того, что кластер находится в полном нашем распоряжении. В то время как в реальности, под управлением Yarn, вы можете запросить больше ресурсов, чем выделено для вашей Yarn очереди (а не имеющихся в кластере), и будете именно что ждать в очереди, пока ресурсы освободятся. Так что тема стояния в очереди вообще не раскрыта.
Вызов функции, имеющей побочный эффект, и сам этот побочный эффект в общем случае никак не связаны. Из того, что вы вернули структуру. которая должна была быть сохранена в базу, не следует вообще никак, что она на самом деле была туда сохранена. Ну как минимум потому, что база не обязана ваши контракты соблюдать.
Да, примерно. В принципе, когда кластеризацию маркеров включаешь (а ее почти всегда надо включать, если мы вдруг конечно не работаем в одном масштабе) - то напрашивается какой-то признак, сколько там чего в кластере.
И нахрена это кому-то надо? Понимаете, недостаток данной статьи именно в том, что не указано, что за проблему автор пытается решить. И вы ее тоже не сформулировали. Зачем вам чистый код? Чтобы что?
Поэтому я и говорю, что на практике у меня никогда не было такой потребности - получить чистый код. И я такой не один.
А раз вы не знаете, куда вы хотите попасть, то вам все равно, в какую сторону пойти (почти цитата).
Да ладно, чей-то их не рекламируют? В продовольственном магазине конечно нет, а так их вполне пытаются продавать. И вот эта реклама как правило или часто бывает мимо.
Собственно, я уже сразу высказался, что некоторые виды товаров вполне могут так зайти. А мой изначальный комментарий относился вот к этому:
и как видите, тут вообще никаких ограничений нет, как будто все товары одинаковые. А они очевидно все разные. Хотя, например, совпадение рекламы с избранным - вполне может работать, и я на свое избранное регулярно получаю предложения скидок, например. В таком виде это может и сработает - но заметьте, что продукт я уже выбрал, меня лишь пытаются подтолкнуть к реальной покупке. Попытки же продать что-то похожее - скорее всего фигня, потому что сложный товар я как правило выбираю придирчиво, и никакой ИИ всех моих критериев знать не может - ему просто неоткуда, поэтому его предложения и часто ошибочны.
Смотря какие. Если вам выдали музыку, которая вам не попала в настроение - ничего страшного. А у товара есть кучи параметров, которые должны совпадать точно. Вот поэтому скажем рекомендации даже профессиональных магазинов в области инструмента или там спорттоваров очень редко попадают в точку - потому что "похожие" с их точки зрения товары отличаются возможно одним, но очень важным для меня параметров. И в итоге мне не подходят вообще.
Ну то есть, я согласен что есть такие виды "товаров", где такое может работать и работает. Но есть и куча таких, где не работает совсем.
мне не показывают рекламу белья по какой-то причине :) но идея хорошая!
Только маркетологи считают, что это работает. Покупатели как правило так не думают. Либо рекомендации опаздывают - когда покупка уже сделана, либо не попадают в цель. Удачные рекомендации - скорее исключение, чем правило.
Кстати, если копнуть глубже, это эта уязвимость сводится к тому, что если на вход методу, преобразующему XML в json, подсунуть XML с открывающими тэгами очень глубокой вложенности, то будет, сюрприз, stack overflow. Ну т.е. не знаю как где, а в Java это исключение вполне себе можно отловить, и продолжить работу. Даже нужно отловить - потому что приложение, которое не ловит исключения при парсинге XML, ему и так дорога в помойку. То есть это в принципе и на DDoS не очень-то тянет.
Хм. А какое вам дело до DDoS, если вы на этом собираетесь тесты писать? Это не означает, что надо было выбрать Java WebSocket, просто это странная мотивация при выборе. Более того, эти уязвимости - они все в определенных версиях, причем довольно старых. Ну так, к примеру:
CVE-2022-45688 @ Maven-org.json:json-20131018 - как вам версия 2013 года (при наличии двух десятков более свежих?)
Основной мой посыл в том, что это число зависит от профиля нагрузки приложения. То есть, если причина ограничения в 5 в производительности HDFS - то зачем мне пять ядер, если у меня в ряде случаев приложение занимается тем, что читает данные миллионами строк из реляционной БД по JDBC, и кладет в кафку? А может у конкретного приложения и HDFS нет вообще.
Нет, у нас скорее как правило меньше. Потому что чтение из БД это наше одно из основных занятий у приложения.
Не забывайте, что это только про постгрес. В оракле все чуть иначе. Что там в стандарте, например, и кто к нему ближе - я лично не знаю.
Не увидел с ходу прямой связи. Я не говорил что тут нет кучи разложенных граблей - наоборот, они тут на каждом углу лежат. Я говорил, что расписание может логически быть привязано к какой-то зоне по умолчанию (локальной сервера или UTC), или же к зоне клиента (который мобилен), или к конкретной именованной зоне типа Владивостока. Все варианты, использованные не по назначению, скорее всего приведут к проблемам. То что вы описываете - ну наверное одна из таких потенциальных проблем.
Так я вообще этого ни разу не отрицал.
Строго говоря, расписание может быть как привязано к зоне, так и нет. Сервер как правило никуда не переезжает, поэтому его события - они в локальной зоне, которую можно считать константой (хотя тоже... кто знает) либо в UTC.
Если же это расписание событий клиента - то он просто по определению может быть в любой зоне, причем в течение дня в разных. Так что его расписание должно включать зону.
146%
Ну это еще и означает, что скорее всего оно все не совместимо скажем с тем, как сделано в Оракле. Потому что документация Оракла утверждает, что
Ну и кстати насчет отображение - это некоторое упрощение. Есть же to_char, и там можно выбрать много чего (но, нельзя например выбрать формат отображения Europe/Moscow, и из вашего объяснения становится ясно, почему так - потому что оно не хранится). Оракл это умеет.
поправочка - очередной далеко не новый X. Метод этот был известен кажись еще в 80-х. То есть ему лет 50 небось, не удивлюсь если и больше.
И гдеж вы видите в Spring Data JDBC магию?
Я пишу на Java/Scala, если что, та же фигня :)
Число возможных вариантов далеко не бесконечно, от 1 до числа ядер на узле кластера (минус константа). И где-то там очевидно оптимум есть. И я даже не исключаю, что иногда он равен пяти.
И да, вопрос мониторинга был поднят возможно в первой статье на эту тему, что мне попалась на хабре с год назад.
Тут на самом деле имелось в виду, что мы знаем параметры очереди Yarn (хотя с учетом наследования от родительской очереди определить их далеко не тривиально). И ориентироваться при выборе ресурсов вполне можем на очередь, а не на параметры голого кластера. В зависимости от текущего профиля его нагрузки. Но это сложный вопрос, и у меня нет на него даже примерных ответов.
Да, я не хочу сказать, что 5 ядер вообще смысла не имеют. Я хочу сказать, что конкретно 5 ядер ни на чем не основаны. И еще, если вы увеличиваете число ядер - то вы должны и память на executor практически пропорционально увеличить. А это уже повлечет определенные негативные последствия. То есть, какой-то оптимум тут скорее всего есть, но каков он конкретно - зависит от многих параметров, и в первую очередь от профиля нагрузки - т.е. от того, чем ваше приложение вообще занимается.
Слух про оптимальные 5 ядер - он давно ходит по интернету. И всегда все ссылаются на одну и туже статью, где это основано на утверждении, что если больше 5 ядер выделить, то HDFS будет якобы плохо. Только вот измерений там никаких нет, и в итоге непонятно, каким образом вообще на HDFS может влиять то, сколько ядер выделено на один executor.
Я уже не говорю о том, что в принципе, spark может не работать с HDFS, в частном случае. А например, читать данные из реляционной БД по JDBC, или скажем из HBase, ну или из кафки. В общем, заниматься чем-то другим.
А еще практически все подобные тексты исходят из того, что кластер находится в полном нашем распоряжении. В то время как в реальности, под управлением Yarn, вы можете запросить больше ресурсов, чем выделено для вашей Yarn очереди (а не имеющихся в кластере), и будете именно что ждать в очереди, пока ресурсы освободятся. Так что тема стояния в очереди вообще не раскрыта.
Вызов функции, имеющей побочный эффект, и сам этот побочный эффект в общем случае никак не связаны. Из того, что вы вернули структуру. которая должна была быть сохранена в базу, не следует вообще никак, что она на самом деле была туда сохранена. Ну как минимум потому, что база не обязана ваши контракты соблюдать.
А почему не в javascript? :) Ну просто для примера:
https://github.com/Leaflet/Leaflet.markercluster
оно будет передавать клиенту некластеризованные маркеры, но показывать будет уже кластеризованные.
Да, примерно. В принципе, когда кластеризацию маркеров включаешь (а ее почти всегда надо включать, если мы вдруг конечно не работаем в одном масштабе) - то напрашивается какой-то признак, сколько там чего в кластере.
И нахрена это кому-то надо? Понимаете, недостаток данной статьи именно в том, что не указано, что за проблему автор пытается решить. И вы ее тоже не сформулировали. Зачем вам чистый код? Чтобы что?
Поэтому я и говорю, что на практике у меня никогда не было такой потребности - получить чистый код. И я такой не один.
А раз вы не знаете, куда вы хотите попасть, то вам все равно, в какую сторону пойти (почти цитата).