Ускоряем базу данных веб-сайта

Отношения между таблицами

Чтобы база данных стала реляционной, одних данных мало. Между ними нужны еще и связи (те самые relations, от которых и пошло слово «реляционный»).

Для связи между таблицами служит так называемый внешний ключ (foreign key). Название довольно точно выражает его суть. Если в таблице A есть столбец для хранения первичного ключа таблицы B, то такой столбец и называется внешним ключом. Первичные и внешние ключи устанавливают связи между таблицами, превращая набор таблиц в цельную конструкцию — реляционную базу данных.

Приведу пример. Допустим, мы создали еще одну простую таблицу — справочник товаров. Назовем ее GOODS.

Товарный справочник GOODS
ID NAME PRICE UNIT COUNTRY
1 Яблоки 50.00 кг Россия
2 Груши 60.40 кг Франция
3 Апельсины 40.00 кг Марокко
4 Макароны 21.00 шт Франция
5 Кефир 25.30 шт Россия
6 Молоко 30.50 шт Россия

Ее колонки: ID — первичный ключ, NAME — название товара, PRICE — его цена, UNIT — краткое название единицы измерения, COUNTRY — название страны-производителя.

Хорошо ли построена такая таблица? Вроде бы всем упоминавшимся выше принципам она удовлетворяет: уникальные имена столбцов с однородными данными, строки с уникальным первичным ключом. Казалось бы, все на месте. Тем не менее построена она непрофессионально. Здесь мы подходим к принципам, о которых я еще не упоминал, — к понятию о нормализации таблиц. Суть в том, чтобы всюду, где только можно, избегать избыточности в хранении данных путем выделения их в отдельные таблицы.

Посмотрим на нашу таблицу GOODS. Чем она плоха? Представьте себе, что завтра придется изменить название какой-нибудь страны. Такое случается часто. Бирма когда-то меняла свое название на Мьянму, Польша — на Польскую Республику. Хочется ли вам менять огромное количество строк во всех таблицах, где эти страны упоминаются? Представьте также, что вас попросят отобрать запросом весь штучный товар. Можете ли вы быть уверены в том, что оператор всюду набил эту аббревиатуру правильно и одинаково? Скорее всего, окажется, что в таблице встречаются все мыслимые вариации: «шт», «Шт», «шт.», «штук» и «штуки».

Думаю, проблема понятна. Выходом из этой ситуации будет выделение из нее двух других таблиц: справочника стран (COUNTRIES) и справочника единиц измерений (UNITS).

Справочник единиц измерения UNITS
ID NAME SHORT_NAME
1 Штуки шт
2 Килограммы кг

Сам справочник товаров GOODS будет теперь выглядеть совершенно по-другому (см. таблицу).

Товарный справочник GOODS после нормализации
ID NAME PRICE UNIT_ID COUNTRY_ID
1 Яблоки 50.00 2 1
2 Груши 60.40 2 2
3 Апельсины 40.00 2 3
4 Макароны 21.00 1 2
5 Кефир 25.30 1 1
6 Молоко 30.50 1 1

Что изменилось? Вместо столбцов с названиями единиц измерения и стран появились столбцы UNIT_ID и COUNTRY_ID с кодами, отсылающими нас к другим таблицам. Это и есть внешние ключи. Что означает значение 2 в столбце UNIT_ID? Оно означает, что интересующая нас информация по единице измерения находится той строке таблицы UNITS, где ID = 2. Достаточно заглянуть в этот справочник, чтобы убедиться, что называется эта единица полностью «штуки», а кратко — «шт».

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

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

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

Какими бывают базы данных?

Итак, БД – это упорядоченное хранение информации. Какую же структуру они имеют? Сегодня существует 3 основных модели баз данных. К ним относят:

Иерархическая модель. Такие базы данных имеют древовидную структуру, компоненты которой разделяются на «родителей» и «потомков». Отличительной чертой иерархических БД является то, что у каждого «потомка» может быть только один «предок».

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

Реляционная модель. Данные в реляционной базе представлены в виде множества таблиц, каждая из которых состоит из столбцов и записей (строк). Каждый столбец имеет название, а каждая строка содержит определенную информацию. Взаимодействие с реляционной БД строится на уровне логики, которая подвластна каждому, кто успешно закончил 5 классов средней школы. Кстати, на курсе «Пользователь ПК» в нашей Академии ребята знакомятся именно с реляционной моделью БД на примере простой, но полезной программы MS Access.

