Я слышал кое-что о NoSQL и о том, что он может стать заменой методов хранения SQL DB из-за того, что взаимодействие с БД часто является узким местом для скорости в Интернете.
У меня есть несколько вопросов:
Что именно это?
Как это работает?
Почему это было бы лучше, чем использовать базу данных SQL? И насколько это лучше?
Является ли технология слишком новой, чтобы начать внедрять ее, или стоит взглянуть на нее?
Ответы:
Что именно это?
С одной стороны, конкретная система , но она также стала общим словом для множества новых бэкэндов хранения данных, которые не следуют реляционной модели БД.
Как это работает?
Каждая из систем, помеченных общим именем, работает по-разному, но основная идея состоит в том, чтобы предложить лучшую масштабируемость и производительность за счет использования моделей БД, которые не поддерживают все функциональные возможности общей СУБД, но при этом все еще достаточно функциональны, чтобы быть полезными. В некотором смысле это похоже на MySQL, которому в свое время не хватало поддержки транзакций, но именно из- за этого ему удалось превзойти другие системы БД. Если бы вы могли написать свое приложение так, чтобы оно не требовало транзакций, это было бы здорово.
Почему это было бы лучше, чем использовать базу данных SQL? И насколько это лучше?
Было бы лучше, когда ваш сайт должен масштабироваться настолько масштабно, чтобы лучшая СУБД, работающая на лучшем оборудовании, которое вы можете себе позволить, и максимально оптимизированная, просто не справлялась с нагрузкой. Насколько это лучше, зависит от конкретного варианта использования (большое количество операций по обновлению в сочетании с большим количеством объединений очень трудно для «традиционных» СУБД) - в крайних случаях вполне может быть фактором 1000.
Является ли технология слишком новой, чтобы начать внедрять ее, или стоит взглянуть на нее?
Зависит в основном от того, что вы пытаетесь достичь. Это, конечно, достаточно зрелый, чтобы использовать. Но немногие приложения действительно нуждаются в таком масштабном масштабировании. Для большинства достаточно традиционных СУБД. Тем не менее, в связи с тем, что использование Интернета становится все более распространенным, вполне вероятно, что такие приложения станут более распространенными (хотя, вероятно, не доминирующими).
источник
transaction?Нет такой вещи как NoSQL!
NoSQL - модное слово.
В течение десятилетий, когда люди говорили о базах данных, они имели в виду реляционные базы данных. И когда люди говорили о реляционных базах данных, они имели в виду те, которые вы контролируете с помощью языка структурированных запросов Эдгара Ф. Кодда. Хранить данные другим способом? Безумие! Все остальное - просто файлы.
Но в последние несколько лет люди начали подвергать сомнению эту догму. Люди задавались вопросом, действительно ли таблицы со строками и столбцами являются единственным способом представления данных. Люди начали думать и кодировать и придумывали много новых концепций организации данных. И они начали создавать новые системы баз данных, предназначенные для этих новых способов работы с данными.
Философии всех этих баз данных были разными. Но у всех этих баз данных было общее то, что язык структурированных запросов больше не подходит для их использования. Таким образом, каждая база данных заменила SQL своими собственными языками запросов. Так появился термин NoSQL, как ярлык для всех технологий баз данных, которые бросают вызов классической модели реляционных баз данных.
Так что же общего у баз данных NoSQL?
На самом деле, не так много.
Вы часто слышите такие фразы, как:
Это правда? Ну, некоторые из этих утверждений могут быть верными для некоторых баз данных, обычно называемых NoSQL, но каждая из них также ложна по крайней мере для одной другой. На самом деле, единственное, что объединяет базы данных NoSQL, это то, что они являются базами данных, которые не используют SQL. Вот и все. Единственное, что их определяет, это то, что отличает их друг от друга.
Так что же отличает базы данных NoSQL?
Итак, мы ясно дали понять, что все эти базы данных, обычно называемые NoSQL, слишком разные, чтобы оценивать их вместе. Каждый из них должен оцениваться отдельно, чтобы решить, подходят ли они для решения конкретной проблемы. Но с чего начать? К счастью, базы данных NoSQL можно сгруппировать в определенные категории, которые подходят для разных вариантов использования:
Документ-ориентированный
Примеры: MongoDB, CouchDB
Сильные стороны: гетерогенные данные, работа объектно-ориентированная, гибкая разработка
Их преимущество в том, что они не требуют согласованной структуры данных. Они полезны, когда ваши требования и, следовательно, структура вашей базы данных постоянно меняются, или когда вы имеете дело с наборами данных, которые принадлежат друг другу, но при этом выглядят совсем по-другому. Если у вас есть много таблиц с двумя столбцами, называемыми «ключ» и «значение», то, возможно, стоит изучить их.
Граф базы данных
Примеры: Neo4j, GiraffeDB.
Сильные стороны: Data Mining
Хотя большинство баз данных NoSQL отказываются от концепции управления отношениями с данными, эти базы охватывают ее даже больше, чем так называемые реляционные базы данных.
Их цель заключается в определении данных по их связи с другими данными. Если у вас есть много таблиц с первичными ключами, которые являются первичными ключами двух других таблиц (и, возможно, некоторые данные, описывающие отношения между ними), то это может быть что-то для вас.
Основные магазины
Примеры: Redis, Cassandra, MemcacheDB
Сильные стороны: быстрый поиск значений по известным ключам
Они очень просты, но это делает их быстрыми и простыми в использовании. Если вам не нужны хранимые процедуры, ограничения, триггеры и все эти расширенные функции базы данных, и вы просто хотите быстрое хранение и извлечение ваших данных, тогда это для вас.
К сожалению, они предполагают, что вы точно знаете, что ищете. Вам нужен профиль пользователя 157641? Нет проблем, займет всего лишь микросекунды. Но что, если вы хотите, чтобы имена всех пользователей в возрасте от 16 до 24 лет имели «вафли» в качестве любимой еды и входили в систему в течение последних 24 часов? Вот незадача. Если у вас нет определенного и уникального ключа для конкретного результата, вы не сможете легко достать его из своего магазина KV.
Является ли SQL устаревшим?
Некоторые сторонники NoSQL утверждают, что их любимая база данных NoSQL - это новый способ работы, а SQL ушел в прошлое.
Они правы?
Нет, конечно, нет. Хотя есть проблемы, для которых SQL не подходит, он все же имеет свои сильные стороны. Многие модели данных просто лучше всего представить в виде набора таблиц, которые ссылаются друг на друга. Тем более, что большинство программистов баз данных десятилетиями обучались думать о данных в реляционной форме, и попытка внедрить это мышление в новую технологию, которая не была создана для этого, редко заканчивается хорошо.
Базы данных NoSQL не являются заменой SQL - они являются альтернативой.
Большинство программных экосистем вокруг различных баз данных NoSQL еще не настолько развиты. Несмотря на достигнутые успехи, у вас еще нет дополнительных инструментов, которые были бы такими же зрелыми и мощными, как доступные для популярных баз данных SQL.
Кроме того, существует гораздо больше ноу-хау для SQL. Поколения ученых-компьютерщиков потратили десятилетия своей карьеры на исследования, посвященные реляционным базам данных, и это показывает: литература, написанная о базах данных SQL и моделировании реляционных данных, как практических, так и теоретических, может заполнить множество библиотек, заполненных книгами. Как создать реляционную базу данных для ваших данных - тема настолько хорошо изученная, что трудно найти угловой случай, когда не существует общепринятых практических рекомендаций.
С другой стороны, большинство баз данных NoSQL все еще находятся в зачаточном состоянии. Мы все еще придумываем лучший способ их использования.
источник
Поскольку кто-то сказал, что мой предыдущий пост был не по теме, я постараюсь дать компенсацию :-) NoSQL не предназначен и никогда не был заменой для более массовых баз данных SQL, но пара слов для того, чтобы получить вещи в правильной перспективе.
В основе философии NoSQL лежит мнение о том, что, возможно, по соображениям коммерческой целесообразности и переносимости, движки SQL, как правило, игнорируют огромную мощь операционной системы UNIX и ее производных.
С базой данных на основе файловой системы вы можете сразу же воспользоваться постоянно растущими возможностями и мощью базовой операционной системы, которая в течение многих лет неуклонно растет в соответствии с законом Мура. При таком подходе многие команды операционной системы автоматически становятся также «операторами базы данных» (например, «ls», «sort», «find» и другие бесчисленные утилиты оболочки UNIX).
Имея это в виду и немного творчества, вы действительно можете разработать базу данных на основе файловой системы, способную преодолеть ограничения многих распространенных механизмов SQL, по крайней мере, для конкретных шаблонов использования, что и составляет основу философии NoSQL, как я это вижу.
Я управляю сотнями веб-сайтов, и все они используют NoSQL в большей или меньшей степени. На самом деле, они не содержат огромных объемов данных, но даже если бы некоторые из них сделали это, я мог бы подумать о творческом использовании NoSQL и файловой системы для преодоления любых узких мест. Что-то, что, вероятно, будет сложнее с традиционными «тюрьмами» SQL. Я призываю вас поискать «unix», «manis» и «shaffer» в Google, чтобы понять, что я имею в виду.
источник
Если я правильно помню, это относится к типам баз данных, которые не обязательно следуют реляционной форме. Вспоминаются базы данных документов, базы данных без определенной структуры, которые не используют SQL в качестве определенного языка запросов.
Как правило, он лучше подходит для веб-приложений, которые зависят от производительности базы данных, и не нуждаются в более сложных функциях Relation Database Engine. Например, хранилище Key-> Value, предоставляющее простой интерфейс запроса по идентификатору, может быть в 10-100 раз быстрее, чем соответствующая реализация SQL-сервера, с меньшими затратами на обслуживание разработчика.
Одним из примеров является этот документ для хранилища кортежей OLTP , который пожертвовал транзакциями для однопоточной обработки (без проблем с параллелизмом, так как параллелизм не разрешен) и сохранил все данные в памяти; достижение в 10-100 раз лучшей производительности по сравнению с аналогичной системой, управляемой СУБД . По сути, он отходит от представления «Один размер подходит всем» для систем SQL и баз данных.
источник
На практике NoSQL - это система баз данных, которая поддерживает быстрый доступ к крупным двоичным объектам (docs, jpgs и т. Д.) С использованием стратегии доступа на основе ключей. Это отход от традиционного доступа SQL, который достаточно хорош только для буквенно-цифровых значений. Не только внутренняя стратегия хранения и доступа, но также синтаксис и ограничения формата отображения ограничивают традиционный SQL. Реализации BLOB традиционных реляционных баз данных также страдают от этих ограничений.
За кулисами это косвенное признание отказа модели SQL поддерживать любую форму OLTP или поддержку новых форматов данных. «Поддержка» означает не только хранилище, но и возможности полного доступа - программно и по запросу с использованием стандартной модели.
Реляционные энтузиасты быстро изменили определение NoSQL с Not-SQL на Not-Only-SQL, чтобы SQL оставался в курсе событий! Это не очень хорошо, особенно когда мы видим, что большинство Java-программ сегодня прибегают к ORM-отображению базовой реляционной модели. Новая концепция должна иметь четкое определение. Иначе это закончится как SOA.
Основа систем NoSQL лежит в паре случайный ключ - значение. Но это не ново. Традиционные системы баз данных, такие как IMS и IDMS, поддерживают хэшированные ключи случайных чисел (без использования какого-либо индекса), и они все еще поддерживают. На самом деле IDMS уже имеет ключевое слово NONSQL, где они поддерживают доступ SQL к своей старой сетевой базе данных, которую они назвали NONSQL.
источник
Это как джакузи: и бренд, и общее название. Это не просто конкретная технология, а скорее особый тип технологии, в данном случае относящийся к крупномасштабным (часто редким) «базам данных», таким как Google BigTable или CouchDB.
источник
NoSQL - это реляционная база данных, реализованная в awk с использованием плоских файлов на сервере. Хотя они утверждают, что «NoSQL по существу не имеет произвольных ограничений и может работать там, где другие продукты не могут. Например, нет ограничений по размеру поля данных, числу столбцов или размеру файла», я не думаю, что это так. масштабная база данных будущего.
Как говорит Джоэл, массово масштабируемые базы данных, такие как BigTable или HBase , гораздо интереснее. GQL - это язык запросов, связанный с BigTable и App Engine. Он в значительной степени настроен на SQL, чтобы избежать функций, которые Google рассматривает как узкие места (например, объединения). Тем не менее, я не слышал, чтобы это упоминалось как «NoSQL» раньше.
источник
NoSQL - это система баз данных, которая не использует строковые SQL-запросы для извлечения данных.
Вместо этого вы создаете запросы, используя API, который они предоставляют, например, Amazon DynamoDB является хорошим примером базы данных NoSQL.
Базы данных NoSQL лучше подходят для больших приложений, где важна масштабируемость.
источник
Да, NoSQL отличается от RDBMS и OLAP. Он использует более слабые модели согласованности, чем традиционные реляционные базы данных.
Модели согласованности используются в распределенных системах, таких как распределенные системы с общей памятью или распределенное хранилище данных.
Системы баз данных NoSQL часто высоко оптимизированы для операций поиска и добавления и часто предлагают мало функциональных возможностей помимо хранения записей (например, хранилищ значений ключей). Снижение гибкости во время выполнения по сравнению с системами полного SQL компенсируется значительным увеличением масштабируемости и производительности для определенных моделей данных.
Он может работать на структурированных и неструктурированных данных. Он использует коллекции вместо таблиц
Смотреть SQL против NoSQL: Битва за Backends ; это все объясняет.
источник