Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.

Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.

У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.

Может показаться откровенной наглостью в наши дни утверждать, что Вы изобрели алгоритм сортировки, который на 30% быстрее, чем лучший существующий. Увы, я должен сделать гораздо более наглое заявление: я написал алгоритм сортировки, который в два раза быстрее, чем std :: sort для многих входных данных. И за исключением случаев, когда я специально конструирую воспроизведение нахудших для него ситуаций, алгоритм никогда не бывает медленнее, чем std :: sort (и даже когда попадаются эти худшие случаи, они обнаруживаются и происходит автоматический возврат к std :: sort).

Почему это утверждение неудачное? Потому что мне, вероятно, будет сложно убедить вас в том, что я ускорил сортировку в два раза. Однако, чтобы всех убедить, всё это должно теперь оказаться описанным довольно длинным сообщением в блоге, а весь исходный код - открытым кодом, чтобы вы могли опробовать его на любых данных. Так что я либо могу убедить вас множеством аргументов и измерений, либо вы можете просто опробовать алгоритм сами.

Реактор сегодня - это стильно, модно, молодежно. Почему многие из нас практикуют реактивное программирование? Мало кто может ответить однозначно на этот вопрос. Но эта статья рассказывает не об этом, а о проблемах, которые реактор может создать даже опытному программисту и о методах их решений. Берем под контроль количество одновременно выполняемых задач, правильно распределяем задачи в пуле и достигаем отличных результатов с параллельной обработкой в reactor.

Ни для кого не секрет, что Python прочно занял первенство в ML и Data Science. А что если посмотреть на другие языки и платформы? Насколько в них удобно делать аналогичные решения?

К примеру, распознавание текста на картинке.

• Заголовок
• Суть статьи
  На основе этих нескольких предложений вместе с заголовком читатель должен понять, интересно ли ему читать эту статью дальше.
• Краткое изложение
  Здесь в максимально сжатом виде, тезисно, но с необходимой точностью и полнотой должна быть отражена суть данной статьи — от нескольких предложений до нескольких страниц. Кому-то, кто глубоко в теме этого может быть достаточно для понимания всей статьи. Но в любом случае читателю полезно представлять в самом общем виде, о чем эта статья, и какие выводы он получит в конце.
  
• Логика статьи
  Если статья длинная, содержит много разделов и сложную логику, то эта глава может быть также полезной. По сути это расширенное оглавление. Здесь кратко, на одной-двух страничках, излагается логика рассуждения, сухо, без деталей. Опять-таки, кому-то этого будет достаточно для того, чтобы все понять. Если сложно, то читатель может это пропустить (как оглавление) и читать дальше.
• Упрощенное изложение
  Если статья достаточно сложная, то многим было бы удобно сначала понять концептуально, что же хочет сказать автор. Поэтому неплохо сначала изложить все так, как если бы вы рассказывали студентам, упуская сложные доказательства, и, возможно, не столь формальным и строгим языком. Для очень многих такой уровень изложения может быть достаточным, и они остановятся здесь.
• Строгое изложение
  Здесь строго профессиональное изложение.
  

Привет, Хабр.

Недавно я поделился опытом о том, какие параметры мы в команде чаще всего используем для Kafka Producer и Consumer, чтобы приблизиться к гарантированной доставке. В этой статье хочу рассказать, как мы организовали повторную обработку события, полученного из Kafka, в результате временной недоступности внешней системы.

Современные приложения работают в очень сложной среде. Бизнес-логика, обернутая в современный технологический стек, работающая в Docker-образе, который управляется оркестратором вроде Kubernetes или OpenShift, и коммуницирующая с другими приложениями или enterprise-решениями через цепочку физических и виртуальных маршрутизаторов. В таком окружении всегда что-то может сломаться, поэтому повторная обработка событий в случае недоступности одной из внешних систем — важная часть наших бизнес-процессов.

Данная статья является продолжением серии «Кейс Locomizer», см. также

• Какие знания можно на самом деле извлечь из анонимизированного датасета с координатами пользователей
• Открываем One Ring — инструментарий для гибкой конфигурации сложных процессов обработки данных на Spark в облаке

Если вас не пугает картинка выше, если вы знаете чем отличается big-endian от little-endian, если вам всегда было интересно как "устроены" бинарные файлы, значит эта статья для ВАС!

Эта заметка продолжает разбор улучшений производительности, которые могли бы стать явью, если бы не разные "но". Предыдущая часть о StringBuilder-е находится здесь.

Здесь мы рассмотрим несколько "улучшений", отклонённых из-за непонимания тонкостей спецификации языка, неочевидных угловых случаев и других причин. Поехали!

Введение

Недавно столкнулся с задачей реализовать контроллер, различным образом обрабатывающий ситуации, где есть параметры запроса и где их нет. Проблема усугублялась тем, что нужны были именно два разных метода в контроллере. Стандартные возможности Spring MVC не позволяли этого сделать. Пришлось копнуть чуть глубже. Кому интересно — добро пожаловать под кат.

Пролог

А что если бы можно было создать интерфейс, например, такой:

@Service
public interface GoogleSearchApi {
    /**
     * @return http status code for Google main page
     */
    @Uri("https://www.google.com")
    int mainPageStatus();
}

А затем просто внедрять его и вызывать его методы:

@SpringBootApplication
public class App implements CommandLineRunner {
    private static final Logger LOG = LoggerFactory.getLogger(App.class);

    private final GoogleSearchApi api;

    public App(GoogleSearchApi api) {
        this.api = api;
    }

    @Override
    public void run(String... args) {
        LOG.info("Main page status: " + api.mainPageStatus());
    }

    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

Такое вполне возможно реализовать (и не очень то и сложно). Дальше я покажу, как и зачем это делать.

В этой статье я расскажу о минах, заложенных под производительность, а также об их обнаружении (желательно ещё до взрыва) и обезвреживании.

Практические задачи по Java — для курсов и прочих занятий

Несколько вводных слов

Приветствую, это вторая заметка о Spring Data JPA. Первая часть была целиком посвящена подводным граблям, а также советам бывалых. В этой части мы поговорим о том, как заточить фреймворк под свои нужды. Все описанные примеры доступны здесь.