Комментарии 31
Проблема Писатель-Писатель принципиально не решается без proxy-сервиса на логическом уровне анализа SQL-трафика приложения.
Извините, но это не так.
SET Итог = Итог+ДельтаТаких алгоритмов в принципе не существует, ...
просто добавить Итог в условие, или поле версии - инкремент
Много читать, еле осилил, но так и не нашел:
- Master-Master, подразумевает возможность записи на любой мастер. У вас один вход в прокси.
- в двух словах - САР теорему как решили?
Про Писатель-Писатель комментария не понял.
Про САР , это побатчевая(позапросная) синхронизация запросов на изменение - запрос на изменение идет на все сервера( разумеется параллельно, асинхронно)и ждет подтверждения от всех, только потом переходит к следующему запросу. В конце транзакции обязательная сверка состава по хэш сумме(на случай перепутывания потоков). В случае несовпадения, ошибка и откат, либо если возможно автокоррекция.(это должно происходить крайне редко), в определенных случаях(принимает решение прокси) использование централизованного механизма принятия изменения(но дает большие издержки)
нельзя настроить транзакционную репликацию, добиться синхронности данных на множестве серверов и сказать, что это кластер СУБД.
кроме того, что можно, так вы сами это и делаете.
то что вы рассказываете - старый добрый 2РС, и его ХА транзакции.
При параллельном выполнении от всех серверов на всех серверах - очень быстро заканчиваются коннекты.
Короче, как делают:
Если заменить ваш хэш на серийный номер транзакции, как в РАФТ протоколе, не исключает хеш, как дополнительную проверку. Прокси сделать в виде GTC - Global Transaction Coordinator, который определяет мастера. Все сервера - могут писать, если сервер падает, то падают подключенные клиенты и выполняемые транзакции. клиенты переподключаються, и перевыполняют транзакции, так-же как в без кластерном варианте... я не буду цикл стаей делать, бета кластера доступна и бесплатна.
Ванильный постгрес со всеми транзакциями
Переезд на кластер и обратно, без копирования данных
Почти линейная масштабируемость
Я человек простой). Вы на вашем(описанном) решении сможеет запустить 1С 8.х, равномерно распределить нагрузку по физическим серверам постгрес? Если да, то я могу вам клиентов набросать) Да и сам за реализацию заплатил бы, что бы посмотреть. Мы например проводим нагрузочные тесты, скоро будем запускать первые внедрения.
Я с 1С не работал, лет 20. Если клиенты разные - то или на DNS балансировать, или Т3 урл, клиент будет выбирать сервер.
"бета кластера доступна и бесплатна", обращайтесь
Не понял, а чем относительно стандартная реализация построения кластер высокой доступности для постгре не устраивает? Postgresql, patroni, etcd, keepalived, haproxy, pgbouncer.. Стандартная потоковая репликация (асинхронная или синхронная), лидер (запросы на запись/чтение) и несколько реплик (запросы на чтение)
Как один из вариантов:
https://its.1c.ru/db/metod8dev/content/5971/hdoc
Тем что мастер-мастер не позволяет сделать кластер, тем что транзакционную нагрузку не позволяет распределять.
Какой ещё "мастер-мастер". Вы пишите, что у вас транзакции (т.е. запросы на изменения) передаются сразу на все серверы. Здесь никакого "распределения" нет. Стандартная репликация в постгре работает практически так же, но быстрее - транзакция выполняется на мастере (формируется план выполнения и т.п.) а на реплики передаётся wal-файлы, который там проигрывается (асинхронно или синхронно). Всё распределение нагрузки в таких кластерах (как и у вас) - это только распределение нагрузки по чтению.
Мульти-мастер читал собирали на mysql - это когда разные запросы на изменения могут принимать разные ноды (например нода в Европе и нода в Азии) и потом делать синхронизацию в обе стороны.
Более того. В вашей схеме нужно ещё потрудиться, чтобы данные на всех нодах были консистентные (у вас же нет мастера явного который может выступать эталоном). Т.е. Вы всегда пытаетесь делать по сути синхронную репликация, что является медленным решением и оправдано не всегда.
Ну то есть статью вы совсем не читали) целый раздел про то что нагрузка подавляющим образом состоит из запросов на чтение. Но если эти запросы в транзакциях то вы не можете их выносить за их рамки. Поэтому данные изменяются сразу и везде(на этом никакого распределения нагрузки разумеется нет) а вот запросы на чтение распределяются и нагрузка распределяется
Я прочитал, что запросы на чтение у вас распределяются неким образом. Но вы видимо невнимательно прочитали мой первый пост. В стандартных схема построения HA-кластера для постгре это давно реализуется достаточно стандартными решениями (я вам даже ссылку привёл. Там, вроде про это тоже говорится.. Причём на примере кластерах для 1С).
Я вам говорю о том, что то, что вы описываете, реализуется достаточно стандартными методами и по достаточно стандартным схемам. И в интернете масса примеров вплоть до пошаговый инструкций и объяснений как и почему.
Да нет, мне кажется это как раз вы поверхностно читаете описания подобных решений. Я открыл вашу ссылку. Там название Построение отказоустойчивого PostgreSQL. Ну так это совсем про другое. Отказоустойчивость и горизонтальное масштабирование это разные вещи. Уверен вы не найдете в описании каким образом балансируются запросы в рамках транзакций. На базе отказоустойчивого кластера можно сделать перенаправление каких либо отчетов(мы давно делали для always on - Microsoft) , транзакционной нагрузки -никогда!
Вы видимо совсем не читали то, что я вам прислал и, похоже, вообще мало читали по вопросу построения кластер в, в том числе отказоустойчивых и, в том числе, для постгре.
Отказоустойчивый кластер - это общепринятое название кластера с высокой доступностью (примерно то что вы у себя обозначаете 24/7).
Горизонтальная масштабируемость это обычно то, ради чего вообще кластеры и делаются. В кластер постгре она достигается за счёт перераспределение запросов на чтение между нодами кластера. Это достаточно стандартная практика.
А то что вы написали - это выглядит как попытка изобрести велосипед. При этом не очень удачная. Т.к., например, в силу описанных вами механизмов борьбы за согласованность данных , ваша система сразу будет проигрывать стандартным решениям в высоконагруженных приложениях с большими объёмами запросов на запись или изменение данных.
Вы почитайте про то как данные синхронизируются в постгре, что такое потоковая синхронизация, асинхронная, синхронная, причём здесь wal-файлы, что такое patroni и как он связан с etcd или consul, посмотрите схемы построения кластеров постгре и т.д. Может окажется, что не нужно городить огороды на ровном месте.
Ну, ок. Регалиями своими на тему репликации хвастаться не буду. Давайте проведем логический эксперимент. Давайте так, у вас есть набор не конкурирующих между собой документов. Вы их делите на части и проводите из разных потоков. Расскажите мне с помощью какого решения вы можете разделить sql нагрузку по этим документам? Расскажите про принципы, если не сможете то покажите на стенде. Я вот готов и рассказать и показать на стенде, предлагаю если хотите спор.
и даже в этом случае , перенаправление отчета с ноды обычной на отказоустойчивую не обычная процедура, с коробки не взлетит. Очень придется помучаться с синхронизацией временных таблиц активно используемых 1С в отчетности. Но вы про это скорее всего тоже не знаете, ведь где то там написано, что какой то там кластер делается на раз два)
Вы как-то путаетесь в терминах. Это кластер бывает отказоусточивым, а не нода. Думаю, что никакой "отчёт" вы никуда не "перенаправите", если у вас нода с этим "отчётом" перестала работать.
А по поводу временных таблиц в 1с.. Вы правы, я не специалист в тонкостях работы 1С и даже не могу назвать себя специалистом в кластерах, но.. Вы всё же невнимательно прочитали статью по ссылке. А она была именно про 1С (о чем я вам сказал). Почитайте там раздел: Использование резервного сервера PostgreSQL для механизма копий базы данных. Возможно в нем есть ответы на ваши вопросы. ;)
"Какой-то там кластер" - серьёзное утверждение для кластеров на ПО, используемых Red Hat, IBM Compose, Zalando и др..
Кстати, Mazars, тоже использовала patroni для организации кластер для 1с (порядка 200 баз, как они писали) .. по крайней мере в 2021ом.
P. S. : читайте более внимательно и возможно..... не потребуется городить огородов на ровном месте ;)
Я обладаю техникой быстрого чтения) Читаю быстро но вдумчиво. Разумеется раздел про механизма копий БД я прочитал сделав на нем акцент. Ответов на мои вопросы в нем нет. Вы просто бросаете ссылки и не готовы погружаться в детали.
Хотите авторитетом давить?(авторитетом ссылок))) нут так вот ниже ссылочку привел - "По результатам российского конкурса Microsoft среди партнеров, компания SOFTPOINT с решением DATA CLUSTER была признана лучшей компанией в номинации “Data Platform Solution”, подтвердив тем самым высокую экспертизу в области ИТ- решений для бизнеса. " Так это решение до сих пор продается, аналогов не знаю. Если есть - покажите. Я вот лично готов показать, привести референсы. К слову с этим решением вышли в финалисты международные , если не ошибаюсь, вместе c HP(в Вашингтоне поздравляли). А вы при этом хотите меня убедить, что я не разбираюсь совсем в кластерах) Вы сами себя ограничиваете в новых знаниях.
Впрочем у нас же не танцевальный или литературный батл. Я еще раз готов подтвердить и продемонстрировать алгоритмы как на словах так и на стенде. Если вы так любите ссылки, приведите мне пожалуйста какую нибудь развернутую где описаны детально алгоритмы горизонтального масштабирования. Приведенная ссылка ни о чем, там лишь одна фраза по делу.
Механизм копий баз данных имеет особенность в использовании внешнего типа репликации данных при размещении данных в PostgreSQL. Особенность связана с тем, что резервный сервер PostgreSQL доступен только на чтение, включая временные таблицы. Такое ограничение приводит к тому, что запросы к СУБД, с созданием временных таблиц, выполняемые 1С:Предприятие, будут завершаться с ошибкой.
Для снятия этого ограничения требуется развёртывание дополнительного кластера PostgreSQL, доступного для записи данных. Ниже будет описан пример развёртывания такого сервера.
и дальше описания инсталляций...
Читал про ваш data cluster. По описанию за мульт в год предлагается что-то вроде бесплатного haproxy (в лучшем случае в комбинации с keepalived) при стандартно развёрнутом кластере postgresql или кластере mssql. При этом, вы уж извините, описание на сайте такое же технически корявое, как и статья. И никакой конкретики. Есть термины always on и потоковая репликация, которые относятся к стандартным механизмам построения кластером от ms и к репликации постгре (про это я вам писал, кстати), но именно про само решение практически ничего технического не сказано - общие слова. Смешали всё в кучу, описали стандартную схему построения кластер высокой доступности для двух субд и при этом, про само решение - что это и чем это отличается от чего-то стандартного так ничего и не сказали (с технической точки зрения).
По поводу медалек и реестров, - это бумажки, а с учётом выше сказанного их реальная ценность достаточно спорная, вы уж извините :)
По поводу "горизонтального масштабирования".. Вы серьёзно не понимаете что это такое или чисто шутите? Для примера ссылки не нужны. Кластер сам по себе это и есть штука, которая придумана для "горизонтально масштабирования" системы. Добавляете ноду, перераспределяете нагрузку (в данном случае добавляете ещё один сервер, который может обрабатывать запросы на чтение) и тем самым горизонтально масштабируете систему. ..я про это выше писал, но вы, видимо, это пропустили.
..на всякий случай:
Высокодоступность - это про то, что умирание одной из нод позволяет системе продолжать работу.
Плохо, что вы не утруждаете себя разбираться в технических вопросах ...может это из за скоростного чтения :). Возможно тогда вы бы поняли о чем на самом деле приведенная ссылка и зачем там разные технические описания.
На всякий случай приведу ещё одну ссылку, где тоже присутствуют технические описания и схемы про кластеры постгре и ms sql, но, скорее всего, для вас это тоже будет неинтересно и не убедительно :)
https://infostart.ru/1c/articles/1499932/
P. S. : когда техническая составляющая туманна - на первый план выступает хороший маркетинг ;)
Коллеги, мне кажется что в ходе дискуссии "смешались в кучу кони, люди...". Кластер, который состоит из набора взаимосвязанных нод обычно строится для выполнения нескольких задач:
Высокая доступность - когда в случае выхода оборудования одной из нод, вторая подхватывает нагрузку.
Высокая надежность - если вдруг БД испорчена, то есть реплика на другой ноде и система продолжает обработку запросов от пользователя.
Катастрофоустойчивость - это когда случается пожар, наводнение и прочее, то нода географически распределенная подхватывает обслуживание.
Высокая производительность - это когда трафик от приложения распределяется между нодами, таким образом возрастает потенциал системы в плане обслуживания роста ИТ системы
В идеале чтобы кластер все это мог выполнять, но на практике первые 3 - с 4 есть проблемы, так как общие данные, синхронизации, блокировки и прочее. Так вот в статье описан 4 аспект кластеризации (сложности мастер-мастер, когда изменения идут на много нод одновременно).
А дискуссии не получается. Я не вижу никаких технических аргументов, поэтому даже затрудняюсь, что мне отвечать) А не технические аргументы - покажите у кого конкретно работает мастер-мастер кластер СУБД? - уважаемый оппонент делает вид, что не замечает. Поэтому вот такая у нас "дискуссия")
Да, что значит "мастер-мастер"?..
Мультимастер системы (в субд) - это не то, что Вы описываете, а системы которые имеют в кластере несколько узлов независимо принимающих все типы запросов (и на чтение и на изменение) и при этом обеспечивается целостность данных на уровне всего кластера (логику работы я вам тоже приводил). У вас же описана какая то система (даже не репликации), а синхронного выполнения запросов (т.е. выполнение запросов с подтверждением) на нескольких серверах. Это даже не вписывается в ни в кластер ms sql (с его always on) ни в кластер postgresql (с его потоковой репликацией) описанный в решении Data Cluster вашей же компании.
Вы описываете оболочку, которая операции изменения отдаёт сразу на все ноды (даже не ноды, а независимые серверы). В вашей схеме, если просто, сервер приложений отдаёт запрос (например, insert) на вашу оболочку, которая отправляет этот запрос на все серверы субд. Потом она неким образом проверяет (ожидает подтверждения), что везде всё выполнилось и считает, что всё ок, а если где-то не выполнилось, то откатывает изменения на всех серверах. Цитата:
Если тип запроса Изменение, то отправляет его на все сервера асинхронно. При этом к следующему запросу он не переходит, пока не дождется положительного ответа от всех серверов. Если произошла ошибка, то она транслируется в клиентское приложение и откатывается транзакция на всех серверах
Небольшое пояснение. Синхронная репликация не значит, что данные реплицируются последовательно на серверы. Это значит, что при шаге репликации ожидается подтверждение о том, что репликация завершилась успехом. А сами запросы отправляются на серверы с максимальной скоростью (это вы называете асинхронно).
По приведенной цитате сразу возникает куча вопросов, но самы "толстый" - это: т.е. если один из допустим 10 серверов не смог выполнить запрос (место на диске закончилось или сетевой порт умер), то вместо того чтобы исключить этот сервер как неработающий, предлагается просто парализовать работу всех других серверов.. Офигенное решение! Поставить 10 серверов, чтобы отказ одного остановил работу всей системы.
Про скорость работы такого решения можно даже особо не говорить: построение плана выполнения запроса - везде, дополнительные затраты на анализ и модификацию запросов.. Похоже, что всё, что у вас выполняется по плану - ограничено простейшими update, insert, delete и select. О хранимых функциях, тригерах, динамическом построении запросов речи здесь вообще не будет.
По части технической реализации (кроме общего упоминания общих терминов вроде 'прокси' или 'мастер') вы практически ничего не пишите (от слова "совсем"). Поэтому странно упрекать меня в отсутствии технических описаний. Особенно, с учётом того, что это не я статью писал, а вы, а в комментариях я даже более детально пишу о том, как происходит репликация в кластере постгре, а также о том какие программный средства используются обычно для построения отказоусточивых кластерных решений для постгре.
По поводу мультимастера я тоже написал выше (вы снова невнимательны).
Кстати, как организовывается у вас отказоустойчивость самой вашей оболочки (или того же Data Cluster) тоже ничего нет (технического описания).
Ну, это попытка, что то осмыслить в моих утверждениях;)
Давайте, что бы к чему то прийти нужно разбить задачу на части и попытаться по частям прийти к некоторому соглашению.
Первое, с чего мы начали - почему вы привязались к репликации? Если мы говорим про триггеры, очереди и т.п. так она не единственный и далеко не самый эффективный способ переноса информации. Я к слову изначально рассматривал триггеры с сокетами для синхронизации - увы по производительности большие просадки.
Зеркалирование сетевых SQL пакетов на изменение самый быстрый способ - но имеет коллизии. Для этого кстати есть дублирующий чисто репликационный (централизованный) механизм. Почему не расписал детальней ? Потому что в планах опубликовать статью посвященную только транспортным механизмам.(минимум страниц на 10-ть)
Второе, ответьте на вопрос - вы правда считаете, что основную нагрузку на систему дают запросы на изменение? Сначала определитесь с этим вопросом, иначе все остальное бессмысленно обсуждать.
Третье, самое главное. Можно сколько угодно спорить, доказывать свою правоту. Но проще всего показывают ситуацию нагрузочные тесты. Простейшие я вам описал, когда вы проводите с нескольких потоков документы, они проводятся без коллизий, и у вас равномерно нагружаются все ноды кластера. Покажите мне хотя бы одно такое решение с подобными заявленными свойствами?
1. Когда я говорил про триггеры - я говорил по сути о пользовательских функциях, которые на уровне субд вешаются на те или иные события в таблицах (добавление, обновление, удаление записей). Такие штуки недоступные вашему прокси не то что на предмет их внутренней логики работы, но даже на предмет вообще их наличия. А коли так, то в общем случае прокси не может оценивать является ли тот или иной запрос на изменения идемпотентным или нет, т.е. можно его отправлять на все серверы или нет.
самое интересно, что если вы даже каким-то образом определили, что запрос не идемпотентный, отправили его на один сервер, то потом у вас возникает проблема - а как же провести синхронизацию изменений?.. ведь добавление (или изменение) записи может изменять данные не только в одной таблице. Например, изменение суммы счета в таблице счетов может с помощью отработки триггеров обновлять информацию в таблице каких-нибудь итогов сделанную для аналитики.
Зеркалирование запросов на все серверы в общем случае (даже если всё там просто с запросами) не является "самым быстрым способом". Почему? Дело в том, что т.к. у вас используется механизм подтверждения выполнения запроса всеми серверами (как - вопрос десятый), то время выполнения запроса с точки зрения сервера приложений будет определяться временем выполнения запроса самым медленным сервером (это если ничего не упадет. если упадет - то всё вообще встанет). Почему будут быстрые и медленные серверы если они одинаковые? Ну, самый явный ответ такой. Т.к. в вашей системе запросы на чтение перераспределяются между разными серверами, то состояние памяти, кэшей, загрузки процессоров, буферов ввода/вывода и т.п. будет на серверах разное, и кому-то не нужно будет читать данные с дисков для выполнения запроса, а кому-то нужно (если очень просто).
В стандартной схеме репликации (допустим синхронной) всё гораздо проще и быстрее. На мастере строится план выполнения запроса (у вас он будет строиться каждым сервером самостоятельно). Запрос выполняется, но транзакция не закрывается. При выполнении формируется WAL-файл, который передается на все серверы-реплики. Серверы реплики проигрывают этот файл (это не выполнение запроса, а уже гораздо более быстрые операции со страницами данных, индексов и т.п.). Если всё ок - то передается подтверждение о том, что транзакция выполнена. Мастер получив подтверждения закрывает транзакцию (делает у себя commit). Примерно так.
2. Чаще всего, пожалуй, основную нагрузку (в части системы ввода/вывода например) будут создавать запросы на чтение (просто в силу того что чаще всего их больше). Я с этим и не спорил :)
Но это, тоже кстати, не всегда. Могут быть системы в которых это не так. Допустим, чисто гипотетически, какая-то система хранения сырых данных, поступающих с датчиков мониторинга, где сами сырые данные практически для доступа не используются.
Но, ещё раз, балансировка/распределение запросов на чтение между всеми нодами кластера - это тоже достаточно стандартная процедура (и я вам тоже про это писал). :)
3. То, что у вас равномерно нагружаются все ноды, к сожалению, не говорит о том, что работают они эффективно, а просто говорит о том, что они выполняют одну и ту же работу.
Объясню в чем разница. Пусть каждая ваша нода может выполнять 10 операций в единицу времени. И пусть операция добавления одной записи занимает 6 операций, операция репликации занимает 4 операции (я уже писал, почему это быстрее простого выполнения запроса выше), а операция чтение - 2 операции.
Фишка в том, что в вашем случае каждая из нод потратит по 6 операций на добавление и у каждой останется по 4 операции на выполнение, допустим, 2 чтений. Ноды будут загружены равномерно.
В случае репликации мастер нода потратит те же 6 операций, и у неё останется 4 операции для 2х чтений, но остальные ноды потратят по 4 операции и у них останется по 6 операция для 3х чтений.. Ноды (в свете операция добавления записей), конечно по графику будут загружены неравномерно, но эта неравномерность будет говорить о том, что большинство нод могут сделать больше работы (например обработать больше запросов на чтение)
...такие вот простые рассуждения
P.S.: под "не идемпотентным" в данном случае понимается запрос, который при выполнении на разных серверах будет давать разный результат
Ну насчет проверки на результат тут все понятно, парсинг, в контексте 1С, как правило никаких ошибок. Если бы была сложная система с хранимками , то там собирается своего рода база знаний. И вот если произошла ошибка то при проверке завершения транзакции проверяется состав хэш суммы(это как раз триггеры делают) и если он не совпадает (это как раз произойдет когда чтение -запись перепуталась в хранимке например) то транзакция откатывается с ошибкой. По идее это будет происходить редко, после этого в базу знаний эта ошибка записывается и в дальнейшем она пойдет по централизованному алгоритму. В котором подобных коллизий быть не может. Это если вкратце.
Проблема в том, что я не согласен категорически прям с половиной ваших утверждений. Даже и не знаю с чего начать, и пожалуй не вижу в этом смысла.
Давайте тогда так - практика в бизнесе это последняя инстанция и истина. Вот на днях будут проводится очередные нагрузочные тесты, потом будут внедрения и очередные статьи(первая будет по нагрузочным тестам, другие я перечислил в плане публикаций). Я в них все подробно опишу. На текущий момент люди серьезно разбирающиеся в этой тематике уже крайне заинтересовались моими исследованиями. Поэтому время покажет...
честно говоря не понял про какие хеши речь с помощью которых можно проверить выполнилась транзакция или нет.. да ещё и рассчитываемые на триггерах (триггерах базы? это ещё и схемы менять что ли?). также не понял что за база знаний.
..очень как-то всё сложно и искусственно, на мой взгляд, много допущений и много вопросов. но больше всего, если честно, так и непонятно для чего это когда есть проверенные достаточно эффективные механизмы.
а "практика и бизнес", они, как ни странно, разные бывают. бывает, что и микроскопами гвозди забивают, а потом радуются как эффективно это было сделано. ;)
ну.. в целом согласен, что каждый высказался, и другая сторона услышала достаточно, чтобы принять к сведению, задуматься или не принять к сведению и не задуматься :)
в любом случае, успехов :)
Все 4 описанных вами сценария реализуются по достаточно стандартным схемам. "Катастрофоустойчивость" по сути отличается только размещением узлов кластер, а производительность обеспечивается, как минимум, распределение запросов на чтение для кластеров с одним мастером/лидером) или всех запросов для кластеров с несколькими мастер-узлами (я писал про это.. там где про Европу и Азию).
В статье совершенно не про мультимастера. Почему? Потому что никакого распределения нагрузки по записи не происходит. Функцию мастера пытаются переложить на какую-то оболочку, которая отправляет одни и те же(!) запросы на множество серверов с ожиданием подтверждения их выполнения. Сравните с тем, как делается стандартная синхронная репликация в постгре, и попробуйте ответить на вопрос зачем нужна эта оболочка и чем она лучше мастер-ноды в схеме стандартной репликации.
Подробнее - смотри комментарий ниже.
(320) Решения SOFTPOINT для Microsoft World Partner Conference - YouTube
это кстати нашей компании другое давнишнее решение под MSSQL, что бы вы не думали что новички
А в сторону Citus не смотрели?
Обязательно посмотрю, спасибо! Но проблема в том, что аналогов не обнаруживается уже несколько лет, что я провожу исследования. Получается, что то типа pdw в Microsoft, ну или репликации не важно на чем, со всеми ее недостатками. Да и пощупать или получить более детального технического описания нельзя. Как правило кто то чего то видел и все.) Вообщем если у кого есть еще ссылки на аналогичные продукты(если они есть) , просьба поделится.
Почитал. В целом все основано на сегментировании таблиц. Это типочный pdw в Microsoft.
Вот примеры из описания.
Механизм распределенного SQL
Распределенный планировщик и исполнитель запросов, который распараллеливает запросы по сегментам, обеспечивая массовый параллелизм и эффективное использование ресурсов.
Вывод - это совсем не то же самое, а точнее совсем другое)
У меня данные везде одни и те же , синхронно зеркалируются а масштабирование за распределения запросов на чтение.
Создание распределенного вычислительного кластера для СУБД. Часть 1