Комментарии 14
Уже даже фотку собаки настоящую в статью не ставят. Оно же даже не походе на шарпея...
господи, куда мы катимся?!
Это лучше, чем потом сопли по интернету "яндекс спер мою фотку/логотип/другая атрибутика, ай ай ай, какой нехороший, засудим его". Они не хотят так https://habr.com/ru/articles/838754/
Виноват не он.
Спасибо за информацию. Хотя мне идея фотки понравилась - думаю ИИ не сам придумал фото шарпея на фоне цвета шарпея.
Да. А ещё хуже вездуссущая реклама Яндекса с ещё более омерзительными (ибо анимированными) картинками, от которых в голове что-то замыкает. Нейрослоп повсюду, и никто ни на секунду не задумывается какое это неуважение к потребителю и отвратительная в принципе практика. 5 рублей на сток-фото пожалели, б***
Очень интресная статья, спасибо.
Ну вот не могу отделаться от мысли, что под такие задачи, как диск и почта, не лучше ли было выбрять более подходящую БД ?
С шардингом, репликами, авто балансировкой нагрузки, автофайловером, все из коробки - ну ту же монгу(не к ночи будет помянута).
К ShardDB прикрутить redis раз там на чтение в основном, который тоже хорошо масштабируется на чтение репликами.
И получается уже стандарная инфра для проектов такого типа.
Ну зачем идти в строгую реляционку ? Как-то много напильником допиливать, не финансы же все таки.
Звучит как "переписать весь почтовый сервис чтоб можно было на хабре пожаловаться как монга тормозит и/или теряет почту юзеров" :-)
Или "как мы учили монгу переживать ученьки"... хотя такое по-любому уже было, возможно только опубликовано где-то внутри Яндекса, такие страшилки не для публики...
Там с изолированными по своим партишенам юзерами любая база сойдёт. Проблемы начинаются там, где надо ещё между нодами в кластере что-то делать.
Меня тоже такая мысль посещала при прочтении, но история с переездом с Оракла куда-то вполне закрывает этот вопрос. ПОдходит только то, что потребует меньше изменений и есть нормальные компетенции в команде. Ну и вариантов кроме OLTP to OLTP без серьёзных переработок не остаётся.
Ответы на многие вопросы можно найти тут https://habr.com/ru/companies/oleg-bunin/articles/791018/
не финансы же все таки.
Порой, потеря ценной переписки или важных документов может быть пострашнее финансовых потерь.
Как уже упоминалось, то на часть вопросов есть ответы в статье Володи Бородина про миграцию Яндекс Почты с Oracle. Плюс в статье про шардирование в Яндекс Диске.
Но в целом основные моменты следующие:
Для реализации значительной части функционала нужна реляционная БД. Исходный функционал был написан с использованием Oracle. Соответственно перейти с Oracle на Postgresql было значительно проще.
Во время первичной разработки был меньше выбор чем есть сейчас. Из того что было протестировано Postgresql показался самым подходящим вариантом. А сейчас полностью переписывать и переходить на что-то новое будет слишком дорого и пока нету такого, что текущая система не справляется, то тратить человеко-годы на это не хочется.
Что касается использования дополнительных БД, типа REDIS, Mongo и прочего - то тут у нас часто такой подход, что если на PosgresSql мы можем написать и реализовать нужный функционал, без сильных побочных эффектов, то обычно мы предпочитаем не использовать другие БД, фреймворки или сервисы, пусть и чуть лучше для этого заточенные(но без того что бы они прям на порядки были лучше или вообще на PostgresSql нужный функционал не реализуем с нужной производительностью). Так как для этого нужна дополнительная экспертиза, дополнительные усилия в поддержке и появляются дополнительные точки отказа.
Спасибо за статью! Если не секрет, поделитесь пожалуйста информацией:
1) какова была трудоемкость вашего решения в человеко-годах (от проектирования до развертывания)
2) почему не ydb?
специальная handler
как ручка превратилась в handler? редактор с AI-автозаменой?
Интересная статья. Как я понял, вы отдаете строки подключения для клиентов, а они сами ходят на шарды, но как вы боретесь с ограничением в 100 подключений в постгре? Предположу, что у вас явно больше чем 100 клиентов в моменте
Почтовый Шарпей: как мы приручили 700+ шардов PostgreSQL