Почему кластер RDBM не может работать с NoSQL?

Один из больших плюсов для СУБД nosql заключается в том, что они могут сгруппировать более легко. Предположительно с NoSQL вы можете создавать сотни дешевых машин, которые хранят разные фрагменты данных и запрашивают все сразу.

Мой вопрос в том, почему реляционные СУБД не могут делать это как mysql или sql-сервер? Разве что поставщики просто не разработали технический способ сделать это с помощью своего существующего продукта, или есть некоторые проблемы с реляционной моделью, которая мешает этому быть выполнимым? Что отличает нас от NoSQL способ хранения и доступа к данным (ключ /значение, документы и т. Д.), Что упрощает кластеризацию, если это правда?

83 голоса | спросил fregas 17 FebruaryEurope/MoscowbSun, 17 Feb 2013 20:19:52 +0400000000pmSun, 17 Feb 2013 20:19:52 +040013 2013, 20:19:52

5 ответов


133

Распределенные системы баз данных 101

Или распределенные базы данных - что делает FK веб-масштаб «на самом деле означает?

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

Во-первых, некоторая терминология

Свойства ACID (Atomicity, Consistency, Isolation and Durability): Это ключевые инварианты, которые необходимо применять для надежной реализации транзакции, не вызывая нежелательных побочных эффектов.

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

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

Изоляция требует, чтобы транзакции не мешали друг с другом. Система должна гарантировать одинаковые результаты, если транзакции выполняются параллельно или последовательно. На практике большинство продуктов RDBMS позволяют режимам, изолирующим от производительности.

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

Я объясню некоторые технические препятствия, которые предъявляют эти требования к распределенным системам ниже.

Архитектура общего диска: Архитектура, в которой все обрабатывающие узлы в кластере имеют доступ ко всему хранилищу. Это может стать центральным узким местом для доступа к данным. Примером системы с общим диском является Oracle RAC или Exadata .

Архитектура без общих архитектур: Архитектура, в которой обрабатываются узлы в кластер имеет локальное хранилище, которое не видно другим узлам кластера. Примерами систем без общего доступа являются Teradata и Netezza .

Архитектура общей памяти: Архитектура, в которой несколько процессоров ( или узлы) могут получить доступ к общему пулу памяти. Большинство современных серверов имеют общий тип памяти. Общая память облегчает определенные операции, такие как кеши или примитивы атомной синхронизации, которые гораздо сложнее делать в распределенных системах.

Синхронизация: Общий термин, описывающий различные методы обеспечения последовательного доступа к общему ресурсу несколькими процессами или потоками. Это гораздо сложнее делать в распределенных системах, чем в системах с общей памятью, хотя некоторые сетевые архитектуры (например, BYNET) Teradata имеют примитивы синхронизации в сетевом протоколе. Синхронизация также может сопровождаться значительным объемом служебных данных.

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

Конечная согласованность: Термин, используемый для описания семантики транзакции, которая отменить немедленное обновление (согласованность при чтении) на всех узлах распределенной системы для выполнения(и, следовательно, более высокую пропускную способность транзакции) при записи. Конечная согласованность является побочным эффектом использования репликации кворума в качестве оптимизации производительности для ускорения транзакция совершает в распределенных базах данных, где несколько копий данных хранятся на отдельных узлах.

Алгоритм Лампорта: Алгоритм реализации взаимного исключения (синхронизация) через системы без общей памяти. Обычно взаимное исключение внутри системы требует атомарного считывания-сравнения-записи или аналогичной инструкции типа, обычно используемого только для общей системы памяти. Существуют и другие распространенные алгоритмы синхронизации, но Lamport's был одним из первых и является самым известным. Как и большинство распределенных механизмов синхронизации, алгоритм Lamport сильно зависит от точной синхронизации и синхронизации часов между узлами кластера.

Двухфазная фиксация (2PC): Семья протоколов, которые гарантируют, что обновления базы данных, включающие несколько физических систем, совершают или откатываются последовательно. Независимо от того, используется ли 2PC в системе или через несколько систем через диспетчер транзакций, она несет значительные накладные расходы.

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

