Итак... эта вещь NoSQL

Ответ 1

Я также большой поклонник MongoDB. Это, как было сказано, абсолютно не является оптовой заменой для РСУБД. Facebook имеет 300 миллионов пользователей, но если некоторые из ваших друзей не появляются в списке один раз, или один из альбомов отсутствует на случайном запросе, вы заметили бы? Возможно нет. Если ваше обновление статуса не просачивается ко всем вашим друзьям в течение нескольких минут, это имеет значение? Едва. Если баланс Wal-Mart не синхронизирован, кто-то потеряет голову? Определенно.

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

Большой толчок к NoSQL исходит из того, что за последние 30 лет мы использовали системы RDMBS для обоих сценариев. У нас теперь есть более подходящий инструмент для многих ситуаций. На самом деле некоторые будут спорить больше всего. Но никто не будет спорить со всеми.

Ответ 2

Я пишу это, но как спор к ответу Рекса.

Я оспариваю мысль о том, что nosql является безразличным и нечетким.

Я работал с CODASYL много лет назад с C и Cobol - отношения сущностей очень жесткие в CODASYL.

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

Часто считается само собой разумеющимся, что SQL является синонимом RDBMS, но люди пишут SQL-драйверы для CODASYL, XML, инвертированных наборов и т.д.

RDBMS/SQL не соответствует точности данных или отношений. Фактически, РСУБД является постоянной причиной неточности и неправильного восприятия отношений. Я не вижу, как RDBMS предлагают лучшую целостность данных и отношений, чем, например, hasoop. Наденьте слой JDO - и мы можем построить сеть хороших и чистых отношений между сущностями в hadoop.

Однако мне нравится работать с SQL, потому что это дает мне возможность script adhoc отношений, хотя я понимаю, что adhoc-отношения являются постоянной причиной фальсификации отношений и проблем.

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

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

Однако в базе данных, связывающей отношения, вы можете связать объекты в отношениях по мере их появления. Когда отношения мутируют, связь естественным образом мутирует с данными. Отношения и их мутация документируются в системе баз данных без дорогостоящей необходимости перенормировать схему. В этот момент СУРБД хороша только как временные dbs.

Но тогда вы можете противостоять тому, что СУРБД также позволяет гибко мутировать ваши отношения, поскольку именно это делает SQL. Правда, очень верно - пока вы выполняете BCNF или даже 4NF. В противном случае вы начнете видеть, что ваши запросы и загрузчики данных выполняют реплицированные операции. Но тогда ваши долгие годы в бизнесе RDBMS до сих пор, по крайней мере, заставило вас понять, что BCNF очень дорогой и оперативно неэффективен, и что мы постоянно виноваты в 2,5 NFing наших схем.

Сказать, что RDBMS и SQL способствует целостности данных и отношений, является грубым неверным выражением. Либо вы работаете в компании, которая настолько крошечная, либо вы не остаетесь на своих должностях более двух лет - вы не увидите количество данных или информационную мутацию и проблемы, вызванные РСУБД. Нарушение СУБД является причиной того, что руководители ограничиваются в представлении компьютерными приложениями и причиной финансовых сбоев компаний, которые не видят изменений в поведении на рынке, поскольку их взгляды были ограничены программистами, чьи взгляды были ограничены их почитанием их любимых Схемы РСУБД.

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

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

Причина, по которой люди не переходят на SQL-less, - это отсутствие хорошей среды сценариев, такой как SQL, для выполнения анализа отношений adhoc. Не потому, что технология SQL-less не соответствует точности или целостности. Анализ Adhoc отношений очень важен в наши дни благодаря быстрым и гибким подходам и стратегиям разработки приложений, которые мы имеем в настоящее время.

Ответ 3

Позвольте мне задавать вопросы по одному:

Я знаю, что не могу делать транзакции через отношения... когда это будет большой проблемой?

Каскадное удаление снимков. Или даже просто базовая ссылочная целостность. Понятие "внешние ключи" действительно не может быть применено к "коллекциям" (монгонский термин для таблиц). Вы можете делать атомные записи только для одного "документа" (запись AKA). Поэтому, если у вас проблема с БД, вы можете осиротеть данные в БД.

Я получаю столько же производительности, сколько у меня есть процессоры и оперативная память бесплатно?

Не бесплатно, но определенно с другим набором компромиссов. Например, Mongo отлично работает при выполнении однозадачных, ключевых/стоимостных запросов. Тем не менее, Mongo плохо работает над реляционными запросами. Для многих из них вам понадобится использовать map-reduce. Монго - "RAM-шлюха". Mongo в основном требует 64-бит для любого значительного набора данных. Mongo будет всасывать пространство на диске, загружать 140 ГБ DB, и вы можете в конечном итоге использовать 200+ ГБ, поскольку файл подкачки растет во время использования.

И вам по-прежнему нужен быстрый привод.

На самом деле я считаю безопасным сказать, что MongoDB - это действительно система БД, которая обслуживает передовые аппаратные средства (64-разрядные, много оперативной памяти, SSD). Я имею в виду, что вся БД сосредоточена вокруг поиска данных индекса данных в ОЗУ (привет 64-бит), а затем делает целенаправленный случайный поиск на диске (привет SSD).

почему... разве не вся индустрия прыгает с корабля из MySQL?

