В чем состоит отличие реляционных баз данных от неструктурированных файлов
Обновлено: 07.07.2024
Согласно рейтингу DB-Engines, в топе самых популярных СУБД четыре реляционных (SQL) и одна нереляционная (NoSQL). Реляционные базы данных занимают львиную долю рынка и наиболее известны. Однако в ряде случаев лучше выбрать NoSQL-решения различного типа.
Мы подготовили небольшой гайд по типам баз данных, чтобы вы могли принять верное решение.
Что такое реляционные и нереляционные базы данных
Реляционная база данных (SQL) — база, где данные хранятся в формате таблиц, они строго структурированы и связаны друг с другом. В таблице есть строки и столбцы, каждая строка представляет отдельную запись, а столбец — поле с назначенным ей типом данных. В каждой ячейке информация записана по шаблону.
Нереляционная база данных (NoSQL) — хранит данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях. В отличие от реляционных БД, NoSQL базы данных не поддерживают запросы SQL.
Реляционные базы данных, или базы данных SQL
Особенности. Основная особенность — надежность и неизменяемость данных, низкий риск потери информации. При обновлении данных их целостность гарантирована, они заменяются в одной таблице.
Реляционные базы данных, в отличие от нереляционных, соответствуют ACID — это требования к транзакционным системам. Соответствие им гарантирует сохранность данных и предсказуемость работы базы данных:
- Atomicity, или атомарность — ни одна транзакция не будет зафиксирована в системе частично.
- Consistency, или непротиворечивость — фиксируются только допустимые результаты транзакций.
- Isolation, или изолированность — на результат транзакции не влияют транзакции, проходящие параллельно ей.
- Durability, или долговечность — изменения в базе данных сохраняются несмотря на сбои или действия пользователей.
При работе с такими СУБД надо учитывать, что любые изменения в объектах нужно отражать в структуре таблиц, физическая структура данных не соответствует объектной модели приложения.
Реляционные БД идеальны для работы со структурированными данными, структура которых не подвержена частым изменениям.
Так выглядит хранение данных в реляционной базе, по сути, это просто таблица:
| Клиент | Средний чек | Число покупок за период |
| 1 | 1000 | 10 |
| 2 | 1500 | 5 |
| 3 | 800 | 6 |
Масштабируемость. Вертикальная, то есть при росте нагрузки растет производительность сервера. Если в базу поступает большой объем данных, рано или поздно наступит порог вертикального масштабирования — сервер не сможет далее увеличивать производительность. Тогда понадобится горизонтальное масштабирование — параллельная обработка данных в кластере серверов.
В больших распределенных системах это может привести к тому, что общая производительность системы упадет, так как нужно поддерживать согласованность данных в нескольких узлах. Это не значит, что СУБД на SQL не подходят для больших проектов — они поддерживают кластеризацию, просто нужно приложить усилия, чтобы настроить систему. Либо использовать базы данных в облаке — там можно получить уже настроенные и надежно работающие кластеры в несколько кликов.
Самые известные SQL-базы данных
MySQL — одна из самых популярных open source реляционных баз данных. Подходит небольшим и средним проектам, которым нужен недорогой и надежный инструмент работы с данными. Поддерживает множество типов таблиц, есть огромное количество плагинов и расширений, облегчающих работу с системой.
Отличается простой установкой, может быть интегрирована с другими СУБД, также интеграция с MySQL есть в любой CMS, фреймворке, языке программирования. Среди минусов — не все задачи выполняет автоматически, если что-то нужное не включено в функционал, придется потратить время на доработку, нет встроенной поддержки OLAP.
MySQL доступна как облачный сервис — в облаке не нужно тратить много времени на развертывание и конфигурацию СУБД. MySQL server стоит выбрать на старте бизнеса, чтобы тестировать гипотезы с минимальными затратами или для небольших проектов как транзакционную базу данных общего назначения.PostgreSQL — вторая по популярности open source SQL СУБД. У нее много встроенных функций и дополнений, в том числе для масштабирования в кластер и шардинга таблиц. Подходит, если важна сохранность данных, предполагается их сложная структура. Позволяет работать со структурированными данными, но поддерживает JSON/BSON, что дает некоторую гибкость в схеме данных.
Отличается стабильностью, ее практически невозможно вывести из строя или что-то сломать в таблицах.
Из минусов — сложность конфигурации требует от пользователей некоторого опыта. Также скорость работы может падать во время проведения пакетных операций или при запросах на чтение.
PostgreSQL также можно развернуть в облаке — в отличие от MySQL, она подходит для крупных и масштабных проектов. Кроме того, ее стоит выбрать, если недопустимы ошибки в данных или есть особые требования к базе данных, например поддержка геоданных. Различные расширения PostgreSQL позволяют реализовать многие специализированные запросы.
Нереляционные базы данных, или базы данных NoSQL
Особенности. В отличие от реляционных, в нереляционных базах данных схема данных является динамической и может меняться в любой момент времени. К данным сложнее получить доступ, то есть найти внутри базы что-то нужное — с таблицей это просто, достаточно знать координаты ячейки. Зато такие СУБД отличаются производительностью и скоростью. Физические объекты в NoSQL обычно можно хранить прямо в том виде, в котором с ними потом работает приложение.
Базы данных NoSQL подходят для хранения больших объемов неструктурированной информации, а также хороши для быстрой разработки и тестирования гипотез.
В них можно хранить данные любого типа и добавлять новые в процессе работы.
Масштабируемость. NoSQL базы имеют распределенную архитектуру, поэтому хорошо масштабируются горизонтально и отличаются высокой производительностью. Технологии NoSQL могут автоматически распределять данные по разным серверам. Это повышает скорость чтения данных в распределенной среде.
Четыре вида нереляционных баз данных
Документоориентированные базы данных — данные хранятся в коллекциях документов, обычно с использованием форматов JSON, XML или BSON. Одна запись может содержать столько данных, сколько нужно, в любом типе данных (или типах) — ограничений нет. Внутри одного документа есть внутренняя структура, однако, она может отличаться от одного документа к другому. Также документы можно вкладывать друг в друга.
То есть вместо столбцов и строк мы описываем все данные в одном документе. Если нам нужно было бы добавить новые данные в таблицу реляционной базы данных, пришлось бы изменять ее схему данных. В случае с документами нужно только добавить в них дополнительные пары ключ-значение.
Пример такой базы данных: MongoDB.
Вот так будет выглядеть хранение данных в отдельных документах вместо таблицы со столбцами и строками:
24 Дек 2020 05:20 IT GIRL 15 Реляционные vs. нереляционные базы данных: отличия и преимущества Блог 2020-12-24 ru Реляционные vs. нереляционные базы данных: отличия и преимуществаSQL vs NoSQL
Любые компьютерные вычисления связаны с обработкой данных. Они бывают структурированными и неструктурированными. Первые размещают в базах данных, где наравне с информацией хранится ее описание. Говоря о БД, часто можно встретить термины SQL и NoSQL.
SQL — это методика обработки (язык, структура, действия), которая используется для того, чтобы проводить чтение и обработку реляционных и нереляционных (NoSQL) баз данных. Как это все работает и для чего нужно — объясняют специалисты Boodet.Online.
Понятие реляционных и нереляционных баз данных
Термин « реляционный » пришел из алгебры (теория множеств). В формате БД это значит, что данные реляционных баз хранятся в виде таблиц и строк. Нереляционные БД размещают информацию в коллекциях документов JSON.
Реляционные БД используют язык SQL (структурированных запросов). Структура таких баз данных позволяет связывать информацию из разных таблиц с помощью внешних ключей (или индексов), которые используются для уникальной идентификации любого атомарного фрагмента данных в этой таблице. Другие таблицы могут ссылаться на этот внешний ключ, чтобы создать связь между частями данных и частью, на которую указывает внешний ключ.
Зачем нужны нереляционные БД ? Их главное преимущество — высокий уровень безопасности и возможность обойти аппаратные ограничения (с помощью Sharding).
Различия SQL и NoSQL
SQL и NoSQL — это термины, которые описывают совершенно разные способы обработки данных. Чем они отличаются и почему это влияет на работу?
SQL используют универсальный язык структурированных запросов для определения и обработки данных. Это накладывает определенные ограничения: прежде чем начать обработку, данные надо разместить внутри таблиц и описать.
NoSQL таких ограничений не имеет. Динамические схемы для неструктурированных данных позволяют:
ориентировать информацию на столбцы или документы;
основывать ее на графике;
организовывать в виде хранилища KeyValue;
создавать документы без предварительного определения их структуры, использовать разный синтаксис;
добавлять поля непосредственно в процессе обработки.
Структура
SQL основаны на таблицах, а NoSQL — на документах, парах ключ-значение, графовых БД, хранилищах с широкими столбцами.
Масштабируемость
В большинстве случаев базы данных SQL можно масштабировать по вертикали. Что это значит? Можно увеличить нагрузку на один сервер, увеличив таким образом ЦП, ОЗУ или объем накопителя.
В отличие от SQL базы данных NoSQL масштабируются по горизонтали. Это означает, что больший трафик обрабатывается путем разделения или добавления большего количества серверов. Это делает NoSQL удобнее при работе с большими или меняющимися наборами данных.
В каких случаях используют SQL?
SQL подойдет, если нужна обработка большого количества сложных запросов, или рутинного анализа данных. Выбирайте реляционную БД , если нужна надежная обработка транзакций и ссылочная целостность.
А в каких NoSQL?
Если объем данных большой, лучше использовать NoSQL . Отсутствие явных структурированных механизмов ускорит процесс обработки Big Data. А еще это безопаснее — такие БД сложнее взломать.
Выбирайте NoSQL , если:
необходимо хранить массивы в объектах JSON;
записи хранятся в коллекции с разными полями или атрибутами;
необходимо горизонтальное масштабирование.
Самые распространенные реляционные базы данных
Для работы с реляционными БД лучше всего подойдут:
Microsoft SQL Server.
MySQL
Бесплатный продукт с открытым исходным кодом от Oracle. Отличается стабильностью и хорошим тестированием обновлений до их внедрения. MySQL можно доработать под свои нужды или поискать готовые исправления в обширной библиотеке профильного сообщества.
Базу данных MySQL можно реплицировать на несколько узлов, что уменьшает рабочую нагрузку при увеличении доступности приложения.
Oracle
Oracle Database часто используют крупные корпорации. Коммерческий вариант БД часто и грамотно обновляется, есть круглосуточная техническая поддержка.
Oracle применяет свой собственный диалект SQL (PL/SQL). Это дает возможность работать со встроенными функциями, процедурами и переменными. Так же, как и MySQL , работает с любыми операционными системами. Если проекту необходимо использовать реляционные БД для работы с Big Data, то Oracle станет хорошей альтернативой NoSQL благодаря особой организации СУБД — группировке объектов по схемам, которые являются подмножеством объектов.
Еще одно важное преимущество Oracle — возможность восстановления предыдущей версии БД. Помимо этого, есть индексация растровых изображений, секционирование, индексацию на основе функций и по обратному ключу, оптимизация приоритетных запросов.
Microsoft SQL Server
Microsoft SQL Server — это отличный вариант для малого и среднего бизнеса. Диалект T-SQL обрабатывает процедуры, встроенные функции и переменные. Есть важное ограничение: Microsoft SQL Server будет работать только с Linux или Windows. Простой интерфейс ускорит процесс миграции БД, если до этого вы пользовались другой системой.
Нереляционные базы данных
Согласно рейтингу Boodet.Online, самыми удобными системами для обработки нереляционных баз данных являются: MongoDB, Apache Cassandra и Google Cloud BigTable. У всех трех широкий функционал и высокий уровень гибкости.
MongoDB
MongoDB — это качественный бесплатный продукт, который чаще всего используют при работе с NoSQL . Решение позволяет менять схемы данных в процессе работы, масштабироваться по горизонтали. Интерфейс очень простой — в нем легко разберется любой сотрудник компании, не обязательно быть IT-профессионалом.
Почему мы поставили Mongo на первое место в списке лидеров обработки нереляционных баз данных ? Все дело в новой функции от разработчиков. Теперь в решении есть глобальная облачная БД, что дает возможность развернуть управляемую MongoDB через AWS, Azure, GCP.
Apache Cassandra
Apache Cassandra — это продукт с открытым исходным кодом, а значит, достаточно гибкий, адаптируемый практически для любых задач. Идентичность узлов упрощает масштабирование для наращивания архитектуры БД.
Apache Cassandra подойдет для масштабных проектов. Продукт обеспечивает высокую скорость чтения и записи. Даже если часть решения использует SQL, можно применить подобные SQL операторы: DDL, DML, SELECT. Для более высокого уровня безопасности есть резервное копирование и восстановление.
Apache Cassandra — это один из немногих инструментов обработки баз данных, который гарантирует безотказность работы (подробнее читайте в своем SLA).
Google Cloud BigTable
Неплохой продукт от Google, который гарантирует задержку обработки не более 10 мс. BigTable уделяют безотказности много внимания. Например, благодаря функции репликации базы данных более долговечны, доступны и устойчивы при зональных сбоях. Это отличный вариант для работы с Big Data в режиме реального времени (машинное зрение, AI) — можно изолировать рабочую нагрузку для приоритетной аналитики.
Так что же лучше?
Специалисты Boodet.Online работают с обоими вариантами баз данных. Основной критерий выбора: подходит ли приложение для решения конкретной задачи. Как мы определяем, что лучше для конкретного проекта:
Если в БД есть предопределенная схема — используем SQL, если схема динамическая — NoSQL.
Выбираем приоритетное направление масштабирования — по горизонтали или по вертикали.
Определяем, что будет использоваться в задаче — неструктурированные данные или многострочные транзакции.
Выводы
Нельзя однозначно сказать, что лучше — SQL или NoSQL . Все зависит от конкретной задачи и типа данных. В некоторых случаях необходимо обработать оба типа БД — тогда рекомендуем выбирать гибридное решение, например, PostgreSQL (объектно-ориентированная СУБД).
Я знаю, что такие решения, как MySQL, PostgreSQL и MS SQL Server, являются реляционными системами баз данных и NoSQL, MongoDB и т. д. являются нереляционными СУБД.
однако, каковы различия между двумя типами систем ?
с точки зрения непрофессионала предпочтительнее.
реляционные базы данных имеют математическую основу (теория множеств, реляционная теория), которые перегоняются в SQL == структурированный язык запросов.
многие формы NoSQL (например, на основе документов, графов,объектов, хранилища ключей и т. д.) может основываться или не основываться на единой математической теории. Как правильно заметил С. Лотт,иерархические хранилища данных действительно имеют математическую основу. То же самое можно сказать и о график базы данных.
Я не знаю универсального языка запросов для баз данных NoSQL.
Хм, не совсем уверен, что ваш вопрос.
СУБД-это инструмент, который позволяет получить доступ к БД.
помимо самих данных, БД-это концепция того, как эти данные структурированы.
Так же, как вы можете программировать с ориентированным объектом методология с компилятором без OO или наоборот, поэтому вы можете настроить реляционную базу данных без СУБД или использовать СУБД для хранения нереляционных данных.
я сосредоточусь на том, что означает реляционная база данных (RDB), и оставлю обсуждение того, что системы делают с другими.
реляционная база данных (концепция) - это структура данных, которая позволяет связывать информацию из разных "таблиц" или разных типов ведер данных. Ведро сведения должны содержать называется ключом или индексом (что позволяет однозначно идентифицировать любой атомарный фрагмент данных в ведре). Другие ведра данных могут ссылаться на этот ключ, чтобы создать связь между их атомами данных и атомом, на который указывает ключ.
нереляционная база данных просто хранит данные без явных и структурированных механизмов для связи данных из разных ведер друг с другом.
Что касается реализации такой схемы, если у вас есть бумажный файл с индексом и в другой бумаге файл вы ссылаетесь на индекс, чтобы получить соответствующую информацию, затем вы реализовали реляционную базу данных, хотя и довольно простую. Таким образом, вы видите, что вам даже не нужен компьютер (конечно, он может стать утомительным очень быстро без помощи), точно так же вам не нужна РСУБД, хотя, возможно, РСУБД является правильным инструментом для работы. Тем не менее, есть варианты того, что могут сделать различные инструменты, поэтому выбор правильного инструмента для работы может быть не всем простой.
Я надеюсь, что это термины непрофессионала достаточно и полезно для вашего понимания.
большинство из того, что вы "знаете" - это неправильно.
прежде всего, как отмечают некоторые из реляционных гуру обычно (а иногда и резко), SQL на самом деле не так близко подходит к реляционной теории, как многие думают. Во-вторых, большинство различий в материале "NoSQL" относительно мало связано с тем, является ли он реляционным или нет. Наконец, довольно сложно сказать, как" NoSQL " отличается от SQL, потому что и представляют довольно широкий диапазон возможности.
одно главное отличие, на которое вы можете рассчитывать, заключается в том, что почти все, что поддерживает SQL, поддерживает такие вещи, как триггеры в самой базе данных, т. е. вы можете создавать правила в самой базе данных, которые предназначены для обеспечения внутренней согласованности данных. Например, вы можете настроить так, чтобы ваша база данных утверждала, что человек должны есть адрес. Если вы это сделаете, в любое время вы добавите человека, это в основном заставит вас ассоциировать человек с каким-то адресом. Вы можете добавить новый адрес или связать его с каким-то существующим адресом, но так или иначе у человека должен быть адрес. Аналогично, если вы удалите адрес, это заставит вас либо удалить всех людей, находящихся в данный момент по этому адресу, либо связать их с каким-либо другим адресом. Вы можете сделать то же самое для других отношений, например, сказать, что у каждого человека должна быть мать, у каждого офиса должен быть номер телефона и т. д.
обратите внимание, что эти виды вещей также гарантированно происходят атомарно, поэтому, если кто-то еще смотрит на базу данных, когда вы добавляете человека, они либо не увидят человека вообще, либо они увидят человека С адрес (или мать, etc.)
большинство баз данных NoSQL делают не попытка обеспечить такого рода принудительное исполнение в самой базе данных. Это зависит от вас, в коде, который использует базу данных, чтобы обеспечить любые отношения, необходимые для ваших данных. В большинстве случаев также можно увидеть данные, которые только частично верны, поэтому даже если у вас есть семейное древо, где каждый человек должен быть связан с родителями, могут быть случаи, когда любые ограничения, которые вы наложили, на самом деле не будут применяться. Некоторые позволят тебе делать это по желанию. Другие гарантируют, что это происходит только временно, хотя точно, как долго это может/будет длиться, может быть открытым для вопроса.
реляционная база данных использует формальную систему предикатов для адресных данных. Базовая физическая реализация не имеет сущности и может варьироваться для оптимизации для определенных операций, но она всегда должна предполагать реляционная модель. С точки зрения непрофессионала, это просто говорит Я точно знаю, сколько значений (атрибутов) каждая строка (Кортеж) в моей таблице (отношение) имеет, и теперь я хочу использовать этот факт соответственно, тщательно и до крайности. вот правда Природа зверя.
поскольку мы, очевидно, поколение, которое имело реляционное воспитание, если вы посмотрите на модели базы данных NoSQL с точки зрения реляционной модели, опять же в терминах непрофессионала, первое очевидное различие заключается в том, что никаких предположений о количестве значений, которые может содержать строка, никогда не делается. Это действительно упрощение вопроса и не относится к тонкостям физических моделей каждой базы данных NoSQL, но это вершина реляционной модели и первое предположение, которое мы должны оставить позади, или, если хотите, самый большой скачок, который мы должны сделать.
мы можем согласиться с двумя вещами, которые верны для каждой СУБД: он может хранить любые данные и имеет достаточную математическую основу, чтобы сделать возможным управление данными любым мыслимым способом. Реальность такова, что вы никогда не захотите совершить ошибку, поставив какую-либо из двух точек на тест, а просто придерживаться того, что на самом деле СУБД действительно создана. В непрофессиональных терминах:уважать зверя внутри!
(обратите внимание, что я избегал сравнения (очевидно) хорошо обоснованных стандартов, вращающихся вокруг реляционной модели, со многими вкусами, предоставляемыми базами данных NoSQL. Если вы хотите, рассмотрите базы данных NoSQL как зонтичный термин для любой СУБД, которая не полностью принимает реляционную модель, в исключении ко всему остальному. Различий слишком много, но это основные разница и то, что я думаю, было бы наиболее полезно для вас, чтобы понять эти два.)
попробуйте объяснить этот вопрос на уровне, относящемся к немного технологии
возьмите MongoDB и традиционный SQL для сравнения, представьте себе сценарий размещения твита в Twitter. Этот твит содержит 9 фотографий. Как вы храните этот твит и соответствующие фотографии?
С точки зрения традиционных отношений SQL, вы можете хранить твиты и изображения в отдельных таблицах и представлять соединение путем создания новой таблицы.
что более того, вы можете установить поле, которое является типом изображения, и zip 9 изображений в двоичный документ и сохранить его в этом поле.
используя MongoDB, вы можете создать такой документ (похожий на концепцию таблицы в реляционном SQL):
поэтому, на мой взгляд, основное различие заключается в том, как вы храните данные и уровень хранения отношений между ними.
в этом примере данные твит и фотографии. Этот различные механизмы об уровне хранения отношений между ними также играют важную роль в различии между ними.
Я надеюсь, что этот небольшой пример поможет показать разницу между SQL и NoSQL (ACID и BASE).
вот ссылка изображения о целях NoSQL из интернета:
разница между реляционными и нереляционными именно в этом. Архитектура реляционной базы данных предоставляет объекты ограничений, такие как первичные ключи, внешние ключи и т. д., что позволяет связать две или более таблиц в отношении. Это хорошо, так что мы нормализуем наши таблицы, то есть разделяем информацию о том, что представляет база данных на множество разных таблиц, один раз можем сохранить целостность данных.
например, скажем, у вас есть ряд таблиц, которые хранится информация о сотруднике. Невозможно удалить запись из таблицы, не удалив все записи, относящиеся к такой записи из других таблиц. Таким образом, вы реализуете целостность данных. Нереляционная база данных не предоставляет эти конструкции ограничений, которые позволят реализовать целостность данных.
Если вы не реализуете это ограничение в интерфейсном приложении, которое используется для заполнения таблиц баз данных, вы реализуете беспорядок, который можно сравнить с Диким Западом.
Хорошая Реализация Реляционных Баз Данных = Атомные Бункеры
Хорошая Реализация Нереляционных Баз Данных = Wild Wild West
в случае фатальной катастрофы (ошибка / ошибки) где бы Вы были более безопасны? Если бы моя жизнь зависела от данных, хранящихся в базе данных, я бы четко выбрал реляционную базу данных.
Я не нахожу никакого значения в kinkyness, я имею в виду, какой смысл изобретать колесо, которое уже круглое, и его вращение является пуленепробиваемым? Также поздравляю @Jerry Coffin за его ответ.
Давайте посмотрим на методы хранения традиционных баз данных и нереляционных баз данных.
Реляционная база данных
Проще говоря Реляционная база данных - это двухмерная таблица , И организация данных, состоящая из связей между ними.
Три преимущества реляционных баз данных:
Легко понять : Двухмерная структура таблицы - это концепция, очень близкая к логическому миру, а реляционная модель легче понять, чем другие модели, такие как сетка и иерархия.
Легко использовать : Общий язык SQL позволяет очень удобно работать с реляционными базами данных.
Легко поддерживать : Полная целостность (целостность объекта, ссылочная целостность и определяемая пользователем целостность) значительно снижает вероятность избыточности и несогласованности данных.
Три недостатка (узкое место) реляционных баз данных:
Высокие требования к одновременному чтению и записи : Параллелизм пользователей на веб-сайте очень высок, часто достигая десятков тысяч запросов на чтение и запись в секунду. Для традиционных реляционных баз данных ввод-вывод на жесткий диск является большим узким местом, и трудно добиться надежной согласованности данных. .
Производительность чтения и записи массивных данных низкая: количество данных, генерируемых веб-сайтом каждый день, огромно. Для базы данных запросы в таблице, содержащей большие данные, очень неэффективны.
Плохая масштабируемость и доступность : В веб-структуре базу данных сложнее всего (но может быть) масштабировать по горизонтали. Когда количество пользователей и посещений системы приложений увеличивается день ото дня, невозможно просто добавить базу данных, как веб-сервер и сервер приложений. Больше оборудования и сервисных узлов для увеличения производительности и нагрузки. Для многих веб-сайтов, которым необходимо обеспечивать круглосуточное бесперебойное обслуживание, очень болезненно обновлять и расширять систему баз данных, что часто требует простоя для обслуживания и миграции данных.
PS: Конечно, для веб-сайтов многие функции реляционных баз данных больше не нужны, такие как согласованность транзакций и чтение и запись в реальном времени. В реляционных базах данных основной причиной низкой производительности являются запросы, связанные с несколькими таблицами, и сложные запросы отчетов SQL со сложными типами анализа данных. Чтобы обеспечить характеристики ACID базы данных, мы должны сделать все возможное, чтобы спроектировать ее в соответствии с требуемой парадигмой.Таблицы в реляционной базе данных хранят отформатированную структуру данных.
Нереляционная база данных
Нереляционные базы данных основаны на хранилище пар ключ-значение , И структура не является фиксированной, каждый кортеж может иметь разные поля, и каждый кортеж может добавлять несколько пар ключ-значение по мере необходимости, так что он не будет ограничен фиксированной структурой, что может сократить некоторые временные и пространственные накладные расходы. . Таким образом, пользователи могут добавлять поля, которые им нужны, в соответствии с их потребностями. Таким образом, для получения различной пользовательской информации отпадает необходимость выполнять связанные запросы к нескольким таблицам, как в реляционной базе данных. Для завершения запроса нужно только получить соответствующее значение в соответствии с идентификатором.
Особенности нереляционных баз данных:
Обычно не поддерживает функции ACID, нет необходимости выполнять анализ SQL, высокая производительность чтения и записи
Формат хранения: ключевое значение, документ, изображение и т.д .; данные не связаны и легко расширяются.
но Нереляционные базы данных не могут предоставлять запросы для значений атрибутов полей, например, если это предусмотрено SQL. И сложно отразить целостность дизайна . Он подходит только для хранения относительно простых данных. Для данных, требующих более сложных запросов, очевидно, что база данных SQL больше подходит.
Классификация нереляционных баз данных, Согласно различным структурированным методам и приложениям, он в основном делится на следующие категории:
·· База данных ключ-значение для высокопроизводительного одновременного чтения и записи ：Redis,Tokyo Cabinet,Flare
·· Документно-ориентированная база данных для массового доступа к данным : MongoDB и CouchDB, могут быстро запрашивать данные в больших объемах данных.
·· Распределенная база данных, ориентированная на масштабируемость : Проблема, которую этот тип базы данных хочет решить, заключается в том, что традиционные базы данных имеют дефекты масштабируемости. Этот тип базы данных может адаптироваться к увеличению объема данных и изменениям в структуре данных.
Читайте также: