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

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

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

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

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

Сначала немного терминологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изоляция в распределенных системах. В тех случаях, когда данные, затронутые транзакцией, находятся на нескольких узлах системы, блокировки и версия (если используется MVCC) должны быть синхронизированы между узлами. Чтобы гарантировать сериализуемость операций, особенно на архитектурах без совместного использования ресурсов, где могут храниться избыточные копии данных, требуется механизм распределенной синхронизации, такой как алгоритм Лампорта, который также сопровождается значительными издержками в сетевом трафике.

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

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

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

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

Shared-Disk системы

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

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

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

Системы Shared-Nothing

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

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

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

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

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

Sharding, репликация кворума и возможная согласованность

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

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

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

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

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

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

Вернуться на платформы RDBMS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СУБД могут и делают масштабирование так же, как и решения NoSQL, хотя!

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

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

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

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

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

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

Редактировать: Также важно учитывать значение объединений. В кластерных системах объединения становятся совсем другой проблемой производительности. Если все находятся на одном и том же узле, они могут повысить производительность, но если вам нужно совершить обратное путешествие в другой узел, это повлечет за собой очень высокую стоимость. Таким образом, модели данных действительно имеют значение, а подход кластеризации влияет на производительность. Такие подходы, как Postgres-XC и Postgres-XL, предполагают, что вы можете потратить немало времени на обдумывание вещей, чтобы вы могли надлежащим образом защитить свои данные и хранить объединенные данные вместе. Но это накладывает на дизайн накладные расходы. С другой стороны, это масштабируется намного лучше, чем многие решения NoSQL, и может быть настроено соответствующим образом. Например, мы (в Adjust) используем NoSQL-подобную стратегию кластеризации для наших 3.5PB данных в PostgreSQL, которая в основном представляет собой анализ журнала. И многие наши разработки глубоко вдохновлены кластерными стратегиями NoSQL. Поэтому иногда модель данных также ограничивает модель кластеризации.

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

Майкл Стоунбрейкер, известный в Ingres, создал хранилище столбцов MPP без разделения ресурсов (Vertica) и новую базу данных SQL MPP без разделения ресурсов (VoltDB), которая распределяет данные между различными узлами в кластере и поддерживает ACID. С тех пор Vertica была куплена HP.

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

Вот доклад Стоунбрейкера о новом SQL относительно NoSQL и "старого SQL". http://www.youtube.com/watch?v=uhDM4fcI2aI

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