Сравнение SQL и NoSQL

  1. Если SQL-системы основаны исключительно на строгом представлении данных, то NoSQL-системы предоставляют свободу и способны работать с любым типом данных.
  2. SQL-системы стандартизированы, за счёт чего запросы формируются с использованием языка SQL. В то же время NoSQL-системы базируются на специфической для каждой из них технологии, что является недостатком.
  3. Масштабируемость. Обе СУБД способны обеспечить вертикальное масштабирование, то есть увеличить объём системных ресурсов на обработку данных. При этом NoSQL, будучи более новой разновидностью баз данных, позволяет применять простые методы горизонтального масштабирования.
  4. В плане надёжности SQL обладает уверенным лидерством.
  5. У SQL-баз есть качественная техническая поддержка за счёт их продолжительной истории, в то время как NoSQL-системы весьма молоды и и решить какую-либо проблему сложнее.
  6. Хранение данных и доступ к их структурам в рамках реляционных систем лучше всего происходит в SQL-системах.

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

Надёжность SQL-систем, особенно MySQL, подтверждается временем и массовостью. Сегодня любой уважающий себя ресурс использует для хранения данных именно систему MySQL.

Особенности реляционных данных

Главная особенность — все объекты хранятся в виде набора 2-мерных таблиц. Каждая таблица включает в себя набор столбцов, где указываются следующие параметры:
— название;
— тип данных (число, строка и т. д.).

Вторая важная особенность заключается в том, что число столбцов фиксировано. Это значит, что структура БД известна заранее, при этом количество рядов либо строк данных практически не ограничено. Грубо говоря, строки в реляционных БД — есть объекты, хранимые в базе.

По большему счёту, БД — это абстрактное понятие, а в случае с реляционной структурой таблица — есть не более чем удобный способ хранения информации. Причём набор таблиц превращается в базу данных тогда, когда он связан логически. А чтобы этим всем управлять, используют СУБД. Классический пример СУБД — система управления MySQL. Иными словами, СУБД MySQL — есть программное воплощение математических идей.

Функциональные особенности выбора

Следующим важным фактором в выборе будет набор функциональных требований к СУБД. Если вы делаете систему полнотекстового поиска, то лучше делать её не на основе redis, mongodb и т. д., а взять специализированные решения: sphinx, elasticsearch. Если вам нужен сервис, который работает с геоданными, убедитесь, что база данных поддерживает географические индексы.

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

Отказоустойчивость также очень важный фактор. Любые сервера выходят из строя. И чем больше серверов в вашей системе, тем выше вероятность отказа какого-либо из них. Старайтесь избегать создания единых точек отказа, хотя бы в критичных подсистемах. Изучите возможности отказоустойчивости систем. Некоторые решения, такие как cassandra, устойчивы даже к отказу целого дата-центра. Не забывайте, что чуда не случится. Во-первых, проводите учения, чтобы убедиться, что вы всё верно сконфигурировали. Во-вторых, ценой отказоустойчивости будет являться потеря скорости.

Обязательно учитывайте надёжность базы данных. К примеру, mongodb до середины 2018 года не поддерживала ACID-транзакции. Оценивайте, критична ли надёжность данного сервиса, или всё же вам больше требуется производительность. Для систем логирования, скорее всего, скорость будет предпочтительнее. Но использование систем без ACID-транзакций для финансовых подсистем — точно не самая лучшая идея.

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

Часто самым лучшим решением будет взять самую знакомую технологию.

Классификации СУБД

Существует несколько признаков, по которым можно классифицировать СУБД.

СУБД по модели данных бывают:

  • Иерархические СУБД
  • Сетевые СУБД
  • Реляционные СУБД
  • Объектно-ориентированные СУБД
  • Объектно-реляционные СУБД

В настоящее время в серьезных проекта используются 2 последних типа.

СУБД по степени распределённости

  • Локальные (СУБД размещается только на одном компьютере)
  • Распределённые (части СУБД могут размещаться на 2-х и более компьютерах).

По способу доступа к БД

Файл-серверные СУБД

В них файлы с данными расположены централизованно на специальном файл-сервере. СУБД же должны быть расположены на каждом клиенте (рабочей станции). Доступ СУБД к данным производится посредством локальной сети. Поддержка синхронизации чтений и обновлений осуществляется за счет временных блокировок затребованных файлов.

Плюсом этой архитектуры можно назвать низкую нагрузку на файловый сервер.

К минусам же: высокая загрузка трафиком локальной сети; сложность или невозможность централизованного управления; нельзя обеспечить такие важные характеристики как надёжность, доступность и безопасность. Файл-серверные СУБД используют в локальных приложениях; в системах с малой интенсивностью обработки данных и небольшими пиковыми нагрузками на базу данных.

Сейчас её при создании крупной информационной системы не используют.

