Что делает Cassandra (и NoSQL в целом) лучшим решением для СУБД?

Что ж, NoSQL сейчас модное слово, поэтому я изучал его. Мне еще предстоит разобраться в ColumnFamilies, SuperColumns и т. Д. Но я смотрел, как отображаются данные.

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

Users = {
    1: {
        username: "dave",
        password: "blahblah",
        dateReged: "1/1/1"
    },
    2: {
        username: "etc",
        password: "blahblah",
        dateReged: "2/1/1",
        comment: "this guy has a comment and dave doesns't"
    },
}

Формат СУБД будет:

Table name: "Users"

id | username | password | dateReged | comment
---+----------+----------+-----------+--------
 1 |  dave    | blahblah |  1/1/1    |
---+----------+----------+-----------+--------
 2 |  etc     | blahblah |  2/1/1    | this guy has a comment and dave doesn't

Если я понимаю это правильно и мои приведенные выше примеры верны, почему я должен предпочесть дизайн РСУБД дизайну NoSQL? Лично я предпочел бы работать со структурой JSON ... Значит ли это, что я должен предпочесть NoSQL, скажем, MySQL?

Думаю, я спрашиваю: «Когда мне выбрать NoSQL вместо СУБД?»

Кстати, как я уже сказал, я до сих пор не совсем понимаю, как реализовать базу данных Cassandra. Т.е. как мне создать указанную выше таблицу "Пользователи" в новой базе данных? Любые руководства, документация и т. Д., На которые вы могли бы указать, были бы замечательными. Мой гугл не очень сильно изменился с точки зрения "начинать с нуля" ...


person dave    schedule 09.09.2010    source источник
comment
Ваше время не могло быть лучше! См. bit.ly/bpuno1.   -  person D'Arcy Rittich    schedule 09.09.2010
comment
Я видел эту ссылку сегодня утром. Обязательно посмотрю, когда вернусь домой;)   -  person dave    schedule 09.09.2010
comment
возможный дубликат Почему nosql с кассандрой вместо mysql?   -  person Thilo    schedule 09.09.2010
comment
Что ж, очевидно, что NoSQL не является гарантированной победой во всех случаях - techcrunch.com/2010/09/07/digg-struggles-vp-engineering-door   -  person Justin    schedule 09.09.2010
comment
Возможный дубликат Что такое NoSQL , как это работает и какие преимущества дает?   -  person Trevor Boyd Smith    schedule 20.02.2017


Ответы (11)


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

РСУБД используют довольно глубокую магию для понимания данных, которыми они владеют, и данных, которые вы запрашиваете, таким образом, чтобы они могли возвращать эти данные наиболее эффективным способом. Если вы не спросили о каком-то столбце, rdbms не тратит усилий на его получение. Если вас интересуют строки, которые имеют общие поля в двух таблицах (это соединение, кстати), СУБД не обязательно проверять каждую пару строк на совпадения, или то, что обычно делает база данных NoSQL, просто дает вы все и заставляете вас проверять. с помощью реляционной СУБД вы обычно можете создавать запросы, которые на самом деле «о» данных, которые вы используете, например, «если дата вторник», и если ваши индексы поддерживают это (если вы выполняете этот запрос много раз, вы бы добавили такой index) вы можете эффективно получить эти строки.

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

person SingleNegationElimination    schedule 09.09.2010
comment
«Примечательно, что на одном узле NoSQL не дает абсолютно никаких преимуществ перед РСУБД. Однако реляционные СУБД обладают множеством преимуществ перед NoSQL. кто они такие?' - erm Нет. Один пример: время записи в MongoDB значительно быстрее, чем время записи на сервер MS SQL. Немного вводит в заблуждение утверждать, что преимуществ нет. Возможно, он не подходит для этой цели, но если вам нужна скорость, в этом есть преимущество. - person Michael Shimmins; 09.09.2010
comment
MongoDB не имеет схемы, это также большая разница для одного узла. - person TTT; 10.09.2010
comment
Да, без схем - другое дело. Вопрос действительно в том, почему это должно быть хорошо? Я немного подозрительно отношусь к установке без схемы. Теоретически это упрощает внесение изменений. На уровне базы данных это, безусловно, имеет место, вам не нужно зацикливаться на добавлении или удалении свойств на этом уровне. С другой стороны, это никоим образом не облегчает семантические последствия миграции базы данных. Как правильно поступать при обработке полей, которые могут быть нулевыми? Бестактность нисколько не смягчает этого. - person SingleNegationElimination; 12.09.2010