Контроль параллелизма нескольких версий (MVCC): Управление конфликтом путем записи новых версий данных в другое место и разрешения другим транзакциям увидеть старую версию данных до тех пор, пока не будет выполнена новая версия. Это уменьшает конкуренцию базы данных за счет некоторого дополнительного трафика записи для записи новой версии, а затем старая версия старается устареть.

Алгоритм выбора: Распределенные системы с несколькими узлами по своей сути меньше чем одна система, так как есть больше режимов отказа. Во многих случаях необходим какой-то механизм для кластеризованных систем для устранения сбоя узла. Алгоритмы выбора - это класс алгоритмов, используемых для выбора лидера для координации распределенного вычисления в ситуациях, когда узел «лидер» не является на 100% определенным или надежным.

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

Облицовка: Набор данных может быть горизонтально разделенных на несколько физических узлов в архитектуре без общего доступа. Если это разделение не является прозрачным (то есть клиент должен знать схему раздела и определять, какой узел запрашивать явно), это называется очертаниями. Некоторые системы (например, Teradata) разделяют данные по узлам, но местоположение прозрачно для клиента; этот термин обычно не используется в сочетании с этим типом системы.

Согласованное хеширование: Алгоритм, используемый для распределения данных на разделы основанный на ключе. Он характеризуется равномерным распределением хэш-ключей и возможностью эластично расширять или уменьшать количество ковшей эффективно. Эти атрибуты делают его полезным для разделения данных или загрузки через кластер узлов, где размер может динамически изменяться с добавлением или удалением узлов из кластера (возможно, из-за сбоя).

Репликация нескольких мастеров: Техника, которая позволяет записывает через несколько узлов в кластере для репликации на другие узлы. Этот метод облегчает масштабирование, позволяя разбивать или разделять некоторые таблицы на разных серверах, а другие - на все кластеры. Записи должны быть реплицированы на все узлы, а не на кворум, так что транзакционные коммиты большедорогой в реплицируемой архитектуре с несколькими мастерами, чем на реплицируемой системе кворума.

Неблокирующий коммутатор: Сетевой коммутатор, который использует внутренние аппаратный параллелизм для достижения пропускной способности, который пропорционален количеству портов без внутренних узких мест. Наивная реализация может использовать перекрестный механизм, но это имеет сложность O (N ^ 2) для N портов, ограничивая ее меньшими коммутаторами. Более крупные коммутаторы могут использовать более сложную внутреннюю топологию, называемую неблокирующим минимальным оконечным коммутатором, для достижения линейного масштабирования пропускной способности без использования оборудования O (N ^ 2).

Создание распределенной СУБД - насколько это сложно?

Несколько технических проблем делают это довольно сложно на практике. Помимо дополнительной сложности построения распределенной системы, архитектор распределенной СУБД должен преодолеть некоторые сложные инженерные проблемы.

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

Согласованность распределенных систем: Чтобы принять пример внешнего ключа, приведенный выше, система должна иметь возможность оценивать согласованное состояние. Например, если родительский и дочерний отношения внешнего ключа могут находиться на разных узлах, необходим какой-то механизм распределенного блокирования, чтобы гарантировать, что устаревшая информация не используется для проверки транзакции. Если это не применяется, вы можете иметь (например) условие гонки, в котором родитель удаляется после проверки его присутствия, прежде чем разрешить вставку ребенка.

Задержка принудительного применения ограничений (т. е. ожидания до фиксации для подтверждения DRI) требует блокировки, которая должна удерживаться на время транзакции. Этот тип распределенной блокировки имеет значительные накладные расходы.

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

Изоляция на распределенных системах: . Если данные, затронутые транзакцией, находятся на нескольких системных узлах, блокировки и версия (если используется MVCC) должны быть синхронизированы по узлам. Гарантируя сериализацию операций, особенно в архитектурах без общего доступа, где избыточные копии данных могут храниться, необходим механизм распределенной синхронизации, такой как алгоритм Lamport, который также имеет значительные накладные расходы в сетевом трафике.

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

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

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

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

Системы с общим диском

