Философия SQL или причина популярности NoSQL.

zabivator — 08.06.2010 Феномен NoSQL уникален. Люди отказываются от ACID, люди отказываются от высокоуровневого языка для описания своих действий, от отсутствия избытычности (третья нормальная форма) в пользу чего?

NOSQL выходит на сцену
В пользу крайне примитивного хранилища данных, в котором ничего вышеперечисленного нет, и при работе с которым приходиться вникать в низкоуровневые детали реализации, а также проектировать с учётом ограничений хранилища.
На первый взгляд, сплошные неудобства.
На второй взгляд - адепты NoSQL скажут, что на не нужны третья нормальная форма и ACID, зато нужна производительность.

В ответ на предложение заняться оптимизацией запросов, настройкой кешей либо (увы) денормализацией данных адепты NoSQL обычно:
1) не знают или знают поверхностно SQL хранилища
2) отмахиваются "Зачем? Я просто возьму классную NoSQL xxx, и в ней этого не будет".

Те, кто смогли в разговоре внятно обосновать причину выбора NoSQL::
1) Знают SQL и крутили его для решения задачи
2) Указывают на конкретные недостатки решения в SQL решении, способы решения этих недостатков в NoSQL хранилище, а также регрессии и издержки такого решения в NoSQL.

Но активней всего агитируют за NoSQL как раз люди не понимающих этих вопросов!
Данный феномен казался мне:
1) вопиющим дилетантством (люди не владеют предметом == SQL, чтобы делать такой выбор)
2) саботажом производственных норм и целей разработки (вместо решения задачи люди играют в NoSQL).

Кажется, теперь я понял причину данного феномена.

Структуры команды при реализации проекта с использованием SQL
Я не рискну проводить таксономию SQL и NoSQL.
Это обширная и сложная тема, достаточно сослаться на статью Майка Стоунбрейкера.

Давайте зайдём со стороны... менеджмента.

Каким образом выглядит разработка прикладных программ c использованием SQL баз?

Язык SQL позволяет развязать собственно приложение (отражение предметной области) от способа хранения данных.
При таком раскладе у нас есть три обязанности:
1) Анализ предметной области и реализация её в коде приложения
2) Анализ структур данных приложения и реализация их в виде схемы базы.
3) Запросы к базе со стороны приложения.
4) Настройка базы под нужды приложения, оптимизация её (индексы, партицирование, кластеризация), денормализация базы как крайная мера.

При таком подходе обычно нужны:
1) Аналитик
2) Разработчик
3) DB-developer

Компании чётко разделяют эти позиции, поскольку отдельные специалисты более дешёвы заменимы, чем универсалы совмещающие две или три позиции.
Над проектом ставят архитектора, что обязан владеть всеми тремя категориями, но не занимается реализацией. Естественно, есть менеджер что управляет процессом.

SQL является таким универсальным посредником между DB и разработчиком с аналитиками. В этом смысле предметная область на хранилище не влияет - предметная область фиксируется в виде схемы базы, а уж от неё и запросов начинает свою работу DBA.

Структуры команды при реализации проекта с использованием NoSQL
Каким же образом выглядит разработка с использованием NoSQL?

NoSQL хранилище требует отражения предметной области и структуры приложения в терминах хранилища.
Роли смываются!

Нету универсального посредника - SQL, который являлся lingua franca для различных частей команды!

В отдельных случаях такое смешение оправданно - в противном случае не получится уложится в требование производительности, сроки и бюджет.

Альтернатива смешению - масштабирование команды. Но при росте команды мы получаем рост сроков, возврастающее число коммуникаций, а как следствие - формализма, и более дорогое внесение изменений.

Взрыв различных ORM - не случайность, а закономерное следствие отказов от DBA.
Первое, что сделали разработчики приложений - сделали ORM.
Второе, что они сделали - придумали NoSQL.

При выборе решения нужно чётко осознавать, какие входные требования вам спущены.