Главное преимущество NoSQL - горизонтальная масштабируемость и распределенное хранилище. Это означает, что вы можете иметь большое количество «узлов кластера» и писать на них параллельно. Кластер гарантирует, что изменения в конечном итоге распространятся на другие узлы кластера (конечная согласованность).

NoSQL - это не столько SQL (термин означает «не только SQL»). Фактически, некоторые продукты NoSQL действительно поддерживают подмножество SQL. Причина, по которой формат данных отличается (JSON или список пар свойство / значение по сравнению с табличными данными): в реляционных базах данных количество столбцов (и имена столбцов) определяется в центральном месте, что плохо работает с горизонтальными масштабируемость (вам нужно будет остановить все узлы кластера для изменения схемы). Кроме того, соединения не поддерживаются в такой степени, потому что это нарушит горизонтальную масштабируемость (данные из нескольких узлов кластера могут потребовать чтения, если данные распределены).

person Thomas Mueller    schedule 09.09.2010
comment
А Oracle, DB2, SqlServer, Teradata и т. Д. Не поддерживают кластеризацию ?? По крайней мере, не раньше 1992 года. - person James Anderson; 09.09.2010
comment
Они действительно поддерживают кластеризацию, но они также не поддерживают горизонтальную масштабируемость, потому что они пытаются поддерживать все свойства ACID. Продукты NoSQL не пытаются поддерживать все функции ACID. Некоторые говорят, что NoSQL на самом деле означает NoACID: dbmsmusings.blogspot.com/2010/08/ - person Thomas Mueller; 09.09.2010
comment
@ Томас Мюллер: Именно поэтому многие люди говорят, что NoSQL ПЛОХО. И он также не поддерживает объединения, и, тем самым, вызывает денормализацию и тем самым создает избыточность, которая (почти обязательно) приводит к проблемам согласованности данных. Плюс плохая согласованность в конечном итоге. Если сервер выйдет из строя, он должен был записать все данные на диск, когда он сказал, что это так. Когда он в конечном итоге фиксирует данные на диск (но говорит, что он был зафиксирован раньше), тогда произойдут плохие вещи ... - person Stefan Steiger; 01.04.2016
comment
@StefanSteiger, да. Иногда эти плохие вещи не кажутся такими уж плохими, по крайней мере, вначале, и горизонтальная масштабируемость воспринимается как более важная. А иногда людям просто нравится иметь NoSQL в своем резюме, потому что это круто :-) - person Thomas Mueller; 01.04.2016

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

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

Для некоторых веб-приложений вам может даже понадобиться комбинация обоих: базы данных nosql для некоторых типов информации, транзакционной реляционной базы данных для заказов и других вещей, где согласованность транзакций является обязательной.

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

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

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

person HLGEM    schedule 09.09.2010

Преимущество NoSql в том, что он проще, и если у вас есть ОО-шоры, он удовлетворяет все ваши потребности в постоянстве.

Преимущество реальной базы данных на основе SQL заключается в том, что вы можете легко повторно использовать и расширять свои данные способами, которые не были предусмотрены в исходном дизайне. Кроме того, «объектные» базы данных имеют тенденцию работать очень плохо (даже если это возможно), когда вы хотите выполнить эквивалент агрегированных запросов SQL, таких как COUNT, SUM, AVG.

Googles BIGTABLE, самая большая объектно-ориентированная база данных в мире (и, вероятно, самая большая база данных за период), также поддерживает функции SQL и sql, такие как индексация и строгая типизация.

person James Anderson    schedule 09.09.2010

РСУБД - это согласованность. Они отлично справляются с данными, которые часто сбрасываются с транзакциями. См. Также ACID (атомарность, последовательность, изоляция, долговечность). Иногда вам все это не нужно, например, при хранении данных из журналов или работе с данными, которые не собираются меняться, а просто накапливаются.

Базы данных NoSQL позволяют снизить требования к транзакциям и повысить производительность (а также упростить масштабирование до больших распределенных хранилищ данных).

person woolstar    schedule 09.09.2010

Ответ прост. Если вам нужно хранилище данных - используйте NoSQL, если вам нужно больше возможностей, чем просто хранение данных - используйте СУБД.

person Tommix    schedule 23.11.2014

Думаю, я спрашиваю: «Когда мне выбрать NoSQL вместо СУБД?»

