Попробую коллегам помочь рассказать зачем всё это. Идея-то ведь была интересная.
Почти всегда под какую-либо систему, даже служебную, нужна база данных. Для 2FA, PAM, почты и чего угодно.
Настраивают эти системы профильные специалисты - по ИБ, инфраструктурные и так далее. Но они не специалисты в базах данных, а хочется сразу и отказоустойчивость, и DR, и чтобы настройки все правильные, и соответствие best paracticies.
И вот родилась идея - а давайте сделаем такой космолет: ставит безопасник свою SEIM, и ему нужда БД. Он просто выбирает:
хочу Postgres Pro
максимальную отказоустойчивость
резервирование в другом ЦОД-е
ресурсы - много!
Нажимает кнопку "Поехали!", и через три минуты получает логин/пароль к базе, которая уже развернута со всеми кластерами/настройками/DR и всеми "прибамбасами". Вбивает их в свой инсталлятор SEIM, нажимает "next" и спокойно продолжает настройку своей системы.
Ну огонь же идея? Тогда помчали. Рисую три варианта архитектуры под разные классы критичности.
Первое препятствие: в банке нельзя просто так развернуть что хочешь и как попало, всё очень строго.
А значит что? Стандартизируем наши варианты архитектуры и вносим их в альбом типовых решений банка.
Мы сделали это, по-моему, месяца за два - фантастический срок, если кто сталкивался с подобной процедурой.
Для этого мы устаивали несколько сессий со всеми заинтересованными, я открывал на своем ноутбуке DrawIO - и "понеслась": разобрали "по косточкам" вообще всё. И для полноты картины провел демонстрационную сессию конкурентного решения, про него сейчас говорят "из каждого утюга".
Далее то, о чем пишут коллеги - имитируем ландшафт банка у себя в лабе.
Препятствие два: одна и та же вещь может очень по-разному настраиваться в разных сочетаниях OS/БД. И тут приходилось "бить по рукам" коллег - "фу, брось каку, поломаешь ФСТЭК!" :-)
Препятствие три: изолированная среда, как пишут коллеги. Но это не было самоцелью, это издержки "космических перелетов".
Но наш высококлассный конструктор космолетов таки собрал этот корабль! (Игорь, спасибо!).
Оставалось вывести на приборную панель элементы управления: выбор места назначения - Марс, Венера или Альфа-Центавра, и кнопку "Пуск". И приложить краткий атлас для не разбирающихся в астронавигации. Но... не вывели. Поэтому чтобы "попасть на марс" нужно "под панелью скрутить вот эти два проводочка и дернуть вот ту пимпочку". Но в целом - он летает.
Если идея такая хорошая, то почему её давно не сделали до нас?
Продолжим космическую аналогию: есть много готовых ракетоносителей. Ими относительно легко "пульнуть на орбиту" груз. Но наши цели слишком разнообразны - и на орбиту вывести, и на Марсе высадиться, и на Альфа-Центавру слетать.
Так вот, все пытаются орбитальную ракету отправить путешествовать по галлактике. И раз за разом неуспешно. А подход должен быть другим. Мы (я) знаем про гравитационные маневры и черные дыры, пояса астероидов. И вообще про полеты в космосе. И космолет модульно собирается в зависимости от цели. Иногда уже на орбите, перед финальным запуском.
И под капотом там не просто космолет, а сборщик космолетов. По задумке, это все ещё должно было масштабироваться. Как бизнес-идея.
И в этом красота и главное отличие от просто очередной пачки ansible-скриптов.
Вы изобретаете dbms_scheduler из Oracle. Не подумайте, ничего плохого в этом не вижу, даже наоборот. Если интересно - можете подсмотреть что там есть хорошего для вас.
Например - объединение заданий в классы: "эти 10 - закрытие дня", "эти 20 - отчетность" и так далее.
Выстаивание последовательности заданий: "эта задача стартует по завершению вот той" - выстаивается цепочка логически взаимосвязанных заданий и не нужно до минут высчитывать время выполнения каждой из них.
Приоритезация и окна выполнения: "с 23:00 до 6:00" должны быть выполнены эти 200 заданий, их приоритет такой-то.
Ну можно уточнить что в настоящий момент окно не фиксировано, хранится вообще в токенах, а не словах, может быть специальным образом агрегировано, части могут быть переданы между чатами.
Но эти детали не меняют сути - LLM не помнит что сказала вам секунду назад. :) Или моя информация устарела )
И нейросети учатся на диалогах с пользователем. Просто не в режиме реального времени. Их используют при обучении новой версии модели
Да идея очевидна и привлекательна своей красотой. Нейросеть выходит в свет и учится у людей. Об попытках и результатах такого подхода и было бы интересно узнать.
Можно я приведу аналогию, как эта идея выглядит для меня? Это как учиться какой-либо теме по статье на хабре и тысяче комментариев к ней. Там безусловно будут камменты и с истиной, и с глубиной. Но... дальше объяснять не надо? Вы же знаете о чем 1000 камментов под статьей? :) И что о теме поймет нейросеть?
Взять LLM-стажера и дотянуть его до мидла, как это делается с человеком - ну мечта же? В реальности про такое я (я) не слышал. И если есть наработки в этой области, то мне было бы интересно.
Вполне может быть, я не специалист по нейросетям, а интересуюсь скорее в прикладном плане в своих областях.
Но вот сама GPT 5.1 утверждает что принципиально ничего не поменялось, просто контекст переехал из браузера пользователя в "обвязку" внешними сервисами OpenAI. И так же история чата/ов "скармливается" нейросети большими кусками при каждом "привет", чтобы она понимала где она сейчас.
О собственной памяти нейросети, и тем более её обучении на диалогах речи не идет.
Ну то есть GPT5.1 утверждает что вся его "память" - внешняя.
Может врет, конечно :) Буду благодарен если поделитесь про какие техники идет речь и где почитать (но в гугле не забанили, "где" - найду).
А по моей информации модель не то что не обучается на диалогах, а даже не помнит предыдущего предложения в чате. Просто в рамках чата каждый раз при нажатии Enter скидывается в LLM вся его история от начала времен, и LLM каждый раз читает её заново. Это наглядно видно при работе через API, но и в браузерной сессии происходит то же самое, только средствами браузера. Про температуру уже сказали - это специально внесенный рандом. Которой можно и убрать.
Для, якобы, дообучения модели есть механизм LoRa, но это скорее "патч" поверх модели, а не обучение на диалогах.
Почему странное, если вы описали тоже самое что в статье, но другими словами? :)
На первой схеме и показано что CPU простаивает пока идет ввод-вывод, и можно его "уплотнить" (больше утилизировать), если не ждать IO. Пусть пока делает что то полезное. :) Это вторая схема.
Так что всё верно - async IO это про утилизацию CPU. И, соответственно, более быструю обработку и, как следствие, более быстрый результат.
Сам вопрос "что такое взрослые нагрузки" тянет не на статью, а на диссертацию. Актуальность которой теряется прямо во время написания - выходят новые "фичи", снимаются старые ограничения и т.д.
Я видел и базы 200Гб, которые "умирают" от нагрузки, и 10 Тб, которые живут вполне себе нормально. Некоторый диапазон, который компании устанавливают для себя приведен в начале статьи: это 1-5 Тб. И эту цифру они выбирают исходя не только из производительности, но и с учетом возможностей инфрастурктуры, возможности восстановления нужных объемов в допусках SLA, резервирования и так далее.
Объем в чистом виде - очень относительная метрика, но другой, которая была бы лучше, нет. А компаниям в любом случае приходится формализовывать критерии если количество баз измеряется тысячами.
Ответьте на один вопрос - а у вас какой размер самой большой базы Postres и под какой нагрузкой? Не вы слышали у кого-то, а именно у вас?
И в статье нет сравнения с Oracle, в статье сравнение ASYNC IO и не-ASYNC IO.
То, что вам не хватило цифр - ок. Но приходится выбирать - публиковать статью со всеми четырьмя тысячами замеров, или популярно и доступно рассказать для не-специалистов в БД, о чем собственно, речь.
Классическая ситуация при ручной многопоточной обработке :)
Не знаю вашей задачи и ситуации, но попробую угадать по наиболее типичным сценариям.
Распараллеленивание построчно, например, каким нибудь mod(hash()) - наверное самая неэффективная стратегия. Во-первых, это заставляет каждый поток читать весь объем данных, и вместо чтения огромной таблицы один раз, она читается 10 раз. Во вторых, это заставляет делать вычисления mod(hash()) для каждой строки в каждом потоке. В-третьих - конкуренция. Если потоки идут по близким данным, то достаточно двум сессиям столкнуться на блокировке, и все остальные тоже туда же "налетят", образуя "кучу-малу". Процесс этот лавинообразный - конкуренция порождает конкуренцию -> повышает нагрузку. Если в потоках данные еще и модифицируются, да хотя бы статус "в обработке" меняется, то все это так же лавинообразно встает на блокировках.
Оптимальная стратегия, конечно, зависит от задачи и условий. Если это переливка больших объемов, то лучше делить таблицу на диапазоны и отдавать свой диапазон каждому потоку. Отдельный уровень "просветления" - делать это не на логическом уровне: значении, например, PK, а прямо на "физическом" - деля на диапазоны прямо пофайлово через ctid. Это самый быстрый способ указать базе на конкретную строку или диапазон. Но нужно хорошо понимать ограничения и подводные камни.
Классический способ "развести" потоки и не читать данные помногу раз - деление на диапазоны по какому нибудь достаточно хорошо распределенному значению, идеальный пример - Primary Key. Если условия позволяют, то делать это можно прямо при старте потоков, не заморачивась каким-либо координатором.
Если данные динамически меняются, то тут можно применить схожий подход, но уже с координатором "сверху" - пусть он отдает обработчиками диапазоны, а не отдельные строки.
Если это какая-то большая очередь для разбора и обработка строки занимает существенно больше времени, чем выбор этой строки, то можно идти и по всем строкам каждому потоку, пропуская уже обрабатываемые "соседом" строки через skip locked.
Бывают ситуации когда обработчик очереди просто нужно "дергать" чаще. Не давать скопиться значительному объему.
Есть и другие способы и стратегии, но для mass process, хорошими практиками будет не читать данные по нескольку раз и развести потоки так, чтобы они не пересекались в одних структурах.
Почему свеженалитые данные могут вести тебя "не так".
Первое, это конечно же, кеширование на разных уровнях. Тут для повторяемости лучше всего подходит обнуление всех кешей и и много итераций теста.
Второе - план запроса. Если статистика не актуальна, то планы могут "плыть", но это легко отлавливается.
Третье менее очевидно, но тоже имеет место быть: это отложенная очистка блока. Идея в чем - если транзакция достаточно большая, то она по commit не идет в каждый затронутый блок, не снимает блокировки, не меняет статусы транзакций - это слишком накладно.
За нее это сделает следующий пришедший в страницу select. Но даже такое снятие блокировки со строки - это модификация страницы, а значит - запись в wal со всеми вытекающими. А уже следующий select "чистить" ничего не будет и ведет себя немного иначе.
Autodesk Fusion 360. Бесплатен для персонального использования, но для скачивания придется озаботиться vpn.
Как раз предназначен для параметрического моделирования, но возможен и "free hand". Параметрического - значит что можно вернуться назад и изменить размер, форму - все последующие шаги и вся модель "пересчитаются" сами.
На "борту" сразу скругления, фаски, отверстия и т.д. При подсказках ИИ осваивается за пару вечеров.
Безусловно, если в ваших условиях Split Brain допустим, то норм.
Просто я считаю необходимым предупреждать ищущих решение в интернете о возможности такой ситуации чтобы это не было сюрпризом. Что при потере связности узлов появятся два активных мастера и keepalive с чистой душой поднимет два одинаковых IP-шника на обоих нодах. И что в итоге за каша в данных может получиться даже бог не ведает.
Именно поэтому (почти) нет штатных двухузловых конфигураций кластеров на основе репликации. А не из-за вредности разработчиков :)
Про "почти" могу отдельно написать, если интересно. Но для двух локальных узлов можно посмотреть в сторону кластеризации не на основе репликации, а на основе Shared Storage. Как пример - PaceMaker (не к ночи помянут будет).
Добрый день. Не могли бы вы раскрыть, какие проблемы решаются использованием S3 Storage взамен классической архитектуры? (Если сформулировать вопрос совсем просто - зачем это надо?).
Бесконечное и прозрачное масштабирование? Ок, принимается. Но это же размен легкости разовых mantainance-tasks на постоянные real-time проблемы?
Облачное хранение? Но если это не Amazon, то облачные провайдеры вполне себе предоставляют блочные устройства.
Хочется понять point статьи - это про замену GreenPlumb и Arenadata DB на Data Ocean Nova или про использование S3 и HDFS как универсального хранилища систем класса DataLake?
Продолжая аналогию с токарем: он хотя бы должен знать что бывает резьба дюймовая и метрическая.
Чтобы решать какую-то проблему с помощью ИИ нужно хотя бы знать о её наличии. Как пример, недавний пост на Хабре с "удивительной" борьбой с NULL в sql, хотя это поведение просто описано в документации.
Попробую коллегам помочь рассказать зачем всё это. Идея-то ведь была интересная.
Почти всегда под какую-либо систему, даже служебную, нужна база данных. Для 2FA, PAM, почты и чего угодно.
Настраивают эти системы профильные специалисты - по ИБ, инфраструктурные и так далее. Но они не специалисты в базах данных, а хочется сразу и отказоустойчивость, и DR, и чтобы настройки все правильные, и соответствие best paracticies.
И вот родилась идея - а давайте сделаем такой космолет: ставит безопасник свою SEIM, и ему нужда БД. Он просто выбирает:
хочу Postgres Pro
максимальную отказоустойчивость
резервирование в другом ЦОД-е
ресурсы - много!
Нажимает кнопку "Поехали!", и через три минуты получает логин/пароль к базе, которая уже развернута со всеми кластерами/настройками/DR и всеми "прибамбасами".
Вбивает их в свой инсталлятор SEIM, нажимает "next" и спокойно продолжает настройку своей системы.
Ну огонь же идея? Тогда помчали. Рисую три варианта архитектуры под разные классы критичности.
Первое препятствие: в банке нельзя просто так развернуть что хочешь и как попало, всё очень строго.
А значит что? Стандартизируем наши варианты архитектуры и вносим их в альбом типовых решений банка.
Мы сделали это, по-моему, месяца за два - фантастический срок, если кто сталкивался с подобной процедурой.
Для этого мы устаивали несколько сессий со всеми заинтересованными, я открывал на своем ноутбуке DrawIO - и "понеслась": разобрали "по косточкам" вообще всё. И для полноты картины провел демонстрационную сессию конкурентного решения, про него сейчас говорят "из каждого утюга".
Далее то, о чем пишут коллеги - имитируем ландшафт банка у себя в лабе.
Препятствие два: одна и та же вещь может очень по-разному настраиваться в разных сочетаниях OS/БД. И тут приходилось "бить по рукам" коллег - "фу, брось каку, поломаешь ФСТЭК!" :-)
Препятствие три: изолированная среда, как пишут коллеги.
Но это не было самоцелью, это издержки "космических перелетов".
Но наш высококлассный конструктор космолетов таки собрал этот корабль! (Игорь, спасибо!).
Оставалось вывести на приборную панель элементы управления: выбор места назначения - Марс, Венера или Альфа-Центавра, и кнопку "Пуск". И приложить краткий атлас для не разбирающихся в астронавигации.
Но... не вывели. Поэтому чтобы "попасть на марс" нужно "под панелью скрутить вот эти два проводочка и дернуть вот ту пимпочку". Но в целом - он летает.
Если идея такая хорошая, то почему её давно не сделали до нас?
Продолжим космическую аналогию: есть много готовых ракетоносителей. Ими относительно легко "пульнуть на орбиту" груз. Но наши цели слишком разнообразны - и на орбиту вывести, и на Марсе высадиться, и на Альфа-Центавру слетать.
Так вот, все пытаются орбитальную ракету отправить путешествовать по галлактике. И раз за разом неуспешно.
А подход должен быть другим. Мы (я) знаем про гравитационные маневры и черные дыры, пояса астероидов. И вообще про полеты в космосе. И космолет модульно собирается в зависимости от цели. Иногда уже на орбите, перед финальным запуском.
И под капотом там не просто космолет, а сборщик космолетов. По задумке, это все ещё должно было масштабироваться. Как бизнес-идея.
И в этом красота и главное отличие от просто очередной пачки ansible-скриптов.
Вы изобретаете dbms_scheduler из Oracle. Не подумайте, ничего плохого в этом не вижу, даже наоборот. Если интересно - можете подсмотреть что там есть хорошего для вас.
Например - объединение заданий в классы: "эти 10 - закрытие дня", "эти 20 - отчетность" и так далее.
Выстаивание последовательности заданий: "эта задача стартует по завершению вот той" - выстаивается цепочка логически взаимосвязанных заданий и не нужно до минут высчитывать время выполнения каждой из них.
Приоритезация и окна выполнения: "с 23:00 до 6:00" должны быть выполнены эти 200 заданий, их приоритет такой-то.
Ну и так далее. Удачи.
Ну можно уточнить что в настоящий момент окно не фиксировано, хранится вообще в токенах, а не словах, может быть специальным образом агрегировано, части могут быть переданы между чатами.
Но эти детали не меняют сути - LLM не помнит что сказала вам секунду назад. :) Или моя информация устарела )
Да идея очевидна и привлекательна своей красотой. Нейросеть выходит в свет и учится у людей. Об попытках и результатах такого подхода и было бы интересно узнать.
Можно я приведу аналогию, как эта идея выглядит для меня? Это как учиться какой-либо теме по статье на хабре и тысяче комментариев к ней. Там безусловно будут камменты и с истиной, и с глубиной. Но... дальше объяснять не надо? Вы же знаете о чем 1000 камментов под статьей? :) И что о теме поймет нейросеть?
Взять LLM-стажера и дотянуть его до мидла, как это делается с человеком - ну мечта же? В реальности про такое я (я) не слышал. И если есть наработки в этой области, то мне было бы интересно.
Это вопросы ко мне? Правильнее было бы спросить автора комментария:
Так задайте этот вопрос автору комментария:
Обучение чему и как он себе представляет.
Вполне может быть, я не специалист по нейросетям, а интересуюсь скорее в прикладном плане в своих областях.
Но вот сама GPT 5.1 утверждает что принципиально ничего не поменялось, просто контекст переехал из браузера пользователя в "обвязку" внешними сервисами OpenAI. И так же история чата/ов "скармливается" нейросети большими кусками при каждом "привет", чтобы она понимала где она сейчас.
О собственной памяти нейросети, и тем более её обучении на диалогах речи не идет.
Ну то есть GPT5.1 утверждает что вся его "память" - внешняя.
Может врет, конечно :) Буду благодарен если поделитесь про какие техники идет речь и где почитать (но в гугле не забанили, "где" - найду).
А по моей информации модель не то что не обучается на диалогах, а даже не помнит предыдущего предложения в чате. Просто в рамках чата каждый раз при нажатии Enter скидывается в LLM вся его история от начала времен, и LLM каждый раз читает её заново. Это наглядно видно при работе через API, но и в браузерной сессии происходит то же самое, только средствами браузера. Про температуру уже сказали - это специально внесенный рандом. Которой можно и убрать.
Для, якобы, дообучения модели есть механизм LoRa, но это скорее "патч" поверх модели, а не обучение на диалогах.
Почему странное, если вы описали тоже самое что в статье, но другими словами? :)
На первой схеме и показано что CPU простаивает пока идет ввод-вывод, и можно его "уплотнить" (больше утилизировать), если не ждать IO. Пусть пока делает что то полезное. :) Это вторая схема.
Так что всё верно - async IO это про утилизацию CPU. И, соответственно, более быструю обработку и, как следствие, более быстрый результат.
Сам вопрос "что такое взрослые нагрузки" тянет не на статью, а на диссертацию. Актуальность которой теряется прямо во время написания - выходят новые "фичи", снимаются старые ограничения и т.д.
Я видел и базы 200Гб, которые "умирают" от нагрузки, и 10 Тб, которые живут вполне себе нормально.
Некоторый диапазон, который компании устанавливают для себя приведен в начале статьи: это 1-5 Тб. И эту цифру они выбирают исходя не только из производительности, но и с учетом возможностей инфрастурктуры, возможности восстановления нужных объемов в допусках SLA, резервирования и так далее.
Объем в чистом виде - очень относительная метрика, но другой, которая была бы лучше, нет. А компаниям в любом случае приходится формализовывать критерии если количество баз измеряется тысячами.
Ответьте на один вопрос - а у вас какой размер самой большой базы Postres и под какой нагрузкой? Не вы слышали у кого-то, а именно у вас?
И в статье нет сравнения с Oracle, в статье сравнение ASYNC IO и не-ASYNC IO.
То, что вам не хватило цифр - ок. Но приходится выбирать - публиковать статью со всеми четырьмя тысячами замеров, или популярно и доступно рассказать для не-специалистов в БД, о чем собственно, речь.
Раздел "научпоп" там не просто так поставлен.
Классическая ситуация при ручной многопоточной обработке :)
Не знаю вашей задачи и ситуации, но попробую угадать по наиболее типичным сценариям.
Распараллеленивание построчно, например, каким нибудь mod(hash()) - наверное самая неэффективная стратегия. Во-первых, это заставляет каждый поток читать весь объем данных, и вместо чтения огромной таблицы один раз, она читается 10 раз. Во вторых, это заставляет делать вычисления mod(hash()) для каждой строки в каждом потоке. В-третьих - конкуренция. Если потоки идут по близким данным, то достаточно двум сессиям столкнуться на блокировке, и все остальные тоже туда же "налетят", образуя "кучу-малу". Процесс этот лавинообразный - конкуренция порождает конкуренцию -> повышает нагрузку. Если в потоках данные еще и модифицируются, да хотя бы статус "в обработке" меняется, то все это так же лавинообразно встает на блокировках.
Оптимальная стратегия, конечно, зависит от задачи и условий.
Если это переливка больших объемов, то лучше делить таблицу на диапазоны и отдавать свой диапазон каждому потоку. Отдельный уровень "просветления" - делать это не на логическом уровне: значении, например, PK, а прямо на "физическом" - деля на диапазоны прямо пофайлово через ctid. Это самый быстрый способ указать базе на конкретную строку или диапазон. Но нужно хорошо понимать ограничения и подводные камни.
Классический способ "развести" потоки и не читать данные помногу раз - деление на диапазоны по какому нибудь достаточно хорошо распределенному значению, идеальный пример - Primary Key. Если условия позволяют, то делать это можно прямо при старте потоков, не заморачивась каким-либо координатором.
Если данные динамически меняются, то тут можно применить схожий подход, но уже с координатором "сверху" - пусть он отдает обработчиками диапазоны, а не отдельные строки.
Если это какая-то большая очередь для разбора и обработка строки занимает существенно больше времени, чем выбор этой строки, то можно идти и по всем строкам каждому потоку, пропуская уже обрабатываемые "соседом" строки через skip locked.
Бывают ситуации когда обработчик очереди просто нужно "дергать" чаще. Не давать скопиться значительному объему.
Есть и другие способы и стратегии, но для mass process, хорошими практиками будет не читать данные по нескольку раз и развести потоки так, чтобы они не пересекались в одних структурах.
Немного не понял про сетевой стек, он ок.
Почему свеженалитые данные могут вести тебя "не так".
Первое, это конечно же, кеширование на разных уровнях. Тут для повторяемости лучше всего подходит обнуление всех кешей и и много итераций теста.
Второе - план запроса. Если статистика не актуальна, то планы могут "плыть", но это легко отлавливается.
Третье менее очевидно, но тоже имеет место быть: это отложенная очистка блока. Идея в чем - если транзакция достаточно большая, то она по commit не идет в каждый затронутый блок, не снимает блокировки, не меняет статусы транзакций - это слишком накладно.
За нее это сделает следующий пришедший в страницу select. Но даже такое снятие блокировки со строки - это модификация страницы, а значит - запись в wal со всеми вытекающими. А уже следующий select "чистить" ничего не будет и ведет себя немного иначе.
Абсолютно верное замечание.
И первой была серия тестов версий 17 и 18 на том же самом железе, чтобы убедиться что 17-ый идентичен 18-му в "классическом" режиме.
Тестировалось на разном железе.
SATA SSD, три типа PCI-E NVME, и даже RAM-disk.
Виртуализация и bare-metal от 1-го до 16-ти ядер
С разными размерами баз, настройками буферов и степенью параллелизма.
Меняются абсолютные показатели, но относительные всегда плюс/минус одинаковые.
Надо завести учетку на autodesk.com, потом нажать на значок своей учетки справа-сверху -> и в меню "Products and services"
Autodesk Fusion 360. Бесплатен для персонального использования, но для скачивания придется озаботиться vpn.
Как раз предназначен для параметрического моделирования, но возможен и "free hand". Параметрического - значит что можно вернуться назад и изменить размер, форму - все последующие шаги и вся модель "пересчитаются" сами.
На "борту" сразу скругления, фаски, отверстия и т.д. При подсказках ИИ осваивается за пару вечеров.
Безусловно, если в ваших условиях Split Brain допустим, то норм.
Просто я считаю необходимым предупреждать ищущих решение в интернете о возможности такой ситуации чтобы это не было сюрпризом. Что при потере связности узлов появятся два активных мастера и keepalive с чистой душой поднимет два одинаковых IP-шника на обоих нодах. И что в итоге за каша в данных может получиться даже бог не ведает.
Именно поэтому (почти) нет штатных двухузловых конфигураций кластеров на основе репликации. А не из-за вредности разработчиков :)
Про "почти" могу отдельно написать, если интересно. Но для двух локальных узлов можно посмотреть в сторону кластеризации не на основе репликации, а на основе Shared Storage. Как пример - PaceMaker (не к ночи помянут будет).
Я так понимаю, защиты от SplitBrain в принципе не предусмотрено?
Добрый день. Не могли бы вы раскрыть, какие проблемы решаются использованием S3 Storage взамен классической архитектуры? (Если сформулировать вопрос совсем просто - зачем это надо?).
Бесконечное и прозрачное масштабирование? Ок, принимается. Но это же размен легкости разовых mantainance-tasks на постоянные real-time проблемы?
Облачное хранение? Но если это не Amazon, то облачные провайдеры вполне себе предоставляют блочные устройства.
Хочется понять point статьи - это про замену GreenPlumb и Arenadata DB на Data Ocean Nova или про использование S3 и HDFS как универсального хранилища систем класса DataLake?
Продолжая аналогию с токарем: он хотя бы должен знать что бывает резьба дюймовая и метрическая.
Чтобы решать какую-то проблему с помощью ИИ нужно хотя бы знать о её наличии. Как пример, недавний пост на Хабре с "удивительной" борьбой с NULL в sql, хотя это поведение просто описано в документации.