Регулярно вижу тезисы о том, что дескать только лузеры ограничивают себя ORM, а реальные пацаны лезут в БД напрямую SQL-запросами. Дескать, в highload-проектах ORM-щиков нафиг увольняют, а тех кто героически фигачит SQL – повышают, ибо быстродействие, оптимизация и бла-бла-бла.
В этом посте я расскажу, почему это всё херня и вообще You do it wrong. Парни, потому что вы используете базу данных не по назначению. РСУБД – это, как правило, долговременное хранилище данных, предназначенное для аналитических выборок не в режиме реального времени.
Это в вебе так принято, в силу его очевидного насыщения непрофессионалами и тотального снижения порога входа, – что многие привыкли и считают нормальным и писать в некую БД и читать из неё же, формируя страницы “на лету”. Ну, или отвечать на запросы к API, что отличается лишь другим методом рендеринга ответа. И конечно же, “быстродействие БД” закономерно выходит на первый план.
Но в кровавом энтерпрайзе так не делают, и не потому что дураки. Там, на самом деле, бывает всё даже “хуже”: между базой в которую пишут, и базой из которой читают – может находиться две и более промежуточные БД. Гуглите ETL и связанные с ним термины, если интересно.
Потому что существуют несколько принципиально разных типов хранения данных: предназначенный для быстрого чтения, или для быстрой записи, или для аналитических выборок. Если вы выбрасываете SQL ORM под предлогом “у нас хайлоад” – вы поступаете неправильно. Потому что если вам критично время чтения, вы должны читать из key-value storage типа Redis, или из самописного демона который держит всё в оперативке, или ещё из какого иного кэша – но не из SQL-базы!
Если вам критично время записи – аналогично, пишите в очередь, из которой напрямую раздавайте горячую информацию потребителям, а параллельно демоном перекладывайте в SQL на хранение.
Поэтому быстродействие ORM вообще не должно рассматриваться в контексте “быстродействия сервиса” в целом. И более того, функциональность ORM не должна напрямую влиять на функциональность сервиса в целом.
Если у вас ORM выглядит препятствием для сложных выборок – это не повод избавляться от ORM, это повод пересмотреть структуру ваших данных. Скорее всего это означает недостаток проектирования системы. И это сигнал к тому, что возможно данные стоит “переложить” – денормализовать или реструктурировать.
Можно сколько угодно посмеиваться над разработчиками всякого энтерпрайзного проприетарного говна, но понимание таких вещей приходит только с опытом. Прислушайтесь к тому чуваку, который в вашей команде агитирует за ORM. Возможно, он более чем прав.