А, намёк понял.

А, намёк понял.

Возможно, про это стоит делать доклад… Но PgDay не будет этим летом, а PgConf через год (если будет)

Но нет, тут этого нет. последующие запросы с никак не связанными id.

Переформулирую: 10 запросов вида a=1 and b=1; a=1 and b=2; a=1 and b=3, … выполнятся по-разному в зависимости от того, в каком порядке создан индекс (a,b) vs (b,a). Даже несмотря на то, что каждый запрос загружал всегда ровно одну строку (ну или сколько там).

Оптимизатор разве не научился переставлять аргументы?

Но нет, тут этого нет. последующие запросы с никак не связанными id.

Прямо random-random распределение?

да

Оптимизатор разве не научился переставлять аргументы?

Вопрос не в оптимизаторе, а в том, что будет разное количество дисковых операций при обращении к индексам. Особенно в случае index only scan

Вопрос не в оптимизаторе, а в том, что будет разное количество дисковых операций при обращении к индексам. Особенно в случае index only scan

Правило "селективное первым" —- это для того, чтобы index on (a, b) мог быть заодно использован для запросов WHERE A = 'x'.

Вопрос не в оптимизаторе, а в том, что будет разное количество дисковых операций при обращении к индексам. Особенно в случае index only scan

Вы не могли бы пояснить, о чём именно речь?

Вы не могли бы пояснить, о чём именно речь?

Попробую на пальцах. Данные в индексе хранятся блоками по 8 килобайт. Если базе нужна лишь одна строка, то всё равно загружается весь блок. В наших интересах сделать так, чтобы в загружаемом блоке нужными оказались _все_ строки, а не какая-то одна. Допустим, в таблице (a,b) находятся такие записи: (1,1) (1,2) (1,3) (1,4) (2,1) (2,2) (2,3) (2,4) Допустим, в индексный блок помещается лишь 2 записи (в реальности, конечно, в 8кб помещается штук 50-100, но суть это не меняет) Допустим, запрашиваться будут данные по a=1 and b in (1,2,3,4) Индекс (a,b) будет выглядеть следующим образом: блок1: (1,1) (1,2) блок2: (1,3) (1,4) блок3: (2,1) (2,2) блок4: (2,3) (2,4) Запрос (один через in или 4 раздельных) в конечном итоге загрузят блок1 и блок2. Т.е. мы загрузили 2 блока данных с диска, и в них оказались нужные нам строки. Индекс (b,a) будет выглядеть по-другому (самый простой способ понять, это представить как будет выглядеть результат order by b,a ) блок1: (1,1) (2,1) блок2: (1,2) (2,2) блок3: (1,3) (2,3) блок4: (1,4) (2,4) Для загрузки нужных нам четырёх строк придётся загрузить все 4 блока. В каждом будет одна нужная строка, и одна ненужная. Получается, что при таких входных данных индекс (b,a) будет требовать больше места в buffer cache, он будет хуже работать после перезагрузок (ну или подобных действий, когда сбрасывается кэш). Хотя, «в среднем по больнице», колонка b более селективная и «вроде как она должна быть 1-ой в индексе»

Попробую на пальцах. Данные в индексе хранятся блоками по 8 килобайт. Если базе нужна лишь одна строка, то всё равно загружается весь блок. В наших интересах сделать так, чтобы в загружаемом блоке нужными оказались _все_ строки, а не какая-то одна. Допустим, в таблице (a,b) находятся такие записи: (1,1) (1,2) (1,3) (1,4) (2,1) (2,2) (2,3) (2,4) Допустим, в индексный блок помещается лишь 2 записи (в реальности, конечно, в 8кб помещается штук 50-100, но суть это не меняет) Допустим, запрашиваться будут данные по a=1 and b in (1,2,3,4) Индекс (a,b) будет выглядеть следующим образом: блок1: (1,1) (1,2) блок2: (1,3) (1,4) блок3: (2,1) (2,2) блок4: (2,3) (2,4) Запрос (один через in или 4 раздельных) в конечном итоге загрузят блок1 и блок2. Т.е. мы загрузили 2 блока данных с диска, и в них оказались нужные нам строки. Индекс (b,a) будет выглядеть по-другому (самый простой способ понять, это представить как будет выглядеть результат order by b,a ) блок1: (1,1) (2,1) блок2: (1,2) (2,2) блок3: (1,3) (2,3) блок4: (1,4) (2,4) Для загрузки нужных нам четырёх строк придётся загрузить все 4 блока. В каждом будет одна нужная строка, и одна ненужная. Получается, что при таких входных данных индекс (b,a) будет требовать больше места в buffer cache, он будет хуже работать после перезагрузок (ну или подобных действий, когда сбрасывается кэш). Хотя, «в среднем по больнице», колонка b более селективная и «вроде как она должна быть 1-ой в индексе»

