Как выбрать базу данных

Как выбрать базу данных в sql

Для выбора базы данных в SQL необходимо использовать команду USE :

USE database_name; 

где database_name — это имя базы данных, которую вы хотите выбрать.

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

USE mydatabase; 

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

Как новичку выбрать базу данных

На днях спросили у меня такую штуку и я написал страничку ответа. Потом подумал, дописал и вот готовый пост.

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

Никакой полноты изложения. Никаких крайних случаев. Никакого хайлоада. Господа профи, поберегите, пожалуйста, пуканы 😀

Базы бывают очень разные

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

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

Новичку всё это разнообразие не нужно. Ему важно быстрее запустить проект и меньше думать о базах — и так проблем хватает. Конечно, если не стоит задача изучить именно работу с базами.

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

И только вторым делом — о технических.

Эвристики здравого смысла

Используйте только популярные базы

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

Если разработчики БД уверяют, что именно их БД не надо настраивать и она гарантировано работает из коробки, то они врут. Есть исключения — облака, о них позже.

Если вы возьмёте в работу БД с малым количеством документации, с малым сообществом, то в какой-то момент вы рискуете остаться один на один с проблемой, которая убивает ваш проект и которую вы не можете решить самостоятельно с разумной тратой ресурсов.

Поэтому всегда смотрим на популярность БД. Оценить её можно разными способами:

• количество вопросов на stackoverflow.com;
• графики на trends.google.com/trends;
• звёздочки на github.com;
• размер страницы на wikipedia.org;
• в конце поста приведу очень краткий список, на случай если надо было выбрать вчера.

Используйте знакомые базы

Обычно задача разработки не звучит «создать проект с использованием БД X». Главное создать проект, а что внутри — важно чуть менее.

При этом, топовые базы по ключевым возможностям не сильно отличаются друг от друга: умеют хранить данные, умеют в какую-то надёжность, etc.

Поэтому, при прочих равных и при отсутствии необходимости выжать максимум из софта, хорошей стратегией будет брать базу с которой вы уже умеете работать. Это сэкономит много ресурсов.

Убедитесь, что база уже не выбрана

По аналогии с предыдущей эвристикой.

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

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

В этом случае хорошим ходом станет решение не разводить зоопарк.

Спросите профессионалов

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

Опишите проект (дальше будут подсказки как это сделать) и задайте вопрос знакомому или отправьте его в интернеты.

Купите консультацию

Тоже не зазорно. Особенно, если с деньгами нет проблем.

Не надейтесь на авось.

Особенно, если от работоспособности проекта зависит что-то существенное: жизни людей, работа дорогого оборудования, ваша карьера 🙂

Если от вашего решения зависят жизни людей и вы недостаточно компетентны для его принятия, заплатите тому, кто компетентен.

Используйте Open Source решения

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

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

Бизнес корпоративного ПО почти всегда работает по принципу «подсадить и доить». Если в начале разработки вас устраивает текущий план оплаты, убедитесь что вас будет устраивать и 2-3 его следующих ступени.

Масштабировать железо для open source базы может оказаться значительно дешевле, чем для корпоративной.

Ну и в целом, поддерживайте open souce — это наша защита от антиутопического будущего.

Если есть деньги, идите в облака

Если убрать стоимость конфигурации, то облачная инфраструктура, навскидку, в 3-5 раз дороже чем хостинг на выделенном сервере. По крайней мере в неумелых руках.

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

Это как раз тот случай, когда можно поверить разработчикам БД, что та не требует настройки. Как и можно не сильно бояться завязаться на вендора — на текущий момент облачные решения близки по фунциональности к своим open source родителям.

Но помните: чтобы не завязаться жёстко на конкретное облако, тоже думать надо и архитектуру под это прорабатывать.

Технические эвристики

Тоже без сортировки. Считайте это списком вопросов, на которые надо обязательно ответить перед выбором базы данных. Равно как и перед задаванием вопросов профессионалам.

