Согласен. То что автор даже не упомянул планы, и вероятно не пытался их смотреть и делать выводы, сильно обесценивает данный текст.
Отдельными запросами можно решать проблемы производительности только если из за каких-то причин нельзя правильно индексировать БД. (Ну, например если приходится писать в базу очень часто).
Не, ну не обязательно. У меня был опыт, когда мы отчет, выполнявшийся часами в базе Sybase, оптимизировали до минут, при этом все расчеты выполнялись в кластере из Java машин. То есть, по сути. мы смогли данные кластеризовать, загрузить в память, и вычисления распараллелить. В итоге нагрузка выглядела так - минут пять данные грузились в кластер (уж сколько там было запросов, я не вспомню, но видимо по числу узлов кластера), за какое-то смешное время все рассчитывалось, и еще несколько минут отчет выгружался. Запросы, ясное дело, были тут совсем другие, простейшие.
Ну то есть, если у вас есть другой вычислительный ресурс (как у нас было, причем кластер мы собрали из каких-то совсем простых линукс машинок, помнится с гигабайтом памяти каждая всего - да, то было очень давно), то вы можете работу переложить на этот ресурс, и возможно сильно ускорить.
Эти нативные исполнимые файлы запускаются быстрее, требуют меньше памяти и не требуют установленной JVM.
Насколько я помню, потребление памяти там "в принципе такое же", как у обычной программы под обычной JVM - т.е. при старте выделяется хип, и размер этого хипа не будет в общем случае меньше от того, что вы скомпилируете GraalVM. Ну то есть, я бы тут уточнил слегка, о какой памяти идет речь, и какое именно потребление уменьшится.
Ну и насчет запуска быстрее - есть же в новых JDK возможность собрать образ с загруженными классами, который тоже стартует существенно быстрее (по понятным причинам загрузка множества классов из множества jar-ов - это не быстро). Было бы неплохо сравнивать время старта в таком режиме. Ну т.е. я про jpackage, если что.
Если бы только заголовок. Если немного погуглить, станет ясно, что фильтру Блума как идее более 50 лет. Он был придуман примерно в 1970. Так что статья устарела лет на 40 :)
Ну, это в принципе логично. Я бы просто сказал что этот метод все же не универсален. И некоторым это будет сложно. И месяцы и годы - это не то время, которое обычно есть в наличии. Годы в поиске работы - это ужасно.
оба спикера на подкасте не делали ничего подобного, чтобы попасть в их индустрию
Ну это ровно то, что делают рекрутеры, когда советуют программистам, как найти работу. При этом совершенно очевидно, что рекрутеры никогда сами работу программистом не искали, да и не найдут, если попробуют.
Вот только один вопрос - что эта ваша идея применима к синьорам, я прекрасно знаю и согласен. А вот для людей без опыта - вряд ли. Вы попробуйте без опыта завести знакомство на нужном вам уровне? Спикеру на конференции будет интересен другой спикер на конференции, а какой-то джун без опыта - ну при всем уважении к нему как к человеку, он скорее всего не сможет даже вопрос интересный задать. Ну так и как же тогда?
Ну да, разумеется. Корень в дерьмовом контенте, а не ссылке.
Но сама проблема в том, что вот эти вот "авторы" в каком-то смысле потеряли всякий стыд. Т.е. посмотришь - первая статья. В статье нет ничего, и это еще неплохо - иногда просто написан бред. У автора нет никакого авторитета тут на Хабре. И комментариев тоже нет. И другие статьи он не читал - потому что его тема уже разжевана раз сто, и зачастую намного лучше. Никто и звать никак - но просьба подписаться на канал уже наличествует.
И эти вещи весьма сильно коррелируют. Хотя может быть это лишь наше восприятие нам так подсказывает.
Да не, я думаю вы все правильно понимаете, на мой взгляд Lock-и - они более мощный инструмент, и выразить с их помощью все можно. Я скорее опять же о том, что ну вот использую я скажем спарк, который а) на скале б) сильно больше моего проекта, на несколько порядков в) просто сложный. И если вылезут, чинить проблемы или рефакторить чужой код такого размера - да ну его нафиг.
Вот если правда можно сделать автоматически такую конвертацию (а ее таки чисто интуитивно наверное можно сделать на базе какого-нибудь AST процессора или даже antlr) - это выглядит более реалистично. И я такой подход как-то даже применял с другими целями - парсил antlr-ом кучу кода на VBA, чтобы понять что она делает, и переписать в конечном счете на C#.
Ну вот кстати о софте. Софт становится хуже? А покажет мне кто-нибудь софт, сделанный скажем 10 лет назад, который бы умел то, что сегодняшний? Ну вот как пример - тренажер для уже упомянутого настольного тенниса. Берем телефон, ставим на штатив, снимаем игру. Мячи надо слегка раскрасить, чтобы было видно, как они вращаются. А дальше софтинка анализирует скорость полета, вращение, точку попадания, и делает выводы о вашей технике.
Я подозреваю, что 10 лет назад такого по возможностям софта просто не существовало. А сегодня, опять же это лишь мои подозрения, но судя по статьям на Хабре, такое может написать любой программист, взяв в руки OpenCV и скажем питон. И даже не очень долго будет писать. И таких применений я знаю с десяток. Т.е. такой карманный "тренер", который снимает некие показания с датчиков, которые навешали на спортсмена, и подсказывает тому, что он делает неправильно. В тех случаях, когда показатели измеримы, это очень даже эффективно в тренировках.
Заповедником хабр был лет пять назад в лучшем случае. А щас тут публикуют статьи типа "как я вел бизнес своего магазина (заметьте, даже не интернет магазина, а простого), и в конце концов прогорел". Ну так, это я в качестве примера темы, совсем не единственной, которая никаким боком вообще к хабру - и тем не менее таких статей сотни.
Если вы хотите сбросить жирок - вам же никто не запрещает. А я таки да, азартный, и готовлюсь, и над техникой работаю. Ну т.е. я просто хочу сказать, что спортом многие занимаются с разными целями, и сброс жира - не единственная. И скажем, вокруг меня больше таких как я, чем таких, кто ходит в условную качалку сбрасывать.
Про робота смешно. Робот не подсказывает ошибки в технике, чтоб вы знали. Потому что робот у меня есть.
Какой-то все же однобокий взгляд на вещи. А теперь замените качалку на игровые виды спорта, и расскажите мне, как вы будете тренироваться в условно, настольном теннисе, без тренера? Ну то есть да, я же тренируюсь, несомненно, можно книжки почитать (уже смешно в 21 веке, правда), или ютюб посмотреть (уже лучше), но кто мне укажет на недостатки техники и поправит нужными упражнениями?
Ну то есть, исключите из ваших выводов как минимум технически сложные, в том числе наверное все игровые виды.
Все-то вам легко... ведь другие примитивы (*Lock) - они не идентичная замена, у них другая семантика.
Ну то есть, опять же - разумеется это не является нерешаемой проблемой, но это время и деньги.
Ну да, если сравнивать с внедрением Java 9 и модулей - лум это успешная попытка, на первый взгляд. В тот раз поломали вообще все, maven, gradle, а Hadoop и его компоненты до сих пор совместимость с Java новых версий разгребают.
Вы как-то странно читали. Там четко написано, что лум ничего не может сделать в случаях использования двух легаси примитивов. То есть, если у вас в коде wait, то он не работает. Не удалось сделать лум так, чтобы он был совместим с любым легаси кодом.
другие вещи выпиливают
А покажете еще хоть одну? Я вот за 20 с лишним лет не могу вспомнить, чтобы что-то выпилили из того, что было еще в 1.0. Потому что finalize еще не выпилили, так, между прочим.
и каждый сам должен проверять код
Разве что в стране розовых поней. В моем коде вообще нет wait. А вот фреймворки, которые я использую достаточно широко, все как на подбор по какой-то причине сильно больше кода моего проекта. Возможно потому, что у них на гитхабе сотни и тысячи контрибьюторов? Я и говорю о том, что когда ты сталкиваешься с легаси кодом в чужом коде фреймворка (который много больше чем твой проект) - то вот такой случай побороть очень сложно.
Это не невозможно разумеется - если исходники есть, так или иначе можно сесть и вникнуть. Но попробуйте скажем вникнуть в JDBC драйвер постгреса. Я пробовал. Он сравнительно небольшой. Но вы замучаетесь вносить в него исправления, а особенно - их тестировать, потому что они поддерживают все еще Java 7 (как минимум, если не более старые), и кучу разных версий сервера. У меня нет столько разных JDK и столько серверов, чтобы полноценно проверить, что мои правки ничего не сломали. А главное у меня нет столько времени, чтобы полноценно вникать во все то старье, что там годами наворотили :) У меня своего старья хватает.
Вы пытаетесь задавать вопросы переводчику: ПУБЛИКАЦИИ 43 КОММЕНТАРИИ 1
На самом деле интересно. Вот у нас сопоставимых размеров хадуп, к примеру. И что я тут для себя вынес - то что большой кластер k8s упирается в отдельный сервис, в данном случае например в etcd. А у нас хадуп упирался скажем в керберос, или в DNS. В общем, в какие-то отдельные критически важные для жизни сервисы, которые при этом недостаточно хорошо масштабируются.
Мне лично ничего не мешает. А вот если вы почитаете скажем https://habr.com/ru/companies/ydb/articles/786550/ - то увидите, что проект Loom (который делали много лет) сталкивается с блокировкой виртуальных и реальных потоков, если где-то в коде используется syncronized и wait. А избежать этого на практике иногда совершенно нереально. В итоге одно легаси - syncronized и wait, сталкивается с другим легаси - используемыми библиотеками, которые еще не адаптированы.
Причем я подозреваю, что варианта выпилить старые примитивы синхронизации у авторов Loom тоже не было.
Хм. А есть такая асинхронщина, с которой можно обращаться вольно? Мне кажется, в языке типа Java, с кучей легаси решений, тянущихся с рождения, такую реализовать вообще невозможно.
Это и есть рекламный пост. Это компания, она рекламирует свои услуги - в данном случае обучение.
Вы правда этого сами не видите? Если нет - то вот вам хороший признак. Смотрите на автора: 128 публикаций и 29 комментариев, с марта 2023 года, т.е. менее чем за год. По-моему, выводы вполне очевидны.
Спарк там конечно занимает не последнее место, и да, конечно данные в HDFS (Hive уже очень давно умеет использовать спарк движок). В Hive только метаданные, грубо говоря, десятки тысяч схем, по моим оценкам. Отчеты строят. Для клиентов и регулятора. Не вижу никакой причины, почему Hive не может продолжать применяться для части задач. Ее все еще допиливают, и скажем нам бы очень бы хотелось иметь 4 версию - а приходится пока жить на 3.1.
Я вообще писал не совсем про это. Автор сравнивает два продукта, приводя как недостаток Hive, что не рекомендуется делать больше 10000 партиций. При этом не делается никакого сравнения, а как будет себя вести постгрес, если создать столько же.
Даже если заменить 10 на 3-5 - мало что изменится. Все равно это тот же порядок. Все равно чтобы реально сравнить - надо померять на своем количестве данных.
Согласен. То что автор даже не упомянул планы, и вероятно не пытался их смотреть и делать выводы, сильно обесценивает данный текст.
Не, ну не обязательно. У меня был опыт, когда мы отчет, выполнявшийся часами в базе Sybase, оптимизировали до минут, при этом все расчеты выполнялись в кластере из Java машин. То есть, по сути. мы смогли данные кластеризовать, загрузить в память, и вычисления распараллелить. В итоге нагрузка выглядела так - минут пять данные грузились в кластер (уж сколько там было запросов, я не вспомню, но видимо по числу узлов кластера), за какое-то смешное время все рассчитывалось, и еще несколько минут отчет выгружался. Запросы, ясное дело, были тут совсем другие, простейшие.
Ну то есть, если у вас есть другой вычислительный ресурс (как у нас было, причем кластер мы собрали из каких-то совсем простых линукс машинок, помнится с гигабайтом памяти каждая всего - да, то было очень давно), то вы можете работу переложить на этот ресурс, и возможно сильно ускорить.
Насколько я помню, потребление памяти там "в принципе такое же", как у обычной программы под обычной JVM - т.е. при старте выделяется хип, и размер этого хипа не будет в общем случае меньше от того, что вы скомпилируете GraalVM. Ну то есть, я бы тут уточнил слегка, о какой памяти идет речь, и какое именно потребление уменьшится.
Ну и насчет запуска быстрее - есть же в новых JDK возможность собрать образ с загруженными классами, который тоже стартует существенно быстрее (по понятным причинам загрузка множества классов из множества jar-ов - это не быстро). Было бы неплохо сравнивать время старта в таком режиме. Ну т.е. я про jpackage, если что.
Если бы только заголовок. Если немного погуглить, станет ясно, что фильтру Блума как идее более 50 лет. Он был придуман примерно в 1970. Так что статья устарела лет на 40 :)
Ну, это в принципе логично. Я бы просто сказал что этот метод все же не универсален. И некоторым это будет сложно. И месяцы и годы - это не то время, которое обычно есть в наличии. Годы в поиске работы - это ужасно.
Ну это ровно то, что делают рекрутеры, когда советуют программистам, как найти работу. При этом совершенно очевидно, что рекрутеры никогда сами работу программистом не искали, да и не найдут, если попробуют.
Вот только один вопрос - что эта ваша идея применима к синьорам, я прекрасно знаю и согласен. А вот для людей без опыта - вряд ли. Вы попробуйте без опыта завести знакомство на нужном вам уровне? Спикеру на конференции будет интересен другой спикер на конференции, а какой-то джун без опыта - ну при всем уважении к нему как к человеку, он скорее всего не сможет даже вопрос интересный задать. Ну так и как же тогда?
если не найдете себе партнера с такими умениями...
Ну да, разумеется. Корень в дерьмовом контенте, а не ссылке.
Но сама проблема в том, что вот эти вот "авторы" в каком-то смысле потеряли всякий стыд. Т.е. посмотришь - первая статья. В статье нет ничего, и это еще неплохо - иногда просто написан бред. У автора нет никакого авторитета тут на Хабре. И комментариев тоже нет. И другие статьи он не читал - потому что его тема уже разжевана раз сто, и зачастую намного лучше. Никто и звать никак - но просьба подписаться на канал уже наличествует.
И эти вещи весьма сильно коррелируют. Хотя может быть это лишь наше восприятие нам так подсказывает.
Да не, я думаю вы все правильно понимаете, на мой взгляд Lock-и - они более мощный инструмент, и выразить с их помощью все можно. Я скорее опять же о том, что ну вот использую я скажем спарк, который а) на скале б) сильно больше моего проекта, на несколько порядков в) просто сложный. И если вылезут, чинить проблемы или рефакторить чужой код такого размера - да ну его нафиг.
Вот если правда можно сделать автоматически такую конвертацию (а ее таки чисто интуитивно наверное можно сделать на базе какого-нибудь AST процессора или даже antlr) - это выглядит более реалистично. И я такой подход как-то даже применял с другими целями - парсил antlr-ом кучу кода на VBA, чтобы понять что она делает, и переписать в конечном счете на C#.
Ну вот кстати о софте. Софт становится хуже? А покажет мне кто-нибудь софт, сделанный скажем 10 лет назад, который бы умел то, что сегодняшний? Ну вот как пример - тренажер для уже упомянутого настольного тенниса. Берем телефон, ставим на штатив, снимаем игру. Мячи надо слегка раскрасить, чтобы было видно, как они вращаются. А дальше софтинка анализирует скорость полета, вращение, точку попадания, и делает выводы о вашей технике.
Я подозреваю, что 10 лет назад такого по возможностям софта просто не существовало. А сегодня, опять же это лишь мои подозрения, но судя по статьям на Хабре, такое может написать любой программист, взяв в руки OpenCV и скажем питон. И даже не очень долго будет писать. И таких применений я знаю с десяток. Т.е. такой карманный "тренер", который снимает некие показания с датчиков, которые навешали на спортсмена, и подсказывает тому, что он делает неправильно. В тех случаях, когда показатели измеримы, это очень даже эффективно в тренировках.
Заповедником хабр был лет пять назад в лучшем случае. А щас тут публикуют статьи типа "как я вел бизнес своего магазина (заметьте, даже не интернет магазина, а простого), и в конце концов прогорел". Ну так, это я в качестве примера темы, совсем не единственной, которая никаким боком вообще к хабру - и тем не менее таких статей сотни.
Если вы хотите сбросить жирок - вам же никто не запрещает. А я таки да, азартный, и готовлюсь, и над техникой работаю. Ну т.е. я просто хочу сказать, что спортом многие занимаются с разными целями, и сброс жира - не единственная. И скажем, вокруг меня больше таких как я, чем таких, кто ходит в условную качалку сбрасывать.
Про робота смешно. Робот не подсказывает ошибки в технике, чтоб вы знали. Потому что робот у меня есть.
Какой-то все же однобокий взгляд на вещи. А теперь замените качалку на игровые виды спорта, и расскажите мне, как вы будете тренироваться в условно, настольном теннисе, без тренера? Ну то есть да, я же тренируюсь, несомненно, можно книжки почитать (уже смешно в 21 веке, правда), или ютюб посмотреть (уже лучше), но кто мне укажет на недостатки техники и поправит нужными упражнениями?
Ну то есть, исключите из ваших выводов как минимум технически сложные, в том числе наверное все игровые виды.
Все-то вам легко... ведь другие примитивы (*Lock) - они не идентичная замена, у них другая семантика.
Ну то есть, опять же - разумеется это не является нерешаемой проблемой, но это время и деньги.
Ну да, если сравнивать с внедрением Java 9 и модулей - лум это успешная попытка, на первый взгляд. В тот раз поломали вообще все, maven, gradle, а Hadoop и его компоненты до сих пор совместимость с Java новых версий разгребают.
Вы как-то странно читали. Там четко написано, что лум ничего не может сделать в случаях использования двух легаси примитивов. То есть, если у вас в коде wait, то он не работает. Не удалось сделать лум так, чтобы он был совместим с любым легаси кодом.
А покажете еще хоть одну? Я вот за 20 с лишним лет не могу вспомнить, чтобы что-то выпилили из того, что было еще в 1.0. Потому что finalize еще не выпилили, так, между прочим.
Разве что в стране розовых поней. В моем коде вообще нет wait. А вот фреймворки, которые я использую достаточно широко, все как на подбор по какой-то причине сильно больше кода моего проекта. Возможно потому, что у них на гитхабе сотни и тысячи контрибьюторов? Я и говорю о том, что когда ты сталкиваешься с легаси кодом в чужом коде фреймворка (который много больше чем твой проект) - то вот такой случай побороть очень сложно.
Это не невозможно разумеется - если исходники есть, так или иначе можно сесть и вникнуть. Но попробуйте скажем вникнуть в JDBC драйвер постгреса. Я пробовал. Он сравнительно небольшой. Но вы замучаетесь вносить в него исправления, а особенно - их тестировать, потому что они поддерживают все еще Java 7 (как минимум, если не более старые), и кучу разных версий сервера. У меня нет столько разных JDK и столько серверов, чтобы полноценно проверить, что мои правки ничего не сломали. А главное у меня нет столько времени, чтобы полноценно вникать во все то старье, что там годами наворотили :) У меня своего старья хватает.
Вы пытаетесь задавать вопросы переводчику: ПУБЛИКАЦИИ 43 КОММЕНТАРИИ 1
На самом деле интересно. Вот у нас сопоставимых размеров хадуп, к примеру. И что я тут для себя вынес - то что большой кластер k8s упирается в отдельный сервис, в данном случае например в etcd. А у нас хадуп упирался скажем в керберос, или в DNS. В общем, в какие-то отдельные критически важные для жизни сервисы, которые при этом недостаточно хорошо масштабируются.
Мне лично ничего не мешает. А вот если вы почитаете скажем https://habr.com/ru/companies/ydb/articles/786550/ - то увидите, что проект Loom (который делали много лет) сталкивается с блокировкой виртуальных и реальных потоков, если где-то в коде используется syncronized и wait. А избежать этого на практике иногда совершенно нереально. В итоге одно легаси - syncronized и wait, сталкивается с другим легаси - используемыми библиотеками, которые еще не адаптированы.
Причем я подозреваю, что варианта выпилить старые примитивы синхронизации у авторов Loom тоже не было.
Хм. А есть такая асинхронщина, с которой можно обращаться вольно? Мне кажется, в языке типа Java, с кучей легаси решений, тянущихся с рождения, такую реализовать вообще невозможно.
Это и есть рекламный пост. Это компания, она рекламирует свои услуги - в данном случае обучение.
Вы правда этого сами не видите? Если нет - то вот вам хороший признак. Смотрите на автора: 128 публикаций и 29 комментариев, с марта 2023 года, т.е. менее чем за год. По-моему, выводы вполне очевидны.
Спарк там конечно занимает не последнее место, и да, конечно данные в HDFS (Hive уже очень давно умеет использовать спарк движок). В Hive только метаданные, грубо говоря, десятки тысяч схем, по моим оценкам. Отчеты строят. Для клиентов и регулятора. Не вижу никакой причины, почему Hive не может продолжать применяться для части задач. Ее все еще допиливают, и скажем нам бы очень бы хотелось иметь 4 версию - а приходится пока жить на 3.1.
Я вообще писал не совсем про это. Автор сравнивает два продукта, приводя как недостаток Hive, что не рекомендуется делать больше 10000 партиций. При этом не делается никакого сравнения, а как будет себя вести постгрес, если создать столько же.
Даже если заменить 10 на 3-5 - мало что изменится. Все равно это тот же порядок. Все равно чтобы реально сравнить - надо померять на своем количестве данных.