Прежде чем начать рассказывать о базах данных, скажу, для кого эта статья. Если вы бывалый разработчик, то смело пропускайте статью, ничего нового вы с ней не найдете. Статья для тех, кто только планирует начать карьеру в дата-аналитике или data science, кто много раз слышал словосочетание «база данных», но не до конца понимает, что это.
Я решила написать эту статью, потому что именно такой статьи мне очень не хватало несколько лет назад, когда я только начала карьеру в аналитике данных. Тогда я часто слышала слова «база данных», «реляционная база», «primary key», примерно понимала, что они означают, но единую картину в голове у меня сложить не получалось.
Что такое база данных и зачем она?
Компании часто собирают информацию о своих клиентах, сотрудниках, операциях, финансах и т. д. Потом эту информацию можно выгодно использовать. Например, можно ее проанализировать и понять, какими способами можно увеличить прибыль. Можно на ее основе построить хитрые MLмодели, которые помогут улучшить продукт. Или, в конце концов, эту информацию можно просто перепродать другим компаниям.
Чтоб собирать и анализировать информацию, надо уметь ее сохранять. Конечно, можно сохранять информацию в печатном виде в обычных папках или в Excel-файлах. И многие компании до сих пор так сохраняют информацию. Однако, такое подойдет только для маленьких компаний с небольшим количеством данных. Когда компания вырастает, то и данных становится много, такие варианты сохранения информации становятся непригодны. Тогда на помощь приходят базы данных.
Базы данных помогают справиться с большим количеством проблем, решить которые папкам и Excel-файлам не под силу:
В базе данных можно хранить очень огромное количество данных – миллиарды и триллионы записей;
Базы помогают защищать данные - они позволяют давать доступ к данным только определенному кругу лиц. При этом можно ставить ограничения, кому к каким данным можно давать доступ и какого типа доступ, только чтение или редактирование тоже;
Базы данных могут помогать следить за правильностью данных с помощью различного вида проверок;
Также, базы данных могут позволять большому количеству людей одновременно взаимодействовать с данными.
Так что же такое база данных? Если говорить коротко, то это определенная структура, в которой хранится информация. Я понимаю, что из этого определения пока мало что понятно. Однако, более конкретное определение дать сложно, потому что существует много типов баз данных, и все они совершенно разные.
Я думаю, это определение станет понятнее, когда я далее опишу наиболее популярные типы баз данных на конкретных примерах.
Типы баз данных
Существует много разных типов баз данных. Наиболее популярные типы:
Реляционные базы данных
Key-value базы данных
Документно-ориентированные базы данных
Графовые базы данных
Колоночные базы данных
Далее я расскажу о каждом из этих типов. Однако, начну я реляционных баз данных и больше всего буду рассказывать о них, потому что именно этим типом баз данных чаще всего пользуются аналитики данных и data scientist-ы.
Реляционные базы данных (MySQL, PostgreSQL, Oracle DB)
Реляционная база данных – это база данных, которая состоит из таблиц. У реляционной базы данных 2 очень важные характеристики:
Данные распределены по смыслу по таблицам
Между таблицами есть отношения
Рассмотрим пример реляционной базы. Допустим, у нас есть сервис доставки еды. Тогда, если мы построим реляционную базу данных для этого сервиса, то она, скорее всего, будет содержать следующие таблицы:
Таблица с заказами
Таблица с клиентами
Таблица с курьерами
Таблица с ресторанами
На рисунке 1 я попыталась изобразить графически реляционную базу данных. Мы видим таблицы, из которых состоит база, и также видим, какие столбцы содержит каждая из таблиц.
Как я отметила выше, второй важной характеристикой реляционных баз данных является то, что между таблицами существуют отношения. Отношения между таблицами определяются с помощью primary key и foreign key.
Primary key – это столбец (или группа столбцов) таблицы, который содержит уникальные значения для каждой строки. На примере выше primary key каждой таблицы я выделила зеленым цветом. То есть, например, в таблице с заказами каждая строка будет описывать отдельный заказ. Не будет 2 строк, которые описывают один и тот же заказ, потому ID заказа будет разный для каждой строки.
Foreign key – это столбец в таблице, который содержит primary key другой таблицы. На рисунке foreign key отмечены желтым. То есть, таблица с заказами содержит ID клиента, который является primary key в таблице с клиентами, но в таблице с заказами он будет foreign key.
Primary key и foreign key помогают не только связывать между собой таблицы реляционной базы данных отношениями. Они еще помогают следить за целостностью и правильностью данных в базе. Например, если мы ошибемся в ID клиента, добавляя новый заказ в таблицу с заказами, то база выдаст ошибку, так как не найдет соответствующий ID клиента в таблице с клиентами.
Для взаимодействия с реляционными базами данных чаще всего используется SQL (Structured QueryLanguage). Это специальный язык программирования, на котором пишутся запросы к реляционной базе. SQL-запросами можно создавать и удалять таблицы в реляционной базе, изменять данные в существующих таблицах и доставать из таблиц необходимую информацию.
Как я уже говорила выше, реляционные базы данных удобно использовать в аналитике, так как информация в них структурирована и распределена по смыслу, что, конечно, мечта любого аналитика. Однако, аналитики часто пишут сложные и не очень эффективные SQL-запросы, потому важно придумывать способы ускорения обработки запросов к реляционной базе.
Одним из наиболее популярных методов ускорения работы запросов к реляционным базам данных является индексирование таблиц. Индекс – это определенный столбец в таблице, по которому осуществляется поиск.
Приведу пример работы индекса. Например, мы хотим найти все заказы клиента 007 из ресторана 1. Тогда, если у нас в таблице с заказами нет индекса, то мы будем перебирать все заказы пока не найдем нужные. Если же у нас есть индекс в таблице с заказами, то ситуация будет иной. Допустим, что индексом является столбец ID ресторана. Тогда наши данные в таблице с заказами будут сгруппированы по ID ресторана. И тогда при поиске заказов клиента 007 из ресторана 1, мы не будем перебирать всю таблицу с заказами, а найдем группу заказов из ресторана 1 и будем искать необходимые данные внутри этой группы.
Из примера выше с индексом выше понятно, что индексом удобно выбирать такой столбец, в разрезе которого часто ищутся данные.
Также, одним из важных свойств реляционных баз данных является соответствие требованиям ACID. Я не буду углубляться в детали этих требований, только отмечу, что эти требования гарантируют целостность и корректность данных, несмотря на ошибки, системные сбои, перебои в питании, изменение данных несколькими пользователями одновременно и прочие необычные ситуации.
Выглядит так, что реляционная база данных идеальная база, и непонятно, почему бы постоянно ее не использовать. Однако, у реляционной базы данных есть и недостатки, и потому данный тип не всегда подходит для нужд бизнеса. Например, реляционная база данных не подходит для данных без четкой структуры, потому что мы не сможем разложить эти данные в отдельные таблицы по смыслу. А данных без четкой структуры гораздо больше, чем данных с четкой структурой.
Какие еще есть типы баз данных?
Прочие типы баз данных, которые не реляционные, часто называются noSQL базы данных. Обсудим наиболее популярные типы нереляционных баз данных.
Key-value базы данных (пример - Redis)
Название говорит о том, какие данные удобно хранить в Key-value базе – в такой базе хранят данные, которые удобно представить в виде пары ключ-значение. Основное преимущество таких баз – это очень быстрый поиск значения по ключу. При этом значение может содержать какие угодно типы данных.
Такие базы данных удобно применять в проектах, где необходимо выдавать быстрый результат по ключу, например, для онлайн торгов или сделок.
Документно-ориентированные (пример - Mongo DB)
В документно-ориентированной базе данных единицей хранения является документ (который может быть в формате json, или xml, или в каком-нибудь еще формате). Удобство таких баз в том, что в них быстро и легко записывать любые типы данных, при этом эти данные не обязаны обладать четкой структурой. Минус таких баз в том, что данные в них неудобно анализировать.
В моей предыдущей компании такой тип баз данных служил базой для реляционных баз. То есть сначала все данные попадали и сохранялись в документно-ориентированной базе. Потом команда дата инженеров обрабатывала эти огромные полотна информации, структурировала и складывала в реляционную базу данных, которую уже могла использовать команда аналитиков и Data Science.
Графовые базы данных (пример - Orient DB)
Как следует из названия, в графовой базе данных данные хранятся в виде графов. Данный тип баз удобен, когда надо находить информацию не только о каком-то объекте, но и доставать информации о связах этого объекта с другими.
Например, в моей текущей компании данный тип баз используется для нахождения куки конкретного юзера и всех взаимосвязанных с этой кукой идентификаторов. Также, такой тип данных часто используется социальными сетями для сохранения информации не только о пользователях, но и о связях каждого пользователя с другими.
Колоночные (столбцовые) базы данных (примеры - Cassandra, Clickhouse)
В реляционных базах данных данные записаны в виде строк. Что же касается колоночных баз данных, то тут данные записываются в виде столбцов. Потому поиск данных в колоночной базе данных осуществляется не перебором всех строк, как это происходит в реляционной базе данных, а поиском необходимого значения в тех столбцах таблицы, которые нас интересуют.
Преимущество колоночных баз данных в том, что они могут быстро находить определенные значения в столбцах, которые нас интересуют.
Ну и напоследок
В заключение скажу, что типов баз данных великое множество. Какие-то типы приобретают популярность, какие-то больше не используются. У каждого типа свои преимущества и недостатки. И, выбирая тот или иной тип баз данных, надо исходить в первую очередь от вида вашего бизнеса и его потребностей.
Комментарии (16)
panzerfaust
07.09.2022 07:41+12Из-за того, что в реляционной базе информация находится в большом
количестве таблиц, отношения между которыми часто сложные, такая база не
подходит для ситуаций, когда результат в ответ на запрос к данным надо
выдавать очень быстро.Вы вводите свою аудиторию (новичков) в заблуждение. Потом эти новички на голубом глазу транслируют все эти мифы на собеседованиях или даже в своей профессиональной деятельности.
В дизайне RDB нет ничего такого, что делает их принципиально медленными. Чаще встречается просто неграмотное использование. Да, делать аналитический запрос из нормализованных таблиц с 10 джойнами - плохая идея. Но это идея человека, а не RDB.lola_kochieva Автор
07.09.2022 11:58Спасибо за коммент! Я соглашусь. Я не очень удачно сформулировала то, что хотела сказать, я имела в виду, что "реляционная база не та база, которая используется, когда нужно выдавать ответы за милисекунды. Есть более быстрые структуры". Пока удалю этот абзац, надо подумать как переформулировать)
hbn3
09.09.2022 00:38В дизайне RDB нет ничего такого, что делает их принципиально медленными.
Самое интересное, что некоторые nosql базы используют тот-же mysql в качестве хранилища данных.
Akina
07.09.2022 07:56+7Отношения между таблицами определяются с помощью primary key и foreign key.
В общем случае это неверное утверждение. От таблицы на стороне "один" не требуется наличия именно PRIMARY KEY, требуется только ограничение UNIQUE. Да, в 99% случаев используется именно PK, ибо он и накладывает ограничение уникальности, и присутствует в таблице намного чаще, чем UNIQUE INDEX.
Формально индекс требуется только для того, чтобы процесс проверки отношения был быстрым. Чисто теоретически и требование уникальности, и вообще требование наличия индекса - они избыточны, и введены именно из заботы о скорости работы. В подавляющем большинстве СУБД - как обязательные.
Foreign key – это столбец в таблице, который содержит primary key другой таблицы.
А вот это в корне неверно. Весьма частое заблуждение. Foreign key - это вообще не какая-то структура. Это правило. Правило, которое использует подсистема контроля целостности СУБД. Вот формулировка этого правила уже включает выражение, вычисленное на основании значений полей в текущей таблице, и ссылку на аналогичное выражение в другой таблице, а действие этого правила заключается именно в том, чтобы выражение в текущей таблице либо было NULL, либо присутствовало в списке значений выражения другой таблицы.
Индекс – это определенный столбец в таблице, по которому осуществляется поиск.
Ну вообще-то совсем не так. Индекс - это, во-первых, отдельная структура, а в случае некластерного индекса отдельная физически, во-вторых, вовсе необязательно по одному столбцу. Композитные индексы вообще обычное дело, да и индексы по выражению тоже не сказать что экзотика (если СУБД таковые поддерживает, конечно).
erogov
07.09.2022 08:32+3Вопрос на засыпку: может ли реляционная СУБД быть колоночной?
(Вполне может, потому что реляционность и детали физического хранения данных никак не связаны.)
sshikov
07.09.2022 20:13Не просто может, а бывает. Sybase IQ. И даже Oracle умеет в колоночное хранение. Это лишь два примера, что сразу пришли в голову.
erogov
07.09.2022 20:47+1Да их море. Но почему-то эта странная категория «колоночных баз» кочует из статьи в статью.
sshikov
07.09.2022 20:53Ну так и я об этом же. Более того, скажем Hive это какая база, колоночная или нет? Оказывается это зависит от того, в каком физически формате хранится таблица — Parquet колоночный, а Avro нет. То есть это вообще не свойство СУБД, если на то пошло.
hard_sign
08.09.2022 14:46Потому что переводчики никак не договорятся о терминах, а начинающие писатели не дают себе труда разобраться.
Есть модель данных – wide column store. Это Google BigTable, Cassandra, ScyllaDB. И это не реляционные бд, по функциональности они эквивалентны документо-ориентированным.
А есть устройство физического хранения – columnar store. Это Exasol, Greenplum, ClickHouse. Ну и конечно пионер этого движения – Vertica. И вот эти-то базы как раз реляционные.
А для русскозяычных писателей то и другое – «колоночные БД».
rmrfchik
07.09.2022 10:57+2Отношение это и есть таблица. В РСУБД (RDBMS), "реляционный/relation" означает "таблица".
Не "связи между таблицами", а "таблица".
В текстах про реляционные БД термин "отношение" лучше использовать именно как синоним "таблица", а не "связь между таблицами".
VasilichLift
07.09.2022 11:24+1Не хотелось бы пополнять армию "хейтеров". А мой комментарий явно покажет, что я в армии задротов уже давно. Но выскажу свое мнение не претендуя на глубокую экспертность.
Невозможно ввести человека в суть баз данных без четкого понимания математической базы которая легла в основу продукта, ставшего потом коммерческим, независимо от того возможно ли физически эту теорию воплотить в жизнь.
Невозможно понять декларативную природу SQL не владея логикой предикатов и базовыми знаниями теории множеств (а это очень важно - использование декларативного стиля написания это первый шаг к оптимизации запросов). Не понимая, природу деревьев, в частности B-дерева, невозможно рассуждать о преимуществах индексных структур, хотя на B-tree тоже свет клином не сошелся.
Опять же нельзя упустить, что колончатые базы, как правило, используются для доступа к данным через OLAP-ориентированные запросы к денормализованным структурам данным (отсылка к реляционной теории и нормализации) и почему в этом случае мы получаем максимальный эффект от колончатой природы хранения данных. Причем использование одного из диалектов SQL, по прежнему остается востребованным интерфейсом взаимодействия пользователя с структурами хранения данных в колончатых СУБД.
Я ни в коем случае не утверждаю, что статья не имеет права на жизнь, но я бы больше назвал ее "Введение в базы данных для менеджера", когда нам надо на пальцах объяснить нетехническому человеку, за что он должен заплатить деньги. Увы, как введение для начинающего разработчика, она пока не дотягивает, поскольку не отвечает на вопросы "как" и "почему". Как по мне для технарей описание дорожной карты процесса обучения было бы гораздо более полезным введением (с обоснованием по каждому пункту, почему он должен приложить усилия для приобретения предложенных знаний). Но это сугубо ИМХО.
sshikov
07.09.2022 20:12+1Я решила написать эту статью, потому что именно такой статьи мне очень не хватало несколько лет назад, когда я только начала карьеру в аналитике данных.
Однако же только на Хабре точно таких статей было больше одной.
EvgenichTalagaev
08.09.2022 01:54Здравствуйте, а не подскажите какие-нибудь книги по введению в бд для новичков?
smk
Спасибо за статью, люблю подобный материал - не очень много, но достаточно структурировано и очень доходчиво.
Касательно реляционных баз данных - я бы сравнил их с комбайном/мультитулом - в них можно сделать все тоже, что и в других базах данных, но работать оно будет в среднем похуже - медленнее, и логика сложнее. Так как на Mysql написано очень много проектов (особенно веб-), то используется достаточно часто. Как собственно и php.
Для других типов баз данных не хватает примеров, аналогично реляционным БД, для бОльшего понимания.
lola_kochieva Автор
Спасибо за отзыв)