Анализ популярности NoSQL
Плох тот солдат, что не мечтает стань генералом. Разработчики приложений сталкиваются с проблемами производительности баз, и ищут альтернативы. Их уровень компетенции РЕДКО включает в себя знания узкоспециализированных DB-разработчиков, и как следствие они в большинстве случаев не могут решить проблемы производительности приложений, выходящие за рамки "банальных" (индексы по Primary Key).

Таким образом, решая проблему "на своём" уровне, разработчики хотят видеть структуру хранилища отражающую их предметную область, и имеющую минимальный overhead.
Теперь вы понимаете?

Вопросы резервного копирования данных, их целостности, работа хранилища в условиях нехватки памяти, параллельные запросы - эти вопросы разработчики НЕ ПОНИМАЮТ ДО КОНЦА, и не в состоянии их эффективно решить.

Будем реалистами - специлисты широкого профиля редко хорошо знают НЕСКОЛЬКО областей одновременно.
Те, что владеют DB-разработкой обычно РУГАЮТ NoSQL.
Те, что НЕ владеют DB-разработкой НАДЕЯТСЯ на NoSQL.
Я могу пересчитать по пальцам одной руки своих знакомых, которые ИСПОЛЬЗУЮТ NoSQL, и ПОНИМАЮТ почему они это делают.

Кто виноват?
В управлении IT-проектами есть совершенно печальная черта - во всяком случае, я её наблюдал на работе, у знакомых в проектах, книгах и статьях - разработчики не понимают целей разработки и роли в команде.
Со свойственным им максимализмом они пытаются охватить ВСЁ.

Корень проблемы лежит в смешении ролей в команде и отсутствия DB-разработчика. Незначительное число программистов имеют самодисциплину при выборе инструментов и использования.
Люди, понимающие плюсы-минусы обоих решений и способных проект реализовать стоят очень дорого.

Вместо использовании молодых энтузиастов (как правило специалистов в одной области) в мирных целях, менеджмент зачастую спускает на тормозах вопросы выбора архитектуры без проведения нормального анализа.
Куда соблазнительней поверить в модные тренды, чем забивать голову сложными вопросами, не так ли?

Применимость инструментов
Все мы мечтаем сделать супер-стартап и продать его за мультимиллионы гуглю.
Но пока мы занимается коммерческой разработкой оперденей на заказчика - и должны решать ЕГО проблемы, а не собственные амбиции.

Проекты можно условно классицировать так:

1) Малобюджетные сайты - бюджет пара тысяч долларов
2) Средние программы автоматизации бизнес-процессов - "опердени" - бюджет обычно до десяти тысяч долларов
3) Биллинг, телеком - бюджет сильно больше 10000 долларов
4) Высоконагруженные сайты вырастают из стартапов, бюджет не определён.

Для каждой группы - свои инструменты.
Для (1) и (2) и (3) важным критерием является предсказуемость, а как следствие разумным выбором являются "классические" инструменты, разделяющие задачу на части и снижающие риски vendor-lock'а на разработчике - т.е. SQL.

Для (4) никакие рецепты не работают - зависит от проекта и его требований.

Ниша NoSQL - высоконагруженные сайты, вырастающие из стартапов.

Выводы
SQL изначально создавался как язык, разделяющий вопросы хранения данных и запросы по манипуляции ими.
Разработка с использованием SQL подразумевает как минимум четырёх людей:
1) Менеджер
2) Архитектор
3) Разработчик приложения (совмещающий функции аналитика или делящий их с архитектором)
4) DB-разработчик

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

NoSQL данную проблему НЕ РЕШАЕТ. Компетенция специалиста в хранилищах данных от простого выбора NOSQL НЕ ПОЯВИТСЯ.

Если вы не согласны - значит, вы можете написать по памяти CAP-теорему, сформулировать третью нормальную форму, и слово vector-clock для вас далеко не пустой звук. В противном случае - вам просто нравится играть в NoSQL на деньги работодателя, а ваш менеджмент не понимает или не хочет решать проблему.

В конце-концев эффективность бизнеса - проблема владельца и управления, а не рядового специалиста, коим вы являетесь.

Оставить комментарий

Популярные посты:

• Ранее
• Архив