А, понял, спасибо. Но, всё же, «в среднем по больнице» при создании индексов под запросы " WHERE a = 'x' AND b = 'y' " считается, что 'x' / 'y' независимы. Если это не так, то, конечно, описанным вами способом можно выиграть в производительности.

А, понял, спасибо. Но, всё же, «в среднем по больнице» при создании индексов под запросы " WHERE a = 'x' AND b = 'y' " считается, что 'x' / 'y' независимы. Если это не так, то, конечно, описанным вами способом можно выиграть в производительности.

Немного позанудствую: «'x' / 'y' независимы» вопрос не в зависимости-независимости, а в том, какое пространственно-временное распределение имеют входные параметры. Я, например, нечасто сталкивался с полностью равномерными распределениями. Обычно всё-таки есть перекос (не только в самих данных, но и в параметрах). И наоборот: при нагрузочном тестировании оказывается, что использовать равномерное распределение для всех данных противопоказано. Например, распределение имён и фамилий далеко не равномерное. Получить много «Ивановых Иванов Ивановичей» одним random’ом тяжело, а на практике такая комбинация сплошь и рядом.

Немного позанудствую: «'x' / 'y' независимы» вопрос не в зависимости-независимости, а в том, какое пространственно-временное распределение имеют входные параметры. Я, например, нечасто сталкивался с полностью равномерными распределениями. Обычно всё-таки есть перекос (не только в самих данных, но и в параметрах). И наоборот: при нагрузочном тестировании оказывается, что использовать равномерное распределение для всех данных противопоказано. Например, распределение имён и фамилий далеко не равномерное. Получить много «Ивановых Иванов Ивановичей» одним random’ом тяжело, а на практике такая комбинация сплошь и рядом.

