Я слышал о NoSQL и что в конечном итоге это может стать заменой методам хранения SQL DB из-за того, что взаимодействие с БД часто является шеей бутылки для скорости в Интернете.
Итак, у меня есть несколько вопросов:
Что это такое?
Как это работает?
Почему это лучше, чем использование базы данных SQL? И насколько это лучше?
Является ли эта технология слишком новой, чтобы начать внедрять ее или стоит взглянуть?
Что это такое?
С одной стороны, конкретная система, но она также стала общим словом для множество новых хранилищ данных, которые не соответствуют реляционной модели БД.
Как это работает?
Каждая из систем, помеченных общим именем, работает по-разному, но основная идея состоит в том, чтобы предложить лучшую масштабируемость и производительность с использованием моделей БД, которые не поддерживают все функции общей RDBMS, но все еще достаточно функциональных возможностей для использования, В некотором смысле это похоже на MySQL, который в свое время не поддерживал поддержку транзакций, но именно из-за этого ему удалось превзойти другие системы БД. Если бы вы могли написать свое приложение таким образом, чтобы не требовать транзакций, это было здорово.
Почему это лучше, чем использование базы данных SQL? И насколько это лучше?
Было бы лучше, когда ваш сайт должен масштабироваться настолько массово, что лучшая СУБД, работающая на лучшем оборудовании, которое вы можете себе позволить и оптимизированное как можно больше, просто не может не отставать от нагрузки. Насколько это лучше, зависит от конкретного варианта использования (много активности обновления в сочетании с большим количеством подключений очень сложно на "традиционных" РСУБД), в крайних случаях вполне может быть 1000.
Является ли эта технология слишком новой, чтобы начать внедрять ее или стоит взглянуть?
В основном зависит от того, чего вы пытаетесь достичь. Это, конечно, достаточно зрело, чтобы использовать. Но немногие приложения действительно должны масштабировать это в массовом порядке. Для большинства из них достаточно традиционной СУБД. Однако, когда использование Интернета становится все более распространенным все время, вполне вероятно, что приложения, которые сделают это, станут более распространенными (хотя, вероятно, и не доминирующими).
NoSQL - это модное слово.
В течение десятилетий, когда люди говорили о базах данных, они подразумевали реляционные базы данных. И когда люди говорили о реляционных базах данных, это означало, что вы контролируете язык структурированного запроса Edgar F. Codd. Хранение данных каким-то другим способом? Безумие! Все остальное - только плоские файлы.
Но в последние несколько лет люди стали подвергать сомнению эту догму. Люди задавались вопросом, действительно ли таблицы с строками и столбцами являются единственным способом представления данных. Люди начали думать и кодировать, и придумали много новых концепций, как можно организовать данные. И они начали создавать новые системы баз данных, разработанные для этих новых способов работы с данными.
Философия всех этих баз данных была иной. Но одна вещь, с которой были связаны все эти базы данных, заключалась в том, что язык структурированных запросов больше не подходит для их использования. Таким образом, каждая база данных заменяет SQL своими собственными языками запросов. И поэтому появился термин NoSQL, как метка для всех технологий баз данных, которые бросают вызов классической модели реляционной базы данных.
Собственно, не так много.
Вы часто слышите фразы типа:
Это правда? Ну, некоторые из этих утверждений могут быть верны для некоторых баз данных, обычно называемых NoSQL, но каждый из них также является ложным по меньшей мере для одного другого. На самом деле единственное, что есть в базе данных NoSQL, - это то, что они являются базами данных, которые не используют SQL. Это. Единственное, что их определяет, это то, что отличает их друг от друга.
Итак, мы ясно дали понять, что все те базы данных, которые обычно называются NoSQL, слишком различны, чтобы оценивать их вместе. Каждый из них должен оцениваться отдельно, чтобы решить, подходят ли они для решения конкретной проблемы. Но с чего мы начнем? К счастью, базы данных NoSQL могут быть сгруппированы по определенным категориям, которые подходят для разных случаев использования:
Документ-ориентированный
Примеры: MongoDB, CouchDB
Сильные стороны: гетерогенные данные, рабочие объектно-ориентированные, гибкие разработки
Их преимущество заключается в том, что они не требуют согласованной структуры данных. Они полезны, когда ваши требования и, следовательно, ваш макет базы данных постоянно меняются или когда вы имеете дело с наборами данных, которые принадлежат друг другу, но все равно выглядят совсем по-другому. Когда у вас много таблиц с двумя столбцами, называемыми "ключ" и "значение", тогда они могут быть полезны.
Графические базы данных
Примеры: Neo4j, GiraffeDB.
Сильные стороны: интеллектуальный анализ данных
В то время как большинство баз данных NoSQL отказывается от концепции управления отношениями данных, эти базы данных охватывают ее даже больше, чем так называемые реляционные базы данных.
Их внимание сосредоточено на определении данных по его отношению к другим данным. Когда у вас много таблиц с первичными ключами, которые являются первичными ключами двух других таблиц (и, возможно, некоторые данные, описывающие связь между ними), тогда они могут быть чем-то для вас.
Магазины с ключевыми знаками
Примеры: Redis, Cassandra, MemcacheDB
Сильные стороны: быстрый поиск значений с помощью известных ключей
Они очень упрощены, но делают их быстрыми и простыми в использовании. Если вам не нужны хранимые процедуры, ограничения, триггеры и все эти расширенные функции базы данных, и вы просто хотите быстро хранить и извлекать данные, то это для вас.
К сожалению, они предполагают, что вы точно знаете, что ищете. Вам нужен профиль User157641? Нет проблем, займется только микросекундами. Но что, когда вы хотите, чтобы имена всех пользователей, которые в возрасте от 16 до 24 лет, имеют "вафли" в качестве их любимой еды и вошли в систему за последние 24 часа? Везет, как утопленнику. Если у вас нет определенного и уникального ключа для конкретного результата, вы не можете легко его достать из своего магазина K-V.
Некоторые сторонники NoSQL утверждают, что их любимая база данных NoSQL - это новый способ делать что-то, а SQL - в прошлом.
Правильны ли они?
Нет, конечно, нет. Хотя есть проблемы, для которых SQL не подходит, он все еще имеет свои сильные стороны. Многие модели данных просто лучше всего представлены в виде набора таблиц, которые ссылаются друг на друга. Тем более, что большинство программистов баз данных на протяжении десятилетий обучались на основе данных, и, пытаясь надавить на это мышление на новую технологию, которая не была создана, она редко заканчивается.
Базы данных NoSQL не заменяют SQL - они являются альтернативой.
Большинство программных экосистем вокруг разных баз данных NoSQL еще не настолько зрелы. Несмотря на прогресс, у вас все еще нет дополнительных инструментов, которые столь же зрелые и мощные, как те, которые доступны для популярных баз данных SQL.
Кроме того, для SQL существует гораздо больше ноу-хау. Поколения компьютерных ученых провели десятилетия своей карьеры в исследованиях, ориентированных на реляционные базы данных, и это показывает: литература, написанная о базах данных SQL и реляционных данных, как практических, так и теоретических, может заполнять множество библиотек, полных книг. Как создать реляционную базу данных для ваших данных - это тема, так хорошо исследованная, что трудно найти угловой случай, когда нет общепринятой практической практики.
Большинство баз данных NoSQL, с другой стороны, все еще находятся в зачаточном состоянии. Мы все еще выясняем, как их использовать.
Поскольку кто-то сказал, что мой предыдущий пост был вне темы, я постараюсь компенсировать:-) NoSQL не является и никогда не был предназначен для замены более основных баз данных SQL, но несколько слов находятся в чтобы получить информацию в правильной перспективе.
В базе данных на базе файловой системы вы можете немедленно воспользоваться постоянно растущими возможностями и мощью базовой операционной системы, которые в течение многих лет неуклонно растут в соответствии с законом Мура. При таком подходе многие команды операционной системы автоматически становятся также "операторами базы данных" (подумайте о "сортировке" "ls", "find" и других бесчисленных утилитах оболочки UNIX).
Имея это в виду и немного творчества, вы действительно можете создать базу данных на базе файловой системы, которая сможет преодолеть ограничения многих распространенных механизмов SQL, по крайней мере, для конкретных шаблонов использования, что является целым рядом с NoSQL философия, как я ее вижу.
Я запускаю сотни веб-сайтов, и все они используют NoSQL в большей или меньшей степени. Фактически, они не содержат огромные объемы данных, но даже если некоторые из них могли бы, возможно, подумать о творческом использовании NoSQL и файловой системы для преодоления любых узких мест. Что-то, что, вероятно, будет более сложным с традиционными SQL-тюрьмами. Я призываю вас к google для "unix", "manis" и "shaffer", чтобы понять, что я имею в виду.
Если я правильно помню, это относится к типам баз данных, которые не обязательно соответствуют реляционной форме. База данных документов приходит на ум, базы данных без определенной структуры и которые не используют SQL в качестве конкретного языка запросов.
Он обычно лучше подходит для веб-приложений, которые полагаются на производительность базы данных и не нуждаются в более продвинутых функциях в Relation Database Engines. Например, хранилище Key- > Value, обеспечивающее простой запрос по интерфейсу id, может быть на 10-100x быстрее, чем соответствующая реализация SQL-сервера, с более низкой стоимостью обслуживания разработчика.
Одним из примеров является paper для OLTP Tuple Store, который пожертвовал транзакциями для однопоточной обработки (нет concurrency, потому что не разрешено concurrency), и сохранял все данные в памяти; достигая 10-100x более высокой производительности по сравнению с аналогичной системой RDBMS. В основном, он отходит от представления "Один размер подходит всем" для систем SQL и баз данных.
На практике NoSQL - это система баз данных, которая поддерживает быстрый доступ к большим двоичным объектам (docs, jpg и т.д.) с использованием стратегии доступа на основе ключевых слов. Это отход от традиционного доступа SQL, который достаточно хорош для буквенно-цифровых значений. Не только внутренняя стратегия хранения и доступа, но и синтаксис и ограничения в формате отображения ограничивают традиционный SQL. Из-за этих ограничений страдают также реалии BLOB традиционных реляционных баз данных.
За сценой это косвенное признание отказа модели SQL поддерживать любую форму OLTP или поддержку новых форматов данных. "Поддержка" означает не только сохранение, но и полный доступ - программирование и запрос с использованием стандартной модели.
Реляционные энтузиасты быстро модифицировали defnition NoSQL из Not-SQL в Not-Only-SQL, чтобы сохранить SQL на картинке! Это не очень хорошо, особенно когда мы видим, что большинство программ Java сегодня используют ORM-отображение базовой реляционной модели. Новая концепция должна иметь четкое определение. Иначе это закончится как SOA.
В основе систем NoSQL лежит случайная пара ключ-значение. Но это не ново. Традиционные системы баз данных, такие как IMS и IDMS, поддерживали хешированные ключи ramdom (без использования какого-либо индекса), и они все еще делают. На самом деле у 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 нереляционную базу данных?
Да, NoSQL отличается от СУБД и OLAP. Он использует более слабые модели согласованности, чем традиционные реляционные базы данных.
Модели согласованности используются в распределенных системах, таких как распределенные системы общей памяти или распределенные хранилища данных.
Как это работает внутри?
Системы баз данных NoSQL часто высоко оптимизированы для операций поиска и добавления и часто предлагают небольшую функциональность, помимо хранения записей (например, хранилища значений ключа). Сниженная гибкость во время выполнения по сравнению с полными системами SQL компенсируется заметным увеличением масштабируемости и производительности для определенных моделей данных.
Он может работать с структурированными и неструктурированными данными. Он использует Коллекции вместо таблиц
Как вы запрашиваете такую "базу данных"?
Смотреть SQL vs NoSQL: Битва за Backends; это все объясняет.