Обладают ли ваши данные специфическими свойствами?

Есть типы данных, которые очень отличаются от других и, по сути, определяют какие типы баз для них нужны. Например:

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

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

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

Объекты с какой структурой будут храниться в БД?

Если структура объектов фиксирована и известна, то скорее всего удобнее будет использовать реляционные БД.

Если структура объектов сложная, может часто меняться, не известна полностью, то может быть удобнее использовать документо-ориентированные БД.

Если между объектами предполагаются сложные связи, если информация о связях не должна разрушаться, должна быть надёжной, то с большей вероятностью вам подойдёт реляцонная БД. Если наоборот — документо-ориентированная.

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

Насколько сложные запросы предполагаются?

Чем больше коллекций объектов и связей между объектами предполагается включать в один запрос к базе, тем с большей вероятностью лучше будет взять реляционную БД.

Или графовую базу, если всё совсем плохо и не формализировано.

Какие гарантии надёжности нужны?

Если для вас это основной критерий, платите эксперту.

Чем взрослее БД, тем она надёжнее —взрослые БД больше отлаживали, больше ошибок в них исправлено.

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

Какие гарантии ACID нужны?

1. Читаете статью на вики про ACID.
2. Смотрите как на эти понятия ложится ваш проект.
3. Читаете документацию базы и смотрите подходят ли её гарантии для вашего случая.

Какой объём данных будет храниться?

Если небольшой или средний (допустим, до терабайта), то обычно это не главный критерий.

Если больше, надо смотреть и тестировать конкретные use cases с конкретными базами.

Какая нагрузка на базу ожидается?

Опять таки, если небольшая, то это не основной критерий для выбора базы.

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

Могу предложить два подхода к оценке:

• Если становится страшно, когда думаете о нагрузке, значит она большая 😀
• Поставьте эксперимент: разверните базу, наполните данными, эмулируйте нагрузку и посмотрите как грузится железо и как быстро отвечает база.

Если ожидается большая нагрузка, то либо ставьте эскперементы с каждой базой-кандидатом, либо платите эксперту.

Какой тип доступа к данным предполагается?

Как продолжение предыдущего вопроса.

Чего будет больше: чтения или записи?

Есть базы заточенные на чтение данных и медленную запись. Есть, наоборот, на быструю запись и медленное чтение. Есть те, что можно оптимизировать в обе стороны.

Обращение ко всем данным будет с равной вероятностью или будут данные, с которыми будут работать значительно больше, чем с остальными?

Достаточно ли будет запустить базу на одной машине?

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

Ответ на этот вопрос, по сути, зависит от ответов на все вопросы о данных и нагрузке.

Какие средства есть для организации миграций?

Подробно про миграции я писал:

• О миграциях backend
• Миграции backend на практике

Ставьте эксперименты

Если сомневаетесь в определении пригодности базы по какому-либо критерию и считаете его важным для проекта — ставьте эксперименты.

Лучше потратить неделю на проверку решения, чем выкинуть полгода работы.

Не выбирайте встраиваемые базы данных

Если не уверены на 100% в том, что делаете.

Есть класс баз данных, ориентированных не встраивание в другое ПО (и на очень простые веб проекты). Это отличные базы, но если вы используете их для веба, то можете столкнуться с большими сложностями в масштабировании. Например, не сможете поднять второй процесс веб-сервера для ускорения обработки запросов.

Особо выделю SQLite. Это отличная база, её часто и справедливо рекомендуют для обучения. Но то, что удобно для обучения, далеко не всегда удобно для практики.

Если сомневаетесь, берите реляционную БД

Если до конца не ясно что выгоднее: документо-ориентированная или реляционная БД, берите реляционную.

Популярные реляционные БД давно неплохо умеют работать с документами, обычно в формате JSON, поэтому поверх их всегда можно сделать хранилище документов нормального качества. Обратное про документо-ориентированные базы, к сожалению, сказать нельзя.

Подумайте насколько удобно вам будет работать с базой