Система с общим диском - это та, где все узлы имеют доступ ко всему хранилищу. Таким образом, вычисление не зависит от местоположения. Многие платформы СУБД также могут работать в этом режиме - Oracle RAC является примером такой архитектуры.

Общие дисковые системы могут существенно масштабироваться, поскольку они могут поддерживать связь M: M между узлами хранения и узлами обработки. SAN может иметь несколько контроллеров, а несколько серверов могут запускать базу данных. Эти архитектуры имеют переключатель в качестве центрального узкого места, но переключатели перекладины позволяют этому переключателюимеют большую пропускную способность. Некоторая обработка может быть выгружена на узлы хранения (как в случае с Exadata Oracle), что может уменьшить трафик на пропускной способности хранилища.

Хотя коммутатор теоретически является узким местом, доступная полоса пропускания означает, что архитектуры с общим диском будут достаточно эффективно масштабироваться для больших объемов транзакций. Большинство основных архитектур СУБД используют этот подход, поскольку он обеспечивает достаточно хорошую масштабируемость и высокую надежность. С избыточной архитектурой хранения, такой как волоконный канал, нет единой точки отказа, поскольку между любым обрабатывающим узлом и любым узлом хранения есть как минимум два пути.

Системы общего доступа

Системы без общего доступа - это системы, в которых по крайней мере некоторые данные хранятся локально на узле и не видны непосредственно другим узлам. Это устраняет узкое место центрального коммутатора, позволяя базе данных масштабироваться (по крайней мере теоретически) с количеством узлов. Горизонтальное разбиение позволяет разделить данные по узлам; это может быть прозрачным для клиента или нет (см. выше).

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

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

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

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

Облицовка, репликация кворума и конечная согласованность

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

Однако репликация записей во все узлы O (M x N) для M узлов и N пишет. Это делает записи дорогими, если запись должна быть реплицирована на все узлы до того, как транзакция будет разрешена. Репликация кворума является компромиссом, который позволяет записывать репликации в подмножество узлов немедленно, а затем лениво выписывается на другие узлы с помощью фоновой задачи. Записи могут выполняться более быстро, обеспечивая при этом определенную степень избыточности, гарантируя, что они реплицируются в минимальное подмножество (кворум) узлов до того, как транзакция будет сообщена как переданная клиенту.

Это означает, что чтение узлов вне кворума может отображать устаревшие версии данных до тех пор, пока фоновый процесс не завершит запись данных в остальные узлы. Семантика называется «Конечная согласованность» и может быть или не быть приемлемой в зависимости от требований вашего приложения, но означает, что транзакционные транзакции ближе к O (1), чем O (n) при использовании ресурсов.

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

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

Например, BigTable Google не реализует репликацию кворума посам, хотя он и сидит в GFS, кластерной файловой системе, которая использует репликацию кворума. BigTable (или любая система без общего доступа) может использовать надежную систему хранения с несколькими контроллерами и разбивать данные среди контроллеров. Параллельный доступ затем будет достигнут путем разбиения данных.

Вернуться к платформам РСУБД

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

Системы с общим доступом и общим доступом могут масштабироваться до очень больших рабочих нагрузок. Например, Oracle RAC может поддерживать 63 обрабатывающих узла (которые могут быть большими SMP-машинами сами по себе) и произвольное количество контроллеров хранения в SAN. IBM Sysplex (кластер мейнфреймов zSeries) может поддерживать несколько мэйнфреймов (каждый из которых обладает значительной вычислительной мощностью и собственной пропускной способностью ввода-вывода) и несколькими контроллерами SAN. Эти архитектуры могут поддерживать очень большие объемы транзакций с использованием семантики ACID, хотя они и предполагают надежное хранение. Teradata, Netezza и другие производители делают высокопроизводительные аналитические платформы на основе проектов без общего доступа, которые масштабируются до чрезвычайно больших объемов данных.