Примеры файл-серверных СУБД:

  • dBase,
  • FoxPro,
  • Microsoft Access,
  • Paradox,
  • Visual FoxPro.

Клиент-серверные СУБД

Клиент-серверная СУБД расположена на сервере вместе с базой данных и осуществляет доступ к БД исключительно в монопольном режиме. Все запросы на обработку данных клиентских приложений и станций обрабатываются централизованно.

Недостатком такого типа СУБД можно назвать повышенные требования к серверу.

Достоинствами: более низкую загрузку локальной сети; преимущества централизованного управления; поддержку высокой надёжности, доступности и безопасности.

Примеры клиент-серверных СУБД:

  • Caché,
  • Firebird,
  • IBM DB2,
  • Informix,
  • Interbase,
  • MS SQL Server,
  • MySQL, Oracle,
  • PostgreSQL,
  • Sybase Adaptive Server Enterprise,
  • ЛИНТЕР.

Встраиваемые СУБД

Это вид СУБД, который может выступать лишь в качестве составной части определенного программного комплекса, без необходимости процедуры отдельной установки. Такой вид СУБД может быть использован для локального хранения данных своего приложения и не рассчитан на коллективное использование в компьютерной сети. Физически же это зачастую реализуется в виде подключаемой библиотеки. Со стороны приложения доступ к данным происходит посредством SQL-запросов либо через специальный программный интерфейс.

Примеры встраиваемых СУБД:

  • Firebird Embedded,
  • BerkeleyDB,
  • Microsoft SQL Server Compact,
  • OpenEdge,
  • SQLite,
  • ЛИНТЕР.

Для рассмотрения лишь части основных возможностей и внутреннего устройства любой СУБД требуется один или несколько отдельных учебных курсов.

История

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

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

Какие бывают NoSQL-СУБД: основные типы нереляционных баз данных

Все NoSQL решения принято делить на 4 типа:

  1. Ключ-значение (Key-value) – наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы . Такие СУБД применяются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в масштабируемых Big Data системах, включая игровые и рекламные приложения, а также проекты интернета вещей (Internet of Things, IoT), в т.ч. индустриального (Industrial IoT, IIoT). Наиболее известными представителями нереляционных СУБД типа key-value считаются Oracle NoSQL Database, Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB, которые поддерживают высокую разделяемость, обеспечивая беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД .
  2. Документно-ориентированное хранилище, в котором данные, представленные парами ключ-значение, сжимаются в виде полуструктурированного документа из тегированных элементов, подобно JSON, XML, BSON и другим подобным форматам . Такая модель хорошо подходит для каталогов, пользовательские профилей и систем управления контентом, где каждый документ уникален и изменяется со временем .  Поэтому чаще всего документные NoSQL-СУБД используются в CMS-системах, издательском деле и документальном поиске. Самые яркие примеры документно-ориентированных нереляционных баз данных – это CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML .
  3. Колоночное хранилище, которое информацию в виде разреженной матрицы, строки и столбцы которой используются как ключи. В мире Big Data к колоночным хранилищам относятся базы типа «семейство столбцов» (Column Family). В таких системах сами значения хранятся в столбцах (колонках), представленных в отдельных файлах. Благодаря такой модели данных можно хранить большое количество атрибутов в сжатом виде, что ускоряет выполнение запросов к базе, особенно операции поиска и агрегации данных . Наличие временных меток (timestamp) позволяет использовать такие СУБД для организации счётчиков, регистрации и обработки событий, связанных со временем: системы биржевой аналитики, IoT/IIoT-приложения, систему управления содержимым и т.д. Самой известной колоночной базой данных является Google Big Table, а также основанные на ней Apache HBase и Cassandra. Также к этому типу относятся менее популярные ScyllaDB, Apache Accumulo и Hypertable .
  4. Графовое хранилище представляют собой сетевую базу, которая использует узлы и рёбра для отображения и хранения данных . Поскольку рёбра графа являются хранимыми, его обход не требует дополнительных вычислений (как соединение в SQL). При этом для нахождения начальной вершины обхода необходимы индексы. Обычно графовые СУБД поддерживают ACID-требования и специализированные языки запросов (Gremlin, Cypher, SPARQL, GraphQL и т.д.) . Такие СУБД используются в задачах, ориентированных на связи: социальные сети, выявление мошенничества, маршруты общественного транспорта, дорожные карты, сетевые топологии . Примеры графовых баз: InfoGrid, Neo4j, Amazon Neptune, OrientDB, AllegroGraph, Blazegraph, InfiniteGraph, FlockDB, Titan, ArangoDB.

