Имеет ли смысл использовать NoSQL для нераспределенной системы?(пытаясь понять возможную последовательность)

Question

Последние два дня я читал и изучал NoSQL и MongoDB, CouchDB и т. Д., Но до сих пор не могу определить, подходит ли мне этот тип хранилища.

Что беспокоитя - это постоянная вещь последовательности.Этот тип согласованности только включается при использовании кластеров?(Я размещаю свои сайты на одном выделенном сервере, поэтому я не знаю, могу ли я извлечь выгоду из NoSQL). Для каких типов приложений нормально иметь конечную согласованность (вместо ACID), а для каких нет?т?Можете ли вы дать мне несколько примеров?Что самое худшее, что может произойти в приложении, для которого нормально иметь конечную согласованность?

Еще одна вещь, которую я прочитал, это то, что MongoDB хранит много вещей в памяти.В документах говорится о 32-битных системах с ограничением данных в 2 ГБ.Это из-за ограничения оперативной памяти для 32-битных систем?

Answer 1

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

CouchDB полностью КИСЛОТНЫЙ. Обновление документа является атомарным, непротиворечивым, изолированным и долговечным (используя рекомендованный производственный параметр CouchDB для delayed_commits = false, ваше обновление записывается на диск до возврата кода успеха 201). не обеспечивает CouchDB - это многоэлементные транзакции (поскольку их очень трудно масштабировать, когда элементы хранятся на отдельных серверах). Неразбериха между «транзакцией» и «ACID» вызывает сожаление, но простит с учетом того, что типичные РСУБД обычно поддерживают и то и другое.

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

Хитрость в возможной согласованности заключается в том, как обрабатываются обновления одного и того же элемента на разных хостах. В CouchDB эти отдельные обновления обнаруживаются как «конфликты» для одного и того же элемента, и репликация гарантирует, что все конфликтующие обновления присутствуют на всех хостах. CouchDB затем выбирает один из них для представления в качестве текущей ревизии. Этот выбор можно изменить, удалив конфликты, которые никто не хочет оставлять.

Answer 2

• Последние два дня я читал и изучал NoSQL и MongoDB, CouchDB и т. Д., Но до сих пор не могу сказать, подходит ли мне этот тип хранилища.

Базы данных NoSQL решают набор проблем , которые трудно решить с помощью традиционных RDMS. NoSQL может быть the right storage for you, если в этом наборе есть какие-либо проблемы.

• Возможна ли согласованность только при использовании кластеров?

Возможная согласованность «включается», когда вы могли бы прочитать назад другую / предыдущую версию данных из той, которая была только что сохранена. Например:

Вы сохраняете один и тот же фрагмент данных в БОЛЬШЕ, ЧЕМ ОДИН , скажем, A и B. В зависимости от конфигурации, операция persist может вернуться только после сохранения в A (а не в B только что ). Сразу после этого вы читаете эти данные из B, которого еще нет. В конце концов оно будет там, но, к сожалению, нет, когда вы прочитаете его обратно

• Для каких приложений нормально иметь согласованность (вместо ACID), а для каких нет?

NOT OK => У вас есть семейный банковский счет на 100 долларов США. Теперь вы и ваш супруг пытаетесь купить что-то одновременно (в разных магазинах) за 100 долларов. Если бы банк реализовал это с помощью модели «возможной согласованности», например, для более чем одного узла, ваш супруг (а) мог бы потратить 100 долларов через пару миллисекунд после того, как вы уже потратили все это. Не очень хороший день для банка.

OK => У вас 10000 подписчиков в Twitter. Вы написали в твиттере: «Эй, кто хочет сегодня взломать?». 100% -ная согласованность будет означать, что ВСЕ эти 10000 получат ваше приглашение одновременно. Но на самом деле ничего плохого не случилось бы, если бы Джон увидел твой твит через 2 секунды после Мэри.

• Что самое худшее, что может произойти в приложении, для которого нормально иметь конечную согласованность?

Огромная задержка между например. когда узел A получает данные, а узел B получает те же данные [они синхронизированы]. Если бы решение NoSQL было надежным, это могло бы случиться хуже.

• Еще одна вещь, которую я прочитал, это то, что MongoDB хранит много вещей в памяти. В документах говорится о 32-битных системах с ограничением данных в 2 ГБ. Это из-за ограничения оперативной памяти для 32-битных систем?

из документов MongoDB:

" MongoDB - это серверный процесс, работающий в Linux, Windows и OS X. Его можно запускать как 32- или 64-разрядное приложение. Рекомендуется запускать в 64-разрядном режиме, поскольку Mongo ограничен общий размер данных около 2 ГБ для всех баз данных в 32-разрядном режиме."

Answer 3

Теорема Brewers CAP - лучший источник, чтобы понять, какие варианты доступны для вас. Я могу сказать, что все зависит, но если мы говорим о Mongo, то он обеспечивает горизонтальную масштабируемость из коробки, и это всегда приятно в некоторых ситуациях.

Теперь о последовательности. На самом деле у вас есть три варианта обновления ваших данных:

1) Первое, что нужно рассмотреть, это «безопасный» режим или «getLastError ()», как указано Андреасом. Если вы выполняете «безопасную» запись, вы знаете, что база данных получила вставку и применила запись. Однако MongoDB сбрасывается на диск только каждые 60 секунд, поэтому сервер может выйти из строя без данных на диске.

2) Второе, что нужно рассмотреть, это «ведение журнала» (v1.8 +). При включенном ведении журнала данные отправляются в журнал каждые 100 мс. Таким образом, у вас есть меньшее время до сбоя. Драйверы имеют опцию «fsync» (проверьте это имя), которая идет на один шаг дальше, чем «безопасная», она ожидает подтверждения того, что данные были сброшены на диск (то есть файл журнала). Однако это касается только одного сервера. Что произойдет, если жесткий диск на сервере просто умрет? Ну, вам нужен второй экземпляр.

3) Третье, что нужно учитывать, это репликация Драйверы поддерживают параметр «W», который говорит «реплицируйте эти данные на N узлов» перед возвратом. Если запись не достигает «N» узлов до истечения определенного времени ожидания, запись завершается неудачно (генерируется исключение). Однако вам необходимо правильно настроить букву «W» в зависимости от количества узлов в вашем наборе реплик. Опять же, поскольку жесткий диск может выйти из строя, даже при ведении журнала, вы захотите посмотреть на репликацию. Затем происходит репликация в центрах обработки данных, которая слишком длинна, чтобы попасть сюда. Последнее, что нужно учитывать, это ваше требование «откатиться». Насколько я понимаю, MongoDB не обладает такой способностью «отката». Если вы делаете пакетную вставку, лучшее, что вы получите, это указание на то, какие элементы потерпели неудачу.

Во всяком случае, существует множество сценариев, когда согласованность данных становится обязанностью разработчика, и вы должны быть осторожны и включать все сценарии и корректировать схему БД, потому что нет «Это правильный способ сделать это» в Монго, как мы привыкли в RDB-ы.

О памяти - это вопрос производительности, MongoDB хранит индексы и «рабочий набор» в оперативной памяти. Ограничивая вашу оперативную память, вы ограничиваете свой рабочий набор. На самом деле вы можете иметь SSD и меньший объем оперативной памяти, а не огромное количество RAM и HDD - по крайней мере, это официальные рекомендации. В любом случае, этот вопрос индивидуален, вы должны выполнить тесты производительности для ваших конкретных случаев использования