Как уже упоминалось, то на часть вопросов есть ответы в статье Володи Бородина про миграцию Яндекс Почты с Oracle. Плюс в статье про шардирование в Яндекс Диске.
Но в целом основные моменты следующие:
Для реализации значительной части функционала нужна реляционная БД. Исходный функционал был написан с использованием Oracle. Соответственно перейти с Oracle на Postgresql было значительно проще.
Во время первичной разработки был меньше выбор чем есть сейчас. Из того что было протестировано Postgresql показался самым подходящим вариантом. А сейчас полностью переписывать и переходить на что-то новое будет слишком дорого и пока нету такого, что текущая система не справляется, то тратить человеко-годы на это не хочется.
Что касается использования дополнительных БД, типа REDIS, Mongo и прочего - то тут у нас часто такой подход, что если на PosgresSql мы можем написать и реализовать нужный функционал, без сильных побочных эффектов, то обычно мы предпочитаем не использовать другие БД, фреймворки или сервисы, пусть и чуть лучше для этого заточенные(но без того что бы они прям на порядки были лучше или вообще на PostgresSql нужный функционал не реализуем с нужной производительностью). Так как для этого нужна дополнительная экспертиза, дополнительные усилия в поддержке и появляются дополнительные точки отказа.
Как уже упоминалось, то на часть вопросов есть ответы в статье Володи Бородина про миграцию Яндекс Почты с Oracle. Плюс в статье про шардирование в Яндекс Диске.
Но в целом основные моменты следующие:
Для реализации значительной части функционала нужна реляционная БД. Исходный функционал был написан с использованием Oracle. Соответственно перейти с Oracle на Postgresql было значительно проще.
Во время первичной разработки был меньше выбор чем есть сейчас. Из того что было протестировано Postgresql показался самым подходящим вариантом. А сейчас полностью переписывать и переходить на что-то новое будет слишком дорого и пока нету такого, что текущая система не справляется, то тратить человеко-годы на это не хочется.
Что касается использования дополнительных БД, типа REDIS, Mongo и прочего - то тут у нас часто такой подход, что если на PosgresSql мы можем написать и реализовать нужный функционал, без сильных побочных эффектов, то обычно мы предпочитаем не использовать другие БД, фреймворки или сервисы, пусть и чуть лучше для этого заточенные(но без того что бы они прям на порядки были лучше или вообще на PostgresSql нужный функционал не реализуем с нужной производительностью). Так как для этого нужна дополнительная экспертиза, дополнительные усилия в поддержке и появляются дополнительные точки отказа.
про человеко-годы боюсь не смогу ответить,
а про YDB — то, на момент первичного переезда, особенно начала проработки и разработки его, YDB еще не было