Насколько модель данных влияет на масштабируемость и производительность в так называемой базе данных «NoSQL»?

Вы никогда не сможете поговорить о так называемой базе данных «NoSQL», не приведя теорему CAP (согласованность, доступность, раздел: выберите два). Если вам нужно выбрать, скажем, между MongoDB (Разделение, Согласованность) и CouchDB (Доступность, Разделение), первое, о чем вам нужно подумать: «Мне нужны правильные данные или мне нужен доступ все время?».

Эти новые базы данных были созданы для разделения. Но что если я этого не сделаю ? Что если я просто думаю, что это круто - иметь ключ / значение, столбец, документ, любую базу данных вместо реляционной, и просто создать один экземпляр сервера и никогда его не осколковать? В таком случае, разве у меня не было бы доступности и согласованности? MongoDB не нужно будет ничего копировать, поэтому он будет доступен. И у CouchDB будет только один источник данных, поэтому он будет довольно последовательным.

Так что это будет означать, что в этом случае MongoDB и CouchDB будут иметь небольшую разницу в терминах использования? Ну, кроме, конечно, производительности, API и т. Д., Но это больше похоже на выбор между PostgreSQL и MySQL, чем на наличие двух принципиально различных требований.

Я прямо здесь? Могу ли я изменить базу данных AP или CP на AC, не создавая более одного экземпляра? Или мне чего-то не хватает?

Давайте зададим вопрос в обратном порядке. Что делать, если я беру реляционную базу данных, скажем, MySQL, и помещаю ее в конфигурацию master / slave. Я не использую транзакции ACID. Если я требую, чтобы любая запись была немедленно синхронизирована с ведомым устройством, разве это не сделало бы это базой данных CP? А что, если я синхронизирую его через несколько предопределенных интервалов, и не имеет значения, читает ли клиент устаревшие данные из ведомого устройства. Не сделает ли это базу данных AP? Не значит ли это, что если я откажусь от соответствия ACID, я все равно смогу использовать реляционную модель для разделенной базы данных?

По сути: масштабируемость того, от чего вы готовы отказаться в теореме CAP, больше, чем базовая модель данных? Имеет ли столбец, документ, значение ключа, что-либо еще, повышает масштабируемость по сравнению с реляционной моделью? Можем ли мы спроектировать реляционную базу данных, разработанную с нуля для допусков на разделы? (Может быть, оно уже существует). Можем ли мы сделать базу данных NoSQL ACID-совместимой?

Извините, это много вопросов, но я недавно много читал о базах данных NoSQL, и мне кажется, что самое большое преимущество их использования заключается в том, что они лучше соответствуют «форме» ваших данных, а не только разделу, CAP и отказ от соответствия кислоте. В конце концов, не у всех есть так много данных, что им нужно разделить их. Есть ли преимущество в производительности / масштабируемости для того, чтобы не использовать реляционную модель, прежде чем я даже подумаю о разделении своих данных?

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

Возьмем, к примеру, идею о том, что вы создаете облачную систему хранения файлов, похожую на google drive, dropbox или box, но вместо того, чтобы использовать реальную файловую систему, вы решаете, что для вас было бы выгоднее виртуализировать файловую систему. Теперь у вас есть проблема, потому что ваша модель данных внезапно становится древовидной структурой, которая будет ужасно неэффективной в СУБД (несмотря на то, что именно так все индексируется). Потому что теперь у вас есть таблица из 3 столбцов с именами, пользователями и родителями. Пользователь - это внешний ключ для таблицы пользователей, а Parent - это самозаверяющий внешний ключ, который может иметь значение NULL. Он может иметь значение NULL, поскольку корневой каталог не может иметь родителя. Так что же является первичным ключом? В данном случае это составной ключ во всех столбцах ... Что неожиданно делает Родителя нашим злейшим врагом.

Теперь вместо этого подумайте, как бы вы поместили это в какую-то форму хранилища документов? Вместо того, чтобы бороться с данными, вы можете работать с ними и сохранять их в виде древовидной структуры, что, в свою очередь, сократит время разработки, а также сократит затраты на обслуживание. Если вы снижаете затраты, разве это не учитывает другой тип масштабируемости? Кроме того, в этом случае вы правильно создаете систему с нуля, что должно обеспечить большую гибкость для самого приложения. В настоящее время я выполняю это на одном сервере с использованием MongoDB, что, как вы объяснили, дает мне доступную, согласованную модель, которая не сильно отличается от рассмотрения различий в MySQL или Postgres.

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

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

Правильно ли я понял ваш вопрос?

Редактировать: замедлится ли больше данных? Да. Насколько это замедлит ход событий? Честно говоря, у меня недостаточно опыта, чтобы дать адекватный ответ. Ключ / Значение: по существу таблица поиска с большими объемами данных, связанных с ключом поиска. Это будет действительно очень быстро, потому что вы можете искать вещи только по ключу. Столбец / Семейство: по сути, гораздо более структурированное хранилище ключей / значений. Вы можете запрашивать только на основе столбца, так что это должно быть очень быстро. Документ: схема стиля агрегации. Здесь вы хотите объединить похожие данные вместе. Денормализация в порядке и ожидается для такого рода базы данных. В зависимости от того, выполняете ли вы много операций записи или чтения, вы можете организовать свои данные таким образом, чтобы они распределялись по нескольким осколкам для распределения записей или операций чтения (обратите внимание, что вы можете создать гибридный подход, который будет полезен для обеих сторон, но в целом вы нужно выбрать оптимизацию для одного или другого) График: Сила этого в том, что он может создавать и разрушать отношения очень быстро. Если у вас есть некоторые данные, где у вас есть отношения, которые должны меняться между данными (подумайте о какой-то форме механизма рекомендаций), то вам следует использовать это.

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