Коллеги а есть где то исследование гендерного распределения в нашей профессии?

Нет, но дискриминация мужчин в бухгалтерии и отделах кадров очевидна.

Всем доброго дня! Помогите определиться какие варианты технологий можно выбрать под следующую задачу:
Есть несколько бд, например постгрес. Они шардированы по определенному принципу, например пользователи по фамилии от А до Н в 1й базе а от н до я - во второй. Перед ними стоит еще одна база которая умеет в ответ на заппос информации отдавать простую пару  с наименованием нужной основгой базы. Например для фамилии на В отдаст В=1. Абстрагируясь от примера выше - количество записей в этой предварительной базе будет сотни миллионов.
Вопрос: какую базу вы бы выбрали для этой межкластерной индексации? Обычный постгрес? Или что-то может побыстрее?
Важно чтобы целевое решение было опенсорсное.

Зависит от, того, сколько это памяти займет, и поместится ли в оперативку. Если немного, и задача только определить реплику по фамилии - можно брать что-то наподобие Redis

а) шаридирование по имени человека - плохо, ибо не контролируется вами
б) промежуточная база - должна выбирать адрес шарда - в ней не может быть миллионы записей
в) ну и смотрите в сторону noSQL баз, особенно если все же там у вас будет не миллиарды записей (in memory тогда)

Нене, там будут именно сотни миллионов записей потому что фио это только пример, в реальности данных будет куда как больше. Ну например ключ это уникальное ID пользователя или id операции там какой нибудь а значение номер шарды.
Соответственно инмемори не подходит. А еще и по надежности не устраивает. Вариант когда мы запись поднимаем из этой бд индексов в кэш для ускорения - да, ок, но это отдельный и более менее понятный вопрос.
Речь исключительно про перформанс. Какая опенсорс база будет быстрее постгреса на огромном количестве простых ключ-значение запросов?

если у вас в чистом виде key-value хранилище, то зачем вам SQL база? может что-то типа кассандры?

Касандра не очень хороша с т.з. скорости чтения, всё же она для записи

тогда бы я и промежуточную базу шардировал (hash, range, по любому критерию), что бы шардов было от 10 до 1000.
тогда промежуточные базы будут небольшими и влезут в память, а роутинг между ними сделать легко - 1000 записей, даже база не нужна.

Да вот я и думаю в строну чего то не SQL

Не, выгдядит сложно и ненадежно, сорри

хорошо, но перед выходом в прод подумайте как вы будете обеспечивать доступность, надежность и конситеность базы (чем больше база - тем это сложнее), т.к. у вас она single point of outage.

Имена имеют свойство меняться. Шардировать по такому признаку - сомнительная затея, на мой взгляд.
По решениям - Redis или Clickhouse. Первый быстрее, второй - дешевле.

Нереляционку, как выше писали.
Но я бы очень крепко задумался, а нужна ли там вообще база?
Неужели номер шарда нельзя вычислить, настолько хаотичное распределение?

С вычислением вариант тоже рассматриваем, просто с ним все более менее понятно

Если можно вычислить, нет ни одного аргумента в пользу базы в сотни лямов записей. Разве что, вычисление длится минут 20 )

кстати, можно тогда в сторону scylladb посмотреть.
но вообще я сторонник создать правило и функцию шардирования (что и делал когда-то).

серьезно? кликхаус? поиск по айдишнику? это прям эталон вредного совета.

20 Октября Нил Форд будет хостить воркшоп по архитектурным катам. Если есть желание можно организовать команду и поучаствовать 🙂
https://learning.oreilly.com/live-training/courses/architectural-katas/0636920458463/

How it works: You put together a first-rate team of three to five people, ready to tackle an architecture challenge. We’ll share the architecture problem with you at the kickoff on October 20. Then your team will have to solve it, working virtually in whatever way is best for you (video calls, group chat, shared docs, etc.). Teams will submit their solutions by November 3 and reconvene at the semifinals on November 17 to find out which will move on to the finals on December 3. At the finals, one member of each team will present their solutions to the judges and a winner will be announced. Registration opens October 20 following the first event; the first 100 teams to sign up will be selected to participate.
Not ready to compete but want to be part of the action? Register for the event and join us to see how Architectural Katas work, cast your vote for the winning team, and learn how to successfully present architecture plans to stakeholders.