Планируется ли сделать github ci/cd для тестов (а они есть?) и для создания готовых сборок под разные ОС? А то как-то ИМХО пока без наличия автоматизации сборки и тестирования страшновато использовать Ваш продукт, хоть он и кажется более функциональным чем nekoray или hiddify
Перевод оффицальных мануалов тоже полезен, хотя бы новичкам.
P.S. Авторам - кажеться, что огромные скрины Google Authenticator (и другие) это излишне, честно очень неудобно скролировать такую статью где банальный скрин (еще и полностью или частично заретуширован) занимает 2 экрана на 2k мониторе.
Работая в прошлом в банке с АБС на oracle был кейс что в бд хранились файлы с образцами подписей клиентов. Файлы занимают сущие копейки и хранить их в бд кажется логичным, тем более оракл это умел.
Если изначально таблица была на 1 шарде, а потом мы сказали роутеру что она стала референсной, то на другие шарды она заедет сама или все же ручками нужно ее копировать во все шарды?
А что будет если сделать UPDATE/DELETE/INSERT по этой таблице? Она по всем шардам бахнет запросы? Это я про поддержание таблицы в консистентном состоянии на всех шардах.
>> SELECT * FROM users LIMIT 1; -- возвращается столько пользователей, сколько шардов.
Это конечно неожиданное поведение. Хотя если явно говорите, что во всех запросах должен быть ключ шардирования, то вроде как логично что результат будет такой, НО все равно не логично.
И у MySQL его нету, по факту Vitess имеет некоторые неявные ограничения, а количество специалистов по нему (те кто реально поддерживал промышленный Vitess) стремиться к нулю. Так что я считаю, что для MySQL тоже нет решения.
1) Почему 14-я версия пг? На дворе уже 18-я есть. Ну хотя бы на 17-й тестировали;
2) Не указано производился ли тюнинг ОС на VM: измененные параметры sysctl, параметры i/o планировщика и прочее
3) Не указана версия ubuntu на VM
4) Не понял из статьи был ли это Managet k8s от Yandex или или свой на VM, а так же не понял был ли это чистый кластер (без соседей) или там что-то уже работало.
5) Про jit в пг выше валидный вопрос.
6) Насколько я понял пулер соединений не использовался или использовался?
Все эти тонкости могут повлиять на итоговую производительность в тестах.
>>нужно запускать pgbench в кубе, в одном случае в том же ns, что и бд.
Тут может быть куча разных кейсов. БД как правио живут в разных ns с приложениями, более того, БД могут жить в отдельном k8s чем приложение и это тоже валидный кейс.
Увы, но у Yandex.Cloud нет local-ssd на managed k8s, так что такой тест не получиться сделать. Если только разворачивать свой k8s на обычных VM с local-ssd, но это другая история и тут возникают вопросы - а правильно ли будет настроен кубер.
Я с Вами полностью согласен. Проследить все эти истории патчей из нескольких комитфестов, кучи рассылок, в каких-то репозиториях - это просто не реально обычному разработчику, который вдруг захотел помочь, хотя бы просто тестирванием
То есть единой точки ведения истории патча просто не существует. Посмотри там, сходи у того дома углы поотбивай, а потом иди туда покопайся в мусоре, а потом залезь в этот вагон уходящего поезда, а потом вот еще под этой половицей посмотри.
Но если честно, я в это слабо верю. Если ПостгресПро отдает приличное количество наработок в ванилу, то например от Тантор я не вижу рвения (или они втихушку это делают?). Возможно причина отчасти как раз в качестве кода, типа "А ну и так сойдет для ком. клиентов", но сдается мне, что есть и другая составляющая. Ну честно, не верю я что компания готова по доброте душевной отдать коммерческие наработки в ванилу. Ну выложили бы тогда все патчи у себя на сайте - берите люди добрые, у кого хватит сил и терпения - патчите и собирайте свои версии постгрес, а у кого еще и железные яйца, то используйте в проде. Но реальность увы другая Андрей.
>Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом.
Согласен, работают, но речь то про другое. Работают ли они full time над ванилой или full time над ответвлением постгрес в рамках коммерческой компании где они трудоустроены? Это все же разные постгрес и разные процессы. Какой процент времени они готовы тратить на ванилу, а какой на коммерческий продукт компании? Я уверен, что у все этот процент есть, так же как и есть список фичей которые коммерческая компания готова отдать в ванилу, но примут ли это в ванилу - риторический вопрос.
>Но сам процесс редко является проблемой
Не согласен. Вот пришел человек с патчем, предлагает фичу/багфикс, а в ответ тишина, пушит патч по 10 раз и снова тишина. Это не проблема когнитивной сложности системы, до этой части процесса дело даже не дошло. Это проблема процесса разработки, когда у комитеров/ревьюверов нехватка времени/сил или чего-то еще, чтобы проверить этот патч или хотя бы дать ответ человеку - мол хэй, ты молодец, но мы тут что-то загружены, давай ты пушнешь патч через пару недель когда будет посвободней. Ну а когда большой патч с классной фичей отклоняют, что мол мы не можем его проревьювить, мы боимся что он что-то поломает в неочевидном месте? По-моему это тоже проблемма процесса - мы не можем наладить процесс тестирования продукта, чтобы тесты покрывали наиболее важные части кода и когда мегафича что-то ломает, то тесты бы это отражали.
Внимание дефицитно наверно потому, что все они работают в каких-то компаниях на full time, а роль комитера в postgres она в режиме совместительства. Интересно есть ли разработчики внутри postgres кто работает только там на full time?
Почему же контрибьюторов не сильно много? Рискну предположить, что из-за модели разработки, из-за высокого порога вхождения. Кажеться, что сама модель разработки postgres далека от совершенства и даже не пытается измениться. Комитфесты, рассылки в hackers, присылание файлов patch, боже даже irc есть (интересно там кто-то есть?), система ревьювинга и коллективной разработки из прошлого века (уж простите, я избалован github/gitlab/gitea/forgejo/jira и прочими удобными инструментами, забросайте меня помидорами, я их люблю).
Речь не о бета выпусках (они кстате есть), а о смене модели формирования релизов и мышления в core team. Чтобы выделить какой-то roadmap ликвидации основных болячек, да хоть какой-то roadmap (которого в принципе нет, там написано no formal list of feature requirements required for development), позволить принимать патчи более оперативно и не мурыжить авторов годами.
Возьмем к примеру патч с 64-битным счетчиком транзакций от постгреспро - уверен он оттестирован и проверен, но не принимают в ванилу, почему? Он большой, затрагивает много чего… очень интересная причина. А может причина в том что он исправит родовую травму и у платных дистрибутивов постгрес будет -1 платная фича?
Тот же патч Андрея (uuid v7) который не вошел в 17 версию по смешной причине с rfc.
Есть и другие интересные и нужные патчи которые остались висеть в комитфестах без продвижения потому что автор просто устал ждать и убеждать.
Любой новый функционал должен покрываться тестами и соответствовать каким-то адекватным требованиям и при наличии таковых он имеет право быть принятым, но…
Эмммм, у Вас там не один бинарник? почему нельзя без докера? А если я не хочу докер, ну банально ресурсы не позволяют этот слоеный пирог запустить.
Планируется ли сделать github ci/cd для тестов (а они есть?) и для создания готовых сборок под разные ОС? А то как-то ИМХО пока без наличия автоматизации сборки и тестирования страшновато использовать Ваш продукт, хоть он и кажется более функциональным чем nekoray или hiddify
Перевод оффицальных мануалов тоже полезен, хотя бы новичкам.
P.S. Авторам - кажеться, что огромные скрины Google Authenticator (и другие) это излишне, честно очень неудобно скролировать такую статью где банальный скрин (еще и полностью или частично заретуширован) занимает 2 экрана на 2k мониторе.
Работая в прошлом в банке с АБС на oracle был кейс что в бд хранились файлы с образцами подписей клиентов. Файлы занимают сущие копейки и хранить их в бд кажется логичным, тем более оракл это умел.
Если изначально таблица была на 1 шарде, а потом мы сказали роутеру что она стала референсной, то на другие шарды она заедет сама или все же ручками нужно ее копировать во все шарды?
А что будет если сделать UPDATE/DELETE/INSERT по этой таблице? Она по всем шардам бахнет запросы? Это я про поддержание таблицы в консистентном состоянии на всех шардах.
>> SELECT * FROM users LIMIT 1; -- возвращается столько пользователей, сколько шардов.
Это конечно неожиданное поведение. Хотя если явно говорите, что во всех запросах должен быть ключ шардирования, то вроде как логично что результат будет такой, НО все равно не логично.
>у MySQL есть готовое решение, а у Postgres нет.
И у MySQL его нету, по факту Vitess имеет некоторые неявные ограничения, а количество специалистов по нему (те кто реально поддерживал промышленный Vitess) стремиться к нулю. Так что я считаю, что для MySQL тоже нет решения.
Есть кстате ProxySQL который с 3-й версии научился проксировать PostgreSQL, то есть по сути можно что-то сделать на нем. Но как оно работает я не проверял.
Статья неплохая, но есть много вопросов
1) Почему 14-я версия пг? На дворе уже 18-я есть. Ну хотя бы на 17-й тестировали;
2) Не указано производился ли тюнинг ОС на VM: измененные параметры sysctl, параметры i/o планировщика и прочее
3) Не указана версия ubuntu на VM
4) Не понял из статьи был ли это Managet k8s от Yandex или или свой на VM, а так же не понял был ли это чистый кластер (без соседей) или там что-то уже работало.
5) Про jit в пг выше валидный вопрос.
6) Насколько я понял пулер соединений не использовался или использовался?
Все эти тонкости могут повлиять на итоговую производительность в тестах.
>>нужно запускать pgbench в кубе, в одном случае в том же ns, что и бд.
Тут может быть куча разных кейсов. БД как правио живут в разных ns с приложениями, более того, БД могут жить в отдельном k8s чем приложение и это тоже валидный кейс.
Увы, но у Yandex.Cloud нет local-ssd на managed k8s, так что такой тест не получиться сделать. Если только разворачивать свой k8s на обычных VM с local-ssd, но это другая история и тут возникают вопросы - а правильно ли будет настроен кубер.
Спасибо
Спасибо, послежу
А что не дерьмо тогда (и чтобы оно было опенсорсное и чтобы документация конфетка и багов не было)?
Может Вы просто не умеете его готовить? Я про Clickhouse
Я с Вами полностью согласен. Проследить все эти истории патчей из нескольких комитфестов, кучи рассылок, в каких-то репозиториях - это просто не реально обычному разработчику, который вдруг захотел помочь, хотя бы просто тестирванием
То есть единой точки ведения истории патча просто не существует. Посмотри там, сходи у того дома углы поотбивай, а потом иди туда покопайся в мусоре, а потом залезь в этот вагон уходящего поезда, а потом вот еще под этой половицей посмотри.
>и версия патча дошла до 65.
Спасибо за разбор такой длинной истории, но где же эта 65-я версия? Где можно скачать файлы патча?
Спасибо за статью.
Есть ли планы что-то отдать в ванильный постгрес?
Любопытно про что угодно и не того качества.
Но если честно, я в это слабо верю. Если ПостгресПро отдает приличное количество наработок в ванилу, то например от Тантор я не вижу рвения (или они втихушку это делают?). Возможно причина отчасти как раз в качестве кода, типа "А ну и так сойдет для ком. клиентов", но сдается мне, что есть и другая составляющая. Ну честно, не верю я что компания готова по доброте душевной отдать коммерческие наработки в ванилу. Ну выложили бы тогда все патчи у себя на сайте - берите люди добрые, у кого хватит сил и терпения - патчите и собирайте свои версии постгрес, а у кого еще и железные яйца, то используйте в проде. Но реальность увы другая Андрей.
>Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом.
Согласен, работают, но речь то про другое. Работают ли они full time над ванилой или full time над ответвлением постгрес в рамках коммерческой компании где они трудоустроены? Это все же разные постгрес и разные процессы. Какой процент времени они готовы тратить на ванилу, а какой на коммерческий продукт компании? Я уверен, что у все этот процент есть, так же как и есть список фичей которые коммерческая компания готова отдать в ванилу, но примут ли это в ванилу - риторический вопрос.
>Но сам процесс редко является проблемой
Не согласен. Вот пришел человек с патчем, предлагает фичу/багфикс, а в ответ тишина, пушит патч по 10 раз и снова тишина. Это не проблема когнитивной сложности системы, до этой части процесса дело даже не дошло. Это проблема процесса разработки, когда у комитеров/ревьюверов нехватка времени/сил или чего-то еще, чтобы проверить этот патч или хотя бы дать ответ человеку - мол хэй, ты молодец, но мы тут что-то загружены, давай ты пушнешь патч через пару недель когда будет посвободней. Ну а когда большой патч с классной фичей отклоняют, что мол мы не можем его проревьювить, мы боимся что он что-то поломает в неочевидном месте? По-моему это тоже проблемма процесса - мы не можем наладить процесс тестирования продукта, чтобы тесты покрывали наиболее важные части кода и когда мегафича что-то ломает, то тесты бы это отражали.
Внимание дефицитно наверно потому, что все они работают в каких-то компаниях на full time, а роль комитера в postgres она в режиме совместительства. Интересно есть ли разработчики внутри postgres кто работает только там на full time?
Почему же контрибьюторов не сильно много? Рискну предположить, что из-за модели разработки, из-за высокого порога вхождения. Кажеться, что сама модель разработки postgres далека от совершенства и даже не пытается измениться. Комитфесты, рассылки в hackers, присылание файлов patch, боже даже irc есть (интересно там кто-то есть?), система ревьювинга и коллективной разработки из прошлого века (уж простите, я избалован github/gitlab/gitea/forgejo/jira и прочими удобными инструментами, забросайте меня помидорами, я их люблю).
Речь не о бета выпусках (они кстате есть), а о смене модели формирования релизов и мышления в core team. Чтобы выделить какой-то roadmap ликвидации основных болячек, да хоть какой-то roadmap (которого в принципе нет, там написано no formal list of feature requirements required for development), позволить принимать патчи более оперативно и не мурыжить авторов годами.
Возьмем к примеру патч с 64-битным счетчиком транзакций от постгреспро - уверен он оттестирован и проверен, но не принимают в ванилу, почему? Он большой, затрагивает много чего… очень интересная причина. А может причина в том что он исправит родовую травму и у платных дистрибутивов постгрес будет -1 платная фича?
Тот же патч Андрея (uuid v7) который не вошел в 17 версию по смешной причине с rfc.
Есть и другие интересные и нужные патчи которые остались висеть в комитфестах без продвижения потому что автор просто устал ждать и убеждать.
Любой новый функционал должен покрываться тестами и соответствовать каким-то адекватным требованиям и при наличии таковых он имеет право быть принятым, но…