Ничто не даётся бесплатно. Чем больше может база, тем сложнее с ней может быть работать: делать запросы, мигрировать данные и схемы.

Вы можете выиграть в надёжности, но сильно потерять в скорости разработки.

Обычно, реляционные БД сложнее в обращении, чем документо-ориентированные.

Очень краткий алгоритм выбора базы

1. Если от проекта зависят жизни или большие деньги, нанимаем эксперта.
2. Если что-то уже используется, в первую очередь рассматриваем это.
3. Если команда умеет работать с конкретной базой, в первую очередь рассматриваем её.
4. Если данные специфические, ищем популярную специфическую базу.
5. Если структура данных не формализирована и часто меняется, берём популярную документо-ориентированную базу.
6. Если структура данных формализирована, редко меняется или работа с данными требует повышенных гарантий, используем популярную реляционную БД.

Краткий список популярных баз

Хороших баз много и лучше выбрать самому, но если очень горит, то вот:

• Реляционные: PostgreSQL, MariaDB
• Докуменнто-ориентированные: MongoDB
• Графовые: Neo4j

Похожее:

1. О миграциях backend
2. Миграции backend на практике
3. Бесконечность схем данных
4. Экзокортекс: метаинформация
5. Тарантога: модель данных
6. Экзокортекс: минимальная функциональность

Нравится блог?
Делитесь постами с друзьями!

• Paul Graham: Superlinear returns
• Используем DALL-E-3 для геймдева
• Концепт-документ шоу настольной ролевой MMO игры
• Feeds Fun — читалка новостей с тегами и ChatGPT
• РПГ победившего маркетинга
• Истина где-то рядом
• Open source сервисы аутентификации
• Эксперименты с Тарантогой закончены
• Два примера overengineering из FastAPI
• Глупые прогнозы об Искусственном Интеллекте
• Пара слов о GitHub Сopilot
• Делаем простой ИИ тамагочи на ChatGPT
• Итоги 2022 года для меня и блога
• OpenAI Chat для геймдева
• Рим: суета, реновация, мошенники
• Будапешт: бани, гуляш, булки
• Используем DALL-E для геймдева
• Как завалить собес у меня
• Концепт-документ игры Space Opera Engine
• Как новичку выбрать базу данных

Как выбрать систему управления базами данных: сравнение лучших СУБД

Перед разработкой проектов любых масштабов всегда встает вопрос: «А какую СУБД мне выбрать?». И это неудивительно, ведь вариантов довольно много, а запутаться в них может даже профессионал. Чтобы понять, какую систему управления базами данных выбрать, следует учитывать ряд критериев и тип программного обеспечения.

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

Критерии выбора

Под критериями подразумеваются важные параметры, которые влияют на выбор СУБД. Например, в первую очередь следует понять, для какого проекта подбирается ПО. Затем нужно ответить на вопрос «Какие данные будут храниться в СУБД?». И так далее. Как только вы определитесь с четкими критериями, вам станет проще ориентироваться в обилии программного обеспечения.

Тип проекта

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

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

Что будет храниться в базе данных

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

Объем хранилища

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

Тип базы данных

База данных может быть серверная или файловая – это важное условие, которое следует учитывать при выборе системы. Первый подходит для работы по сети, второй – для локальных задач. Если вам нужно, чтобы БД была вместе с приложением без установки дополнительного ПО, то стоит выбрать файловую систему. Отличный тому пример – SQLite.

Нагрузка и масштабируемость

Еще один критерий – требуемая нагрузка. Здесь следует ответить на вопрос: «Сколько пользователей будут одновременно работать с базой данных?». Также важно заранее предусмотреть масштабируемость. Учитывайте, что постоянно увеличивать ОЗУ, процессор и другие параметры не получится. Поэтому выбирайте СУБД с прицелом на способность переносить текущие и двукратно увеличенные нагрузки.

Безопасность и отказоустойчивость

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

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

Стоимость

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

