pgsql – PostgreSQL

Это хорошее желание, но вам потребуется ещё несколько лет работы, чтобы понять какие там могут быть на самом деле проблемы и какие вопросы реально ставить. Пока что — делайте по учебнику, смотрите — что получилось.

Я хочу знать как принимать это решение без эксперимента

Никак, это непрофессионально

Там много нюансов с требованиями — по операциям, сложности, консистентности, надёжности и доступности. И да, всё на запись, что больше публично доступных значений tpmC — требует именно нетривиальной оценки. Для пг это порядка 200-300к, т.е.в секунду — 3-5к.

На собеседовании задача за час оценить уровень систем дизайна и sre у инженера На нём эвристики подходят, в реальных системах на высоких нагрузках - на мой взгляд нет

Это сильное преувеличение. Чаще всего, если принять произвольный набор требований — остаётся ноль. Потом можно урезать осетра до требований, оправданных бизнес-цэлями — выясняется, что можно выжыть на чём угодно, только на чём-то полегче, на чём-то посложнее.

Разумно. Но я о том же. Мы не всегда можем из требований сделать вывод о том что подходит именно X. И одним из критериев которыми иногда можно играть (но они все равно есть) - является пропускная способность. Поэтому я вижу что она как и другие фичи должна быть частью того как мы выбираем

Вбейте в какой-нибудь llm с поиском "tpmC постгрес результаты". Там будет много интересного, по методике в том числе.

Спасибо, посмотрю!

На самом деле мне тожэ было бы любопытно посмотреть на спортивные результаты по вставкам. И особенно — как их добивались. Но вот вам, как ни странно, сейчас ориентироваться на эти числа было бы очень неполезно.

Вы, и не только вы, почему-то додумываете за меня (кажется), что раз я спрашиваю про цифры, то я планирую именно их использовать как отправную точку при выборе. Но если я у вас не спрашиваю о том какие гарантии консенсуса могут дать те или иные системы, или например насколько их легко масштабировать/решардировать, это же не значит что я не собираюсь принимать во внимание эти требования. Все будет хорошо ) Принципиальная разница в том, что по многим другим пунктам я для себя картину уже рассортировал, до каких-то пока не добрался, а застрял как раз на достижимых показателях производительности. За которыми и пришел.

Почти любую фразу можно при желании трактовать негативно или позитивно, не исключая и протицированную вами. Вы ставите меня в трудное положение, мне есть что ответить, но нелепо превращать вопрос на профессиональную тему в обсуждение моей личности или моих подходов. Предлагаю эту ветку обсуждения остановить на том, что я услышал вашу искреннюю озабоченность тем, как я буду принимать решения, и не оставлю ее без внимания.

А потом вопросы — чо все как-то растоманов не жалуют...

Консенсус тут мимо, запутаемся Консистентность распределённых систем Eventually Strong(lineriazability) Read-your-writes Sequential Causal

Я думаю нагляднее всего - поднять базу и понагружать ее в разных режимах, посматривая метрики. Сам собираюсь понять PG поглубже, чтобы принимать более взвешенные решения при проектировании Так что мне будет интересно. Если что-то такое соберете, отпишите пожалуйста 🙂 Я пока не взялся за эту задачу, но в последствии планирую до нее добраться

Написал статью про JOIN по FK: каждый FK превращается в пару SQL-функций — client(document) и client_document_list(profile), планировщик их полностью инлайнит, планы совпадают с ручными джойнами узел в узел. https://habr.com/ru/articles/1065684/ github: https://github.com/asmgit/pg_relation_sql

FYI: Autobase 2.10.0 released https://github.com/autobase-tech/autobase/releases/tag/2.10.0