NimbusDB - распределенный неблокирующий протокол атомарной фиксации?
С веб-сайта NimbusDB:
Наш распределенный неблокирующий протокол атомарной фиксации позволяет обрабатывать транзакции базы данных на любом доступном узле.
Они утверждают, что могут гарантировать транзакции ACID в распределенной среде и обеспечивают все: согласованность, высокую доступность и терпимость к разделам. Насколько я могу судить по тексту, их "секрет" преодоления ограничений теоремы CAP - это своего рода "предсказуемый и последовательный" способ управления сетевыми разделами.
Мне интересно, есть ли у кого-нибудь какие-то идеи или дополнительная информация о том, что стоит за этим?
2 ответа
Прошло много времени с тех пор, как этот пост был написан, и с тех пор NuoDB много добавила в свои маркетинговые и технические ресурсы на своем веб-сайте.
Они достигли надежности данных и соответствия ACID, используя свою систему распределенного кэша данных. Теперь они называют это " 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:
Все реляционные базы данных общего назначения на сегодняшний день построены вокруг предположения, ориентированного на хранение. К сожалению, это создает фундаментальную проблему относительно масштабирования. По сути, эти системы баз данных представляют собой модные файловые системы, которые обеспечивают одновременный доступ для чтения / записи к дисковым файлам таким образом, чтобы пользователи не мешали друг другу.
Архитектура DDC NuoDB переворачивает эту идею, представляя базу данных как набор контейнерных объектов в памяти, которые при необходимости могут переполняться на диск и могут храниться в резервных хранилищах в целях обеспечения долговечности.
Все серверы в архитектуре NuoDB DDC могут запрашивать и предоставлять объекты (называемые атомами), тем самым действуя как одноранговые узлы. Некоторые серверы имеют подмножество объектов в любой момент времени и поэтому могут предоставлять только подмножество базы данных другим серверам. Другие серверы имеют все объекты и могут предоставить любой из них, но будут медленнее предоставлять объекты, которые не находятся в памяти.
NuoDB состоит из двух типов серверов: Transaction Engine (TE) содержат подмножество объектов; Менеджеры хранилищ (SM) - это серверы, которые имеют полную копию всех объектов. TE чистые в серверах памяти, которым не нужно использовать диски. Они автономны и могут в одностороннем порядке загружать и извлекать объекты из памяти в соответствии с их потребностями. В отличие от TE, SM не могут просто бросать предметы на пол, когда они закончили с ними; вместо этого они должны гарантировать, что они надежно помещены в долговременное хранилище.
Для тех, кто знаком с архитектурой кэширования, вы, возможно, уже поняли, что эти TE в действительности являются распределенным кешем DRAM, а SM являются специализированными TE, которые обеспечивают долговечность. Отсюда и название Durable Distributed Cache.
Они также публикуют технический технический документ, в котором подробно рассматриваются компоненты подсистемы и способы их совместной работы, чтобы обеспечить RIDBS, совместимую с ACID, с большей производительностью системы NoSQL (ПРИМЕЧАНИЕ. бумага). Общая суть в том, что они предоставляют автоматизированную систему разбиения кластеров в сети, которая в сочетании с их системой постоянного хранения решает проблемы теоремы CAP.
Есть также много информативных технических документов и независимых аналитических отчетов по их технологиям в их онлайн-библиотеке документов.
Есть несколько возможных значений слова "последовательность". Смотрите, например, Почему C в теореме CAP не совпадает с C в ACID?,
Кроме того, возможен некоторый уровень дебатов относительно значения C в "ACID": хотя он обычно определяется в смысле, связанном с целостностью базы данных ("ни одна транзакция не должна видеть состояние базы данных, которое нарушает объявленное ограничение"). - по модулю несоответствий, которые эта транзакция сама создала "), один комментатор сказал, что он интерпретировал это как ссылку на" состояние базы данных, которое видно (или, возможно, лучше, насколько эффективно используется) любой транзакцией, не изменяется, пока эта транзакция находится в progress Перефразировано: транзакции совместимы с ACID, если они выполняются как минимум в режиме повторяющегося чтения.
Если вы используете CAP-C для обозначения "все узлы видят одни и те же данные одновременно", то доступность обязательно будет ограничена, потому что, хотя система занята распределением данных по различным узлам, она не может разрешить доступ любой транзакции к старшие версии) эти данные. (Если, конечно, доступ к старшим версиям - это как раз то, что нужно, например, когда транзакция выполняется в MVCC.)
Если вы воспринимаете CAP-C как нечто вроде "ни одна транзакция не может увидеть несовместимое состояние базы данных", то, по сути, применяется то же самое, за исключением того, что теперь процесс обновления пользователя должен блокировать доступ для всех другие транзакции.
Если вы навязываете правило о том, что "всякий раз, когда транзакция получила доступ к определенному узлу N для чтения из какого-либо ресурса R (предполагая, что к R теоретически можно получить доступ более чем к одному узлу), то всякий раз, когда эта транзакция снова обращается к R, она должна делать поэтому на том же узле N.", тогда я могу представить, что это увеличит вашу гарантию" согласованности ", но вы платите за доступность, потому что, если узел N выпадает, то именно из-за наложенного правила ваша транзакция больше не сможет получить доступ к R даже если это можно сделать на других узлах.
В любом случае, я думаю, что если такое учреждение, как Беркли, представит доказательство какой-то теоремы, то вы в безопасности, если вы будете рассматривать громкие заявления, такие как упомянутое вами, как ложь маркетинга.