До сих пор на рынке недорогих, но сверхвысоких объемов полноразмерных платформ ACID RDBMS доминировал MySQL, который поддерживает репликацию sharding и multi-master. MySQL не использует репликацию кворума для оптимизации пропускной способности записи, поэтому транзакционные транзакции стоят дороже, чем в системе NoSQL. Sharding обеспечивает очень высокую пропускную способность чтения (например, Facebook широко использует MySQL), поэтому этот тип архитектуры хорошо масштабируется при нагрузках с высокой нагрузкой.

Интересная дискуссия

BigTable - это архитектура без совместного использования (по существу, распределенная пара ключей), как указано Майклом Hausenblas ниже . Моя первоначальная оценка его включала механизм MapReduce, который не является частью BigTable, но обычно используется в сочетании с ним в наиболее распространенных реализациях (например, Hadoop /HBase и Google MapReduce).

Сравнивая эту архитектуру с Teradata, которая имеет физическое сходство между хранилищем и обработкой (то есть узлы имеют локальное хранилище, а не общую SAN), вы можете утверждать, что BigTable /MapReduce является общей дисковой архитектурой через глобально видимую параллельную систему хранения.

Пропускная способность системы стиля MapReduce, такая как Hadoop, ограничена пропускной способностью неблокирующего сетевого коммутатора. 1 Неблокирующие коммутаторы могут, однако, обрабатывать агрегаты большой полосы пропускания из-за параллелизма, присущего дизайну, поэтому они редко являются существенным практическим ограничением производительности. Это означает, что архитектура общего диска (возможно, более известная как система с общим хранилищем) может масштабироваться до больших рабочих нагрузок, даже если сетевой коммутатор теоретически является центральным узким местом.

Исходным моментом было отметить, что, хотя это центральное узкое место существует в системах с разделяемыми дисками, секционированная подсистема хранения с несколькими узлами хранения (например, серверы планшетов BigTable или контроллеры SAN) может масштабироваться до больших рабочих нагрузок. Архитектура неблокирующего коммутатора может (теоретически) обрабатывать столько текущих соединений, сколько имеет порты.

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

ответил ConcernedOfTunbridgeWells 17 FebruaryEurope/MoscowbSun, 17 Feb 2013 22:28:52 +0400000000pmSun, 17 Feb 2013 22:28:52 +040013 2013, 22:28:52
18

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

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

Для компании, в которой я работаю, Clustrix , предлагает серию гомогенных вычислительных и запоминающих узлов, подключенных по высокоскоростной сети. Реляционные данные хеш распределяются по узлам на основе каждого индекса в кусках, которые мы называем «срезами». Каждый срез будет иметь две или более реплик, распределенных по всему кластеру, для обеспечения долговечности в случае сбоя узла или диска. Клиенты могут подключаться к любому узлу кластера для выпуска запросов с использованием протокола проводки MySQL.

Немного неестественно думать о компонентах базы данных ACID независимо от того, что так много из них соединяется вместе, но здесь говорится:

Atomicity . Clustrix использует двухфазные фиксации для обеспечения атомарности. Операции UPDATE и DELETE также блокируют строки через наш распределенный менеджер блокировки, потому что мы внутренне превращаем эти операции в SELECT, а затем выполняем точные операции UPDATE /DELETE.

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

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

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

Изоляция . Clustrix обеспечивает изоляцию MVCC на уровне контейнера. Наша атомарность гарантирует, что все применимые реплики получат конкретную запись, прежде чем сообщать о совершенной транзакции, в основном уменьшает проблему изоляции до того, что вы имели бы в некластерном случае.

Долговечность . Каждый фрагмент реляционных данных хранится в двух или более узлах для обеспечения отказоустойчивости в случае сбоя узла или диска. Также, вероятно, стоит отметить, что версия устройства нашего продукта имеет карту NVRAM, где WAL хранится по соображениям производительности. Многие базы данных с одним экземпляром улучшают производительность своих WAL с помощью контрольных точек с интервалами, а не при каждой фиксации. Этот подход проблематичен в распределенной системе, потому что делает «переигрывание туда»? сложный вопрос. Мы избегаем этого в приборе, предоставляя надежную гарантию долговечности.

ответил Matt 5 MaramTue, 05 Mar 2013 06:39:44 +04002013-03-05T06:39:44+04:0006 2013, 06:39:44
11

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

