NimbusDB - распределенный неблокирующий протокол атомарной фиксации? - PullRequest
2 голосов
/ 19 мая 2011

с веб-сайта NimbusDB :

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

Они утверждают, что могут гарантировать транзакции ACID в распределенной среде и обеспечивают все: согласованность, высокую доступность и допуск раздела. Насколько я могу судить по тексту, их «секрет» преодоления ограничений теоремы CAP - это своего рода «предсказуемый и последовательный» способ управления сетевыми разделами.

Мне интересно, есть ли у кого-нибудь какие-то идеи или дополнительная информация о том, что стоит за этим?

Ответы [ 2 ]

3 голосов
/ 20 мая 2011

Существует несколько возможных значений слова «согласованность». См., Например, Почему C в теореме CAP не совпадает с C в ACID? .

Кроме того, возможен некоторый уровень дебатов относительно значения C в «ACID»: хотя оно обычно определяется в смысле, который относится к целостности базы данных («ни одна транзакция не должна видеть состояние базы данных, которое нарушает» объявленное ограничение - по модулю несоответствий, которые эта транзакция создала сама, разумеется "), один комментатор сказал, что он интерпретировал это как ссылку на" состояние базы данных, которое видно (или, возможно, лучше, насколько эффективно используется) любой транзакцией, не изменяется, пока транзакция выполняется. Перефразировано: транзакции совместимы с ACID, если они выполняются как минимум в режиме повторяющегося чтения.

Если вы берете CAP-C в значении «все узлы видят одни и те же данные одновременно», то доступность обязательно ограничивается, потому что, пока система занята распределением данных между различными узлами, она не может разрешить какой-либо транзакционный доступ (старшие версии) этих данных. (Если, конечно, доступ к старшим версиям - это как раз то, что нужно, например, когда транзакция выполняется в MVCC.)

Если вы воспринимаете CAP-C как нечто вроде «ни одна транзакция не может увидеть несовместимое состояние базы данных», то, по сути, применяется то же самое, за исключением того, что теперь процесс обновления пользователя должен блокироваться. доступ ко всем другим транзакциям.

Если вы навязываете правило о том, что «всякий раз, когда транзакция получила доступ к определенному узлу N для чтения из какого-либо ресурса R (предполагая, что к R теоретически может быть получен доступ более чем на одном узле), то всякий раз, когда эта транзакция снова обращается к R, он должен делать это на том же узле N. ", тогда я могу представить, что это увеличит вашу гарантию" согласованности ", но вы платите за доступность, потому что, если узел N выпадает, то именно из-за наложенного правила ваша транзакция не может получить доступ к R больше, даже если это можно сделать на других узлах.

Во всяком случае, я думаю, что если такое учреждение, как Беркли, предложит доказательство какой-либо теоремы, то вы в безопасности, если вы считаете громкие заявления, такие как упомянутое вами, ложью маркетинга *. 1013 *

1 голос
/ 16 июня 2014

Прошло много времени с тех пор, как этот пост был написан, и с тех пор NuoDB много добавила в свои маркетинговые и технические ресурсы по продуктам на своем веб-сайте.Система кеширования данных.Теперь они называют это « Emergent Architecture: » (стр. 6-7)

Архитектура открывает множество возможных будущих направлений, включая «путешествие во времени»возможность создавать копию базы данных, которая воссоздает свое состояние в более раннее время;«Облачный взрыв» - способность перемещать базу данных по облачным системам, управляемым отдельными группами;и «связывает» механизм, который обращается к теореме CAP, позволяя администратору базы данных указать, какие системы выдерживают сетевой раздел, чтобы обеспечить согласованность и устойчивость раздела с непрерывной доступностью.

Со страницы Как это работает Страница:

Современные поставщики баз данных применяют три общих шаблона проектирования для традиционных систем, чтобырасширить их в распределенных масштабируемых системах баз данных.Эти подходы - Shared-Disk, Shared-Nothing и Synchronous Commit - преодолевают некоторые ограничения развертываний на одном сервере, но остаются сложными и подвержены ошибкам.

Путем отступления и переосмысления дизайна базы данных с нуляДжим Старки, технический основатель NuoDB, предложил совершенно новый подход к разработке, который называется Durable Distributed Cache (DDC).Чистый эффект - это система, которая динамически масштабируется / расширяется на обычных машинах и виртуальных машинах, не имеет единой точки отказа и обеспечивает полную семантику транзакций ACID.

Основное архитектурное отличиеМежду моделью NewSQL NuodDB и моделью более традиционных систем RDMS является то, что NuoDB инвертирует традиционные отношения между памятью и хранилищем, создавая совместимую с ACID RDBMS с базовой конструкцией, аналогичной распределенной кэш-памяти DRAM.Со страницы NuoDB Durable Distributed Cache :

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

Архитектура DDC NuoDB переворачивает эту идею, представляя собой базу данныхкак набор контейнерных объектов в памяти, которые при необходимости могут переполняться на диск и могут храниться в резервных хранилищах в целях обеспечения долговечности.

Все серверы в архитектуре NuoDB DDC могут запрашивать и предоставлять объекты (называемые атомами).) тем самым действуя как равные друг другу.Некоторые серверы имеют подмножество объектов в любой момент времени и поэтому могут предоставлять только подмножество базы данных другим серверам.Другие серверы имеют все объекты и могут предоставлять любые из них, но будут медленнее предоставлять объекты, которые не находятся в памяти.

NuoDB состоит из двух типов серверов: Механизмы транзакций (TE) содержат подмножествообъекты;Менеджеры хранилищ (SM) - это серверы, которые имеют полную копию всех объектов.TE чистые в серверах памяти, которым не нужно использовать диски.Они автономны и могут в одностороннем порядке загружать и извлекать объекты из памяти в соответствии с их потребностями.В отличие от TE, SM не могут просто уронить объекты на пол, когда они закончили с ними;вместо этого они должны гарантировать, что они надежно размещены в надежном хранилище.

Для тех, кто знаком с архитектурами кэширования, вы, возможно, уже поняли, что эти TE в действительности являются распределенным кешем DRAM, а SM являются специализированными TE,долговечность.Отсюда и название Durable Distributed Cache.

Они также опубликовать технический документ , в котором подробно рассматриваются компоненты подсистемы и способы их совместной работы, чтобы обеспечить RIDBS, совместимую с ACID, с большей производительностью системы NoSQL (ПРИМЕЧАНИЕ.скачать документ).Общая суть заключается в том, что они предоставляют автоматизированную систему разделения сетевых кластеров, которая в сочетании с их системой постоянного хранения решает проблемы, связанные с теоремой CAP .

. Существует также много информативных техническихофициальные документы и независимые аналитические отчеты об их технологии в их онлайн-библиотеке документов

...