С ростом технологических достижений традиционные способы хранения данных подвергаются сомнению. С принятием NoSQL отраслевыми гигантами и постоянно растущим количеством вариантов баз данных NoSQL, становится тенденцией рассматривать NoSQL как альтернативу реляционным базам данных для основной разработки программного обеспечения.
Однако, что касается реляционных баз данных, они существуют уже несколько десятилетий. Нетрудно найти разработчиков, которые обладают знаниями и опытом в написании SQL-запросов, проектировании отношений сущностей, нормализации схем и обеспечении свойств ACID. Это не относится к NoSQL, где не хватает знаний, опыта и опыта.
Это может привести к неправильным проектным решениям при использовании NoSQL там, где он не подходит. Другая распространенная ошибка при принятии NoSQL происходит, когда разработчики, работающие с реляционной базой данных, проектируют базу данных NoSQL, придерживаясь основ реляционных баз данных.
Хотя в этой статье я больше говорю о NoSQL, я верю, что у реляционных баз данных есть свои сильные стороны там, где они должны быть.
Поэтому, если вы используете реляционные базы данных прямо сейчас или собираетесь использовать их для нового программного проекта, не волнуйтесь, придерживайтесь своего решения, и оно не умрет в ближайшем обозримом будущем. Также имейте в виду, что NoSQL не означает «Нет SQL», это означает «Не только SQL».
В этой статье я выделю несколько моментов, которые будут полезны новичкам в освоении NoSQL.
Почему NoSQL сложен?
Короче говоря, использовать базы данных NoSQL несложно. Сложность заключается в том, чтобы правильно использовать его в нужных местах. Прежде всего, важно понимать, что NoSQL не следует тем же принципам, что и реляционные базы данных, таким как фиксированные схемы, нормализация, поддержка выразительных запросов, таких как SQL.
Одна из распространенных ошибок разработчиков - это попытка нормализовать базу данных NoSQL, когда они портят всю структуру базы данных, что затрудняет эффективное извлечение элементов.
Базы данных NoSQL кардинально отличаются от других аналогов в зависимости от типа базы данных NoSQL (база данных документов, база данных ключевых значений, база данных графиков и т. Д.) И конкретной реализации поставщика (MongoDB, DynamoDB, Cassandra и т. Д. ). Из-за этого не существует универсальных передовых методов или принципов для проектирования схемы базы данных или запросов, которые подходят для всех типов баз данных NoSQL. Это создает проблему при разработке уникальной базы данных для соответствующего типа NoSQL, придерживаясь его собственных передовых практик.
Например, если мы рассматриваем базу данных документов, нам необходимо учитывать ограничения размера коллекции, то, как они разделены, доступные типы запросов и поддержку индексирования, чтобы можно было эффективно извлекать элементы (или вложенные атрибуты), необходимые для приложения. Это непростая задача, поскольку есть несколько мест, где что-то может пойти не так.
Некоторые из передовых методов работы с реляционными базами данных, такие как отказ от хранения всего в базе данных, по-прежнему применимы к NoSQL. Хотя в некоторых базах данных NoSQL можно хранить такие файлы, как изображения, перекодированные видео и т. Д., Имеет смысл хранить их в распределенной файловой системе, а затем использовать базу данных для хранения метаданных файлов.
Дублирование данных может стать лучшей практикой
Если вы разработчик, настроенный на отказ от дублирования данных на уровне базы данных, самое время пересмотреть решение с помощью NoSQL.
Для некоторых типов баз данных NoSQL дублирование атрибутов данных в разных таблицах или коллекциях может стать даже лучшей практикой, позволяющей избежать сложных запросов.
Например, сегодня хранилище не так дорого, тогда как вычислительная мощность, напротив, дороже. Следовательно, хранение данных в различных формах с использованием большего объема памяти для прямого поиска может иметь смысл, а не выполнение сложных в вычислительном отношении запросов.
Итак, вы можете задаться вопросом, почему все эти дорогостоящие запросы в реляционных базах данных, скорее, хранят данные и их отношения с дублированием в NoSQL, где мы могли бы выполнять прямой поиск и извлечение? Ответ заключается в том, что это не так просто, поскольку создание или обновление данных в NoSQL может стать более сложным, если данные разбросаны по множеству таблиц или коллекций.
Следовательно, важно оценить, как данные потребляются и обновляются приложением, и соответствующим образом спроектировать базу данных.
Запросы к NoSQL уникальны для каждой базы данных NoSQL
Это еще одна область, которая действительно сбивает с толку NoSQL. Каждая из этих баз данных NoSQL имеет свой собственный язык запросов. Это действительно сложно для разработчиков, которые раньше работали с реляционными базами данных, поскольку SQL может быть применим во многих реализациях реляционных баз данных с небольшими отличиями. При использовании NoSQL вы должны обратиться к документации, чтобы понять, какие конкретные типы данных поддерживаются, а также ограничения запросов и функций.
С некоторыми типами баз данных NoSQL (например, некоторые базы данных документов и базы данных ключевых значений) не удивляйтесь, увидев, что можно запрашивать только ключевые атрибуты или использовать предопределенные индексы в отличие от реляционных баз данных, где вы можете запрашивать практически по любому признаку.
Еще один важный момент, который следует учитывать при работе с базами данных NoSQL, - это поддерживаемые ими модели согласованности. Хотя некоторые из этих баз данных поддерживают строгую согласованность, другие могут быть ограничены возможной согласованностью. Поддержка согласованности также может варьироваться в зависимости от типа запроса, будь то чтение, запись или обновление.
Транзакции обрабатываются по-разному
Для большинства баз данных NoSQL сложно создавать транзакции, аналогичные реляционным базам данных, где база данных обеспечивает поддержку более высокого уровня для фиксации и отката. Поэтому также важно определить уровень поддержки со стороны базы данных NoSQL для реализации транзакций.
Для большинства баз данных NoSQL вам потребуется обрабатывать транзакции и откат на уровне приложения. Тем не менее, многие из этих баз данных NoSQL предоставляют некоторые базовые функции, которые сделают вашу жизнь проще.
Например, некоторые базы данных NoSQL поддерживают такие функции, как условная запись и атомарные обновления, которые можно использовать для эффективной реализации транзакций.
Например, вы можете создать операцию обновления, в которой говорится, что, если сумма равна только сумме «x», обновлять элемент (или генерировать исключение, если оно изменилось, что необходимо соответствующим образом обработать в приложении. Преимущество состоит в том, что коллекции или таблицы не блокируются во время выполнения транзакции, что положительно сказывается на производительности базы данных.
Использование как NoSQL, так и реляционного
По моему опыту, многие функции веб-приложений и мобильных приложений требуют различных возможностей запросов, когда целесообразно начинать с реляционной базы данных.
Если ваше приложение требует специальной поддержки высокой пропускной способности, доступности и масштабирования хранилища, вы можете рассмотреть возможность использования баз данных NoSQL для соответствующей области использования в дополнение к реляционной базе данных.
За последние несколько лет внедрение микросервисов также сделало логичным использование нескольких типов баз данных в зависимости от требуемых возможностей приложения.
Например, вы можете рассмотреть возможность использования базы данных NoSQL с ключевыми значениями в памяти, такой как Redis для хранилища сеансов, с использованием реляционной базы данных для хранения бизнес-объектов и т. Д.
Итак, отвечая кратко, становится обычной практикой использовать разные типы баз данных вместе для создания приложений, а не придерживаться одной базы данных для всех.
Заключение
Между NoSQL и реляционными базами данных есть много различий. Хотя мы обсудили некоторые проблемы использования NoSQL, в некоторых случаях использование NoSQL дает множество преимуществ.
Например, некоторые преимущества включают возможность обработки больших объемов данных для хранения, масштабируемость, гибкий сбор данных и т. Д.
Следовательно, перед использованием NoSQL важно провести достаточное базовое исследование, получить опыт и иметь непредвзятый образ мышления, поскольку некоторые практики, которые вы уже усвоили при работе с базами данных, необходимо отучить, независимо от того, насколько вы опытны.
