В чем разница между NoSQL и базой данных, ориентированной на столбцы?
Чем больше я читаю о NoSQL, тем больше он начинает звучать для меня как база данных, ориентированная на столбцы.
В чем разница между NoSQL (например, CouchDB, Cassandra, MongoDB) и базой данных, ориентированной на столбцы (например, Vertica, MonetDB)?
7 ответов
NoSQL - это термин, используемый не только для SQL, который охватывает четыре основные категории - базы данных Key-Value, Document, Column Family и Graph.
Базы данныхключ-значение хорошо подходят для приложений, которые часто выполняют небольшие операции чтения и записи вместе с простыми моделями данных. Эти записи хранятся и извлекаются с использованием ключа, который однозначно идентифицирует запись и используется для быстрого поиска данных в базе данных.
например, Redis, Riak и т. д.
Базы данных документов могут хранить различные атрибуты вместе с большими объемами данных.
например, MongoDB, CouchDB и т. д.
Базы данныхсемейства столбцов предназначены для больших объемов данных, производительности чтения и записи и высокой доступности.
например, Кассандра, HBase и т. д.
Графовая база данных - это база данных, которая использует графовые структуры для семантических запросов с узлами, ребрами и свойствами для представления и хранения данных.
например, Neo4j, InfiniteGraph и т. д.
Прежде чем понимать NoSQL, вы должны понять некоторые ключевые понятия.
Согласованность - все серверы в системе будут иметь одинаковые данные, поэтому любой, использующий систему, получит одну и ту же копию независимо от того, какой сервер ответит на их запрос.
Доступность - система всегда будет отвечать на запрос (даже если это не самые последние данные или непоследовательные данные в системе или просто сообщение о том, что система не работает).
Допуск раздела - система продолжает работать в целом, даже если отдельные серверы выходят из строя или недоступны.
В большинстве случаев базы данных NoSQL удовлетворяют только двум из трех свойств.
Из вашего вопроса,
CouchDB: AP (доступность и раздел) и база данных документов
Cassandra: AP (доступность и раздел) и база данных семейства колонок
MongoDB: CP (согласованность и разбиение) и база данных документов
Vertica: CA (согласованность и доступность) и база данных семейства колонок
MonetDB: ACID (долговечность изоляции согласованности атомарности) и реляционная база данных
От: http://blog.nahurst.com/visual-guide-to-nosql-systems
Взгляните на эту статью1, статью2 и ppt для различных сценариев, чтобы выбрать конкретный тип базы данных.
Некоторые базы данных NoSQL ориентированы на столбцы, а некоторые базы данных SQL также ориентированы на столбцы. Независимо от того, является ли база данных ориентированной на столбцы или строки, это физическая деталь реализации базы данных и может быть верной как для реляционных, так и для нереляционных (NoSQL) баз данных.
Например, Vertica - это реляционная база данных, ориентированная на столбцы, поэтому она фактически не может считаться хранилищем данных NoSQL.
Хранилище данных с "движением NoSQL" лучше определить как нереляционную, горизонтально-масштабируемую базу данных без разделения ресурсов без (обязательно) гарантий ACID. Некоторые ориентированные на столбцы базы данных можно охарактеризовать таким образом. Помимо хранилищ столбцов, реализации NoSQL также включают хранилища документов, хранилища объектов, хранилища кортежей и хранилища графиков.
База данных NoSQL - это парадигма, отличная от традиционных баз данных на основе схем. Они предназначены для масштабирования и хранения документов, таких как данные JSON. Очевидно, у них есть способ запроса информации, но вы должны ожидать синтаксиса для получения данных, например, eval("person = * and age > 10). Даже если они поддерживают стандартный интерфейс SQL, они предназначены для чего-то другого, так что если вам нравится SQL Вы должны придерживаться традиционных баз данных.
База данных, ориентированная на столбцы, отличается от традиционных баз данных, ориентированных на строки, тем, как они хранят данные. Храня целый столбец вместе вместо строки, вы можете минимизировать доступ к диску при выборе нескольких столбцов из строки, содержащей много столбцов. В ориентированных на строки базах данных нет разницы, если вы выбираете только одно или все поля из строки.
Вы должны заплатить за более дорогую вставку все же. Вставка новой строки вызовет много дисковых операций, в зависимости от количества столбцов.
Но нет никакой разницы с традиционными базами данных с точки зрения SQL, ACID, внешних ключей и тому подобного.
Я бы посоветовал прочитать раздел таксономии статьи NoSQL в Википедии, чтобы понять, насколько разные базы данных NoSQL отличаются от традиционных баз данных, ориентированных на схему. Ориентация на столбцы подразумевает строки и столбцы, что подразумевает (двумерную) схему, в то время как базы данных NoSQL, как правило, не содержат схем (хранилища значений ключей) или имеют структурированное содержимое, но без формальной схемы (хранилища документов).
Для хранилищ документов структура и содержимое каждого "документа" не зависят от других документов в той же "коллекции". Добавление поля обычно является изменением кода, а не изменением базы данных: новые документы получают запись для нового поля, в то время как более старые документы считаются нулевыми для несуществующего поля. Точно так же, "удаление" поля может означать, что вы просто перестанете ссылаться на него в своем коде, а не будете пытаться удалить его из каждого документа (если только пространство не слишком дорого, и тогда у вас есть возможность удалить только те, самое большое содержание). Сравните это с тем, как нужно изменить всю таблицу, чтобы добавить или удалить столбец в традиционной базе данных строк / столбцов.
Документы также могут содержать списки и другие вложенные документы. Вот пример документа из MongoDB (пост из блога или другого форума), представленный в формате JSON:
{
_id : ObjectId("4e77bb3b8a3e000000004f7a"),
when : Date("2011-09-19T02:10:11.3Z"),
author : "alex",
title : "No Free Lunch",
text : "This is the text of the post. It could be very long.",
tags : [ "business", "ramblings" ],
votes : 5,
voters : [ "jane", "joe", "spencer", "phyllis", "li" ],
comments : [
{ who : "jane", when : Date("2011-09-19T04:00:10.112Z"),
comment : "I agree." },
{ who : "meghan", when : Date("2011-09-20T14:36:06.958Z"),
comment : "You must be joking. etc etc ..." }
]
}
Обратите внимание, что "комментарии" - это список вложенных документов с собственной независимой структурой. Запросы могут "проникать" в эти документы из внешнего документа, например, для поиска сообщений с комментариями Джейн или сообщений с комментариями из определенного диапазона дат.
Короче говоря, два основных различия, типичных для баз данных NoSQL, заключаются в отсутствии (формальной) схемы и содержимого, которые выходят за рамки двумерной ориентации традиционной базы данных строк / столбцов.
Различение между магазинами coloumn Читайте этот блог. Это отвечает на ваш вопрос.
Как писал @tuinstoel, статья отвечает на ваш вопрос в пункте 3:
3. Интерфейс. Группа A отличается тем, что является частью движения NoSQL и обычно не имеет традиционного интерфейса SQL. Группа B поддерживает стандартные интерфейсы SQL.
Вот как я это вижу: базы данных, ориентированные на столбцы, имеют дело с тем, как данные физически хранятся на диске. Как следует из названия, каждый столбец хранится в отдельном пространстве / файле. Это позволяет сделать 2 важные вещи:
- Вы достигаете лучшей степени сжатия порядка 10:1, потому что у вас есть один тип данных для работы.
- Вы достигаете лучшей производительности чтения данных, потому что вы избегаете сканирования всей строки и можете просто выбирать столбцы, указанные в вашем запросе SELECT.
С другой стороны, NoSQL - это совершенно новое поколение баз данных, которые определяют "логические" совокупные уровни для объяснения данных. Некоторые рассматривают данные как имеющие иерархические отношения (агрегат является "узлом"), в то время как другие рассматривают данные как документы (что является совокупным уровнем). Они не определяют физическую стратегию хранения (некоторые могут это делать, но абстрагируются от конечного пользователя).
Кроме того, все движение NoSQL больше связано с неструктурированными данными, или, вернее, наборами данных, схема которых не может быть заранее определена или заранее неизвестна и, следовательно, не может соответствовать строгой реляционной модели.
Колонно-ориентированные базы данных по-прежнему работают с реляционными данными, хотя устраняют необходимость в индексе и т. Д.