14. Контакты
В группе компаний Rambler&Co всегда есть
открытые вакансии для тех, кто хочет
профессионально расти и развиваться,
занимаясь тем, что по-настоящему нравится
hr@rambler-co.ru
www.rambler-co.ru/jobs
Hinweis der Redaktion
Всем привет. Меня зовут Станислав Герман и я ведущий разработчик в Рамблер
Наверное когда вы слышите Рамблер на ум приходит поисковик из 90х, но на данный момент Рамблер это группа компания с ежемесячной аулдиторией 40 млн пользовтелей и более 50 проектами различной сложности. Я думаю многим из вас знакомы такие новостные и медиа проекты как Lenta Gazeta Afisha и Большинства из этих контентных площадок в компании построенны на Ruby on Rails.
В Ruby on Rails проектах мы используем паттерн CQRS Command Query Responsabilty Segregation В основе паттерна лежит принцип «вопрос не должен изменить ответ». Вы можете разделить модели на предназначенные для чтения (commands) и записи (query). Давайте я попробую объяснить на небольшом примере, как такой подход ложится на реалии Ruby on Rails приложения.
Command это модель ActiveRecord, в общем случае.
Каждый раз когда данные изменились в реляционной DB, происход вызов записи в базу для чтения в данном случае это mongoDB коллекция posts.
Теперь дынные разделены на две базы данных. Одна для для изменений вторая предназначена для для чтения.
На уровне модели для чтения реализация достаточно простая это Plain Old Ruby Object.
Враппер вокруг mongo_ruby_driver реализующий репозиторий. Так как не надо писать в базу нам не нужен тяжелий mongoid. PostRepository метод all возвращает экземпляры класса PostView представленный правее.
Дынные сериализуются в noSQL уже в подготовленном виде, удобном для чтения и денормализованном и они отвязаны от ActiveRecord.
Разделив код на уровне данных и моделей мы получили ряд преимуществ на уровне дизайна кода и его поддержки.
А что если посмотреть на данный пример чуть шире, то очевидно что дальнейшее раздение может принести дополнительные выгоды.
Монолитная архитектура на начальных этапах - когда кодовая база не большая, удобна.
При увеличении сложности системы её становится сложнее поддерживать, большая связность, сложность тестирования, проблемы с масштабируемостью.
Один из способов избежать этого Command Query Responsabilty Segregation.
В реализации CQRS мы разделяем приложение на два. Можно их назвать CMS и Site.
Два приложения одно только для записи второе только для чтения. CMS и Site.
У нас есть Postgress который перегоняет подготовленные и денормализованные данные в noSQL.
MongoDB master реплицируется с отдельными БД для каждого инстанса приложения.
При увеличении нагрузки на сайт мы можем практически до бесконечности горизонтально масштабировать приложение.
Так же плюсом является безопасность решения CMS закрыта от опасного внешнего интернета и не site не CMS не влияют на работоспособность друг друга.
Состоит в том что данный подход требует осторожности в использовании Он отлично подходит для контентных сайтов но не подойдет например для социальной сети.
В первую очередь необходима большая нагрузка на чтение по сравнению с записью.