[Предостережение: я никогда раньше не читал о NoSQL]

Согласно Wikipedia, NoSQL не очень хорош в объединениях: что подразумевает (для меня) отсутствие ссылочных целостность и отсутствие нормализации.

person ChrisW    schedule 09.09.2010
comment
Честно говоря, я плохо разбираюсь в SQL. Думаю, однажды я использовал ключевое слово JOIN. Только один раз. Такая потеря на меня не повлияет. - person dave; 09.09.2010
comment
@dave: Если вы не понимаете SQL (или, что более важно, его основы в реляционной алгебре), тогда, очевидно, решения SQL и NoSQL будут казаться очень похожими. На самом деле различия не начинают проявляться, пока у вас не будет много данных (и / или много транзакций). - person Daniel Pryden; 09.09.2010
comment
Соединения @dave связаны с нормализацией базы данных: изображения в правом поле этой статьи являются быстрым введением. - person ChrisW; 09.09.2010

Как упоминается во многих книгах о NoSQL, вопрос не в том, какая база данных лучше другой. Это больше то, что вам нужно.

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

например, Cassandra отлично подходит для добавления или удаления узлов из кластера, обеспечивая такую ​​высокую масштабируемость. Но когда вы сравниваете Cassandra с MySQL в среде с одним узлом (одним сервером) и без распределенной архитектуры, различий мало, поскольку не используются основные преимущества Cassandra.

Итак, почему вы должны использовать SQL? Самая частая причина - управление транзакциями. В настоящее время ни одна из популярных баз данных NoSQL изначально не поддерживает транзакции. Вы можете имитировать их, но они не являются частью встроенных функций, как в большинстве баз данных SQL.

Для Cassandra есть полное и бесплатное обучение на https://academy.datastax.com

Там вы не только найдете тренинги по установке и настройке Cassandra, но и по использованию ее инструментов. Он даже дает вам сертификаты об окончании.

У Datastax есть собственный дистрибутив Cassandra, но он следует тем же рекомендациям, что и проект Apache; он предлагает некоторые дополнительные инструменты.

person pfernandom    schedule 08.09.2014

Самый простой ответ, который я могу придумать, - это когда ваши данные не соответствуют реляционной модели.

person T3hc13h    schedule 09.09.2010
comment
Я видел несколько вещей, которые не вписываются в объектно-ориентированную модель, но еще не видел ничего, что нельзя было бы смоделировать в реляционной БД. - person James Anderson; 09.09.2010
comment
@James Anderson Иерархии (деревья) можно смоделировать в реляционной БД, но это немного сложно / особенно. - person ChrisW; 09.09.2010
comment
Вы, безусловно, МОЖЕТЕ моделировать что угодно в реляционной базе данных, но во многих случаях вам действительно нужно искажать свои данные. - person Nils Weinander; 09.09.2010
comment
@JamesAnderson, одна вещь, которую сложно смоделировать в реляционной базе данных, - это когда у вас есть разное количество столбцов для каждой точки данных, например, для медицинских тестов. Вы можете использовать для этого таблицу EAV, но если вы это сделаете, вам, вероятно, будет лучше использовать базу данных NoSQL, чтобы сделать то же самое быстрее. - person HLGEM; 30.04.2015

Я говорил на OSCON о том, когда NoSQL может быть правильным выбором, и о некоторых различных подкатегориях, о которых следует знать: http://assets.en.oreilly.com/1/event/45/The%20NoSQL%20Ecosystem%20Presentation.pdf

person jbellis    schedule 09.09.2010
comment
@jbelis: реляционные базы данных не масштабируются, реляционные базы данных работают медленно. Эти утверждения могут относиться к определенным продуктам СУБД. Они не имеют ничего общего с реляционной моделью. Было бы вполне разумно создать РСУБД NOSQL (то есть реляционную, а не SQL), которая не имела бы тех же предполагаемых недостатков. Как я часто наблюдал, энтузиасты NOSQL иногда кажутся чрезмерно стремящимися выбросить реляционного ребенка с водой в ванне SQL :) - person nvogel; 10.09.2010
comment
Странно, как существуют реляционные базы данных с триллионами записей, но люди до сих пор утверждают, что они не масштабируются. Они не масштабируются только тогда, когда вы некомпетентны в проектировании базы данных. - person HLGEM; 27.07.2011

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

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

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

Это не просто черно-белое.

person TomFH    schedule 15.01.2014