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

Question

Ну, сейчас 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

Предполагая, что я правильно понимаю, и приведенные выше примеры верны, с какой стати я выбрал бы дизайн RDBMS вместо дизайна NoSQL? Лично я предпочел бы работать со структурой JSON ... Значит ли это, что я должен выбрать NoSQL, скажем, MySQL?

Полагаю, я спрашиваю: «Когда мне выбрать NoSQL вместо RDBMS?»

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

RDBMS '- это все о последовательности. Они отлично справляются с данными, которые часто подвергаются транзакциям. См. Также КИСЛОТА (атомарность, консистенция, изоляция, долговечность). Иногда вам не нужно все это, например, при хранении данных из журналов или работе с данными, которые не будут меняться, просто накапливайте.

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

Для Кассандры существует полное и бесплатное обучение по https://academy.datastax.com

Там вы найдете не только тренинги по установке и настройке Cassandra, но и использование ее инструментов. Это даже дает вам сертификаты завершения.

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

Answer 9

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

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

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

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

Answer 10

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