Зависит от задач. Во многих задачах важен throughput (самое простое что приходит в голову: файл с тысячами записей нужно обработать во много потоков за минимальное время). В таких случаях правильнее смотреть именно на average time. Но в других задачах, типа того же веба, важно latency. Тогда надо смотреть на процентили: медиану P50 или там P95. Бывает также важно и то и другое, поэтому приходится выводить и avg, и P95.
Это правда. Но есть и разница. "Тётя Ася сказала, что..." звучит, как ни странно, для многих гораздо менее убедительно, чем "ИИ сказал, что...". Тётя Ася хотя бы к сплетням добавляет "не ну я конечно не знаю, но мне так сказали, за что купила за то продаю" или там "я так думаю". Слова всяких тёть и дядь как-то уже приноровились фильтровать (плоховато, но хоть как-то). Галлюцинации ИИ фильтровать научиться ещё предстоит.
главный недостаток такого подхода всё-таки не в "некошерности", а как раз в области производительности, как ни странно. Точнее — масштабируемости. Всё действительно очень быстро, пока влезает на одну машину. При увеличении объёмов / нагрузки вы будете добавлять процессор / память на сервер субд, до тех пор пока не обнаружите, что ой, а больше 256 ядер больше чем на 4GHz как-то не получается воткнуть в железку. А с горизонтальным масштабированием у РСУБД до сих пор всё сложно... ну, как. некоторые решения есть, но у них куча своих ограничений — не получится просто включить галочку в конфиге и всё смасштабируется, придётся приложение адаптировать.
Действительно, заинтриговали, но не сказали самого интересного: какой статус этой разработки? Экспериментальный патч в недрах Postgres Pro? Доработка для следующей версии Postgres Pro EE? Патч, отправленный в hackers?
ну, не думаю что прям вот щас вендекапец будет. Такое ведь видели уже, что с Me, что с Vista... поддержку 10ки продлят до тех пор, пока не выйдет 12 (ну или 11 допилят).
Возможно не совсем скоро. Гугл говорит, что LHC генерирует данных около 4 петабайт в год, а общий объём хранилищ CERN порядка 600 петабайт. Бывают уже компьютеры, на которых можно обучить нейронку (мягко говоря не самое экономное с вычислительной и энергетической точек зрения занятие) на сотне-другой петабайт данных? :)
Сейчас да, но это рассматривается как печальное, но временное явление. Все эти поиски "новой физики" или "суперсимметрии" — это про поиски более простой и более объясняющей теории, из которой все эти Хиггсы бы разумным образом следовали (а желательно ещё чтобы ОТО вместе с большим взрывом и теорией инфляции оттуда заодно тоже следовала). Пока не нашли, но ищут.
Имхо главная проблема натуральных ключей — в том, что "натуральность" меняется со временем, и делать соответствующие доработки в ПО может оказаться слишком дорого. Ну, грубо говоря, ИНН сейчас есть у всех граждан РФ и не меняется в течение жизни, так что если вы делаете что-то типа госуслуг, то почему бы не сделать его первичным ключом? А через год принимают закон, по которому ИНН становится можно менять по заявлению, и... ой.
За первый пункт +100500. Классический приём: письмо 10 адресатам с вопросом вида "Коллеги, что будем делать" или "коллеги, когда будет YYY". Естественно, все 10 адресатов молчат, потому что каждый думает, что спрашивают не его. Есть подозрение, что некоторые товарищи такое письмо применяют для ИБД: вроде как ПМ своё дело сделал, команду потеребил, а команда ни гугу.
это именно лимит, а не способ разделить ресурсы по разным пользователям. На практике, юзер в БД — это обычно не юзер в смысле человек, а приложение. Поэтому, если у вас например есть какое-нибудь мониторинговое приложение, и есть основания опасаться, что оно внезапно (из-за бага или уязвимости) откроет 100 подключений, можно ему зарезать connection limit. А основному бизнес-приложению не ограничивать, т.к. это как раз для него предназначенная БД.
ну как-то не понятно зачем сомневаться, если легко проверить.
portnov=# show max_connections;
max_connections
-----------------
100
(1 row)
portnov=# create user usr1 with connection limit 30;
CREATE ROLE
portnov=# create user usr2 with connection limit 30;
CREATE ROLE
portnov=# create user usr3 with connection limit 30;
CREATE ROLE
portnov=# create user usr4 with connection limit 30;
CREATE ROLE
portnov=# create user usr5 with connection limit 30;
CREATE ROLE
portnov=# create user usr6 with connection limit 30;
CREATE ROLE
portnov=# create user usr7 with connection limit 30;
CREATE ROLE
portnov=# create user usr8 with connection limit 30;
CREATE ROLE
portnov=# create user usr9 with connection limit 30;
CREATE ROLE
portnov=# create user usr10 with connection limit 30;
CREATE ROLE
portnov=# \du usr*
List of roles
Role name | Attributes | Member of
-----------+----------------+-----------
usr1 | 30 connections | {}
usr10 | 30 connections | {}
usr2 | 30 connections | {}
usr3 | 30 connections | {}
usr4 | 30 connections | {}
usr5 | 30 connections | {}
usr6 | 30 connections | {}
usr7 | 30 connections | {}
usr8 | 30 connections | {}
usr9 | 30 connections | {}
вот подключиться всем этим пользователям по 30 раз каждому одновременно — PG не даст, max_connections не позволит.
так можно убедиться, что PG действительно "увидел" huge pages и стал ими пользоваться: если почему-то не получится, он упадёт на старте, а не будет молча работать в "медленном" режиме, как при try.
вы ссылаетесь на документацию конкретного облачного сервиса. В PG такой параметр у юзера есть, но он не обязательный, по дефолту не задан, и даже если задан — он не отбирает лимиты у других юзеров. Ну, просто потому, что у них-то этого лимита нету. https://postgrespro.ru/docs/postgresql/16/sql-createrole
Зависит от задач. Во многих задачах важен throughput (самое простое что приходит в голову: файл с тысячами записей нужно обработать во много потоков за минимальное время). В таких случаях правильнее смотреть именно на average time. Но в других задачах, типа того же веба, важно latency. Тогда надо смотреть на процентили: медиану P50 или там P95. Бывает также важно и то и другое, поэтому приходится выводить и avg, и P95.
Это правда. Но есть и разница. "Тётя Ася сказала, что..." звучит, как ни странно, для многих гораздо менее убедительно, чем "ИИ сказал, что...". Тётя Ася хотя бы к сплетням добавляет "не ну я конечно не знаю, но мне так сказали, за что купила за то продаю" или там "я так думаю". Слова всяких тёть и дядь как-то уже приноровились фильтровать (плоховато, но хоть как-то). Галлюцинации ИИ фильтровать научиться ещё предстоит.
главный недостаток такого подхода всё-таки не в "некошерности", а как раз в области производительности, как ни странно. Точнее — масштабируемости. Всё действительно очень быстро, пока влезает на одну машину. При увеличении объёмов / нагрузки вы будете добавлять процессор / память на сервер субд, до тех пор пока не обнаружите, что ой, а больше 256 ядер больше чем на 4GHz как-то не получается воткнуть в железку. А с горизонтальным масштабированием у РСУБД до сих пор всё сложно... ну, как. некоторые решения есть, но у них куча своих ограничений — не получится просто включить галочку в конфиге и всё смасштабируется, придётся приложение адаптировать.
Действительно, заинтриговали, но не сказали самого интересного: какой статус этой разработки? Экспериментальный патч в недрах Postgres Pro? Доработка для следующей версии Postgres Pro EE? Патч, отправленный в hackers?
ну, не думаю что прям вот щас вендекапец будет. Такое ведь видели уже, что с Me, что с Vista... поддержку 10ки продлят до тех пор, пока не выйдет 12 (ну или 11 допилят).
https://www.youtube.com/shorts/1Hu0f_ti9EQ
«извините, был напуган»
Возможно не совсем скоро. Гугл говорит, что LHC генерирует данных около 4 петабайт в год, а общий объём хранилищ CERN порядка 600 петабайт. Бывают уже компьютеры, на которых можно обучить нейронку (мягко говоря не самое экономное с вычислительной и энергетической точек зрения занятие) на сотне-другой петабайт данных? :)
Сейчас да, но это рассматривается как печальное, но временное явление. Все эти поиски "новой физики" или "суперсимметрии" — это про поиски более простой и более объясняющей теории, из которой все эти Хиггсы бы разумным образом следовали (а желательно ещё чтобы ОТО вместе с большим взрывом и теорией инфляции оттуда заодно тоже следовала). Пока не нашли, но ищут.
водопад как 10 лет назад не существовал примерно нигде, так и не существует...
Имхо главная проблема натуральных ключей — в том, что "натуральность" меняется со временем, и делать соответствующие доработки в ПО может оказаться слишком дорого. Ну, грубо говоря, ИНН сейчас есть у всех граждан РФ и не меняется в течение жизни, так что если вы делаете что-то типа госуслуг, то почему бы не сделать его первичным ключом? А через год принимают закон, по которому ИНН становится можно менять по заявлению, и... ой.
https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_money
всего голосов 1: ↑3/2ħ и ↓-1/2ħ
три с половиной землекопа.
Хорошо что не 0.3000004.
За первый пункт +100500. Классический приём: письмо 10 адресатам с вопросом вида "Коллеги, что будем делать" или "коллеги, когда будет YYY". Естественно, все 10 адресатов молчат, потому что каждый думает, что спрашивают не его. Есть подозрение, что некоторые товарищи такое письмо применяют для ИБД: вроде как ПМ своё дело сделал, команду потеребил, а команда ни гугу.
и что характерно - такой ответ с большой вероятностью будет передан выше по инстанциям дословно именно в таком виде. Или даже напрямую клиенту.
это именно лимит, а не способ разделить ресурсы по разным пользователям. На практике, юзер в БД — это обычно не юзер в смысле человек, а приложение. Поэтому, если у вас например есть какое-нибудь мониторинговое приложение, и есть основания опасаться, что оно внезапно (из-за бага или уязвимости) откроет 100 подключений, можно ему зарезать connection limit. А основному бизнес-приложению не ограничивать, т.к. это как раз для него предназначенная БД.
ну как-то не понятно зачем сомневаться, если легко проверить.
вот подключиться всем этим пользователям по 30 раз каждому одновременно — PG не даст, max_connections не позволит.
так можно убедиться, что PG действительно "увидел" huge pages и стал ими пользоваться: если почему-то не получится, он упадёт на старте, а не будет молча работать в "медленном" режиме, как при try.
вы ссылаетесь на документацию конкретного облачного сервиса. В PG такой параметр у юзера есть, но он не обязательный, по дефолту не задан, и даже если задан — он не отбирает лимиты у других юзеров. Ну, просто потому, что у них-то этого лимита нету.
https://postgrespro.ru/docs/postgresql/16/sql-createrole
в небольших конторах один человек может совмещать обязанности ПМ-а, аналитика, инженера-внедренца... он даже ещё и тимлидом может оказаться :)