Виды NoSQL-СУБД

Иерархическая база данных

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

Компьютер способен быстро ориентироваться в ней. Иерархический принцип взят за основу в структурировании файлов и папок в операционной системе Windows, а реестр хранит информацию о параметрах работы тех или иных приложений в структурированном иерархическим способом виде.

Все интернет-ресурсы также построены по иерархическому принципу, так как при его использовании ориентироваться в рамках сайта очень легко.

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

Требования к проектированию БД

О видах и особенностях реляционных БД мы уже поговорили. Теперь давайте подробнее обсудим сложности их проектирования. В данном случае этот процесс начинается с постановки задач, исходя из нужных требований, особенностей использования, недостатков либо достоинств той либо иной системы управления. В случае с СУБД MySQL необходимо правильно составить общую структуру.

Требования обычно следующие:
1. База данных должна быть относительно простой в плане обработки информации.
2. Она должна быть максимально компактной и неизбыточной настолько, насколько это возможно без ущерба для функциональности.

Возможны и другие требования, причём нередко они противоречат друг другу

Именно поэтому важно найти оптимальный баланс с точки зрения архитектуры, учитывая назначение конечного продукта

Так как проектирование — важнейший процесс, им занимается проектировщик. Обычно к работе привлекают профессиональных администраторов серверов либо архитекторов БД, имеющих большой практический опыт. Нужно четко понимать, что проектируется и какие результаты должны получиться на выходе. Это бывает непросто, так как, если речь идёт о серьёзных проектах, готовая структура может включать в себя десятки и сотни таблиц, которые бывают связаны друг с другом как простыми, так и замысловатыми способами.

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

Если вы хотите овладеть базами данных на высоком профессиональном уровне, записывайтесь на соответствующий курс в OTUS. Практикующие эксперты научат вас особенностям управления БД и тому, как эффективно взаимодействовать с любой реляционной СУБД, используя для этого язык структурированных запросов SQL.

Состав СУБД

Обычно современная СУБД содержит следующие компоненты:

  • ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию;
  • процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода;
  • подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД;
  • сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы.

Реляционная база данных

Под данным типом баз данных понимается их представление в рамках двумерной таблицы. Она имеет несколько столбцов, в которых устанавливаются такие параметры, как, например, тип вводимых данных (текст, число, дата и др.).

Таблица здесь является способом хранения введённых в неё данных и способна реагировать на любые обращения со стороны СУБД. Главная проблема в работе с реляционными базами данных состоит в их правильном проектировании.

Во время проектирования базы данных следует учесть следующие два фактора:

Самый понятный курс PHP
Онлайн-уроки в удобное время!
Начать бесплатно

  1. база данных должна быть компактной и не содержать избыточных компонентов;
  2. обработка базы данных должны происходить просто.

Проблема в том, что эти факторы друг другу противоречат. А ведь проектирование — важнейший момент при составлении базы данных и дальнейшей работе с ней. Заниматься им рекомендуется администратору сервера, обладающему определённым опытом.

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

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

СУБД

Система управления базами данных — это термин, который не нужно расшифровывать. Она представляет собой встраивыемый модуль или полноценную программу, которая способна работать с данными и вносить изменения в базы.

Существует две модели СУБД — реляционная и безсхемная. О том, что такое реляционные базы данных, уже рассказано выше. Безсхемные СУБД основанные на принципах неструктурированного подхода избавляют программиста от проблем реляционной модели, в число которых входит низкая производительность и трудное масштабирование данных в горизонтальном формате.

Неструктурированные базы данных (NoSQL) создают структуру по ходу и убирают необходимость в создании жёстко определённых связей между данными. Здесь можно экспериментировать с разными способами доступа к тем или иным видам данных.

К реляционным базам данных относятся:

  • SQLite;
  • MySQL;
  • PostgreSQL.

Из них наиболее распространённой является база данных MySQL, но остальные тоже имеют популярность и с ними можно столкнуться.

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

По принципу NoSQL работает база данных MongoDB. Они хранят все данные как единое целое в одной базе. При этом данные могут быть и одиночным объектом, но в то же время любой запрос не останется без ответа.

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

Зачем изучать базы данных?

Вообще – это странный вопрос. Понимание устройства и работы БД не только расширит кругозор, но и даст вполне реальную практическую пользу каждому, кто:

Складывает в сознании научную картину мира
Понимает, как важно уметь работать с многообразием цифровой информации
Хочет стать программистом

Остановимся подробнее на последнем пункте из списка. Зачем программисту базы данных?

