– Это ж надо, — ни к кому не обращаясь, громко сказала она. – Это ж надо! Так прямо и написано – главной задачей общества является извлечение прибыли в интересах акционеров. Ну вы подумайте! Ничего не боятся!
Юлий Дубов, «Меньшее зло»
Увидев такой заголовок, вы наверняка уже решили, что статья – или глупость, или провокация. Но не спешите с выводами: сотрудникам крупных корпораций, в особенности корпораций с государственным участием, довольно-таки часто приходится сравнивать разные платформы, в том числе и совершенно разные – например как те, что вынесены в заголовок.
Конечно, СУБД так никто не сравнивает, ибо их сильные и слабые стороны хорошо известны. Как правило, сравнению подлежат платформы, решающие какую-либо прикладную задачу. В статье я покажу методику, которая при этом используется, на примере баз данных как предмета, не понаслышке знакомого читателям Хабра. Итак,
Мотивация
Когда вы начинаете учебный проект или проект-хобби, мотивация для выбора платформы может быть самой разнообразной: «эту платформу я лучше всего знаю», «с этой мне интересно разобраться», «здесь лучшая документация»… В случае коммерческой компании критерий выбора один: сколько придётся заплатить и что я за эти деньги получу.
Естественно, хочется заплатить поменьше, а получить побольше. Однако необходимо решить, что важнее – меньше заплатить или больше получить, и приписать каждому узлу вес. Допустим, что нам важнее качественное решение, чем дешёвое, и припишем узлу «Стоимость» вес 40%, а узлу «Возможности» – 60%.
В крупных корпорациях обычно всё наоборот – вес стоимости не опускается ниже 50%, а может быть и больше 60%. В модельном примере важно лишь то, что суммарный вес дочерних узлов любого родительского узла должен быть 100%.
Отсекающие условия
Сайту известно около 500 систем управления базами данных. Естественно, если выбирать целевую платформу из такого количества вариантов, то может получиться обзорная статья, но не коммерческий проект. Для того, чтобы сократить пространство выбора, формулируются отсекающие критерии, и если платформа этим критериям не удовлетворяет, то она не рассматривается.
Отсекающие критерии могут относиться к технологическим особенностям, например:
- ACID-гарантии;
- реляционная модель данных;
- поддержка языка SQL (обратите внимание, это не то же самое, что «реляционная модель»);
- возможность горизонтального масштабирования.
Могут быть критерии общего характера:
- наличие коммерческой поддержки в России;
- открытый исходный код;
- наличие платформы в Реестре Минкомсвязи;
- наличие платформы в каком-нибудь рейтинге (например, в первой сотне рейтинга db-engines.com);
- наличие экспертов на рынке (например, по результатам поиска названия платформы в резюме на сайте hh.ru).
В конце концов, могут быть критерии, специфичные для предприятия:
- наличие специалистов в штате;
- совместимость с системой мониторинга X или с системой резервного копирования Y, на которую завязано всё сопровождение…
Самое главное, чтобы список отсекающих критериев был. В противном случае обязательно найдётся какой-нибудь эксперт (или «эксперт»), пользующийся особым доверием руководства, который скажет «да что ж вы не выбрали платформу Z, я знаю, она лучшая».
Оценка стоимости
Стоимость решения складывается очевидно из стоимости лицензий, стоимости сопровождения и стоимости оборудования.
Если системы примерно одного класса (например, Microsoft SQL Server и PostgreSQL), то для простоты можно считать, что количество оборудования для того и другого решения будет примерно одинаковым. Это позволит не оценивать оборудование, сэкономив тем самым массу времени и сил. Если же приходится сравнивать совершенно разные системы (скажем, Oracle vs. Redis), то очевидно, что для корректной оценки необходимо сделать сайзинг (расчёт количества оборудования). Сайзинг несуществующей системы – занятие весьма неблагодарное, поэтому такого сравнения всё же стараются не допускать. Сделать это просто: в отсекающих условиях пишутся нулевая потеря данных и реляционная модель или же наоборот – нагрузка от 50 тысяч транзакций в секунду.
Для оценки лицензий достаточно запросить у вендора или его партнёров стоимость лицензии на фиксированное количество ядер и поддержки на фиксированный срок. Как правило, у компаний уже выстроены прочные отношения с вендорами программного обеспечения, и если отдел эксплуатации БД не может ответить на вопрос о стоимости самостоятельно, то для получения этой информации достаточно одного письма.
У разных вендоров могут быть разные метрики лицензирования: по количеству ядер, объёму данных или количеству узлов. Standby-база может быть бесплатной, а может лицензироваться так же, как и основная. Если только обнаружились какие-то различия в метриках, придётся детально описывать модельный стенд и считать стоимость лицензий для стенда.
Важный момент для корректного сравнения – одинаковые условия поддержки. Скажем, поддержка Oracle стоит 22% от стоимости лицензии в год, а за поддержку PostgreSQL можно не платить. Корректно ли так сравнивать? Нет, потому что у ошибки, которая не может быть устранена собственными силами, совершенно разные последствия: в первом случае специалисты поддержки быстро помогут её устранить, а во втором случае есть риск задержки проекта или простоя готовой системы в течение неопределённого срока.
Уравнять условия расчёта можно тремя способами:
- Использовать Oracle без поддержки (в реальности такого не бывает).
- Купить поддержку на PostgreSQL – например, у компании Postgres Professional.
- Заложить в расчёт риски, связанные с отсутствием поддержки.
Например, расчёт рисков может выглядеть так: в случае неустранимого сбоя базы данных простой системы составит 1 рабочий день. Планируемая прибыль от использования системы – 40 млрд монгольских тугриков в год, частота аварий оценивается как 1/400, таким образом, риск отсутствия сопровождения оценивается примерно в 100 млн монгольских тугриков в год. Очевидно, что «планируемая прибыль» и «оценочная частота аварий» – величины виртуальные, но гораздо лучше иметь такую модель, чем не иметь никакой.
В действительности система может быть слишком важна, и репутационные потери от длительного простоя окажутся недопустимыми, поэтому поддержка потребуется. Если же простой допускается, то отказ от поддержки иногда может быть неплохим способом сэкономить.
Допустим, что после всех расчётов стоимость эксплуатации платформы A в течение 5 лет оказалась 800 млн монгольских тугриков, стоимость эксплуатации платформы B – 650 млн тугриков, а стоимость эксплуатации платформы C – 600 млн тугриков. Платформа C как победитель получает за стоимость полновесный балл, а платформы A и B – чуть меньше, пропорционально тому, во сколько раз они дороже. В данном случае – 0.75 и 0.92 баллов соответственно.
Оценка возможностей
Оценка возможностей делится на множество групп, количество которых ограничено лишь фантазией того, кто делает оценку. Оптимальным вариантом кажется деление возможностей по командам, которые этими возможностями будут пользоваться; в нашем примере это разработчики, администраторы и офицеры информационной безопасности. Допустим, что веса этих функций распределяются как 40:40:20.
К функциям разработки можно отнести:
- удобство манипуляции данными;
- масштабирование;
- наличие вторичных индексов.
Список критериев, как и их веса, очень субъективны. Даже при решении одной и той же задачи эти списки, веса пунктов и ответы будут существенно отличаться в зависимости от состава вашей команды. Так, например, Facebook для хранения данных использует MySQL, а Instagram построен на базе Cassandra. Вряд ли разработчики этих приложений заполняли такие таблицы. Можно лишь догадываться, что Марк Цукерберг выбрал полноценную реляционную модель, заплатив за это необходимостью прикладного шардирования, в то время как Кевин Систром заложил масштабирование средствами платформы, пожертвовав удобством доступа к данным.
К функциям администрирования относятся:
- возможности системы резервного копирования;
- удобство мониторинга;
- удобство управления мощностями – дисками и узлами;
- возможности репликации данных.
Обратите внимание, что формулировки вопросов должны допускать количественную оценку. Можно даже договориться, как оценивать ту или иную функцию. Давайте, например, попробуем поставить оценки инструментам резервного копирования на примере инструментов, поставляемых с СУБД Oracle:
Инструмент
Комментарий
Оценка
imp/exp
Выгрузка и загрузка данных
0.1
begin/end backup
Копирование файлов
0.3
RMAN
Возможность инкрементального копирования
0.7
ZDLRA
Только инкрементальное копирование, быстрейшее восстановление на точку
1.0
Если чёткие критерии оценки отсутствуют, имеет смысл попросить нескольких экспертов выставить оценки, а затем их усреднить.
Наконец, просто перечислим функции информационной безопасности:
- наличие политик управления паролями;
- возможность подключения внешних средств аутентификации (LDAP, Kerberos);
- ролевая модель доступа;
- возможности аудита;
- шифрование данных на диске;
- шифрование при передаче по сети (TLS);
- защита данных от администратора.
Тестирование производительности
Отдельно хотелось бы предостеречь от использования в качестве аргументов результатов каких-либо нагрузочных тестов, сделанных не вами.
Во-первых, структура данных и профиль нагрузки тестируемых приложений могут существенно отличаться от той задачи, которую собираетесь решать вы. Лет 10-15 назад производители баз данных любили щеголять результатами, достигнутыми в тестах TPC, но сейчас уже, кажется, никто не воспринимает эти результаты всерьёз.
Во-вторых, производительность системы достаточно сильно зависит от того, под какую платформу изначально написан код и на каком оборудовании проводился тест. Мне приходилось видеть множество тестов, где Oracle сравнивали с PostgreSQL. Результаты – от безоговорочного превосходства одной системы до столь же безоговорочного превосходства другой.
И наконец, в-третьих, вы ничего не знаете о том, кто проводил тест. Важна как квалификация, влияющая на качество настройки ОС и платформы, так и мотивация, влияющая на результаты теста сильнее, чем все остальные факторы вместе взятые.
Если производительность является критически важным фактором, проведите тест самостоятельно, желательно с участием специалистов, которые будут настраивать и поддерживать промышленную систему.
Результат
Наконец, результатом всей проделанной работы должна стать электронная таблица, где все оценки сведены, перемножены и просуммированы:
Как вы понимаете, изменением весов и корректировкой оценок можно добиться любого требуемого результата, но это уже совсем другая история…
Источник: habr.com