Запрос к вашей базе данных из миллионов волокон (а не тысяч потоков)

jOOQ — отличный способ сделать SQL в Java, а волокна Quasar значительно улучшают параллелизм

Мы рады объявить еще одну очень интересную гостевую запись в блоге jOOQ Фабио Тудоне из Parallel Universe .

Parallel Universe разрабатывает стек с открытым исходным кодом, который позволяет разработчикам легко программировать экстремально параллельное приложение на JVM. С помощью стека Parallel Universe вы создаете программное обеспечение, которое работает в гармонии с современным оборудованием, а не борется с ним на каждом шагу, сохраняя при этом ваш язык программирования и ваши простые, знакомые стили программирования.

Фабио Тудоне разрабатывает и поддерживает интеграционные модули Quasar в рамках проекта Comsat . Он был частью, а затем руководил разработкой облачной платформы управления корпоративным контентом в течение нескольких лет, прежде чем присоединиться к команде Parallel Universe, и он писал в основном программное обеспечение JVM на протяжении всего своего профессионального пути. В сферу его интересов входят практики разработки и разработки, масштабируемость, параллельное и функциональное программирование, а также платформы времени исполнения. Естественно любопытный и склонный к исследованиям, он любит собирать знания и понимание от людей, мест и культур. Он также интересуется практиками осознания и любит писать всевозможные вещи.

Quasar имеет интеграцию для JDBC и jOOQ как часть проекта Comsat , так что давайте посмотрим в поле.

JDBC, JOOQ и Quasar

comsat-jdbc предоставляет comsat-jdbc волокон JDBC API, чтобы вы могли использовать ваше соединение внутри волокон, а не в обычных потоках Java.

Почему ты бы так поступил? Поскольку волокна — это легкие нити, и у вас может быть гораздо больше волокон, чем в вашей работающей JVM. «Еще много» означает, что мы говорим миллионы против нескольких тысяч.

Это означает, что у вас гораздо больше возможностей параллелизма в вашей системе для параллельного выполнения других задач в ожидании выполнения JDBC, будь то параллельные / параллельные вычисления (например, обмен актерскими сообщениями в вашей высоконадежной актерной системе, подобной Quasar Erlang ) или оптоволокно — блокировка ввода / вывода (например, обслуживание веб- запросов , вызов микро-сервисов , чтение файлов через оптоволоконный NIO или доступ к другим источникам данных с поддержкой оптоволокна, таким как MongoDB ).

Если ваша БД может выдержать это, и еще несколько обычных потоков не взорвут вашу систему (пока), вы даже можете увеличить свой пул Fibre-JDBC (см. Дополнительные точки: где линия ожидания позже) и отправлять больше параллельных команд jOOQ.

Поскольку jOOQ использует соединения JDBC для доступа к базе данных, запустить jOOQ на волокнах так же просто, как comsat-jooq зависимость comsat-jooq и передать ваше соединение JDBC с поддержкой оптоволокна в контекст jOOQ:

Конечно, вы также можете настроить ConnectionProvider для получения соединений из вашего FiberDataSource .

С этого момента вы можете использовать обычный jOOQ, и все будет происходить в режиме блокировки волокна , а не в потоке. Вот и все.

Нет, действительно, в этом нет ничего более: вы продолжаете использовать превосходный jOOQ, только с гораздо более эффективными волокнами, а не нитями. Quasar — хороший гражданин, и он не заставит вас использовать новый API (что особенно приятно, когда оригинальный уже хорош).

Поскольку JVM в настоящее время не поддерживает собственные зеленые потоки или продолжения , которые можно использовать для реализации легких потоков, Quasar реализует продолжения (и волокна поверх них) с помощью инструментария байт-кода . Это можно сделать во время компиляции, но часто удобнее использовать агент Quasar (особенно при работе со сторонними библиотеками), поэтому вот пример проекта Gradle на основе Dropwizard, который также включает в себя настройку агента Quasar (не забывайте о Capsule действительно отличный инструмент развертывания Java для любых нужд, который, разумеется, делает использование Quasar и агентов в целом очень легким). В этом примере не используются все функции jOOQ, скорее, он относится к случаю использования SQL-сборки (как для запросов, так и для CRUD), но вам рекомендуется изменить его в соответствии с вашими потребностями. В ветке without-comsat содержится версия с блокировкой потоков, поэтому вы можете сравнить и увидеть (минимальные) отличия от версии Comsat.

Где линия ожидания?

Возможно, вам сейчас интересно: хорошо, но JDBC — это API, блокирующий потоки, как Quasar может превратить его в блокирующий волокна ? Поскольку JDBC не имеет асинхронного режима, Quasar использует пул потоков за кулисами, в которые волокна распределяют операции JDBC и с помощью которых они размораживаются и планируются для возобновления после завершения операции JDBC (подробнее смотрите шаблоны интеграции Quasar. Информация).

Да, вот неприятная линия ожидания : команды JDBC, ожидающие выполнения пулом потоков. Хотя вы не улучшаете параллелизм БД по сравнению с размером пула потоков JDBC, вы не наносите вреда и своим волокнам, даже если вы все еще используете простой и знакомый API блокировки. Вы все еще можете иметь миллионы волокон.

Можно ли улучшить общую ситуацию? Без стандартного асинхронного API Java RDBMS мы мало что можем сделать. Тем не менее, это может не иметь значения, если база данных является вашим узким местом. Есть несколько хороших сообщений и обсуждений на эту тему, и аргумент сводится к решению, куда вы хотите переместить очередь ожидания.

Бонус: как эта аккуратная интеграция с jOOQ работает под прикрытием?

В настоящее время Quasar требуется, чтобы разработчик (или интегратор) сказал ему, что для инструмента, хотя полностью автоматизированное оборудование находится в разработке (эта функция зависит от некоторых незначительных изменений JRE, которые не будут выпущены до Java 9). Если вы можете удобно изменить исходный код (или скомпилированные классы), то достаточно аннотировать методы с помощью @Suspendable или позволить им throws SuspendExecution , но обычно это не так с библиотеками. Но методы с фиксированными, хорошо известными именами для инструментирования могут быть перечислены в META-INF/suspendables и META-INF/suspendable-supers соответственно для конкретных методов и абстрактных / интерфейсных методов, которые могут иметь приостановленные реализации.

Если их много (или требуется генерация кода), вы можете написать SuspendableClassifier будет поставляться вместе с вашей интеграцией, и зарегистрировать его в SPI Quasar, чтобы обеспечить дополнительную логику инструментария (см. JOOQ ). SuspendableClassifier состоит в том, чтобы проверять информацию о подписи для каждого метода в вашем пути к классам во время выполнения на этапе инструментирования и сообщать, является ли он приостановленным, может ли он иметь приостановленные реализации, если точно ни тот, ни другой случай или если он не знает (Некоторый другой классификатор мог бы сказать, возможно, «приостановленный» или «приостановленный-супер» позже).

Подводя итоги

Ну что ж… Просто наслаждайтесь отличным jOOQ на эффективных волокнах