Простите, я правильно понимаю, что вы предлагаете вытащить данные из 10 таблиц, передать их по сети, реализовать через сторонние библиотеки на другом сервере хеш соединение в памяти… и утверждаете, что это быстрее, чем нативная реализация СУБД? Я пользуюсь PG и могу точно сказать, что соединения в базе быстрее. И слабо верю, что в MySQL оно работает сильно хуже
Про промывку не скажу, я ж программист) Но зная врача, которая за этот прибор отвечает, там все строго по регламенту производителя.
Пробирки у нас вакуэт, забор крови под боком и раз в не-помню-сколько минут оттуда приносят новую партию и ставят на борт — поэтому в холодильнике нужды нет. Сколь я знаю, даже хорошие пробирки, нормальные медсестры и близкий забор крови не спасают от появления сгустков. Плюс есть кровь по проекту централизованной лаборатории, которую у нас на оленях везут. Да, тоже вакуэт пробирки, но там никаких гарантий по качеству забора и транспортировки.
Я могу сказать, что в КДЦ, где я работаю, мазки смотрят только вручную и ни о какой замене этого процесса DxH800 и речи не идёт. Мазки смотрят, когда кровь у человека сильно плохая и там нужно внимательно разбираться, что происходит. Такие вещи прибору не доверяют (плюс допускаю, он не все показатели может в мазке посчитать — это надо у гематологов наших спрашивать)
Кстати, если вас могли испугать интерфейсы re-232, то это не страшно. Мы в лаборатории поставили rs232-to-ethernet конвекторы и пробросили виртуальные com порты на сервер с драйверами ЛИС. Это позволило не держать лишний компьютер с rs-232 рядом с анализаторами и экономит место в лаборатории.
А вообще DxH800 имеет отличную пропускуную способность, кучу показателей ОАК… но не имеет нормальных фильтров от сгустков крови в пробирках. В результате у нас сервисное обслуживание не вылазит с этих приборов. Со старыми МЕКами таких проблем никогда не было.
У нас в лаборатории стоят два таких. На борту прибора винда, экспорт по описанному в документации формату через интерфейс rs-232 (данный интерфейс стандарт в лабораторной диагностике). Так что драйвер, который будет отвечать за двусторонний обмен с лабораторной информационной системой (ЛИС) можно написать под любую платформу. Обмен может быть двусторонний или односторонний. В двустороннем получив пробирку на борт прибор запрашивает у ЛИС перечень показателей общего анализа крови и делает только их, а потом отправляет в ЛИС результаты. В одностороннем, получив на борт пробирку, прибор сразу делает все показатели, а потом отправляет результаты в ЛИС. Результаты хранятся в ЛИС, но какая-то база с результатами в приборе есть (возможность посмотреть через прибор, что делали сегодня/на прошлой неделе/в прошлом месяце должна быть). Не была повода смотреть, какая именно, но скорее всего или MSSQL Express, или Firebird.
Как вариант, можно настроить в привилигерованном lxc контейнере реплику и использовать ее в качестве образа для легковесных overlayfs контейнеров. То есть мастер транслирует wal логи на lxc реплику. Когда мы хотим себе полигон, просто делаем lxc-copy с типом overlayfs (легковесный снимок основного lxc контейнера, который пишет только разность относительно замороженного слоя), переводим postgresql overlayfs копии в боевой режим и экспериментируем на здоровье. Должно происходить мгновенно. Была статья на хабре, где парень что-то похожее на эту схему делал, только на btrfs
Понимаете, просто само название статьи и начала абзацев вроде
Я бы хотел рассмотреть почему же SQL Server так долго строит план запроса.
Давайте поговорим о порядке соединения таблиц подробнее
настраивают на то, что на примере запроса из начала статьи будет разобран алгоритм построения плана и дана общая теория по специфике работы планировщика MS SQL. А закончится статья тем, что автор победил проблему с учётом вышеописанных знаний. По итогу же имеем «Вот запрос, нагенерированный 1С на 20 таблиц с повторами. Он строится иногда долго. Почему? Много таблиц в соединении плохо, так как эн-факториал. Вывод — не делайте много таблиц и уважайте планировщик». Ну такому уровню статей не место на Хабре, простите.
Я так и не понял из статьи, как именно MS SQL находит баланс между стоимостью плана и лимитом по времени перебора. N! вариантов — это хорошо для объяснения на пальцах, но вряд ли именно так все работает. У того же PostgreSQL помимо стандартного планировщика запросов есть ещё модуль генетической оптимизации. На последнем pgconf показывали модуль адаптивной оптимизации, который учитывал предыдущий опыт построения планов по схожим запросам. Наверняка в MS SQL все не менее наворечено и можно тоже что-то понастраивать с вычислением стоимости планов на большом количестве соединений. А просто сказать, что когда много таблиц, то планировщик начинает работать не очень… не информативно.
Хотелось бы для PostgreSQL больше поддержки нативных объектов. Сейчас нет ни оберток над внешними данными (внешние таблицы, схемы и сервера), ни типов, ни расширений, ни объектов полнотекстового поиска (словари, парсеры, шаблоны), ни правил. К сожалению, как бы я ни желал перейти с PgAdmin на DataGrip, пока функционал последнего не позволяет это сделать…
Из анализов здесь нужен простой общий анализ крови, чтобы понять, что подключились бактерии. А после этого в зависимости от клинической картины, опыта врача и стандартов лечения по данному диагнозу назначается антибиотик. А бакпосевы — это все же экстренные случаи не широкого профиля.
Мой опыт PostgreSQL подсказывает никогда не использовать конструкцию NOT IN, это самый медленный вариант из возможных — все жду, когда планировщик PostgreSQL научится с ним нормально работать. Обычно исключение строк реализуется или через EXCEPT, или через LEFT JOIN… WHERE id IS NULL. Но EXCEPT из этих вариантов самый производительный.
А вот теперь суть истории стала понятна и статья обрела смысл) Да, безусловно, использовать внутри рекурсивного запроса конструкцию with для вычисления следующего шага нельзя, это обычно фатально для производительности. Я тоже так стрелял себе в ногу…
Вообще вы подняли хорошую тему — надо бы собрать набор паттернов и антипаттернов в sql и написать большую статью, которая дополнялась бы по мере обсуждения в комментариях. Не хотите попробовать?;)
По факту вся статья сводится к простому правилу — минимизируйте количество строк и столбцов на каждом этапе запроса для увеличения производительности.
По поводу первой части с with… Проблема была не в cte, а в некорректно переписанном запросе, который не использовал условие where product_id = 1234. Ещё бы он не работал медленнее. Зачем вы смущаете юных падованов, связывая замедление с конструкцией with?)
Опять же, аргумент вида
Если айдишних получается, например, в ходе рекурсивного запроса, то в WITH такое условие не утащишь и идея с разделением запроса на куски будет безбожно тормозить
далёк от истины. Ничто не мешает положить результат рекурсивного запроса в виде единственного айдишника в cte, а потом написать
where product_id = (select id from recursive_with)
Касаемо красивой визуализации explain analyze — лично я предпочитаю построение в pgAdmin: толщина связей в отображении плана запроса очень чётко указывают на проблему производительности.
Сколь я помню у PosgresPro есть возможность при создании индекса помещать в его листья дополнительные поля, чтобы не обращаться к таблице. Параметр including, если память не изменяет. А вообще используйте вариант genew с поиском по индексу без обращения к таблице (кстати, вам на самом деле нужен только один составной индекс, а не целых три!). Этот вариант лучше массива залитого gin — в массиве вы теряете согласованность данных на внешних ключах. Кстати, во внешних ключах правильнее использовать on update cascade, чем no action — понятно, что первичные ключи не обновляют, но концептуально… А в запросе вместо distinct можно попробовать group by, он на прежних версиях меньше ошибался.
А вы прочитайте статью, где Николай объясняет причины своего ухода. Он как ведущий конструктор получал 300 долларов в месяц, а после работы клал плитку на стройке и унитазы чинил, чтобы с голоду не сдохнуть. И чудесное руководство, которое ему объясняло, что он никто и его легко заменит студент. По мне так это чистой воды вина руководства «Звезды», что мы потеряли данного специалиста (и кучу других, которые не смогли жить на 200-300 долларов в месяц и завязали с наукой).
Пробирки у нас вакуэт, забор крови под боком и раз в не-помню-сколько минут оттуда приносят новую партию и ставят на борт — поэтому в холодильнике нужды нет. Сколь я знаю, даже хорошие пробирки, нормальные медсестры и близкий забор крови не спасают от появления сгустков. Плюс есть кровь по проекту централизованной лаборатории, которую у нас на оленях везут. Да, тоже вакуэт пробирки, но там никаких гарантий по качеству забора и транспортировки.
настраивают на то, что на примере запроса из начала статьи будет разобран алгоритм построения плана и дана общая теория по специфике работы планировщика MS SQL. А закончится статья тем, что автор победил проблему с учётом вышеописанных знаний. По итогу же имеем «Вот запрос, нагенерированный 1С на 20 таблиц с повторами. Он строится иногда долго. Почему? Много таблиц в соединении плохо, так как эн-факториал. Вывод — не делайте много таблиц и уважайте планировщик». Ну такому уровню статей не место на Хабре, простите.
Вообще вы подняли хорошую тему — надо бы собрать набор паттернов и антипаттернов в sql и написать большую статью, которая дополнялась бы по мере обсуждения в комментариях. Не хотите попробовать?;)
По поводу первой части с with… Проблема была не в cte, а в некорректно переписанном запросе, который не использовал условие where product_id = 1234. Ещё бы он не работал медленнее. Зачем вы смущаете юных падованов, связывая замедление с конструкцией with?)
Опять же, аргумент вида
далёк от истины. Ничто не мешает положить результат рекурсивного запроса в виде единственного айдишника в cte, а потом написать
Касаемо красивой визуализации explain analyze — лично я предпочитаю построение в pgAdmin: толщина связей в отображении плана запроса очень чётко указывают на проблему производительности.