Основная точка модели согласованности ACID заключается в том, что она создает кучу фундаментальных гарантий относительно состояния данных во всем мире внутри системы. Эти гарантии подпадают под ограничения теорем CAP, которые в основном означают, что для их работы вам необходимо иметь все авторитетные источники на одной странице, прежде чем вы сообщите заявке, которую совершили транзакцию. Таким образом, репликация с несколькими мастерами очень трудно обойтись без использования этих ограничений. Конечно, как только вы начинаете делать асинхронную репликацию в среде с несколькими мастерами, эти гарантии выходят из окна. Модель согласования ACID представляет собой сильную модель согласованности, предназначенную для важной или важной информации.

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

Возможности RDBMS и масштабирование, а также решения NoSQL, хотя!

Однако есть случаи, когда RDBMS могут масштабироваться до такой степени, что NoSQL может даже не соответствовать. Он просто делает это по-другому. Я буду рассматривать Postgres-XC как пример того, как масштабирование возможно, не жертвуя сильными гарантиями последовательности.

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

Модель Postgres-XC, я понимаю, вдохновлена ​​Teradata. Он состоит из узлов в двух разных ролях, таких как узлы хранения или координаторы. Координаторы являются многомастными (не задействована реальная репликация), и они подключаются к узлам хранения для обработки фактической обработки данных. Узлы хранения реплицируются в настройке ведущий-ведомый. Каждый узел хранения содержит то, что по сути является осколком базы данных, но координаторы поддерживают согласованную картину данных.

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

В этом отношении Postgres-XC предлагает что-то вроде параметров масштабирования NoSQL, но есть дополнительная сложность из-за дополнительных гарантий согласованности. Я понимаю, что есть коммерческие РСУБД, которые предлагают такую ​​масштабируемость. Терадата делает это. Кроме того, общие дисковые системы могут масштабироваться аналогичным образом, и DB2 и Oracle предлагают такие решения. Поэтому совершенно несправедливо говорить, что РСУБД не могут этого сделать. Они могут. Однако в прошлом потребность была настолько мала, что экономия на масштабе была недостаточной для того, чтобы сделать проприетарные решения очень доступными для большинства игроков.

Наконец, заметка о VoltDB. Как и решения NoSQL, я вижу VoltDB как очень специализированный инструмент. Это очень быстро, но за счет многократных транзакций и долговечности на диске. Это означает, что у вас очень разные проблемы. VoltDB - это то, что вы получаете, когда пионеры РСУБД строят решение NoSQL ;-). VoltDB быстро развивается из-за того, что он определяет параллелизм и долговечность из уравнения. Долговечность становится сетевым свойством, а не внутренним хостингом, а управление параллелизмом управляется запуском запросов по одному, внутренне распараллеленным, в последовательном порядке. Это не традиционная СУБД (и это хорошая вещь, так как она может пойти, но традиционные RDBMS не могут, но обратное тоже очень верно).

ответил Chris Travers 23 FebruaryEurope/MoscowbSat, 23 Feb 2013 15:05:08 +0400000000pmSat, 23 Feb 2013 15:05:08 +040013 2013, 15:05:08
5

Мой ответ будет не так хорошо написан как предыдущий, но здесь идет.

Майкл Стоунбрейкер из «Ингрской славы» создал хранилище столбцов MPP shared-nothing (Vertica) и базу данных New SQL без базы данных MPP (VoltDB), которая распределяет данные между различными узлами в кластере и поддерживает ACID. С тех пор Vertica была куплена HP.

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

Вот рассказ Stonebraker дал новый SQL относительно NoSQL и «Старый SQL». http://www.youtube.com/watch?v=uhDM4fcI2aI

ответил geoffrobinson 22 FebruaryEurope/MoscowbFri, 22 Feb 2013 18:14:18 +0400000000pmFri, 22 Feb 2013 18:14:18 +040013 2013, 18:14:18
0

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

ответил Jeremy Singer 15 MaramFri, 15 Mar 2013 04:40:56 +04002013-03-15T04:40:56+04:0004 2013, 04:40:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132