В чем преимущества использования баз данных NoSQL? В последнее время я много читал о них, но до сих пор не уверен, зачем мне его реализовать и при каких обстоятельствах я бы хотел его использовать.
Ответы:
Реляционные базы данных используют ACID . Итак, у вас будут хранилища данных, ориентированные на транзакции на основе схемы. Это проверено и подходит для 99% реальных приложений. С реляционными базами данных можно делать практически все.
Но существуют ограничения по скорости и масштабированию, когда речь идет о массивных хранилищах данных с высокой доступностью. Например, у Google и Amazon терабайты данных хранятся в больших центрах обработки данных. Запросы и вставка не выполняются в этих сценариях из-за характера блокировки / схемы / транзакции RDBM. По этой причине они внедрили свои собственные базы данных (фактически, хранилища значений ключей) для значительного повышения производительности и масштабируемости.
Базы данных NoSQL существуют уже давно - просто термин новый. Некоторыми примерами являются базы данных графов, объектов, столбцов, XML и документов.
На ваш второй вопрос: можно ли использовать оба на одном сайте?
Почему нет? Оба служат разным целям, верно?
Решения NoSQL обычно предназначены для решения проблемы, для которой реляционные базы данных либо не подходят, либо слишком дороги в использовании (например, Oracle), либо требуют от вас реализации чего-то, что в любом случае нарушает реляционный характер вашей базы данных.
Преимущества обычно специфичны для вашего использования, но если у вас нет какой-либо проблемы с моделированием ваших данных в СУБД, я не вижу причин, по которым вы бы выбрали NoSQL.
Я сам использую MongoDB и Riak для конкретных проблем, когда СУБД не является жизнеспособным решением, для всего остального я использую MySQL (или SQLite для тестирования).
Если вам нужна база данных NoSQL, о которой вы обычно знаете, возможные причины:
Если вам не нужно решение NoSQL, имейте в виду, что эти решения не предназначались для замены СУБД, а скорее как альтернативы там, где первая не работает и, что более важно, они относительно новые, как таковые, в них все еще есть много ошибок и недостающие функции.
О, и что касается второго вопроса, совершенно нормально использовать любую технологию в сочетании с другой, поэтому, чтобы быть полным из моего опыта, MongoDB и MySQL отлично работают вместе, если они не на одной машине.
У Мартина Фаулера есть отличное видео, которое дает хорошее объяснение баз данных NoSQL. Ссылка ведет прямо к его причинам их использования, но все видео содержит хорошую информацию.
У вас есть большие объемы данных, особенно если вы не можете разместить их все на одном физическом сервере, поскольку NoSQL был разработан для хорошего масштабирования.
Несоответствие объектно-реляционного импеданса - объекты вашего домена плохо вписываются в схему реляционной базы данных. NoSQL позволяет вам сохранять ваши данные в виде документов (или графиков), которые могут гораздо более точно соответствовать вашей модели данных.
NoSQL - это система баз данных, в которой данные организованы в документ (MongoDB), пару ключ-значение (MemCache, Redis), форму структуры графа (Neo4J).
Возможно, вот возможные вопросы и ответы на вопрос «Когда переходить на NoSQL»:
Требовать гибкой схемы или иметь дело с данными в виде дерева?
Как правило, при гибкой разработке мы начинаем проектировать систему, не зная заранее всех требований, тогда как в дальнейшем на протяжении всей разработки системе базы данных может потребоваться учитывать частые изменения дизайна, демонстрируя MVP (минимально жизнеспособный продукт). Или вы имеете дело со схемой данных, которая носит динамический характер. например, системные журналы, очень точным примером являются журналы AWS cloudwatch.
Набор данных огромен / велик?
Да Нет. База данных SQL - лучший кандидат для приложений, в которых база данных должна управлять миллионами или даже миллиардами записей без ущерба для производительности.
Компромисс между масштабированием и согласованностью
В отличие от RDMS, база данных NoSQL может терять небольшие данные здесь и там (примечание: вероятность составляет .x%), но ее легко масштабировать с точки зрения производительности. Пример: это может быть полезно для хранения людей, которые находятся в сети в приложении для обмена мгновенными сообщениями, токенов в db, регистрации статистики посещаемости веб-сайта.
Выполнение операций геолокации: поддержка MongoDB с большим количеством хэшей для выполнения операций GeoQuerying и Geolocation. Мне очень понравилась эта функция MongoDB.
В двух словах, MongoDB отлично подходит для приложений, в которых вы можете хранить динамические структурированные данные в больших масштабах.
Отсутствует некоторая важная информация, чтобы ответить на вопрос: какие варианты использования база данных должна быть в состоянии охватить? Должен ли выполняться комплексный анализ существующих данных ( OLAP ) или приложение должно иметь возможность обрабатывать множество транзакций ( OLTP )? Какая структура данных? Это далеко не конец времени для вопросов.
На мой взгляд, неправильно принимать технологические решения на основе смелых модных словечек, не зная точно, что за ними стоит. NoSQL часто хвалят за его масштабируемость. Но вы также должны знать, что горизонтальное масштабирование (по нескольким узлам) также имеет свою цену и не является бесплатным. Затем вам нужно решить такие проблемы, как возможная согласованность, и определить, как разрешать конфликты данных, если они не могут быть разрешены на уровне базы данных. Однако это относится ко всем системам распределенных баз данных.
Радость разработчиков от слова «schema less» в NoSQL поначалу тоже очень велика. Это модное словечко быстро разочаровывается после технического анализа, поскольку оно правильно не требует схемы при записи, но вступает в игру при чтении. Поэтому правильно должно быть «схема при чтении». Может возникнуть соблазн иметь возможность записывать данные по своему усмотрению. Но как мне справиться с ситуацией, если данные есть, но новая версия приложения ожидает другую схему?
Модель документа (как, например, MongoDB) не подходит для моделей данных, в которых существует множество взаимосвязей между данными. Соединения должны выполняться на уровне приложения, что требует дополнительных усилий, и почему я должен программировать то, что должна делать база данных.
Если вы утверждаете, что Google и Amazon разработали свои собственные базы данных, потому что обычные СУБД больше не могут обрабатывать поток данных, вы можете только сказать: вы не Google и Amazon. Эти компании являются острием, около 0,01% сценариев, где традиционные базы данных больше не подходят, но для остального мира они подходят.
Что немаловажно: SQL существует уже более 40 лет, и миллионы часов разработки были потрачены на большие системы, такие как Oracle или Microsoft SQL. Это должно быть достигнуто с помощью некоторых новых баз данных. Иногда также легче найти администратора SQL, чем кого-то для MongoDB. Это подводит нас к вопросу об обслуживании и управлении. Тема не совсем сексуальная, но это часть технологического решения.
Я столкнулся с этим вопросом, когда искал убедительные основания для отхода от дизайна СУБД.
Есть отличный пост Джулиана Брауна, проливающий свет на ограничения распределенных систем. Эта концепция называется теоремой Брюера CAP, которая вкратце гласит:
К распределенным системам предъявляются три требования: согласованность, доступность и устойчивость к разделению (вкратце - CAP). Но вы можете иметь только два из них одновременно.
И вот как я резюмировал это для себя:
Вам лучше выбрать NoSQL, если вы жертвуете согласованностью.
Я разработал и внедрил решения с базами данных NoSQL, и вот мой список контрольных точек, чтобы принять решение о переходе на SQL или документно-ориентированный NoSQL .
НЕЛЬЗЯ
SQL не устарел и в некоторых случаях остается лучшим инструментом. Трудно оправдать использование документально-ориентированного NoSQL, когда
Делает
Если у вас нет этих условий или вы можете смягчить их, то вот 2 причины, по которым вы можете извлечь выгоду из NoSQL:
Больше информации
В своих сообщениях в блоге я более подробно объясняю причины:
Примечание: вышесказанное применимо только к документированному NoSQL. Есть и другие типы NoSQL, требующие других соображений.
Обработка большого количества операций чтения и записи
Если вам нужно быстро масштабироваться, обратите внимание на базы данных NoSQL. И когда вам обычно нужно быстро масштабироваться?
Когда на вашем веб-сайте выполняется большое количество операций чтения-записи и при работе с большим объемом данных, базы данных NoSQL лучше всего подходят для этих сценариев. Поскольку у них есть возможность добавлять узлы на лету, они могут обрабатывать больше одновременного трафика и большие объемы данных с минимальной задержкой.
Гибкость с моделированием данных
Вторая подсказка - на начальных этапах разработки, когда вы не уверены в модели данных, дизайне базы данных, ожидается, что все будет меняться быстрыми темпами. Базы данных NoSQL предлагают нам большую гибкость.
Конечная согласованность важнее сильной согласованности
Предпочтительно выбирать базы данных NoSQL, когда мы можем отказаться от строгой согласованности и когда нам не нужны транзакции.
Хорошим примером этого является веб-сайт социальной сети, такой как Twitter. Когда твит знаменитости становится популярным, и всем он нравится и ретвитят со всего мира. Имеет ли значение, увеличивается или уменьшается количество лайков на короткое время?
Знаменитости определенно не будет волновать, если вместо фактических 5 миллионов 500 лайков система на короткое время покажет количество лайков как 5 миллионов 250.
Когда большое приложение развертывается на сотнях серверов, разбросанных по всему миру, географически распределенным узлам требуется некоторое время для достижения глобального консенсуса.
Пока они не достигнут консенсуса, ценность объекта непостоянна. Через некоторое время ценность объекта в конечном итоге становится стабильной. Вот что такое конечная согласованность.
Хотя несоответствие не означает, что есть какая-либо потеря данных. Это просто означает, что данные быстро перемещаются по земному шару по интернет-кабелям под океаном, чтобы достичь глобального консенсуса и стать последовательными.
Мы постоянно наблюдаем такое поведение. Особенно на ютубе. Часто вы видите видео с 10 просмотрами и 15 лайками. Как это вообще возможно?
Это не. Реальных просмотров уже больше, чем лайков. Просто количество просмотров непоследовательно, и его обновление занимает некоторое время.
Запуск аналитики данных
Базы данных NoSQL также лучше всего подходят для случаев использования аналитики данных, когда нам приходится иметь дело с притоком огромных объемов данных.