Данная статья является переводом другой, в целом, лично я согласен с автором и некоторые советы были бы полезны для меня в своё время. Стоит заметить, что под базами данных тут имеются ввиду реляционные базы данных, если не оговорено другое. Ссылка на оригинал в конце.
Как я уже говорил на некоторых выступлениях, лучший путь улучшить вашу систему — это, в первую очередь, не делать глупых вещей. Я не имею ввиду что вы или ваши разработчики глупые, достаточно легко проглядеть последствия подобных решений и не осознать насколько они плохи для поддержки, не говоря уже о масштабировании. Работая в качестве консультанта, я постоянно встречаю подобные вещи и ещё ни разу не встречал чтобы они работали хорошо хотя бы для кого-нибудь.
Изображения, файлы и бинарные данные
Ваша база данных поддерживает BLOB’ы (Binary Large OBjects — большие двоичные объекты) и это может показаться хорошей идеей хранить файлы в ней, не так ли? Нет, не так! Это не так даже если это достаточно удобно использовать во многих библиотеках для работы с БД.
При хранении таких объектов в базе данных возникает несколько проблем:
- Чтение и запись в БД всегда медленней чем при взаимодействии с файловой системой (прим. переводчика: с кешированием данных в памяти это может быть не так, но это достаточно расточительный способ использовать всю память).
- Ваши бекапы базы данных станут огромными, более трудозатратными.
- Для получения доступа к файлам теперь требуется прохождение через ваше приложение и слой взаимодействия с БД (DB layer).
Последние два пункта действительно весьма серъёзны. Хотите хранить превьюшки изображений в базе данных? Отлично, теперь вы не можете переложить их обработку полностью на nginx’у или другой легковесный web-сервер.
Сделайте себе одолжение, просто храните в БД относительный путь до ваших файлов на диске или используйте что-то вроде S3 или любую другую CDN-сеть (Прим. переводчика: Content Delivery Network — сеть доставки контента, обычно распределённое хранилище для статики, S3 — CDN от Amazon).
Эфемерные данные
Статистика использования, метрики, GPS-локации, данные сессии и всё что угодно, что представляет ценность для вас только короткий период времени или часто меняется. Если вы заметите что постоянно удаляете устаревшие данные часовой, дневной или недельной давности из вашей БД, значит, вы выбрали неправильный инструмент для таких данных.
Используйте redis, statsd/graphite, Riak — что угодно, что лучше приспособлено для подобных задач. Точно такой же совет относится и для агрегации эфемерных данных которые не живут достаточно долго.
Конечно, можно использовать экскаватор для того чтобы вырастить помидоры у себя в саду, но гораздо скорее будет найти в гараже лопату в гараже, чем заказать экскаватор, дождаться пока он будет доставлен и начать вскапывать огород. Используйте правильные инструменты для текущих задач.
Логи
При поверхностном взгляде это выглядит нормально и аргумент «мне, возможно, надо будет выполнять сложные запросы по этим данным когда-нибудь в будущем» является решающим для некоторых людей. Хранение ваших логов в БД — это не самая ужасная идея, но хранение их в той же самой БД, что и ваши остальные данные — неудачное решение.
Возможно, вы достаточно умерены в плане логирования и обычно записываете только одну строку строку на каждый web-запрос. Но даже такой подход генерирует как минимум по одной вставке для каждого действия на вашем сайте, которая будет претендовать на ресурсы которые могли бы использовать ваши пользователи. Настройте вашу систему логирования на уровень большего вывода или логов debug-уровня и посмотрите как ваша боевая БД просто загорится от перегрузки.
Используйте вместо БД что-то вроде Splunk, Loggly или старые добрые файлы с ротацией логов. Пару раз вам придётся разобраться в них нестандартным способом, но даже если вам придётся написать небольшую программку для их анализа и выдёргивания нужных данных, аргумент постоянной экономии ресурсов системы перевешивает.
Подождите, вы думаете, что вы уникальны и неповторимы, и ваша задача настолько отличается от стандартных, что для вас будет вполне нормально использовать что-то из этих трёх пунктов? Нет, в действительности это не так. Поверьте мне.
