думаю, под «select в некоторых случаях может менять данные» подразумевается история в pg про обновление хинт битов при первом чтении вставленной строки. суть в том, что pg версионник, то есть под капотом в его таблицах лежат незакомиченные и удаленные строки, которые периодически чистит автовакуум. при выборе, какие строки убить, автовакуум ориентируется на хинт биты (они нужны еще для кучи разных вещей, не только для этого). когда вы начали транзакцию, но еще не закоммитили ее, строка все равно появляется таблице, а в хитн битах у нее пусто. как только транзакция коммитится, информация об этом замечательном факте попадает в clog. к сожалению, понять в момент коммита, в каких строках таблиц транзакция успела поменять данные проблемно, да и часть страничек может быть вытеснена из буферного кеша (а повторно считывать их дорого). поэтому в строках из закомиченной транзакции хинт биты остаются пустыми. а вот как только мы запросим через select одну из таких строк, pg проставит им хинт биты, что вызовет запись на диск при чтении данных. ну а если таких строк было много, то первое чтение может породить серьезную нагрузку на диск за счет вытеснение грязных страничек их общих буферов pg. это порой ставит в тупик не наступавших на эти грабли людей.
У медицинского оборудования есть общие черты: оно высокотехнологично (УЗИ, МРТ, МСКТ и т.д.), продается небольшими партиями (сравните рынок УЗИ и смартфонов) и имеет очень долгий цикл поддержки. И именно поэтому оно стоит дорого: нужно инвестировать в разработки новых технологий, поддерживать старые аппараты (десятилетиями) и иметь минимально возможный брак (это жизни людей).
Если вы собираете простейший УЗИ аппарат с неясными характеристиками, за результаты которого никто не отвечает, не планируете развивать свою фирму и используется аппарат не для людей — добро пожаловать на алиэкспресс, вас тут найдут ветеренары. Но ни одна больница не возьмет себе такой. Кстати, китайцы из Шеньдженя активно продают свои УЗИ аппараты (у нас в центре стоит один такой) с качеством не хуже мировых брендов. Но и стоят они почему-то не сильно дешевле, а вот в плане поддержки сильно проигрывают.
По поводу школ и всего такого. Производить копеечные УЗИ аппараты с плохими характеристиками для уроков, я думаю можно, просто это никому не нужно. УЗИ считается самым субъективным видом диагностики, где большая часть результата зависит от квалификации врача. Обычный человек увидит только неясные картинки и не сможет их корректно интерпретировать. А дети вряд ли что-то поймут, а школьная программа не заточена на привитие навыков УЗИ диагноста каждому ребенку. Тем же, кому нужны УЗИ для производства, имеют свой список требований, который наверняка не менее жесткий, чем у медицины.
Для PostgreSQL пользуюсь Pyrseas. Он снимает описание со схемы в виде yaml файла, который можно сравнить с любой базой и по разнице автоматически генерируется sql миграция. За счёт этого можно работать в параллельных ветках базы и нормально сливать изменения. Поддерживаются специфичные для PG вещи (вот марица поддерживаемых свойств).
Вы не можете записаться на удобное вам время просто потому, что денег нет. ТФОМС раз в год выдаёт план задание — обязательство каждому медучреждения оплатить N медицинских услуг, не больше и не меньше. И медучреждение обязано их сделать ровно столько, сколько выдал в виде плана ТФОМС. Меньше сделаешь — урежут в следующем году план, больше — не заплатят. Проблема в том, что ТФОМС обязуется оплатить количество услуг в несколько раз меньшее, чем реально нужно населению. Медучреждение планирует этот минимум помесячно, чтобы не выполнить весь годовой план за пару месяцев. Услуг не хватает, а что есть разлетается как горячие пирожки. Денег на ОМС медицину у государства нет, поэтому развивается только платный сегмент. А с учётом полной импортозависимости по реагентам, расходникам и оборудованию, а так же с учётом курса, платная медицина будет только дорожать.
Приношу извинения, автор не вы — пятница вечер))
Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
У вас в статье не шла речь про веб приложение, вы давали общие рекомендации. Я же вам привёл данные из работающей системы медицинских заказов на целый край. И это не редкий аналитический запрос, а типовая проверка для заказа направления между медицинскими учреждениями. Такие данные нельзя хранить отдельно и обновлять, они должны быть актуальны на любой момент времени. И они как то держатся настолько сложными и отлично работают в продакшене. Если вы пишите практики для простых веб приложений, то и указывайте об этом. Реальные промышленные системы обычно на порядок сложнее.
Могу сказать, что у меня идут запросы с агрегациями по соединениям таблиц, в каждой из которых около миллиона записей. Соединяются от трех до пяти таких таблиц. Соединение идёт по покрывающим индексам и почти не трогает сами таблицы, то речь менее чем о сотне мс. Суть в том, что агрерация идёт в pipeline mode по покрывающим индексам и на клиент уходит компактная свертка результатов в пару сотен строк. Если же делать по-вашему, то нужно выкачать несколько миллионов строк с дисков, отослать их на другой сервер и там повернуть ту же самую свертку в памяти в компактную таблицу, но без кучи оптимизаций по работе с общими буферами PG и буферами ОС. Если хотите, напишите предложение по тесту, я его прогоню по-своему и по-вашему.
Простите, я правильно понимаю, что вы предлагаете вытащить данные из 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, пока функционал последнего не позволяет это сделать…
Если вы собираете простейший УЗИ аппарат с неясными характеристиками, за результаты которого никто не отвечает, не планируете развивать свою фирму и используется аппарат не для людей — добро пожаловать на алиэкспресс, вас тут найдут ветеренары. Но ни одна больница не возьмет себе такой. Кстати, китайцы из Шеньдженя активно продают свои УЗИ аппараты (у нас в центре стоит один такой) с качеством не хуже мировых брендов. Но и стоят они почему-то не сильно дешевле, а вот в плане поддержки сильно проигрывают.
По поводу школ и всего такого. Производить копеечные УЗИ аппараты с плохими характеристиками для уроков, я думаю можно, просто это никому не нужно. УЗИ считается самым субъективным видом диагностики, где большая часть результата зависит от квалификации врача. Обычный человек увидит только неясные картинки и не сможет их корректно интерпретировать. А дети вряд ли что-то поймут, а школьная программа не заточена на привитие навыков УЗИ диагноста каждому ребенку. Тем же, кому нужны УЗИ для производства, имеют свой список требований, который наверняка не менее жесткий, чем у медицины.
Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
Пробирки у нас вакуэт, забор крови под боком и раз в не-помню-сколько минут оттуда приносят новую партию и ставят на борт — поэтому в холодильнике нужды нет. Сколь я знаю, даже хорошие пробирки, нормальные медсестры и близкий забор крови не спасают от появления сгустков. Плюс есть кровь по проекту централизованной лаборатории, которую у нас на оленях везут. Да, тоже вакуэт пробирки, но там никаких гарантий по качеству забора и транспортировки.
настраивают на то, что на примере запроса из начала статьи будет разобран алгоритм построения плана и дана общая теория по специфике работы планировщика MS SQL. А закончится статья тем, что автор победил проблему с учётом вышеописанных знаний. По итогу же имеем «Вот запрос, нагенерированный 1С на 20 таблиц с повторами. Он строится иногда долго. Почему? Много таблиц в соединении плохо, так как эн-факториал. Вывод — не делайте много таблиц и уважайте планировщик». Ну такому уровню статей не место на Хабре, простите.