Представь: ты изучаешь C++ и пишешь программу под условным названием «Рабочее место врача-офтальмолога». Это приложение создается для учета пациентов, заполнения их личных данных и истории болезни, подбора рецептов и лекарств и пр. Где хранить всю эту информацию? Разумеется, в базе данных. Она подключается к рабочим файлам проекта, а все взаимодействие происходит через специальную программную оболочку, то есть СУБД.

Еще показательный пример: некоторые выпускники нашего курса «Web-программирование» в качестве дипломного проекта создают новостной портал, который отличается наличием огромного количества контента – как текстового, так и графического и даже медийного. Повторим вопрос: где хранить все это многообразие информации – статьи, изображения, ссылки на видео? Конечно, в базе данных. Мы просто обращаемся к БД и с помощью специального языка запросов вытаскиваем нужную нам информацию для вывода на экран.

Разумеется, взаимодействие с БД принимает различные формы – мы не только вынимаем данные, но и легко ими манипулируем: редактируем, удаляем, добавляем новые. Кстати, для изучения на курсе «Web-программирование» мы выбрали базы данных MySQL, которые сегодня используют не только начинающие разработчики, но и такие IT-гиганты, как Facebook, Google, LinkedIn.

Таким образом, понимание баз данных и умение с ними работать – важнейшее качество не только программиста, но и каждого, кто считает себя продвинутым пользователем. Или стремится им стать. Ты ведь относишься к их числу?

Зачем нужны нереляционные базы данных в Big Data: история появления и развития

NoSQL-базы оптимизированы для приложений, которые должны быстро, с низкой временной задержкой (low latency) обрабатывать большой объем данных с разной структурой . Таким образом, нереляционные хранилища непосредственно ориентированы на Big Data. Однако, идея баз данных такого типа зародилась гораздо раньше термина «большие данные», еще в 80-е годы прошлого века, во времена первых компьютеров (мэйнфреймов) и использовалась для иерархических служб каталогов. Современное понимание NoSQL-СУБД возникло в начале 2000-х годов, в рамках создания параллельных распределённых систем для высокомасштабируемых интернет-приложений, таких как онлайн-поисковики .

Вообще термин NoSQL обозначает «не только SQL» (Not Only SQL), характеризуя ответвление от традиционного подхода к проектированию баз данных. Изначально так называлась опенсорсная база данных, созданная Карло Строззи, которая хранила все данные как ASCII-файлы, а вместо SQL-запросов доступа к данным использовала шелловские скрипты . В начале 2000-х годов Google построил свою поисковую систему и приложения (GMail, Maps, Earth и прочие сервисы), решив проблемы масштабируемости и параллельной обработки больших объёмов данных. Так была создана распределённые файловая и координирующая системы, а также колоночное хранилище (column family store), основанное на вычислительной модели MapReduce. После того, как корпорация Google опубликовала описание этих технологий, они стали очень популярны у разработчиков открытого программного обеспечения. В результате этого был создан Apache Hadoop и запущены основные связанные с ним проекты. Например, в 2007 году другой ИТ-гигант, Amazon.com, опубликовав статьи о своей высокодоступной базе данных Amazon DynamoDB. Далее в эту гонку NoSQL- технологий для управления большими данными включилось множество корпораций: IBM, Facebook, Netflix, eBay, Hulu, Yahoo! и другие ИТ-компаний со своими проприетарными и открытыми решениями .

Многообразие NoSQL-решений

Как правильно выбрать базу данных NoSQL: ключевые факторы

Имея более двух десятков свободно распространяемых и коммерческих баз данных NoSQL на рынке, как вы выбрать нужный продукт или облачный сервис?

Один из важных факторов – четко сформулировать цель, которую вы хотите достичь поместить данные в такую БД.

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

  • В целом, хранилища типа «ключ-значение» (key-value stores) лучше всего подходят для постоянного совместного использования данных несколькими процессами или микросервисами в приложении.
  • Если вы планируете провести глубокий анализ отношений для расчета взаимосвязей, обнаружения мошенничества или оценки ассоциативной структуры, лучше всего будет использовать графовую базу данных графа.
  • Если вам нужно собирать данные очень быстро и на больших объемах для аналитики, посмотрите в сторону широкий колоночных баз данных или, как их еще называют), базы данных с широким значением столбца (wide column store). Такие базы данных NoSQL также предлагают поддержку документов и графов.

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

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

Базы данных NoSQL, имеющие сертификаты безопасности, должны быть рассмотрены в первую очередь. Ищите такие функции, как шифрование данных в состоянии покоя (data at rest) и шифрования данных на лету (data in motion) для защиты конфиденциальной информации.

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

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

Ссылка на основную публикацию