Всё это верно... но когда я вижу, что кто-то тратит время на раздумья о распределении параметров (не данных!), мне сразу начинает казаться, что этот кто-то занимается преждевременной оптимизацией. ;) А с корреляциями в данных мало что можно сделать в PostgreSQL, на данный момент. Да и вообще, это объективно трудно. Да, в большинстве случаев в данных есть корреляции между атрибутами, и предположение независимого распределения очевидно неверно... но на вопрос, что использовать вместо него, этот факт не отвечает. ;(

Всё это верно... но когда я вижу, что кто-то тратит время на раздумья о распределении параметров (не данных!), мне сразу начинает казаться, что этот кто-то занимается преждевременной оптимизацией. ;) А с корреляциями в данных мало что можно сделать в PostgreSQL, на данный момент. Да и вообще, это объективно трудно. Да, в большинстве случаев в данных есть корреляции между атрибутами, и предположение независимого распределения очевидно неверно... но на вопрос, что использовать вместо него, этот факт не отвечает. ;(

Есть простое решение: купить SSD и поместить базу туда. По-моему, если кто-то делает сервис и вообще не задумывается о том, какие данные будут подаваться на вход, его ждут сюрпризы в эксплуатации

Есть простое решение: купить SSD и поместить базу туда. По-моему, если кто-то делает сервис и вообще не задумывается о том, какие данные будут подаваться на вход, его ждут сюрпризы в эксплуатации

Да, купить и поместить. О соотношении затраты / результат надо думать в первую очередь, IMHO.

Что это было?!

Прошу прощения, залипло

Удаляй всё. Они не нужны уже раз ты спрашиваешь. ??

а что это за файлы

в гугл не нашел обьяснения

толкового

Всем привет. Вопрос не по PostgreSQL, a по NoSQL. Требуется хранить информацию о прохождении обследования пациентом. Одно обследование несет в себе информацию объемом более 1000 строк. Если использовать реляционную БД, то я думаю правильней будет хранить путь к файлу с данной информацией. Но тут предложили использовать NoSQL, но я в этой теме слабо обучен, поэтому хочу спросить. Стоит ли для этой задачи использовать NoSQL, или нет?

Всем привет. Вопрос не по PostgreSQL, a по NoSQL. Требуется хранить информацию о прохождении обследования пациентом. Одно обследование несет в себе информацию объемом более 1000 строк. Если использовать реляционную БД, то я думаю правильней будет хранить путь к файлу с данной информацией. Но тут предложили использовать NoSQL, но я в этой теме слабо обучен, поэтому хочу спросить. Стоит ли для этой задачи использовать NoSQL, или нет?

1000 строк, а в каждой строке что?

1000 строк, а в каждой строке что?

Данные измерений пульса, частоты сердца и т.д.

Ну такие числовые данные (метрики) можно хранить по разному. Всё зависит уже от того для чего будешь хранить - графики потом строить как в графане например или ещё что. Или может поиск делать и отчёты чтобы по анализам искать закономерности.

Всем привет. Вопрос не по PostgreSQL, a по NoSQL. Требуется хранить информацию о прохождении обследования пациентом. Одно обследование несет в себе информацию объемом более 1000 строк. Если использовать реляционную БД, то я думаю правильней будет хранить путь к файлу с данной информацией. Но тут предложили использовать NoSQL, но я в этой теме слабо обучен, поэтому хочу спросить. Стоит ли для этой задачи использовать NoSQL, или нет?

Это вас сурово как-то обманули. Результаты медицинских обследований вполне себе укладываются в реляционную модель, и соответственно - в реляционную СУБД.

Ну такие числовые данные (метрики) можно хранить по разному. Всё зависит уже от того для чего будешь хранить - графики потом строить как в графане например или ещё что. Или может поиск делать и отчёты чтобы по анализам искать закономерности.

Будет и отчет и графики

Ну такие числовые данные (метрики) можно хранить по разному. Всё зависит уже от того для чего будешь хранить - графики потом строить как в графане например или ещё что. Или может поиск делать и отчёты чтобы по анализам искать закономерности.

Эммм.... Графики, как правило, сопровождаются отчётами. Так что сразу закладывать и на то, и на другое. Во, вопрошатель уже сам сказал.

Это вас сурово как-то обманули. Результаты медицинских обследований вполне себе укладываются в реляционную модель, и соответственно - в реляционную СУБД.

А не просветите: в каких случаях тогда полезно использовать NoSQL, а то многие говорят что она почти всегда лучше

Будет и отчет и графики

Ну всё зависит от объёмов. На несколько сотен тысяч обследований нормально, после нескольких миллионов начнуться проблемы.

А не просветите: в каких случаях тогда полезно использовать NoSQL, а то многие говорят что она почти всегда лучше

Я не знаю, где лучше использовать NoSQL. Все решения, которые я видел лично, обусловлены были: модно, задорно, молодёжно. Ну и чтоб админ не спал, а замордовался всё это Носкульное гАвнище обслуживать. Как сейчас с эксплуатацией носкулей - не скажу, не знаю. Да и знать, если честно, большим желанием не горю.

Ну всё зависит от объёмов. На несколько сотен тысяч обследований нормально, после нескольких миллионов начнуться проблемы.

Сотен тысяч обследований - это если в БД хранить путь до файла обследования или если хранить всю информацию файла непосредственно в БД?

Сотен тысяч обследований - это если в БД хранить путь до файла обследования или если хранить всю информацию файла непосредственно в БД?

В БД всё. Кроме файлов снимков и т.п.

Ну вот где местные медики, когда они так нужны?! (местные медики - это тут есть люди, которые делают и обслуживают БД для медицины)

Ну вот где местные медики, когда они так нужны?! (местные медики - это тут есть люди, которые делают и обслуживают БД для медицины)

Спит он наверное ))