• Он не соответствует ACID. Вероятно, это довольно плохо для банковской системы (конечно, большинство из них все еще обрабатывают плоские файлы, но это другая проблема). Однако обратите внимание, что вы можете принудительно "безопасно" писать с Mongo и гарантировать, что данные попадают на диск, но только один "документ" за раз.
• Он еще очень молодой. Многие крупные компании по-прежнему используют старые версии Crystal Reports в своем приложении SQL Server 2000, написанном на VB6. Или они строят служебные автобусы для управления сумасшедшими разнородными средами, которые они создали за эти годы.
• Это очень различная парадигма. Возможно, 30% вопросов, которые я регулярно просматриваю в списках рассылки Mongo (и здесь), в основном связаны с "как я могу сделать запрос X?" или "как мне структурировать эти данные?". Использование MongoDB обычно требует предварительной денормализации. Это не только немного сложно, но и нетренирован. Большинство людей только учатся "нормализации" в школе, никто не учит нас, как денормализовать работу.
• Это не правильный инструмент для всего. Честно говоря, я считаю, что MongoDB - отличный инструмент для чтения и записи транзакционных данных. Этот простой "один-раз" CRUD, который включает в себя многие современные приложения. Однако MongoDB на самом деле не очень хорош в отчетности. На самом деле, я честно полагаю, что следующий шаг - это не "Mongo for everything", это "Mongo for transactional" и "MySQL для отчетности". Когда ваши данные становятся настолько большими, что вы выбрасываете "отчеты в режиме реального времени", то использование Map-Reduce для заполнения базы данных отчетов выглядит не так уж плохо.

Как я понял, при масштабировании вы получаете MySQL для подачи Memcache. Теперь кажется, что я могу начать с чего-то, что в равной степени исполнилось с самого начала.

Честно говоря, я работаю над этим в нескольких своих проектах. Опять же, я думаю, что MongoDB действительно делает допустимый уровень кэширования. Фактически, он создает слой кэширования с файловой поддержкой. Поэтому, если вы способны перенаправить MySQL в Mongo, вы получаете Memcached без промахов в кеше. Это также упрощает "нагревание кеша" на новом сервере, просто скопируйте файлы и запустите Mongo, указывая на нужную папку, это действительно так просто.

Ответ 4

Как часто вы думаете, что Facebook делает произвольные запросы против своего хранилища данных? Не все это веб-приложение, и, наоборот, не каждый анализ данных должен быть глубоко проанализирован.

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

Если MongoDB работает для вашего случая использования, непременно сделайте это. Просто не предполагайте, что ваш вариант использования - это все варианты использования. Нет технологии, которая бы соответствовала всем сценариям. Изобретение сверхзвуковых струй не устранило использование грузовых поездов.

Ответ 5

Большая реакция на NoSQL уходит корнями в менталитет многих сторонников NoSQL. В частности, отношение, которое лучше всего суммируется как "SQL слишком сложно, мне не нужно это делать". Мне не нравится NoSQL, потому что во многих случаях кажется, что он поднимает незнание.

Я знаю, что не могу делать транзакции через отношения... когда это будет большой проблемой?

Чаще, чем вы могли ожидать. Есть много вещей, которые могут пойти не так, когда вы не можете принять согласованный набор данных.

Ответ 6

Я использовал MongoDB, Redis (больше, чем ключ-значение пары поддерживает список, набор и отсортированный набор), Tokyo Tyrant, Memcached и MySql и PostgreSQL.

Аргументы между СУБД NoSQL и SQL на основе базы данных полностью необоснованны. Вам нужно выбрать подходящую модель, основанную на вашем случае использования. Если вам нужны ACID-совместимости, продолжайте работу с SQL DB, такой как PostgreSQL, Oracle и т.д. Вам нужна высокая производительность, но вы меньше заботитесь о данных, тогда вы можете рассмотреть базу данных noSQL. Это принципиально разные технологии. Вы даже можете использовать комбинацию моделей. С NoSQL у вас будут отсутствовать отношения, ограничения и иногда транзакция. Фактически, это причина, по которой NoSQL быстрее.

Как только я потерял два месяца совокупных данных с MongoDB.. Не знаю, как я их потерял. Но у меня была резервная копия, и я потерял несколько минут данных. Я вернул MongoDB с резервным копированием. Если вы используете NoSQL, производите резервное копирование или планирование заданий cron для резервного копирования базы данных. Это также применимо для SQL DB.

По сравнению с SQL RDBMS, базы данных NoSQL моложе, и они в настоящее время находятся в полной разработке, но СУБД NoSQL созрели в своей области, то есть они предназначены для высокой производительности и легкой репликации.

На моем веб-сайте (stacked.in) я использовал только redis DB, он работает намного быстрее, чем MySQL.

Ответ 7

Помните, что NoSQL не совсем новый. В конце концов, им нужно было что-то использовать перед SQL и реляционными базами данных, правильно? Фактически, такие системы, как MUMPS и CODASYL, работают одинаково и десятилетиями. Реляционные базы данных дают вам возможность запрашивать данные произвольным образом.

Скажите, что у вас есть база данных с клиентами, их покупки и какие предметы они приобрели. У базы данных NoSQL могут быть клиенты, содержащие покупки и покупки, содержащие элементы. Это позволяет легко узнать, какие предметы приобретает данный клиент, но трудно узнать, какие клиенты приобрели данный товар. Реляционная БД имела бы таблицы для клиентов, покупок, предметов и таблицы, связывающие предметы с покупками. В SQL оба запроса тривиальны для формулировки, а механизм базы данных делает для вас всю тяжелую работу.

Кроме того, имейте в виду, что часть тенденции NoSQL заключается в том, чтобы пожертвовать согласованностью или надежностью для скорости, масштабируемости и стоимости. Реляционные БД могут масштабироваться, но это не дешево. Если вы перейдете к http://tpc.org, вы можете найти RDBMS, которые работают на сотнях ядер одновременно, чтобы доставлять миллионы транзакций в минуту, но они стоят миллионов долларов.

Ответ 8

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