По сути вам не нужно никогда это ставить, если нет необходимости в этих компонентах. Так же на вопрос вроде "чем отличается проприетарный драйвер от ядерного и какой из них новее" представитель AMD на реддите ответил, что как правило если вы используете свежее ядро доступное для вашего дистрибутива, то у вас нет необходимости ставить открытую часть драйверов этим скриптом, т.к. их версии нацелены больше на стабильность и доступность для старого железа.
Соответственно в случае AMD достаточно использовать свежие ядра стабильной ветки. Если вы точно знаете зачем вам нужен openCL или вариации кодеков AMD (amf), то да, вам придется ставить проприетарный драйвер.
Я же написал, просто используйте индексы на те поля которые вам нужны. Индексы хранятся в отдельной таблицы и со своей магией, все что вам нужно от этого джойна - это получить id, а все остальные данные вы получаете уже "наверху". Вы можете обернуть это ещё раз в под запрос и присоединить что то ещё - это все равно будет быстро, т.к. у вас уже будет ограниченный список выборки. И да, джойн тут играет магическую роль, не знаю почему, но планировщик мне показывал бОльшую эффективность, чем с where. Но тут не ручаюсь, стоит 15 версия если что.
Конечно, есть крайний случай, когда у вас фильтр подразумевается по всем полям выводимых данных. Ну, тут уже сами прикидывайте что вам важнее, скорость или место на диске/памяти.
Простите, но слишком лень гуглить более техническое описание того, почему чистый оффсет такой тяжелый. СОВСЕМ ПРИМИТИВНОЕ ОБЪЯСНЕНИЕ: если мы применяем оффсет на что-то, что в конечном итоге использует только индексы (в данном случае возвращается только таблица с полем id), то pg не нужно заглядывать целиком в реальную таблицу с данными, читать байтики там чтобы не ошибиться с оффсетом, попутно проверяю условия и т.д. Т.к. мы используем чистое индексное поле на выходе, то pg может на много быстрее посчитать оффсет. По сути мы упираемся только в то, сколько условных байт нам надо прочитать, чтобы корректно отсчитать строки оффсета. ЭТО ОЧЕНЬ ПРИМИТИВНОЕ ОБЪЯСНЕНИЕ! Возможно тут появится гуру pg и объяснит более корректно.
Ну это всё прекрасно, но как и писали выше - это всё ерунда, главная проблема лимит-оффсет в производительности. Если вы делаете это в лоб, то чем дальше страница тем медленнее будет выполняться запрос.
Где-то когда-то нашел в комментариях решение, которое на удивление дает около константное время запроса на любую страницу. Концепция простая:
SELECT * FROM mega_table AS m0
INNER JOIN (
SELECT id FROM mega_table
WHERE <conditions>
ORDER BY <conditions>
LIMIT <i>
OFFSET <j>
) AS fast_filter ON m0.id = fast_filter.id
<conditions if need>
Суть заключается в том, чтобы избежать некоторых тяжелых операции, если делаете и оффсет и условия и сортировку на одной таблице. Ну и главное, чтобы на поле id из примера был повешен индекс, а так же на те поля по которым вы подразумеваете фильтрацию и сортировку. Хак в том, чтобы использовать только индексные поля, тем самым не заставляя БД тащить тяжелые тосты и вот это всё, а уже в самом конце, когда нам известны id выборки, то их сильно проще забрать, чем перечитывать страницы для оффсета еще и с сортировкой и условиями.
Извиняюсь если описал кривовато, но суть я думаю понятна. На боевом проекте с десятками миллионов записей, где основные данные хранятся в jsonb, а нужные для фильтров данные лежат в соседних полях с индексами - полет отличный, погрешность времени выполнения на уровне погрешности.
Вы вероятно не совсем поняли суть, которая тут происходит.
У нас имеется образ с компилятором golang (это может быть любой образ, может вы собираете ffmpeg, там огромное количество всего вам понадобится). Этот образ, условно, пусть будет весить 600мб
Компилируем бинарник (если это будет ffmpeg, то например компилируете его в один статичный бинарник, пусть на выходе это будет около 50мб)
За конечный образ берете например alpine, т.к. у вас нет никакой линковки, то бинарник будет просто запускаться. Итог: конечный готовый образ у вас будет 60мб (условно), т.е. 50мб ffmpeg + OS alpine.
Та часть dockerfile где мы компилировали мы можем выкинуть уже из системы. Аналогично делается сборка например веб приложений - собираем фронт в образе ноды, бинарник сервера в образе чего-либо, в конечный образ копируем результаты сборки фронта и бэка в любой легкий образ.
PWA это ультимативное решение в довольном большом кол-ве случаев. У меня есть проект, где заказчик изначально интересовался возможностью сделать мобильное приложение под сайт, который мы реализовали сначала. Начал распрашивать для чего и почему. Потребность была простая - сотрудники склада бегают с планшетами на ведроиде, использовать браузер либо неудобно, либо заблочен какой-то функционал специально. Изначально я исходил из того, что с нуля нырять в какой-нибудь флаттер, потом разгребаться с плэймаркетом или придумывать как релизить apk куда-то и короче огромная куча проблем бы была.
Короче говоря для такой простой потребности у заказчика - PWA стало супер быстрым, дешевым и эффективным решением. К тому же оно может сходить проверить кэш, если что-то изменилось, то накатить обновление. Тут отдельно читайте просто всякие хуки внутри воркера и т.п.
Пожалуй самое неприятное - это разбираться как там кэш проверить, обновиться, потом ты обнаруживаешь что у тебя 1000 копий воркеров установлено пока ты тестировал, а если ты это наплодил клиентам, то где-то временно придется запушить апдейт, где ты просто убиваешь всех воркеров или кэш, потом еще пуш для включения обратно. Короче там есть подводные камни, но в плане времени разработки / стоимости - я пока не знаю что может быть ультимативнее.
Если есть большая кодовая база на питоне, проверенная временем, протестированная, но допустим нужен новый функционал с высокими требованиями к скорости, то почему бы и нет? Это будет рациональнее, чем переписывать полностью. Опять же, это всё оценки времени/денег/результата. Относитесь к ЯПам как к инструментам, хватит превращать это в культ.
плиз, хватит сраться уже со всеми тут, что вы хотите доказать? Вы решили что на мой скарказм ответить более продуктивно чем на комментарий по делу? Ну да, проще...
Проблема в вашей реакции на комментарии. Вы публикуете в открытом источнике, с открытыми комментариями, зачем то спорите не по делу. Без всякого негатива - хорошо что вы осознаете что у ваши практики устарели, но может немного для себя стоит тогда пересмотреть что сейчас актуально? Я много лет писал только бэки, а когда пришлось заниматься фулстаком, то с удивлением обнаружил для себя, что сейчас все уже давно пишут на ванильном JS без JQuery, да и вообще существуют более удобные вещи типа vue для ускорения написания фронта со всеми современными фичами.
Слушайте, когда вы позиционируете ваши статьи для новичков, то всё же стоит показывать сразу как правильно. Это для новичков справедливо, что их код хороший, если он просто запускается и делает то что ожидалось и плевать какой там стиль.
Если ваша цель не просто фарм кармы для чего-то и добавление в резюме что "вот, а я на хабре пишук", а вы действительно горите желанием поделится опытом, то просто немного освежите знания, даже не навыки.
Как вы думаете, почему я вообще эту статью открыл, хотя она очевидно для новичков? Я ожидал увидеть для себя что-то новое, может какая-то хитрая настройка nginx появилась, может какой-то ASGI новый появился или с хитрыми настройками. Да даже если бы не увидел нового, но это просто тут было бы - это уже ок.
Это просто ИМХО, в открытой статье с открытыми комментариями. Единственное зачем я пишу что-то критическое в комментариях - это получить от авторов фидбэк в виде следующих хороших статей, надеюсь у вас они так же будут. Прошлая статья ведь действительно полезная у вас.
Считаю что поделился более чем конструктивной критикой пусть и долей токсичности. Выше комментарии вам так же по делу напихали. Это смешно мерятся кол-вом проектов, а тем более советовать что-то писать. Вы из тех кто "сначала сам сделай, а потом критикуй"? Тогда понятно почему у вас так пригорает. Я, да и думаю многие, не пишут на хабр просто потому, что это не принесет чего-то нового. Конечно, есть статьи где люди описывают свой опыт, как применяли что-то и там как бы объективно ничего нового может не быть, но хотя бы интересно читать как люди приходят к тем или иным решениям, оценивают разные инструменты и т.п.
А у вас, повторю, просто вредные советы... в 2024 году
Вероятно вам стоило бы отредактировать ту статью и дополнить, тогда бы она получилась максимально емкой и полезной в закладках, про неё речи вообще нет. Я вот листаю ленту, вижу заявленную тему, читаю отсылку к вашей прошлой статье, понимаю в целом мне не так важно её знать как заявленную тут тему, а тут я получаю плохие советы, устаревшую практику, еще и разбивку зачем то на несколько частей. Вау.
Есть гугл с намного более подробными и верными руководствами, чем ваше. Помимо этого на хабре. О! Я вам помогу, а заодно тем кто наткенется на эту копипасту (вы тут на какие-то мои отсутствующие статьи наезжаете, а где у вас тут оригинальность? Как докажете?).
Вы даже про nginx не описали, что тут вообще читать? Зачем разбивка на части? Может быть чтобы просто нафармить кармы на этой копипасте растянув казалось бы конечную мысль на несколько маленьких статей? Да нет, не думаю что вы на столько меркантильны
Очередной гайд копипаста от прошедшего курсы курсы месяц назад. Я не знаю как это охарактеризовать. Всё что выше и ниже напихают автору - всё по дело. Обычно я пропускаю такие статьи и просто плююсь что потратил время, но как же уже накипело. Что вы привнесли этим? Тут есть что-то новое? Это даже хуже - это что-то 10 летней давности.
Но даже такую копипасту можно было бы разбавить, добавив пример systemd юнита, а может кто-то альпайн хочет на VPS - опишите как там демона написать, заодно сами разберетесь.
Еще больше я в шоке что не вижу ни рекламы, ни ссылок на очередной телеграм канал - нафига это вообще существует?
Так вроде есть Lit уже, может даже не он один.
Я конечно не против, пусть выживет сильнейший, но в чем фича?
Аж глаз радуется.
Бегло пробежал глазами, но это в любом случае идет в закладки, чтобы удобно кидать падаванам как заметку.
Я правда отказался от gunicorn в пользу uWSGI, но это слишком спцифичный кейс когда тредпулы используются внутри хэндлера фласка :))
В проприетарный части просто есть некоторые специфичные компоненты, вроде openCL https://amdgpu-install.readthedocs.io/en/latest/install-script.html#scenarios
По сути вам не нужно никогда это ставить, если нет необходимости в этих компонентах.
Так же на вопрос вроде "чем отличается проприетарный драйвер от ядерного и какой из них новее" представитель AMD на реддите ответил, что как правило если вы используете свежее ядро доступное для вашего дистрибутива, то у вас нет необходимости ставить открытую часть драйверов этим скриптом, т.к. их версии нацелены больше на стабильность и доступность для старого железа.
Соответственно в случае AMD достаточно использовать свежие ядра стабильной ветки.
Если вы точно знаете зачем вам нужен openCL или вариации кодеков AMD (amf), то да, вам придется ставить проприетарный драйвер.
Короче оказалось, что по какой-то причине freesync в прошлых версиях был включен по умолчанию в ядре (как я понял, иначе объяснения нет).
В итоге вернул все частоты включив параметр:
amdgpu.freesync_video=1Я же написал, просто используйте индексы на те поля которые вам нужны. Индексы хранятся в отдельной таблицы и со своей магией, все что вам нужно от этого джойна - это получить id, а все остальные данные вы получаете уже "наверху".
Вы можете обернуть это ещё раз в под запрос и присоединить что то ещё - это все равно будет быстро, т.к. у вас уже будет ограниченный список выборки.
И да, джойн тут играет магическую роль, не знаю почему, но планировщик мне показывал бОльшую эффективность, чем с where. Но тут не ручаюсь, стоит 15 версия если что.
Конечно, есть крайний случай, когда у вас фильтр подразумевается по всем полям выводимых данных. Ну, тут уже сами прикидывайте что вам важнее, скорость или место на диске/памяти.
Да, именно так, спасибо что сократили мою мысль )))
Короче говоря, перепробовав разные варианты, если вам нужна фильтрация и ограничение выдачи, то более оптимального варианта я не нашел.
https://stackoverflow.com/a/27169302
https://dba.stackexchange.com/a/205286
Простите, но слишком лень гуглить более техническое описание того, почему чистый оффсет такой тяжелый.
СОВСЕМ ПРИМИТИВНОЕ ОБЪЯСНЕНИЕ: если мы применяем оффсет на что-то, что в конечном итоге использует только индексы (в данном случае возвращается только таблица с полем id), то pg не нужно заглядывать целиком в реальную таблицу с данными, читать байтики там чтобы не ошибиться с оффсетом, попутно проверяю условия и т.д. Т.к. мы используем чистое индексное поле на выходе, то pg может на много быстрее посчитать оффсет. По сути мы упираемся только в то, сколько условных байт нам надо прочитать, чтобы корректно отсчитать строки оффсета. ЭТО ОЧЕНЬ ПРИМИТИВНОЕ ОБЪЯСНЕНИЕ! Возможно тут появится гуру pg и объяснит более корректно.
Ну это всё прекрасно, но как и писали выше - это всё ерунда, главная проблема лимит-оффсет в производительности. Если вы делаете это в лоб, то чем дальше страница тем медленнее будет выполняться запрос.
Где-то когда-то нашел в комментариях решение, которое на удивление дает около константное время запроса на любую страницу. Концепция простая:
Суть заключается в том, чтобы избежать некоторых тяжелых операции, если делаете и оффсет и условия и сортировку на одной таблице. Ну и главное, чтобы на поле id из примера был повешен индекс, а так же на те поля по которым вы подразумеваете фильтрацию и сортировку.
Хак в том, чтобы использовать только индексные поля, тем самым не заставляя БД тащить тяжелые тосты и вот это всё, а уже в самом конце, когда нам известны id выборки, то их сильно проще забрать, чем перечитывать страницы для оффсета еще и с сортировкой и условиями.
Извиняюсь если описал кривовато, но суть я думаю понятна. На боевом проекте с десятками миллионов записей, где основные данные хранятся в jsonb, а нужные для фильтров данные лежат в соседних полях с индексами - полет отличный, погрешность времени выполнения на уровне погрешности.
Вы вероятно не совсем поняли суть, которая тут происходит.
У нас имеется образ с компилятором golang (это может быть любой образ, может вы собираете ffmpeg, там огромное количество всего вам понадобится). Этот образ, условно, пусть будет весить 600мб
Компилируем бинарник (если это будет ffmpeg, то например компилируете его в один статичный бинарник, пусть на выходе это будет около 50мб)
За конечный образ берете например alpine, т.к. у вас нет никакой линковки, то бинарник будет просто запускаться. Итог: конечный готовый образ у вас будет 60мб (условно), т.е. 50мб ffmpeg + OS alpine.
Та часть dockerfile где мы компилировали мы можем выкинуть уже из системы.
Аналогично делается сборка например веб приложений - собираем фронт в образе ноды, бинарник сервера в образе чего-либо, в конечный образ копируем результаты сборки фронта и бэка в любой легкий образ.
PWA это ультимативное решение в довольном большом кол-ве случаев. У меня есть проект, где заказчик изначально интересовался возможностью сделать мобильное приложение под сайт, который мы реализовали сначала. Начал распрашивать для чего и почему. Потребность была простая - сотрудники склада бегают с планшетами на ведроиде, использовать браузер либо неудобно, либо заблочен какой-то функционал специально. Изначально я исходил из того, что с нуля нырять в какой-нибудь флаттер, потом разгребаться с плэймаркетом или придумывать как релизить apk куда-то и короче огромная куча проблем бы была.
Короче говоря для такой простой потребности у заказчика - PWA стало супер быстрым, дешевым и эффективным решением. К тому же оно может сходить проверить кэш, если что-то изменилось, то накатить обновление. Тут отдельно читайте просто всякие хуки внутри воркера и т.п.
Пожалуй самое неприятное - это разбираться как там кэш проверить, обновиться, потом ты обнаруживаешь что у тебя 1000 копий воркеров установлено пока ты тестировал, а если ты это наплодил клиентам, то где-то временно придется запушить апдейт, где ты просто убиваешь всех воркеров или кэш, потом еще пуш для включения обратно. Короче там есть подводные камни, но в плане времени разработки / стоимости - я пока не знаю что может быть ультимативнее.
Если есть большая кодовая база на питоне, проверенная временем, протестированная, но допустим нужен новый функционал с высокими требованиями к скорости, то почему бы и нет? Это будет рациональнее, чем переписывать полностью. Опять же, это всё оценки времени/денег/результата.
Относитесь к ЯПам как к инструментам, хватит превращать это в культ.
В прошлые падения при недоступности например в РФ обычный sock5 помогал. Мы же не знаем до сих пор что там было.
Не работает ни через США, ни через Европу. Что то у них серьезно накрылось.
Я вас защищаю, как видите, вы скажите мне.
плиз, хватит сраться уже со всеми тут, что вы хотите доказать? Вы решили что на мой скарказм ответить более продуктивно чем на комментарий по делу? Ну да, проще...
Проблема в вашей реакции на комментарии. Вы публикуете в открытом источнике, с открытыми комментариями, зачем то спорите не по делу.
Без всякого негатива - хорошо что вы осознаете что у ваши практики устарели, но может немного для себя стоит тогда пересмотреть что сейчас актуально? Я много лет писал только бэки, а когда пришлось заниматься фулстаком, то с удивлением обнаружил для себя, что сейчас все уже давно пишут на ванильном JS без JQuery, да и вообще существуют более удобные вещи типа vue для ускорения написания фронта со всеми современными фичами.
Слушайте, когда вы позиционируете ваши статьи для новичков, то всё же стоит показывать сразу как правильно. Это для новичков справедливо, что их код хороший, если он просто запускается и делает то что ожидалось и плевать какой там стиль.
Если ваша цель не просто фарм кармы для чего-то и добавление в резюме что "вот, а я на хабре пишук", а вы действительно горите желанием поделится опытом, то просто немного освежите знания, даже не навыки.
Как вы думаете, почему я вообще эту статью открыл, хотя она очевидно для новичков? Я ожидал увидеть для себя что-то новое, может какая-то хитрая настройка nginx появилась, может какой-то ASGI новый появился или с хитрыми настройками. Да даже если бы не увидел нового, но это просто тут было бы - это уже ок.
Это просто ИМХО, в открытой статье с открытыми комментариями. Единственное зачем я пишу что-то критическое в комментариях - это получить от авторов фидбэк в виде следующих хороших статей, надеюсь у вас они так же будут. Прошлая статья ведь действительно полезная у вас.
Что вы тут доказываете, у вас в подписи разве есть это?
Считаю что поделился более чем конструктивной критикой пусть и долей токсичности. Выше комментарии вам так же по делу напихали.
Это смешно мерятся кол-вом проектов, а тем более советовать что-то писать. Вы из тех кто "сначала сам сделай, а потом критикуй"? Тогда понятно почему у вас так пригорает. Я, да и думаю многие, не пишут на хабр просто потому, что это не принесет чего-то нового. Конечно, есть статьи где люди описывают свой опыт, как применяли что-то и там как бы объективно ничего нового может не быть, но хотя бы интересно читать как люди приходят к тем или иным решениям, оценивают разные инструменты и т.п.
А у вас, повторю, просто вредные советы... в 2024 году
Вероятно вам стоило бы отредактировать ту статью и дополнить, тогда бы она получилась максимально емкой и полезной в закладках, про неё речи вообще нет.
Я вот листаю ленту, вижу заявленную тему, читаю отсылку к вашей прошлой статье, понимаю в целом мне не так важно её знать как заявленную тут тему, а тут я получаю плохие советы, устаревшую практику, еще и разбивку зачем то на несколько частей. Вау.
Есть гугл с намного более подробными и верными руководствами, чем ваше. Помимо этого на хабре. О! Я вам помогу, а заодно тем кто наткенется на эту копипасту (вы тут на какие-то мои отсутствующие статьи наезжаете, а где у вас тут оригинальность? Как докажете?).
Просто выборка с хабра:
Краткая история о том, как развернуть веб-сервер Flask в docker контейнере
Подготовка сервера для публикации web-app на Python
Фантастически быстрый деплой веб-приложения
Несколько советов по организации Python-приложения на сервере
Установка Django-проекта на VPS (centOS 7) [Для новичков]
site:habr.com python сервер как развернуть
Вы даже про nginx не описали, что тут вообще читать? Зачем разбивка на части? Может быть чтобы просто нафармить кармы на этой копипасте растянув казалось бы конечную мысль на несколько маленьких статей? Да нет, не думаю что вы на столько меркантильны
Очередной гайд копипаста от прошедшего курсы курсы месяц назад. Я не знаю как это охарактеризовать. Всё что выше и ниже напихают автору - всё по дело.
Обычно я пропускаю такие статьи и просто плююсь что потратил время, но как же уже накипело.
Что вы привнесли этим? Тут есть что-то новое? Это даже хуже - это что-то 10 летней давности.
Но даже такую копипасту можно было бы разбавить, добавив пример systemd юнита, а может кто-то альпайн хочет на VPS - опишите как там демона написать, заодно сами разберетесь.
Еще больше я в шоке что не вижу ни рекламы, ни ссылок на очередной телеграм канал - нафига это вообще существует?