Ну вот где местные медики, когда они так нужны?! (местные медики - это тут есть люди, которые делают и обслуживают БД для медицины)

На сколько я понял, то когда мне советовали использовать NoSQL, то предлагали хранить все данные обследования непосредственно в БД, без отдельных файло

Он? Моя память налево пошла? Но по-моему, тут далеко не один в медицине.

а что это за файлы

https://www.postgresql.org/docs/current/static/storage-file-layout.html

На сколько я понял, то когда мне советовали использовать NoSQL, то предлагали хранить все данные обследования непосредственно в БД, без отдельных файло

Не надо результаты хранить в где попало. Оно прекрасно себя будет чувствовать в РСУБД. И гарантированно лучше, как по поиску, так и по обновлению. Единственное, что приходит в голову - это "шардить" результаты по объекту исследований: т.е. кровь, отдельно, моча - отдельно, ЖКТ - отдельно, нервы - опять же отдельно.

Он? Моя память налево пошла? Но по-моему, тут далеко не один в медицине.

Ну у меня в знакомых только один. А он уже ушёл из группы. Видимо уже не в медицине.

А не просветите: в каких случаях тогда полезно использовать NoSQL, а то многие говорят что она почти всегда лучше

Объясняю: тебе солгали, носкуль лучше на весьма ограниченном круге задач

А у вас, судя по всему, всё будет свалено в одну кучу.

На сколько я понял, то когда мне советовали использовать NoSQL, то предлагали хранить все данные обследования непосредственно в БД, без отдельных файло

Ну попробуйте хранить в БД сами файлы типа картинок. Потом расскажите как у вас распухла БД и почему все запросы стали медленее и т.п.

А картинки - в отказоустойчивый сторадж. И телемаркет!

Всем привет. Как вы относитесь к предлогам в названии полей таблицы?

Ну попробуйте хранить в БД сами файлы типа картинок. Потом расскажите как у вас распухла БД и почему все запросы стали медленее и т.п.

Я прекрасно понимаю что хранить данные из файлов в бд - это плохая идея. Но я это сказал к тому, что мне посоветовали использовать nosql, для хранения этой информации в бд, вот я и подумал, что nosql не разбухает от этого

Я прекрасно понимаю что хранить данные из файлов в бд - это плохая идея. Но я это сказал к тому, что мне посоветовали использовать nosql, для хранения этой информации в бд, вот я и подумал, что nosql не разбухает от этого

А за счет какой магии тогда работает nosql?

А за счет какой магии тогда работает nosql?

Я и не знаю)) Поэтому и спрашиваю тут, как лучше поступить)

Я и не знаю)) Поэтому и спрашиваю тут, как лучше поступить)

Взять и потестить. нагенерить файла по идее не большая проблема.

Взять и потестить. нагенерить файла по идее не большая проблема.

Проблема небольшая, интересно было узнать как работает NoSQL, потому что посмотрел по интернету: все хвалят и советуют его использовать

Проблема небольшая, интересно было узнать как работает NoSQL, потому что посмотрел по интернету: все хвалят и советуют его использовать

Угу. а по факту - учитывая задачу, я бы вобще посмотрел в сторону чего-то поддерживающего s3-api. И валил все файло туда.

Проблема небольшая, интересно было узнать как работает NoSQL, потому что посмотрел по интернету: все хвалят и советуют его использовать

Все ускорения и улучшения - от жертвования чем-то из ACID или других выборов в CAP

Ну вот где местные медики, когда они так нужны?! (местные медики - это тут есть люди, которые делают и обслуживают БД для медицины)

Плюсую, есть)

