Почитал. В целом все основано на сегментировании таблиц. Это типочный pdw в Microsoft.
Вот примеры из описания.
Механизм распределенного SQL
Распределенный планировщик и исполнитель запросов, который распараллеливает запросы по сегментам, обеспечивая массовый параллелизм и эффективное использование ресурсов.
Вывод - это совсем не то же самое, а точнее совсем другое)
У меня данные везде одни и те же , синхронно зеркалируются а масштабирование за распределения запросов на чтение.
Обязательно посмотрю, спасибо! Но проблема в том, что аналогов не обнаруживается уже несколько лет, что я провожу исследования. Получается, что то типа pdw в Microsoft, ну или репликации не важно на чем, со всеми ее недостатками. Да и пощупать или получить более детального технического описания нельзя. Как правило кто то чего то видел и все.) Вообщем если у кого есть еще ссылки на аналогичные продукты(если они есть) , просьба поделится.
Ну насчет проверки на результат тут все понятно, парсинг, в контексте 1С, как правило никаких ошибок. Если бы была сложная система с хранимками , то там собирается своего рода база знаний. И вот если произошла ошибка то при проверке завершения транзакции проверяется состав хэш суммы(это как раз триггеры делают) и если он не совпадает (это как раз произойдет когда чтение -запись перепуталась в хранимке например) то транзакция откатывается с ошибкой. По идее это будет происходить редко, после этого в базу знаний эта ошибка записывается и в дальнейшем она пойдет по централизованному алгоритму. В котором подобных коллизий быть не может. Это если вкратце.
Проблема в том, что я не согласен категорически прям с половиной ваших утверждений. Даже и не знаю с чего начать, и пожалуй не вижу в этом смысла.
Давайте тогда так - практика в бизнесе это последняя инстанция и истина. Вот на днях будут проводится очередные нагрузочные тесты, потом будут внедрения и очередные статьи(первая будет по нагрузочным тестам, другие я перечислил в плане публикаций). Я в них все подробно опишу. На текущий момент люди серьезно разбирающиеся в этой тематике уже крайне заинтересовались моими исследованиями. Поэтому время покажет...
Ну, это попытка, что то осмыслить в моих утверждениях;)
Давайте, что бы к чему то прийти нужно разбить задачу на части и попытаться по частям прийти к некоторому соглашению.
Первое, с чего мы начали - почему вы привязались к репликации? Если мы говорим про триггеры, очереди и т.п. так она не единственный и далеко не самый эффективный способ переноса информации. Я к слову изначально рассматривал триггеры с сокетами для синхронизации - увы по производительности большие просадки.
Зеркалирование сетевых SQL пакетов на изменение самый быстрый способ - но имеет коллизии. Для этого кстати есть дублирующий чисто репликационный (централизованный) механизм. Почему не расписал детальней ? Потому что в планах опубликовать статью посвященную только транспортным механизмам.(минимум страниц на 10-ть)
Второе, ответьте на вопрос - вы правда считаете, что основную нагрузку на систему дают запросы на изменение? Сначала определитесь с этим вопросом, иначе все остальное бессмысленно обсуждать.
Третье, самое главное. Можно сколько угодно спорить, доказывать свою правоту. Но проще всего показывают ситуацию нагрузочные тесты. Простейшие я вам описал, когда вы проводите с нескольких потоков документы, они проводятся без коллизий, и у вас равномерно нагружаются все ноды кластера. Покажите мне хотя бы одно такое решение с подобными заявленными свойствами?
А дискуссии не получается. Я не вижу никаких технических аргументов, поэтому даже затрудняюсь, что мне отвечать) А не технические аргументы - покажите у кого конкретно работает мастер-мастер кластер СУБД? - уважаемый оппонент делает вид, что не замечает. Поэтому вот такая у нас "дискуссия")
Я обладаю техникой быстрого чтения) Читаю быстро но вдумчиво. Разумеется раздел про механизма копий БД я прочитал сделав на нем акцент. Ответов на мои вопросы в нем нет. Вы просто бросаете ссылки и не готовы погружаться в детали.
Хотите авторитетом давить?(авторитетом ссылок))) нут так вот ниже ссылочку привел - "По результатам российского конкурса Microsoft среди партнеров, компания SOFTPOINT с решением DATA CLUSTER была признана лучшей компанией в номинации “Data Platform Solution”, подтвердив тем самым высокую экспертизу в области ИТ- решений для бизнеса. " Так это решение до сих пор продается, аналогов не знаю. Если есть - покажите. Я вот лично готов показать, привести референсы. К слову с этим решением вышли в финалисты международные , если не ошибаюсь, вместе c HP(в Вашингтоне поздравляли). А вы при этом хотите меня убедить, что я не разбираюсь совсем в кластерах) Вы сами себя ограничиваете в новых знаниях.
Впрочем у нас же не танцевальный или литературный батл. Я еще раз готов подтвердить и продемонстрировать алгоритмы как на словах так и на стенде. Если вы так любите ссылки, приведите мне пожалуйста какую нибудь развернутую где описаны детально алгоритмы горизонтального масштабирования. Приведенная ссылка ни о чем, там лишь одна фраза по делу.
Механизм копий баз данных имеет особенность в использовании внешнего типа репликации данных при размещении данных в PostgreSQL. Особенность связана с тем, что резервный сервер PostgreSQL доступен только на чтение, включая временные таблицы. Такое ограничение приводит к тому, что запросы к СУБД, с созданием временных таблиц, выполняемые 1С:Предприятие, будут завершаться с ошибкой. Для снятия этого ограничения требуется развёртывание дополнительного кластера PostgreSQL, доступного для записи данных. Ниже будет описан пример развёртывания такого сервера.
Ну, ок. Регалиями своими на тему репликации хвастаться не буду. Давайте проведем логический эксперимент. Давайте так, у вас есть набор не конкурирующих между собой документов. Вы их делите на части и проводите из разных потоков. Расскажите мне с помощью какого решения вы можете разделить sql нагрузку по этим документам? Расскажите про принципы, если не сможете то покажите на стенде. Я вот готов и рассказать и показать на стенде, предлагаю если хотите спор.
и даже в этом случае , перенаправление отчета с ноды обычной на отказоустойчивую не обычная процедура, с коробки не взлетит. Очень придется помучаться с синхронизацией временных таблиц активно используемых 1С в отчетности. Но вы про это скорее всего тоже не знаете, ведь где то там написано, что какой то там кластер делается на раз два)
Да нет, мне кажется это как раз вы поверхностно читаете описания подобных решений. Я открыл вашу ссылку. Там название Построение отказоустойчивого PostgreSQL. Ну так это совсем про другое. Отказоустойчивость и горизонтальное масштабирование это разные вещи. Уверен вы не найдете в описании каким образом балансируются запросы в рамках транзакций. На базе отказоустойчивого кластера можно сделать перенаправление каких либо отчетов(мы давно делали для always on - Microsoft) , транзакционной нагрузки -никогда!
Ну то есть статью вы совсем не читали) целый раздел про то что нагрузка подавляющим образом состоит из запросов на чтение. Но если эти запросы в транзакциях то вы не можете их выносить за их рамки. Поэтому данные изменяются сразу и везде(на этом никакого распределения нагрузки разумеется нет) а вот запросы на чтение распределяются и нагрузка распределяется
Я человек простой). Вы на вашем(описанном) решении сможеет запустить 1С 8.х, равномерно распределить нагрузку по физическим серверам постгрес? Если да, то я могу вам клиентов набросать) Да и сам за реализацию заплатил бы, что бы посмотреть. Мы например проводим нагрузочные тесты, скоро будем запускать первые внедрения.
Про САР , это побатчевая(позапросная) синхронизация запросов на изменение - запрос на изменение идет на все сервера( разумеется параллельно, асинхронно)и ждет подтверждения от всех, только потом переходит к следующему запросу. В конце транзакции обязательная сверка состава по хэш сумме(на случай перепутывания потоков). В случае несовпадения, ошибка и откат, либо если возможно автокоррекция.(это должно происходить крайне редко), в определенных случаях(принимает решение прокси) использование централизованного механизма принятия изменения(но дает большие издержки)
Было бы интересно почитать каким образом происходит сборка проектов, сдача релизов, тестирование(кем и как), согласование ТЗ на практике. Имеется ли опыт сдачи проектов с частично закрытым кодом но в котором разумеется детально описаны условия тестирования и приемки? Примеры подобных проектов?
Как то все теория, теория. Приведу пример, я занимаюсь видеоаналитикой. Есть масса примеров когда работа нейросетей без математики и структуры не удовлетворяет. К примеру задача распознавания лиц, или задача идентификации объекта. Например когда мы знаем положение камер и необходимо оцифровать объект-человек. Что бы затем решать задачу его более точной и быстрой идентификации в пространстве(куртка, кепка, кроссовки, прическа, рост и т.п. Любая дополнительная информация об объекте может существенно улучшить и ускорить его идентификацию в пространстве). Мои изыскания в этом направлении показывают перспективу симбиоза использования 3D движка(в процессе выбора) для обучения нейросетей а также с другой стороны возможность структурной оптимизации алгоритмов. Язык вырисовывается некоторый аналог SQL в совокупности с объектно-ориентированной моделью. На эту тему планирую опубликовать пару статей с конкретными примерами в том числе с технологией отладки и обучения.
Как то так. В итоге, мое мнение — сухая теория и математика никому не интересна.
Почитал. В целом все основано на сегментировании таблиц. Это типочный pdw в Microsoft.
Вот примеры из описания.
Механизм распределенного SQL
Распределенный планировщик и исполнитель запросов, который распараллеливает запросы по сегментам, обеспечивая массовый параллелизм и эффективное использование ресурсов.
Вывод - это совсем не то же самое, а точнее совсем другое)
У меня данные везде одни и те же , синхронно зеркалируются а масштабирование за распределения запросов на чтение.
Обязательно посмотрю, спасибо! Но проблема в том, что аналогов не обнаруживается уже несколько лет, что я провожу исследования. Получается, что то типа pdw в Microsoft, ну или репликации не важно на чем, со всеми ее недостатками. Да и пощупать или получить более детального технического описания нельзя. Как правило кто то чего то видел и все.) Вообщем если у кого есть еще ссылки на аналогичные продукты(если они есть) , просьба поделится.
Ну насчет проверки на результат тут все понятно, парсинг, в контексте 1С, как правило никаких ошибок. Если бы была сложная система с хранимками , то там собирается своего рода база знаний. И вот если произошла ошибка то при проверке завершения транзакции проверяется состав хэш суммы(это как раз триггеры делают) и если он не совпадает (это как раз произойдет когда чтение -запись перепуталась в хранимке например) то транзакция откатывается с ошибкой. По идее это будет происходить редко, после этого в базу знаний эта ошибка записывается и в дальнейшем она пойдет по централизованному алгоритму. В котором подобных коллизий быть не может. Это если вкратце.
Проблема в том, что я не согласен категорически прям с половиной ваших утверждений. Даже и не знаю с чего начать, и пожалуй не вижу в этом смысла.
Давайте тогда так - практика в бизнесе это последняя инстанция и истина. Вот на днях будут проводится очередные нагрузочные тесты, потом будут внедрения и очередные статьи(первая будет по нагрузочным тестам, другие я перечислил в плане публикаций). Я в них все подробно опишу. На текущий момент люди серьезно разбирающиеся в этой тематике уже крайне заинтересовались моими исследованиями. Поэтому время покажет...
Ну, это попытка, что то осмыслить в моих утверждениях;)
Давайте, что бы к чему то прийти нужно разбить задачу на части и попытаться по частям прийти к некоторому соглашению.
Первое, с чего мы начали - почему вы привязались к репликации? Если мы говорим про триггеры, очереди и т.п. так она не единственный и далеко не самый эффективный способ переноса информации. Я к слову изначально рассматривал триггеры с сокетами для синхронизации - увы по производительности большие просадки.
Зеркалирование сетевых SQL пакетов на изменение самый быстрый способ - но имеет коллизии. Для этого кстати есть дублирующий чисто репликационный (централизованный) механизм. Почему не расписал детальней ? Потому что в планах опубликовать статью посвященную только транспортным механизмам.(минимум страниц на 10-ть)
Второе, ответьте на вопрос - вы правда считаете, что основную нагрузку на систему дают запросы на изменение? Сначала определитесь с этим вопросом, иначе все остальное бессмысленно обсуждать.
Третье, самое главное. Можно сколько угодно спорить, доказывать свою правоту. Но проще всего показывают ситуацию нагрузочные тесты. Простейшие я вам описал, когда вы проводите с нескольких потоков документы, они проводятся без коллизий, и у вас равномерно нагружаются все ноды кластера. Покажите мне хотя бы одно такое решение с подобными заявленными свойствами?
А дискуссии не получается. Я не вижу никаких технических аргументов, поэтому даже затрудняюсь, что мне отвечать) А не технические аргументы - покажите у кого конкретно работает мастер-мастер кластер СУБД? - уважаемый оппонент делает вид, что не замечает. Поэтому вот такая у нас "дискуссия")
Я обладаю техникой быстрого чтения) Читаю быстро но вдумчиво. Разумеется раздел про механизма копий БД я прочитал сделав на нем акцент. Ответов на мои вопросы в нем нет. Вы просто бросаете ссылки и не готовы погружаться в детали.
Хотите авторитетом давить?(авторитетом ссылок))) нут так вот ниже ссылочку привел - "По результатам российского конкурса Microsoft среди партнеров, компания SOFTPOINT с решением DATA CLUSTER была признана лучшей компанией в номинации “Data Platform Solution”, подтвердив тем самым высокую экспертизу в области ИТ- решений для бизнеса. " Так это решение до сих пор продается, аналогов не знаю. Если есть - покажите. Я вот лично готов показать, привести референсы. К слову с этим решением вышли в финалисты международные , если не ошибаюсь, вместе c HP(в Вашингтоне поздравляли). А вы при этом хотите меня убедить, что я не разбираюсь совсем в кластерах) Вы сами себя ограничиваете в новых знаниях.
Впрочем у нас же не танцевальный или литературный батл. Я еще раз готов подтвердить и продемонстрировать алгоритмы как на словах так и на стенде. Если вы так любите ссылки, приведите мне пожалуйста какую нибудь развернутую где описаны детально алгоритмы горизонтального масштабирования. Приведенная ссылка ни о чем, там лишь одна фраза по делу.
Механизм копий баз данных имеет особенность в использовании внешнего типа репликации данных при размещении данных в PostgreSQL. Особенность связана с тем, что резервный сервер PostgreSQL доступен только на чтение, включая временные таблицы. Такое ограничение приводит к тому, что запросы к СУБД, с созданием временных таблиц, выполняемые 1С:Предприятие, будут завершаться с ошибкой.
Для снятия этого ограничения требуется развёртывание дополнительного кластера PostgreSQL, доступного для записи данных. Ниже будет описан пример развёртывания такого сервера.
и дальше описания инсталляций...
Ну, ок. Регалиями своими на тему репликации хвастаться не буду. Давайте проведем логический эксперимент. Давайте так, у вас есть набор не конкурирующих между собой документов. Вы их делите на части и проводите из разных потоков. Расскажите мне с помощью какого решения вы можете разделить sql нагрузку по этим документам? Расскажите про принципы, если не сможете то покажите на стенде. Я вот готов и рассказать и показать на стенде, предлагаю если хотите спор.
и даже в этом случае , перенаправление отчета с ноды обычной на отказоустойчивую не обычная процедура, с коробки не взлетит. Очень придется помучаться с синхронизацией временных таблиц активно используемых 1С в отчетности. Но вы про это скорее всего тоже не знаете, ведь где то там написано, что какой то там кластер делается на раз два)
Да нет, мне кажется это как раз вы поверхностно читаете описания подобных решений. Я открыл вашу ссылку. Там название Построение отказоустойчивого PostgreSQL. Ну так это совсем про другое. Отказоустойчивость и горизонтальное масштабирование это разные вещи. Уверен вы не найдете в описании каким образом балансируются запросы в рамках транзакций. На базе отказоустойчивого кластера можно сделать перенаправление каких либо отчетов(мы давно делали для always on - Microsoft) , транзакционной нагрузки -никогда!
Ну то есть статью вы совсем не читали) целый раздел про то что нагрузка подавляющим образом состоит из запросов на чтение. Но если эти запросы в транзакциях то вы не можете их выносить за их рамки. Поэтому данные изменяются сразу и везде(на этом никакого распределения нагрузки разумеется нет) а вот запросы на чтение распределяются и нагрузка распределяется
Тем что мастер-мастер не позволяет сделать кластер, тем что транзакционную нагрузку не позволяет распределять.
написал в личку, готов к дискуссии, готов посмотреть если что то есть готовое. Пока, что аналогов не видел.
Свое решение могу показать на стенде.
(320) Решения SOFTPOINT для Microsoft World Partner Conference - YouTube
это кстати нашей компании другое давнишнее решение под MSSQL, что бы вы не думали что новички
Я человек простой). Вы на вашем(описанном) решении сможеет запустить 1С 8.х, равномерно распределить нагрузку по физическим серверам постгрес? Если да, то я могу вам клиентов набросать) Да и сам за реализацию заплатил бы, что бы посмотреть. Мы например проводим нагрузочные тесты, скоро будем запускать первые внедрения.
Про Писатель-Писатель комментария не понял.
Про САР , это побатчевая(позапросная) синхронизация запросов на изменение - запрос на изменение идет на все сервера( разумеется параллельно, асинхронно)и ждет подтверждения от всех, только потом переходит к следующему запросу. В конце транзакции обязательная сверка состава по хэш сумме(на случай перепутывания потоков). В случае несовпадения, ошибка и откат, либо если возможно автокоррекция.(это должно происходить крайне редко), в определенных случаях(принимает решение прокси) использование централизованного механизма принятия изменения(но дает большие издержки)
Как то так. В итоге, мое мнение — сухая теория и математика никому не интересна.