Я смотрел алгоритм Дейча-Мокотоффа, но нашёл его реализацию только для английского алфавита. У вас были иностранные имена в латинице? Или вы русские имена транслитерируете?
Да, но в данном случае это было как из пушки по воробьям. Во-первых, лишняя сложность решения. Во-вторых, для транзакционных реализаций внешней индексации из PostgreSQL в ElasticSearch я нашёл только Zombodb. Но он умеет только pg 9.3,9.4,9.5 и es 1.7.1… остальные варианты сопряжения были сложнее и не оправданы на текущем объеме данных
Согласен, качество выдачи надо было добавить. Но на всех запросах, кроме варианта с триграммы + полнотекстовый поиск по «смернов дин онатол» успешно находился «Смирнов Денис Анатольевич». В озвученном варианте (триграмм и полнотекст) по лексеме «дин» нашлась «дина», но не «денис». Во всех остальных случая селективность просто потрясающая и вызывает желание перекреститься)
Это действительно упрощенная модель в статье. В реальности есть и дата рождения, и енп, снилс, паспорта, документы. Есть история изменений и архивный поиск по девичьей фамилии. Это я не тащил в статью, чтобы не загромождать запросы — история была именно про опечатки
А вот за абзац про экранирование строки через $$ вам от меня благодарность! Я писал функции и не понимал, что просто описываю тело функции в виде обычного текстового поля в ddl команде create function .... as $$ ... $$. По факту я могу смело писать
Кстати, PostgresPro вроде имеет свой сертифицированный форк. А расскажите про Линтер, что за зверь такой? А то в интернетах про него внятных технических подробностей не нашёл при поверхностном поиске. И раз вы сказали, что сильная сторона pg — это mvcc, то что тогда у Линтера? Блокировщик?
Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.
думаю, под «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 имеет отличную пропускуную способность, кучу показателей ОАК… но не имеет нормальных фильтров от сгустков крови в пробирках. В результате у нас сервисное обслуживание не вылазит с этих приборов. Со старыми МЕКами таких проблем никогда не было.
Это действительно упрощенная модель в статье. В реальности есть и дата рождения, и енп, снилс, паспорта, документы. Есть история изменений и архивный поиск по девичьей фамилии. Это я не тащил в статью, чтобы не загромождать запросы — история была именно про опечатки
А вот за абзац про экранирование строки через $$ вам от меня благодарность! Я писал функции и не понимал, что просто описываю тело функции в виде обычного текстового поля в ddl команде
create function .... as $$ ... $$. По факту я могу смело писатьвместо идущего в примерах
ведь это одно и то же.
Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.
Если вы собираете простейший УЗИ аппарат с неясными характеристиками, за результаты которого никто не отвечает, не планируете развивать свою фирму и используется аппарат не для людей — добро пожаловать на алиэкспресс, вас тут найдут ветеренары. Но ни одна больница не возьмет себе такой. Кстати, китайцы из Шеньдженя активно продают свои УЗИ аппараты (у нас в центре стоит один такой) с качеством не хуже мировых брендов. Но и стоят они почему-то не сильно дешевле, а вот в плане поддержки сильно проигрывают.
По поводу школ и всего такого. Производить копеечные УЗИ аппараты с плохими характеристиками для уроков, я думаю можно, просто это никому не нужно. УЗИ считается самым субъективным видом диагностики, где большая часть результата зависит от квалификации врача. Обычный человек увидит только неясные картинки и не сможет их корректно интерпретировать. А дети вряд ли что-то поймут, а школьная программа не заточена на привитие навыков УЗИ диагноста каждому ребенку. Тем же, кому нужны УЗИ для производства, имеют свой список требований, который наверняка не менее жесткий, чем у медицины.
Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
Пробирки у нас вакуэт, забор крови под боком и раз в не-помню-сколько минут оттуда приносят новую партию и ставят на борт — поэтому в холодильнике нужды нет. Сколь я знаю, даже хорошие пробирки, нормальные медсестры и близкий забор крови не спасают от появления сгустков. Плюс есть кровь по проекту централизованной лаборатории, которую у нас на оленях везут. Да, тоже вакуэт пробирки, но там никаких гарантий по качеству забора и транспортировки.