Есть два больших проекта, один целиком медицина, другой результаты и там записей на лярд. Все вполне укладывается в реляционную модель и у нас pg.

Есть и вакансии в команду dba, по обслуживанию centsos, бд, tomcat. г. Казань.

Есть и вакансии в команду dba, по обслуживанию centsos, бд, tomcat. г. Казань.

вилка на dba какая?

Есть и вакансии в команду dba, по обслуживанию centsos, бд, tomcat. г. Казань.

Позавчера ещё могли встретиться но уже уехал. Просто ради интереса)

Ребята, по кластерам pg спецы тут есть?

Собственно интересует, кто пробовал поднимать мультимастер на 2 нодах, на возможностях из коробки, поделитесь опытом

Собственно интересует, кто пробовал поднимать мультимастер на 2 нодах, на возможностях из коробки, поделитесь опытом

а мультимастер уже есть в pg?

Собственно интересует, кто пробовал поднимать мультимастер на 2 нодах, на возможностях из коробки, поделитесь опытом

Главный вопрос - зачем оно вам нужно?

Ну вот где местные медики, когда они так нужны?! (местные медики - это тут есть люди, которые делают и обслуживают БД для медицины)

Медики-админы тусуются в другой группе, it в медицине

@it_in_med

Я прекрасно понимаю что хранить данные из файлов в бд - это плохая идея. Но я это сказал к тому, что мне посоветовали использовать nosql, для хранения этой информации в бд, вот я и подумал, что nosql не разбухает от этого

А какого рода медицинские результаты вы получаете, что возникает задача хранить файлы изображений? В диагностике обычно это dicom, так возьмите уже готовый pacs и работайте с ним по api (ну или саму на каком-то опенсорсном движке напишите свой и 100500 раз отстрелите себе ногу). Если это показатели для протокола в карте пациента, то там большая часть залазит в реляционную схему (а кто не поместился - в json). Протоколы лучше генерировать на сервере (а не хранить), если у вас все норм с языком разметки (для типографической точности можете в латехе пострадать, например). Самый главный вопрос - будете ли вы потом по этим показателям искать или строить отчеты? Если будете, то nosql вам точно не зайдёт.

А какого рода медицинские результаты вы получаете, что возникает задача хранить файлы изображений? В диагностике обычно это dicom, так возьмите уже готовый pacs и работайте с ним по api (ну или саму на каком-то опенсорсном движке напишите свой и 100500 раз отстрелите себе ногу). Если это показатели для протокола в карте пациента, то там большая часть залазит в реляционную схему (а кто не поместился - в json). Протоколы лучше генерировать на сервере (а не хранить), если у вас все норм с языком разметки (для типографической точности можете в латехе пострадать, например). Самый главный вопрос - будете ли вы потом по этим показателям искать или строить отчеты? Если будете, то nosql вам точно не зайдёт.

Неужели не я один страдал такой фигней?) С мед.отчетами и как их хранить

Неужели не я один страдал такой фигней?) С мед.отчетами и как их хранить

Нет, не один. Добро пожаловать в клуб)

Нет, не один. Добро пожаловать в клуб)

А еще у нас было все на mssql -_-

Я прекрасно понимаю что хранить данные из файлов в бд - это плохая идея. Но я это сказал к тому, что мне посоветовали использовать nosql, для хранения этой информации в бд, вот я и подумал, что nosql не разбухает от этого

Вообще конечно изображения лучше хранить внешне, а в базе указывать относительный путь.

Это Катманду?

Да

Тьфу, не туда запостил.

С чем может быть связана такая ошибка: 'utf8' codec can't decode byte 0xc2 in position 0: invalid continuation byte - при добавлении сервера? Помогите, пожалуйста.

c тем, что некий питонячий софт посередине не умеет кириллицу

c тем, что некий питонячий софт посередине не умеет кириллицу

? Я не ввожу кириллицу в полях.

в полях чего?

PgAdmin4

какая ОС?

какая ОС?

Windows 7. Это домашний компьютер.

нет ли кириллицы в путях, например, в имени пользователя? :)