Сильные и слабые стороны NoSQL
SQL (Structured Query Language) — универсальный язык запросов, который используется всеми реляционными системами.
NoSQL имеют собственный API для взаимодействия.
Преимущества РСУБД — соответствия базы данных требованиям ACID, целостность данных, структурированность.
Преимущества NoSQL — скорость обработки данных, масштабируемость, распределенность систем.
Сильные стороны
- Возможность хранения больших объемов неструктурированной информации. В NoSQL нет ограничений на типы хранимых данных, а при необходимости можно добавлять новые типы данных.
- NoSQL-базы лучше поддаются масштабированию. Хотя масштабирование поддерживается и в SQL-базах, это требует гораздо больших затрат человеческих и аппаратных ресурсов.
Вычислительные мощности железа ограничены. А цена нескольких простых серверов меньше, чем одного высокопроизводительного. Горизонтальное масштабирование( несколько независимых машин соединяются вместе и каждая из них обрабатывает свою часть запросов) позволяет увеличить мощность кластера добавлением нового сервера.
Рассчитанные на работу в распределенных системах NoSQL хранилища проектируются так, что все процедуры распределения данных и обеспечения отказоустойчивости выполняются NoSQL базой. - Ключевые преимущества NoSQL баз в распределенных системах заключаются в процедурах шаринга и репликации.
Репликация — это копирование обновленных данных на другие сервера. Это позволяет добиться большей отказоустойчивости и масштабируемости системы.
Тип master-slave — это один мастер-сервер и несколько дочерних серверов. Запись может производиться только на мастер-сервер, который передает изменения на дочерние машины. Этот тип репликации даёт хорошую масштабируемость на чтение, но не на запись, так как запись идет только на мастер-сервер. Этот тип репликации имеет свой минус — в случае неисправности мастер-сервера нужно выбирать(автоматически или вручную) новый мастер-сервер.
Второй тип — peer-to-peer — все узлы равны в возможности обслуживать запросы на чтение и запись. Информация о обновлении данных передается от сервера к серверу.
Шаринг — это разделение информации по разным узлам сети. Каждый узел отвечает только за определенный набор данных и обрабатывает запросы, относящиеся только к этому набору данных. NoSQL предполагает, что шаринг реализует сама база данных, он будет производиться автоматически. - Использование облачных вычислений и хранилищ. Использование для тестирования и разработки локального оборудования, а затем перенос системы в облако.
- Быстрая разработка. NoSQL базы данных не требуют большого объема подготовительных действий, который нужен для реляционных баз.
- Многие NoSQL решения имеют ограниченную функциональность, т.к решают определенные задачи. Поэтому для работы с такими базами данных не требуется глубоких знаний SQL-запросов. Это сильно снижает входной порог для начала работы с NoSQL хранилищами.
- Более простые технологии запросов в NoSQL позволяют совершать меньше ошибок. Хотя и существует альтернатива упрощения работы с базой данных — технология ORM, позволяющая автоматически транслировать операции с объектами в запросы к базе данных, но подобные решения могут работать неэффективно или создавать множество ненужных и ошибочных запросов в некоторых случаях.
- Собственные языки запросов современных NoSQL хранилищ гораздо больше подходят для выполнения простых манипуляций с базой данных.
Слабые стороны
- Приложение сильно привязывается к конкретной СУБД. Язык SQL универсален для всех реляционных хранилищ и поэтому в случае смены СУБД не придётся переписывать весь код.
- Ограниченная емкость встроенного языка запросов. SQL имеет очень богатую историю и множество стандартов. Это очень мощный и сложный инструмент для операций с данными и составления отчетов. Практически все языки запросов и методы API хранилищ NoSQL были созданы на основе тех или иных функций SQL, но они имеют куда меньшую функциональность.
- Процесс создания реляционного хранилища включает в себя этап проектирования модели данных. На этой стадии можно оценить узкие места выбранной стратегии и спроектировать действительно надежную и удобную систему. NoSQL решения не требуют определять схему базы данных перед началом работы, поэтому в процессе разработки можно наткнуться на непредвиденные трудности, которые могут привести к отказу от данного NoSQL решения.
- Трудности быстрого перехода с одной нереляционной базы данных на другую.
- Приходится разрабатывать собственные инструменты для работы с БД.
- Специалистов с хорошим знанием SQL гораздо проще найти, в то время когда спецификой работы API некоторых NoSQL решений на серьёзном уровне мало кто увлекается — это значит, что многие специфические моменты оператору базы данных придется осваивать “на ходу”.
У большинства компаний просто нет таких объемов данных и других специфических условий работы, в которых NoSQL решения были бы выгодны в качестве основной базы данных. NoSQL хранилища показывают себя с очень хорошей стороны в симбиозе с реляционными базами данных. Например, в системах, где основной объем информации хранит SQL, а за кэш отвечает NoSQL.
Нереляционным системам всё ещё не хватает универсальности, надежности, целостности и предсказуем