SQL и NOSQL: Священная Война?

 У человеческой натуры есть любопытная особенность: если какое-либо явление существует в нескольких вариациях, люди обязательно поделятся на непримиримые сообщества и будут отстаивать свой выбор, пока звезды не посыпятся с небес. Хранение данных в реляционных и распределенных базах – один из примеров этому феномену.

В этой статье мы поговорим об особенностях SQL и NoSQL, которые сильнее всего влияют на работу веб-разработчика. Расскажем историю этих конкурирующих архитектур и разберемся, действительно ли они соперничают друг с другом. Тем, кто планирует учиться веб-разработке с нуля, эта статья обеспечит необходимый минимум в части хранилищ данных.

Рождение порядка

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

Результатом их трудов стал SQL (Structured Query Language, язык структурированных запросов), который позволял организовывать информацию в таблицы и быстро проводить с ними необходимые операции. Поскольку эти системы использовали отношения (relations) между отдельными структурами данных, такие базы называли реляционными. Работать с ними можно без математических формул, с помощью простых английских слов.

Все было прекрасно до появления Интернета. Погружение человечества в Сеть стало серьезным испытанием для SQL и использующих его реляционных баз данных – они перестали справляться с нагрузкой. Упорядочить записи в типовых журналах и управиться с постоянно растущим количеством разношерстных сайтов – это принципиально разные задачи. В профессиональном сообществе назрело недовольство.

Подчинить хаос

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

К тому же, чтобы увеличить мощность таких систем, достаточно было купить новый сервер – ускорить работу реляционной базы можно только наращиванием аппаратных ресурсов отдельного вычислительного узла. Программисты дали новой технологии прозрачное название NoSQL, и мир вступил в эру «бигдаты».

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

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

Хорошо забытое старое

Инженеры снова взялись за дело и… обнаружили, что изобретают велосипед. Вот, что говорят об этой работе создатели одной из NoSQL баз TimescaleDB:

«В ранних версиях нашего решения был собственный язык, который мы назвали “ioQL”. Строить его было очень круто, но мы быстро поняли, недооценили масштаб предстоящей работы. Нам нужно было определиться с синтаксисом, создать разнообразные коннекторы, обучить пользователей, и т.д. Мы постоянно искали нужный синтаксис для запросов, которые уже могли реализовать через SQL – и это в нашем собственном языке! В итоге однажды мы поняли, что надо просто перейти на SQL».

Другие команды все же попробовали добавить в свои решения методы и технологии «а ля SQL», но от этого стало только хуже. Когда разработчики сталкивались с вроде бы знакомой экосистемой, у них случался когнитивный диссонанс и они не знали, что в этом продукте будет работать привычным образом, а какие вещи изменились.

Так началась эпоха возрождения SQL. Соответствующие интерфейсы появились у крупных неструктурированных решений для работы с данными (Hadoop, Spark), а потом на рынок вышли новые базы данных с лучшими возможностями для масштабирования.

Снова длится бой

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

Одни говорят, что SQL не пригоден для поступающих в реальном времени данных и динамически меняющихся структур. Другие указывают, что, когда этот язык появился в 70-х, ситуация в IT была очень похожа на нынешнюю – такие же разрозненные хранилища с ad hoc правилами работы. Первые указывают на невозможность простого масштабирования ресурсов, вторые ехидно интересуются, когда их компания планирует выйти на глобальный рынок.

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

Какая вообще разница?

Главное различие между реляционными и неструктурированными базами данных – в требованиях, которым должна соответствовать хранимая в них информация. Если эти критерии выполняются, база обеспечивает наилучший результат. В противном случае начинаются проблемы.

У SQL-хранилищ набор таких правил образует акроним ACID:

  • Atomicity (атомарность; неделимость) – каждая операция с данными либо выполняется целиком, либо останавливается.
  • Consistency (последовательность; согласованность) – каждая запись в базе должна полностью соответствовать всем установленным правилам, т.е. в таблице не может быть пустых полей.
  • Isolation (изолированность) – при выполнении нескольких операций с данными ни одна из них не мешает другой, транзакции выполняются в последовательном ключе.
  • Durability (устойчивость; надежность) – результаты выполненных операций не исчезают из-за сбоя на последующих этапах, даже если система вовсе прекращает работу.

По этому списку нетрудно понять, почему успешные в до-Интернетную эпоху структурированные базы не справились с вызовами нового времени. Эти критерии, которые, кстати говоря, еще в конце 70-х сформулировал один из крупнейших IT-деятелей Джим Грей, вызывают ассоциацию с многостраничными журналами, которые бесконечно листает механическая рука. Ни о каких динамических сайтах с разнообразным мультимедийным контентом тут речи нет.

В свою очередь, NoSQL-база устроена таким образом, чтобы в любой момент веб-разработчик мог масштабировать проект с минимальными требованиями к производительности. Данные в таком хранилище должны отвечать принципу BASE:

  • Basic Availability (базовая доступность) – данные остаются доступными даже под влиянием изменений и других внешних факторов.
  • Soft state (гибкое состояние) – состояние и тип хранилища может меняться с течением времени.
  • Eventual consistency (итоговая/финальная согласованность) – даже если в процессе работы данные не согласуются друг с другом, в конце концов противоречия устраняются.

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

Резюме в практическом ключе

Принцип ACID ставит во главу угла правильное исполнение всех операций. Даже в случае критического сбоя данные не будут утеряны. Такие системы оптимально подходят для обеспечения финансовых транзакций, ведения журналов событий и множества других, четко регламентированных задач.

В свою очередь, BASE позволяет работать с меняющимися массивами данными, которые объединяют в себе неизвестное множество форматов. Социальные сети, онлайн-гипермаркеты с сотнями тысяч товаров, умные компьютерные системы – все они работают на базе неструктурированных хранилищ.

Чтобы определиться между SQL и NoSQL в своем проекте, вам достаточно ответить на следующие вопросы:

  1. С какими данными мы будем работать? Если этот набор известен заранее и поддается компактному форматированию, выбор падет на SQL. Если нам нужна гибкость, берем нереляционное решение.
  2. Кто и как часто будет работать с системой (отправлять ей запросы)? Создатели SQL прежде всего хотели, чтобы операции с данными не требовали академической подготовки. Работать с ними легко могут и начинающие веб-разработчики, и даже непрофессиональные пользователи. С другой стороны, неструктурированные системы зачастую страдают от недостатков прикладной реализации, и разобраться с их командами могут только профессионалы.
  3. Как высоко мы планируем расти? Если у вас стоит по серверу на каждом континенте, производительность сайта для живущих там пользователей будет на одном глобальном уровне. Скорость работы реляционных баз упирается в возможности каждого отдельного сервера. Для мировой экспансии они подходят плохо.

Текст: Помогаев Дмитрий

Поделиться:
Опубликовано в рубрике Веб-разработкаTagged , ,

SkillFactory.Рассылка