В общем, по прочтении осталось впечатление, что оптимизация проводилась в основном "методом научного тыка".
В статье описано несколько техник оптимизации, которые можно применить, если они подходят вам в вашем конкретном случае. Разбор сделан на конкретном примере. Эти примеры бесусловно не покрывают все возможные варианты использования данных техник оптимизации и также не ограничены ими.
Автор - разработчик, а не специалист по оптимизации производительности, поэтому и подходы у него соответствующие. Не вижу в этом ничего плохого. Для разработчиков, которые хотят написать быстрый код, методы вполне подходят.
Про метод "научного тыка" в статье кстати сказано в самом начале. Проблемы нашли вполне законным способом - профилированием приложения.
Конечно, на уровне БД тоже нужно было провести анализ - трассировка, профилирование, изучение истории выполнения операторов (есть же в pg аналог ash/awr?), чтобы найти проблемные места и работать уже точечно с ними. Но это уже другой подход - специалиста по производительности, которому до поры до времени даже прикладной код не нужно смотреть.
В таком случае ваши слова о существовании каких-то там ограничений не стоят и выеденного яйца.
Ограничение может быть описано на уровне бэка, это тоже допустимо. Конечно, дополнительные проверки на уровне СУБД это хорошо для целостности, но плохо для производительности. Возможно, в данном случае, "дешевле" реализовать ограничение на уровне приложения.
То, что будет оптимально для списка из 500 кодов, почти наверняка не будет оптимально для 5-7 кодов.
Для списка в блоке предикатов разницы почти никакой не будет. На уровне погрешности.
Но это не отменяет сказанного раньше - критерии отбора, представляющие собой большой список, (как правило) должны использоваться в форме rowset, а не как plain/serialized list.
Иногда insert, join, а потом ещё очистка этой таблицы будут медленнее, чем просто подставить небольшой список в запрос. Я уже не говорю, что нужно будет решить проблемы связанные с параллельной вставкой и удалением.
Если же вы говорите про различные виды таблиц, которые хранятся временно в памяти процесса бд, то это хороший вариант, только не уверен, что они есть в pg и хорошо там работают. В oracle, например, есть global temporary table. Для них можно даже создать индекс. Это все даже будет неплохо работать, если выборка небольшая.
Судя по инфографике, она за 5 лет развелась, бросила всю родню, друзей и уехала в закат путешествовать. Там выращивала овощи, продавала их, даже работала водителем в такси. В итоге все надоело и решила отдыхать.
Суть не в этом. Вектор атаки тут в том, чтобы получить доступ к тонкому клиенту (каким либо способом) и используя его подключение к технологической сети (где сервер и другие объекты) и его же права в ней, реализовать ту или иную атаку на другие объекты сетевой инфраструктуры, которые могут иметь уже свои уязвимости.
На мой взгляд, защищать нужно всех участников, а не только тех, которые кажутся вам более уязвимые, чем другие. Нет никакой разницы какая это система: linux, windows, unix like, ОС мейнфрейма. Если не предприняты меры к её защите, то нельзя говорить о какой-то её устойчивости к той или иной атаке. Злоумышленник будет очень рад, если у вас супер надежный и проверенный linux, но с одной единственной подходящей ему дырой в безопасности. К слову, злоумышленником может быть даже внутренний пользователь, у которого есть доступ, чтобы вставить что-либо физически в тонкий клиент.
Есть ещё CROSS JOIN
Есть ещё иерархические и аналитические
Количество видов join несколько больше.
Сначала в любом случае будут выбраны все нужные стоки, потом все отсортированы и только потом будет фильтрация на limit 10.
Надо было тогда уж кучу серверов на них поднять и распределение нагрузки сделать
Падал с гладильной доски.
В статье описано несколько техник оптимизации, которые можно применить, если они подходят вам в вашем конкретном случае. Разбор сделан на конкретном примере. Эти примеры бесусловно не покрывают все возможные варианты использования данных техник оптимизации и также не ограничены ими.
Автор - разработчик, а не специалист по оптимизации производительности, поэтому и подходы у него соответствующие. Не вижу в этом ничего плохого. Для разработчиков, которые хотят написать быстрый код, методы вполне подходят.
Про метод "научного тыка" в статье кстати сказано в самом начале. Проблемы нашли вполне законным способом - профилированием приложения.
Конечно, на уровне БД тоже нужно было провести анализ - трассировка, профилирование, изучение истории выполнения операторов (есть же в pg аналог ash/awr?), чтобы найти проблемные места и работать уже точечно с ними. Но это уже другой подход - специалиста по производительности, которому до поры до времени даже прикладной код не нужно смотреть.
Ограничение может быть описано на уровне бэка, это тоже допустимо. Конечно, дополнительные проверки на уровне СУБД это хорошо для целостности, но плохо для производительности. Возможно, в данном случае, "дешевле" реализовать ограничение на уровне приложения.
Для списка в блоке предикатов разницы почти никакой не будет. На уровне погрешности.
Иногда insert, join, а потом ещё очистка этой таблицы будут медленнее, чем просто подставить небольшой список в запрос. Я уже не говорю, что нужно будет решить проблемы связанные с параллельной вставкой и удалением.
Если же вы говорите про различные виды таблиц, которые хранятся временно в памяти процесса бд, то это хороший вариант, только не уверен, что они есть в pg и хорошо там работают. В oracle, например, есть global temporary table. Для них можно даже создать индекс. Это все даже будет неплохо работать, если выборка небольшая.
Ответа на вопрос, поставленного в заголовки, в статье нет.
Назвали бы: ora2pg краткое описание возможностей.
Судя по инфографике, она за 5 лет развелась, бросила всю родню, друзей и уехала в закат путешествовать. Там выращивала овощи, продавала их, даже работала водителем в такси. В итоге все надоело и решила отдыхать.
Ну ещё стала носить платья.
Поиграться вполне хватит. Я игрался и на 1060 6гб, работало приемлемо.
Пока что не того уровня нарушение, чтобы хоть кому то ваши руки нужны были.
Телефон можно не разблокировать.
Гибкий?
Под направляющий профиль подкладывают ленту и крепят специальным крепежом с виброразвязкой, а стоечный крепят к стене виброподвесами.
На основе чего сервис даёт рекомендации?
Такая себе история отдавать документы составляющие коммерческую тайну в какой то сервис.
Суть не в этом. Вектор атаки тут в том, чтобы получить доступ к тонкому клиенту (каким либо способом) и используя его подключение к технологической сети (где сервер и другие объекты) и его же права в ней, реализовать ту или иную атаку на другие объекты сетевой инфраструктуры, которые могут иметь уже свои уязвимости.
На мой взгляд, защищать нужно всех участников, а не только тех, которые кажутся вам более уязвимые, чем другие. Нет никакой разницы какая это система: linux, windows, unix like, ОС мейнфрейма. Если не предприняты меры к её защите, то нельзя говорить о какой-то её устойчивости к той или иной атаке. Злоумышленник будет очень рад, если у вас супер надежный и проверенный linux, но с одной единственной подходящей ему дырой в безопасности. К слову, злоумышленником может быть даже внутренний пользователь, у которого есть доступ, чтобы вставить что-либо физически в тонкий клиент.
У тонкого клиента есть например сеть. Из этой сети в теории модно куда то попасть.
Подскажите, а что за железо сейчас под pg?