Однако есть еще вариант open source – он подойдет для коммерческих проектов с ограниченным бюджетом. Такие системы надежные, но их поддержкой придется заниматься самостоятельно.

Поддержка и администрирование

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

Со стороны администрирования следует учитывать, что бывают сложные СУБД. Например, для работы с Oracle Database требуется особая квалификация. Для таких систем нужен отдельный специалист, а значит – дополнительные вложения. Если есть ограничения по бюджету, то лучше оставить свой выбор на простой СУБД, например, SQLite.

Читайте также

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Основные типы СУБД с примерами

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

Реляционные

Этот тип СУБД основан на принципах реляционной модели данных, в которой вся информация представлена в виде таблиц, состоящих из строк и столбцов. Реляционная СУБД позволяет осуществлять различные манипуляции с данными: добавление, удаление, изменение и поиск с использованием языка запросов SQL.

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

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

Примеры СУБД:

• Oracle Database – позволяет управлять большим объемом данных, обеспечивать высокую производительность и надежность при работе с БД. Oracle Database включает множество функций: поддержку многопоточной обработки, масштабирование баз данных, защиту информации и автоматическое управление ресурсами.
• MySQL – одна из самых популярных и распространенных СУБД в мире, используемых в таких отраслях, как веб-разработка, бизнес-аналитика и других.
• SQLite – предназначена для использования в приложениях, которые требуют локального хранения данных. Эта СУБД обеспечивает быстрый доступ к информации и поддерживает стандарт SQL для выполнения запросов и управления БД.

Документная

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

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

Примеры СУБД:

• MongoDB – позволяет использовать данные в формате JSON-подобных документов. MongoDB отличается гибкостью и масштабируемостью, благодаря чему можно обрабатывать большие объемы данных.
• Couchbase – предназначена для хранения крупных файлов. Использует технологию распределенного кэширования, которая позволяет быстро получать доступ к данным в режиме реального времени. Также Couchbase обеспечивает поддержку множества протоколов – HTTP, JSON, REST и многих других.

Графовые

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

Примеры СУБД:

• Neo4j – база данных с открытым исходным кодом. Использует язык запросов Cypher.
• Amazon Neptune – предоставляет полностью управляемую среду. Это позволяет системе легко масштабироваться и иметь высокую доступность данных.
• InfiniteGraph – была создана для хранения и обработки больших графовых структур, которые могут содержать миллионы объектов и связей между ними.

Ключ-значение

Ключ-значение (от англ. Key-Value) – это один из типов нереляционных баз данных NoSQL. Такие СУБД выглядят как системы хранения данных, где каждый элемент данных представлен парой ключ-значение.

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

Примеры СУБД:

• Redis – работает в оперативной памяти и способна обрабатывать огромные объемы данных за очень короткое время благодаря своей высокой производительности. Redis поддерживает множество типов данных: строки, списки, хэши, множества и упорядоченные множества.
• Amazon DynamoDB – полностью управляемая NoSQL база данных, разработанная Amazon Web Services. Она предназначена для обработки любого объема данных и обеспечивает быстродействие в масштабах от миллисекунд до миллиардов запросов в день.

Колоночные

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

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

Примеры СУБД:

• ClickHouse – СУБД от Яндекса с открытым исходным кодом. Она специализируется на аналитических задачах и предназначена для обработки больших объемов данных. ClickHouse способна обрабатывать миллиарды строк данных за секунды благодаря своей архитектуре и оптимизации под различные запросы.
• InfoBright – специально создана для аналитических работ: OLAP (Online Analytical Processing) и BI (Business Intelligence). Использует уникальный метод сжатия данных, что позволяет сократить объем хранимой информации без потери качества.
• Cassandra – подходит для обработки больших объемов данных в режиме реального времени. В Cassandra применяется модель NoSQL и распределенный алгоритм хранения данных, который обеспечивает быстрый доступ к информации.

Заключение

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

7 типов современных баз данных: предназначение, достоинства и недостатки

