MongoDB против MySQL

Недавно я сильно впечатлился возможностями MongoDB. Под Монгу очень приятно программировать, но эта СУБД не подходит для небольших (и даже средних) web-проектов. Я задумался: а что тогда подходит?

Как я уже говорил, основная претензия к MongoDB — прожорливость. Монга скушала все процессорное время, а web-приложение выдавало всего 140 страниц в секунду. Тогда я решил переписать свое приложение, заменив Mongo на MySQL.

Я уже привык к удобствам и переходить обратно на голый SQL не хотелось. Не говорю уже о таких «радостях», как схемы, миграции, нормализация и т.п. Поэтому я принял решение попробовать использовать ORM. Для Ruby это ActiveRecord (используется в Ruby on Rails) и Data Mapper. Первое решение более продвинутое, но сильно тормозит. Отчасти из-за убийственной медлительности ActiveRecord разные пейсатели часто творят на тему «Почему Web-разработчики отказываются от Ruby on Rails?» А рельсы действительно тормозят, поэтому вместо Рельсов я предпочитаю шустрый и неуловимый микрофреймворк Sinatra. Чтобы его не замедлять, оставалось выбрать Data Mapper.

Этот замечательный Data Mapper

Data Mapper мне очень понравился. Да, описывать схему всё равно приходится, но все остальные рутинные задачи с программиста снимаются. Вот как, например, выглядит модель Feed (лента новостей):

class Feed
  include DataMapper::Resource
 
  property :fid, Serial
  property :name, String, :required => true, :length => 64
  property :url, String, :required => true, :length => 256
  property :group, String, :default => 'General', :length => 64
  property :ts, DateTime
 
  has n, :NewsItem
end
 
DataMapper.finalize
DataMapper.auto_upgrade!

Волшебство происходит при вызове метода auto_upgrade!. (Это не я восклицаю, а это в Руби method и method! — два разных метода). DataMapper создаст за юзера таблицы, установит связи и будет отслеживать изменение схемы.

Вторая причина выбора ORM — независимость от конкретной СУБД. В последующих статьях я сравню производительность MySQL с PostgreSQL, SQLite3 и так далее. Заменить СУБД можно в одну строчку в конфигурации:

DataMapper.setup(:default, 'mysql://user:password@localhost/database")

Это для MySQL. Чтобы перевести приложение на работу, например, с PostgreSQL требуется только установить адаптер для DM и заменить строку подключения:

DataMapper.setup(:default, 'postgres://user:password@localhost/database')

А теперь представьте, сколько бы потребовалось переписать, если бы приложение общалось с СУБД на голом SQL! Высокий уровень абстракции — это прекрасно!

Ну так вот, было у меня приложение — RSS-читалка. Фиды и новости хранились в Монго. Это приложение я оставил, но переписал ту часть, которая отвечает за сохранение и загрузку данных в СУБД. Итак, чего удалось мне достигнуть заменой Монго на MySQL? Настает момент истины...

Момент истины

RSS-читалка на Монго выдавала 140 страниц в секунду. MySQL через ORM стал давать 48 страниц в секунду. Трехкратное падение производительности.

Причины трехкратного падения производительности

Признаться, я ожидал роста на порядок, а тут падение. Пришлось искать причины и они были найдены: если в случае с Монго тормозила сама СУБД, то в случае с MySQL СУБД на пике потребляла всего 1,5% времени процессора. Что же тогда тормозит? Тормозит сам Ruby и особенно ORM.

Что делать?

Мне надоело, что как только какая-то технология начинает мне нравится, так сразу же выясняется, что она тормозит. Что же, писать web-приложения по старинке, на голом PHP + SQL? Неужели мы никогда не избавимся от этого обрыдшего LAMP?

Я стал выяснять, почему Ruby + Sinatra + Data Mapper = паралич. Как оказалось, Ruby сам по себе — очень медленный. Невероятно медленный. По двум причинам:

  • гнилой сборщик мусора;
  • высокие расходы на вызов функций.

Что же посоветуют Ruby-гуру? Совета тоже два:

  • не использовать Ruby;
  • не использовать ORM.

Первый совет насмешил, но на самом деле речь не идет об отказе от самого языка. Спецы советуют использовать вместо классического интерпретатора Ruby его Java-клон JRuby, который компилирует программу на Ruby в байткод Джавы. Совет дельный, надо попробовать.

А вот второй совет не очень понравился. Если не использовать ORM, то зачем тогда вообще использовать объектно-ориентированный по самые помидоры Ruby? Логичнее писать тогда уж в процедурном стиле на PHP и использовать голый SQL для доступа к данным.

А что дальше?

Я еще протестирую Data Mapper с другими СУБД, но уже понятно, что узким местом так и будет оставаться сам Ruby. И от него придется отказываться. Просто потому, что поисковики учитывают время генерации страницы и никогда не дадут на медленный сайт много посетителей. Правильно ли использовать инструменты, которые позволяют программисту наслаждаться своей работой, но в результате получается дерьмовый продукт, который никогда не станет популярным?

Вывод

MySQL уделывает всех на небольших наборах данных (до 10 тыс. записей в таблице). Потом на сцену выходит Postgres. Ну а для гигантских объемов слабоструктурированных данных лучше подходит MongoDB. Только у вас должно быть 2+ выделенных под одну Монгу сервера, иначе профит будет незаметен.

Ваша оценка: Нет Средняя оценка: 5 (2 votes)
9

Правильно ли использовать инструменты, которые позволяют программисту наслаждаться своей работой, но в результате получается дерьмовый продукт, который никогда не станет популярным?

Может быть правильнее пересмотреть свое отношение к программированию и поменять мнение о том, что «удобно», а что нет?

Ваша оценка: Нет
11
pomodor

По ссылке какая-то демагогия от старого пердуна, который советует учить Яву 10 лет. А чего тогда уж сразу не 100? Родился, учился, учился, помер — просто идеальный программист. ;)

и поменять мнение о том, что «удобно»

Удобно — это когда средства разработки позволяют управлять сложностью проекта. За счет использования уровней абстракции. ORM — один из таких уровней. И проблема тут не в том, что я все никак не могу "поменять мнение о том, что «удобно»", а в том, что существующие ORM на Ruby дико тормозят.

ЗЫ Почитайте лучше «Совершенный код».

Ваша оценка: Нет
8
DJ_Baldey

ЗЫ Почитайте лучше «Совершенный код».

Спасибо за хорошую литературу! Начал читать, осознаю, что я с автором одного мнения. Но я то на своих шишках набитых, э-э-эхх... мне бы её пораньше...

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.
Linux I класса
Linux II класса
Linux III класса
Счетчики
  • Самый популярный сайт о Linux и Windows 10
О Либератуме

Liberatum — это новости мира дистрибутивов Linux, обзоры, сборки, блоги, а также лучший сайт об Ubuntu*.