Понять, почему появляются новые виды баз данных
Когда я начал свой путь программирования, я достаточно подробно изучил многие языки, такие как Python, и веб-фреймворки, такие как Django. Меня мало интересовали базы данных и то, как они хранят информацию или почему у них есть определенные шаблоны проектирования.
Но со временем я понял, что очень важно понимать, что происходит за кулисами.
Когда я спрашиваю людей, почему они используют определенные системы баз данных на своем рабочем месте, они не имеют ни малейшего представления. Часто такие решения принимаются вышестоящими лицами.
Цель сегодняшнего информационного бюллетеня — рассказать вам, чем отличаются различные системы баз данных с точки зрения целей их использования.
🧠 Пища для размышлений! Почему мы должны ограничивать себя при работе с системами баз данных?
Я согласен, что это довольно сложные системы, но в более широком смысле это просто системы для хранения ваших данных, верно? Вам просто нужен наиболее эффективный способ хранения и извлечения данных. Тогда зачем ограничиваться реляционной БД или БД документов?
Должно ли каждое приложение использовать только один тип базы данных? Вопросы типа «Какая система баз данных является лучшей в 2022 году?» вообще разумно спрашивать?
Подумайте об этом! Вернитесь к этому после прочтения всей статьи
В одном из своих предыдущих выпусков я рассказал о нескольких методах оптимизации ваших запросов к базе данных. Но это только царапает поверхность. Он не говорил о шаблонах проектирования баз данных.
Почему разные базы данных?
Время от времени наши требования к данным меняются. Раньше данные не были огромными. Ценность сбора данных тогда еще не осознавалась. Кроме того, не было достаточно технологий для сбора этих данных.
Но со временем данные развивались и увеличивались в размерах. Сначала у нас были организованные базы данных, такие как SQL, позже у нас были базы данных, такие как MongoDB, для хранения беспорядочных и противоречивых данных. А в современном связанном мире у нас также есть базы данных графов, которые хороши для моделирования данных, которые сложным образом связаны друг с другом.
По сути, эта эволюция показывает, что вам нужно оптимизировать и выбирать механизм хранения или тип базы данных в зависимости от того, что вы хотите делать с данными (например, OLAP или OLTP).
Комментарий к документным и реляционным базам данных 💭
Реляционные базы данных
Реляционные БД долгое время были доминирующим игроком в мире баз данных. Она успешно защитила себя от других и была де-факто для большинства приложений, настолько, что это была первая и единственная технология баз данных, которую каждый изучил в своей технической карьере.
Что такое реляционные БД?
Реляционные базы данных располагают ваши данные в столбцах и строках, называемых таблицами.
Если необходимо добавить больше типов данных, вы можете разделить их на несколько таблиц, а затем связать их с помощью «ключей». Ключи — это идентификаторы, используемые для ссылки на определенную строку в другой таблице.
Этот способ организации данных называется ссылочной целостностью. Потому что данные редактируются не везде, а только один раз, где на них ссылаются. А поскольку он извлекается из указанной области, вам нужно обновить его только в одном месте
- Реляционные базы данных не так просто масштабировать. Я не говорю, что это невозможно. Facebook использует реляционные базы данных. Так что они могут масштабироваться. Но сделать это архитекторам непросто.
- Вот кейс Notion и то, как они сегментировали свои базы данных по мере расширения.
- Реляционные базы данных не очень хороши, если объем данных варьируется. В качестве примера рассмотрим модель, в которой вам нужно хранить сведения о кандидате, подающем заявку на работу.
- Кандидат мог работать в 10 разных компаниях или, может быть, только в 1. Или он мог пойти в 2 школы и 0 университетов, но мог пройти отличные курсы по Udemy. Такие данные не совсем идеальны для прикрепления к ним схемы и, следовательно, не очень подходят для реляционных баз данных.
- Кроме того, если данные имеют слишком много типов, создавать таблицы для каждого типа не идеально, так как соединения будут вызывать собственные накладные расходы на запись и чтение.
- Наличие схемы может накладывать ограничения. Реляционные БД имеют ограничения, связанные с ними. Например, если две таблицы имеют отношение внешнего ключа, удаление строки в одной таблице приведет к удалению связанной строки в связанной таблице.
- Так что это полезно в тех случаях, когда данные должны быть жесткими, но вам придется позаботиться о таких крайних случаях.
- Многоуровневые соединения могут замедлить ваши запросы. Когда вы запрашиваете информацию у нескольких таблиц, вы создаете соединения. Когда у вас есть многоуровневые соединения, подобные этому, запросы становятся все медленнее и медленнее. Если ваши API-интерфейсы работают медленнее, проверьте SQL-запросы, и вы, возможно, поймете, почему.
Итак, когда вы выберете реляционные базы данных?
- Если вы хотите абсолютной согласованности ваших данных,
- Вы знаете, что требования к данным не сильно изменятся в будущем
- Вы знаете, что сможете масштабировать его, когда придет время
Базы данных документов
Документные БД были введены для преодоления некоторых из этих ограничений, которые были у реляционных БД.
Что такое базы данных документов?
БД документов хранят информацию в документах, подобных JSON. Каждая строка в реляционных БД похожа на документ в БД документов. Самая популярная база данных документов — MongoDB. Это очень удобно для хранения динамических данных.
Это очень похоже на данные, с которыми работает ваше приложение. Таким образом, нет необходимости в ORM (объектно-реляционном отображении). Благодаря этому запросы выполняются быстро!
Если вы имеете дело с большими объемами данных, которые могут быть весьма динамичными по своей природе, тогда вам подойдет база данных документов.
Еще одно преимущество базы данных документов заключается в том, что запросы выполняются быстрее, если вы хотите получить доступ ко всему документу, по сравнению с реляционной базой данных, где вам нужно объединить несколько таблиц для доступа к одним и тем же данным.
Но у баз данных документов есть свои проблемы.
Во-первых, в нем нет поддержки объединений, что становится недостатком при объединении данных.
Короче говоря, если «связность» данных высока, то использовать базы данных документов сложно.
Базы данных документов хороши, когда речь идет об отношениях «один ко многим», но не тогда, когда речь идет об отношениях «многие к одному» или «многие ко многим». Нормализация данных в модели документа также непроста.
Итак, когда вы выберете базы данных документов?
- Если ваши данные будут беспорядочными и непоследовательными, управление схемой будет затруднено.
- Если ваш вариант использования включает доступ ко всем документам данных
- Если ваши точки данных автономны и не требуют слишком большого взаимодействия с другими типами данных.
Графические базы данных тоже удивительны!
В эпоху социальных сетей некоторые варианты использования могут быть неоптимальными при использовании традиционных подходов к базам данных.
Связность данных увеличилась во много раз. Количество параметров и точек данных (таких как цена, цвет продукта), связанных с каждым объектом (например, продуктом на сайте электронной коммерции), увеличилось.
Реляционные БД хороши для многих, но не в том случае, если их слишком много.
Вот тут-то и приходят на помощь графовые базы данных. Они довольно крутые, проверьте.
Давайте рассмотрим сценарий! 🖌
Итак, я хочу запросить следующее:
Fetch me all the friends of Rahul who are married and living in Delhi but also are a Python developer.
Ужас написания SQL-запроса для этого был бы невообразимым, и я пока не говорю о времени для запроса.
Здесь отлично работают базы данных Graph.
В графовой базе данных вы можете ответить на этот вопрос, если есть пути, соединяющие их.
На мой взгляд, графовые базы данных проще визуализировать и легче понять. По сути, это узлы, в которых хранятся данные и свойства, а также ребра, показывающие отношения между узлами.
Еда на вынос
Не существует универсального решения для всех. Если история является доказательством, то революционные способы хранения данных еще предстоит открыть.
Но главный вывод заключается в том, что вы должны глубоко понимать, какие данные хранит ваше приложение и как оно их извлекает. Если вы считаете, что какие-то данные в вашем приложении должны быть типом документа, то наличие двух баз данных в одном приложении также не является неправильным. Как гибридное решение!
Этой практике следуют многие крупные компании.
На этой неделе я хотел бы, чтобы вы взглянули на свои данные и спросили, хорошо ли они вписываются в вашу базу данных?
Want to Connect? Software Engineering Weekly is my weekly newsletter where I publish similar articles to make your software engineering journey easy. Subscribe to it for more!
