Имеет ли смысл ORM для сайтов социальных сетей?

Question

Причина, по которой я спрашиваю об этом, заключается в том, что мне нужно знать, имеет ли смысл вообще использовать ORM для сайта социальной сети.

Мой аргумент, почему ORM не вписывается в сайты социальных сетей:

• Сайты социальных сетей не являются продуктом, поэтому вам не нужно поддерживать несколько баз данных. Вы знаете, какую базу данных использовать, и, скорее всего, не будете время от времени ее менять.
• Сайты социальных сетей требуют взаимоотношений «многие ко многим» между пользователями, и, в конце концов, иногда вам потребуется написать простой SQL, чтобы получить эти отношения. Таким образом, значение ORM снова уменьшается.
• В связи с предыдущим пунктом ORM иногда выполняет несколько запросов в бэкэнде для извлечения своей записи, что иногда может быть неэффективным и может стать причиной узкого места в базе данных. В конце вы должны записать простой SQL-запрос. Если мы знаем, что в любом случае будем писать простой SQL, какой смысл использовать ORM?

Это мое ограниченное понимание, основанное на моем ограниченном опыте. Какой у вас опыт создания сайтов социальных сетей? Мои баллы действительны? Хромо ли использовать голый SQL, не беспокоясь об использовании ORM? В каких точках ORM может помочь в создании сайтов социальных сетей?

Answer 1

Значение использования ORM состоит в том, чтобы помочь ускорить разработку , автоматизируя утомительную работу по присваиванию результатов запроса полям объекта и отслеживая изменения в полях объекта, чтобы вы могли сохранить их в базе данных. Отсюда и термин объектно-реляционное отображение .

ORM не имеет для вас большого значения в отношении переносимости базы данных, поскольку вы используете только одну базу данных, на которой вы развернули.

Аспект производительности ORM во время выполнения ничуть не лучше и, как правило, намного хуже, чем написание простого SQL самостоятельно. Как вы уже упоминали, универсальные методы генерации запросов часто допускают наивные ошибки и приводят к избыточным запросам. Опять же, преимущество заключается во времени разработки, а не в эффективности времени выполнения.

Использование ORM по сравнению с неиспользованием ORM, по-видимому, не имеет большого значения для масштабируемости. Другие методы с большей отдачей для масштабируемости включают в себя:

• Управление индексами в СУБД. Улучшите как можно больше алгоритмов от O (n) до O (log ₂ n).
• Интеллектуальная архитектура кэширования.
• Горизонтальное масштабирование с помощью разделения / разбиения базы данных.
• Балансировка нагрузки и репликация базы данных. Чтение из ведомых баз данных, где это возможно, и запись в одну главную базу данных. Индексируйте рабов и хозяев по-разному.
• Дополнение к СУБД дополнительными технологиями, такими как Sphinx Search.
• Вертикальное масштабирование с помощью аппаратного решения проблемы. Джефф Этвуд прокомментировал это в подкасте StackOverflow.

Некоторые люди выступают за перевод вашего управления данными в распределенную архитектуру с использованием облачных вычислений или распределенных нереляционных баз данных. Это, вероятно, не нужно, пока вы не получите очень большое количество пользователей. Как только вы достигнете определенного уровня, все правила изменятся, и вы, вероятно, все равно не сможете использовать СУБД. Но если вы не являетесь архитектором данных в Yahoo, Facebook или LinkedIn, не беспокойтесь об этом - облачные вычисления чрезмерно раскручены.

Существует распространенное мнение, что база данных всегда является узким местом в веб-приложениях, но есть также случай, когда повышение эффективности внешнего интерфейса является по меньшей мере столь же важным. Ср книги Стив Соудерс .

---

Джулия Лерман из Programming Entity Framework (2009), стр. 503 показывает, что затраты на выполнение запросов возрастают на 220% между использованием DataReader напрямую и использованием Microsoft LINQ to Entities.

Также см. Пост Джеффа Этвуда по Все абстракции являются ошибочными абстракциями , где он показывает, что использование LINQ по крайней мере вдвое дороже использования простого SQL даже наивным способом.

Answer 2

Вот мой ответ на ваши очки:

• ORM не требует нескольких баз данных, чтобы быть эффективными, фактически большинство случаев использования ORM не связано с возможностью адаптации к различным базам данных.
• Большинство современных сред ORM достаточно гибки, чтобы извлекать «облегченные» варианты отображаемых классов, это действительно зависит от того, как вы их реализуете.
• Если действительно необходимо, вы можете написать собственные SQL-запросы в рамках ORM. Обратите внимание, что алгоритмы кэширования и производительности часто являются частью этих структур.

Answer 3

ИМО, ORM помогает вам писать чище, яснее код. Если вы используете его небрежно, вы можете вызвать чрезмерные запросы, но это не правило ни в коем случае. Будь я на вашем месте, я бы начал использовать ORM и лучшие практики фреймворка и переходил на SQL, только если вам нужна функциональность, которую ORM не предоставляет.

Answer 4

Вероятность того, что ваш сайт будет достаточно большим, чтобы масштабирование стало проблемой, довольно мала, так почему бы преждевременно оптимизировать, выполняя все в необработанном SQL вместо ORM? Вы можете получить довольно далеко, выбрасывая лучшее оборудование в базу данных, предполагая, что база данных и дизайн приложения приличный. В то время как вам может потребоваться написать сырой SQL для таких вещей, как создание графов друзей, как насчет таких мелочей, как обновление базы данных, когда кто-то меняет там электронную почту, отправляет личное сообщение, загружает фотографию и т. Д.? Использование ORM может упростить все простые задачи с базой данных, которые вам придется выполнять, и в то же время позволяет передавать код там, где это абсолютно необходимо.

Answer 5

ИМХО. ОРМ нужен.

1. Это позволяет вам обращаться к базе данных ООП способом, независимо от того, является ли она множественной или нет.

   2. Более чистый код, вы можете определить все методы, относящиеся к конкретной таблице, в файле класса таблиц, если вам нужен необработанный запрос sql join, нет проблем, определите там это следует за СУХОЙ и ПОЦЕЛУЙ. Это намного лучше, чем вы снова и снова пишете подобный необработанный SQL-запрос.

Answer 6

Также обратите внимание, что в веб-приложениях многие люди уходят от баз данных SQL. ORM может помочь вам перейти на нереляционную базу данных (именно потому, что в вашем коде приложения нет SQL). Посмотрите на использование JDO и JPA в Google App Engine.