Какую базу данных выбрать для проекта, чтобы работа была эффективной? Разбор достоинств и недостатков, а также примеры разных типов БД.

Артём Гогин
руководитель направления в хранилище данных в Сбербанке

Существуют сотни баз данных SQL и NoSQL. Одни популярны, другие игнорируются. Некоторые просты и хорошо документированы, а некоторые сложны в использовании. Одни имеют открытый код, а другие проприетарные. Что, возможно, наиболее важно, некоторые масштабируемы, оптимизированы, высокодоступны, а некоторые сложно масштабировать или поддерживать.

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

1. Нужен ли нам аналитический доступ к базе данных?
2. Нужно ли нам писать или читать в реальном времени?
3. Сколько таблиц / записей мы хотим сохранить?
4. Какая доступность нам нужна?
5. Нужны ли нам столбцы?
6. Сможем ли мы получить доступ к таблицам, отфильтрованным по столбцам или по строкам?

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

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

Если вы когда-либо работали с базами данных, скорее всего, вы начали с этого типа, потому что он самый популярный и распространенный. Такие БД позволяют хранить данные в реляционных таблицах с определенными столбцами определенного типа. Реляционные таблицы хороши для нормализации и объединения.

• Поддержка SQL
• ACID-транзакции (атомарность, согласованность, изоляция и долговечность)
• Поддержка индексации и разделения

• Плохая поддержка неструктурированных данных / сложных типов
• Плохая оптимизация обработки событий
• Сложное / дорогое масштабирование

Примеры: Oracle DB, MySQL, PostgreSQL.

Документно-ориентированные базы данных

Если мы не хотим объединять несколько таблиц для получения нужных данных, мы можем взглянуть на документно-ориентированные базы данных. Они позволяют хранить записи в формате JSON. В этом формате мы можем создать сложное значение для любого ключа и сразу включить всю структуру данных в одну запись.

• Нет привязки к схеме
• Нет необходимости всегда писать все поля в каждой записи
• Хорошая поддержка сложных типов
• Подходит для OLTP

• Плохая поддержка транзакций
• Слабая аналитическая поддержка
• Сложное / дорогое масштабирование

Базы данных в оперативной памяти

Базы данных этого типа могут предоставлять в реальном времени ответ для выбора и вставки определенных записей. Большинство из них в основном хранят данные в ОЗУ, но в некоторых случаях они также предлагают постоянное хранилище на жестких дисках или твердотельных накопителях. Большинство этих баз данных работают с записями «ключ-значение», поэтому значения можно запоминать в формате, ориентированном на документы. Но некоторые базы данных также работают со столбцами и позволяют вторичное индексирование той же таблицы. Использование ОЗУ позволяет обрабатывать данные быстро, но делает их более нестабильными и дорогостоящими.

• Быстрое написание
• Быстрое чтение

• Труднодостижимая надёжность
• Дорогое масштабирование

Примеры: Redis, Tarantool, Apache Ignite.

Базы данных с широкими столбцами

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

• Быстрая запись построчно
• Быстрое чтение по ключу
• Хорошая масштабируемость
• Высокая доступность

• Формат «ключ-значение»
• Нет поддержки аналитики

Примеры: Cassandra, HBase.

Столбчатые базы данных

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

• Быстрое чтение столбец за столбцом
• Хорошая аналитическая поддержка
• Хорошая масштабируемость

• Подходит только для пакетных вставок

Примеры: Vertica, Clickhouse.

Поисковая система

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

• Быстрый доступ по любому слову
• Хорошая масштабируемость

• Подходит только для пакетных вставок
• Плохая аналитическая поддержка

Графовые базы данных

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

• Структура данных графа
• Управляемые отношения между сущностями
• Гибкие конструкции

• Специальный язык запросов
• Трудно масштабировать

Выводы

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

На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

Если вы готовитесь к собеседованию, посмотрите также статью, в которой собраны 27 распространённых вопросов по SQL и ответы на них.

Следите за новыми постами по любимым темам

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