нельзя настроить транзакционную репликацию, добиться синхронности данных на множестве серверов и сказать, что это кластер СУБД.
кроме того, что можно, так вы сами это и делаете.
то что вы рассказываете - старый добрый 2РС, и его ХА транзакции.
При параллельном выполнении от всех серверов на всех серверах - очень быстро заканчиваются коннекты.
Короче, как делают:
Если заменить ваш хэш на серийный номер транзакции, как в РАФТ протоколе, не исключает хеш, как дополнительную проверку. Прокси сделать в виде GTC - Global Transaction Coordinator, который определяет мастера. Все сервера - могут писать, если сервер падает, то падают подключенные клиенты и выполняемые транзакции. клиенты переподключаються, и перевыполняют транзакции, так-же как в без кластерном варианте... я не буду цикл стаей делать, бета кластера доступна и бесплатна.
Ванильный постгрес со всеми транзакциями
Переезд на кластер и обратно, без копирования данных
Проблема Писатель-Писатель принципиально не решается без proxy-сервиса на логическом уровне анализа SQL-трафика приложения.
Извините, но это не так.
SET Итог = Итог+Дельта
Таких алгоритмов в принципе не существует, ...
просто добавить Итог в условие, или поле версии - инкремент
Много читать, еле осилил, но так и не нашел: - Master-Master, подразумевает возможность записи на любой мастер. У вас один вход в прокси. - в двух словах - САР теорему как решили?
Добавлять/удалять товары в корзину --> Order Service
Оплачивать выбранные товары --> Payment Service
Писать отзывы на товары --> Review Service
Доставлять купленные товары --> Shipping Service
Добавлять/удалять товары --> Product Service
Во-первых: они все зависят друг от друга. Дальше по тексту "Product Service" относится к Core, и если задуматься, от него (почти) все зависят
Во вторых: модульная система, сделает то-же самое разделение ответственности, и даже hot-redeploy можно прикрутить.
Приведите хотя-бы один положительный момент от внедрения микросервисов, который без микросервисов не возможен. (Про резюме и job security, не надо, я это выше уже написал)
Имхо, будет верно и такое, что нормальным людям важнее иметь репутацию, желательно децентрализованную, чем анонимность. Наличие анонимности тоже не плохо, но репутация будет гораздо важнее.
"ИИ" не смог 9.11 и 9.9 сравнить. И проблема не в том, что это пофиксили быстро, а в том, что такое элементарное знание вообще вызвало ошибку! А сколько еще ошибок осталось?
Выгоден работодателю на длительном периоде. Но не выгоден менеджеру - увеличение эффективности работников нужно показать здесь и сейчас. Чтоб будет с компании после принятия предложенных манагером 'эффективных' решений, манагера не волнует.
Запрос распадается на аналогичные асинхронные подзапросы для каждой секции, в том числе удаленные, с финальной агрегацией на координаторе. ... а также частичная агрегация результатов, выполняется удаленно.
Как у вас с эффективностью параллельного выполнение запросов?
В основе шардирования и выполнения распределенных запросов лежат стандартные механизмы секционирования и postgres fdw (foreign data wrapper).
Если сделать ванильные RO async реплики и FDW partition, то можно SQL аналитические запросы гонять к большим данным за приемлемое время?
Бенчмарки никто не делал вертикальный VS горизонтальный scale?
Не во всех.
Просто не используйте такие языки и не столкнетесь с проблемой сборки мусора.
Вот щас обидно было
Ну и причем здесь ватерфол? Взять и сделать тесты, для своего кода! кто-то запрещал? Тут даже манагера не надо, просто ответственный подход.
Графики и девелопмент!? А вы точно аджайл делаете?
Мне лично удобнее, когда тикеты и код - ближе друг-другу, github projects например.
Я с 1С не работал, лет 20. Если клиенты разные - то или на DNS балансировать, или Т3 урл, клиент будет выбирать сервер.
"бета кластера доступна и бесплатна", обращайтесь
кроме того, что можно, так вы сами это и делаете.
то что вы рассказываете - старый добрый 2РС, и его ХА транзакции.
При параллельном выполнении от всех серверов на всех серверах - очень быстро заканчиваются коннекты.
Короче, как делают:
Если заменить ваш хэш на серийный номер транзакции, как в РАФТ протоколе, не исключает хеш, как дополнительную проверку. Прокси сделать в виде GTC - Global Transaction Coordinator, который определяет мастера. Все сервера - могут писать, если сервер падает, то падают подключенные клиенты и выполняемые транзакции. клиенты переподключаються, и перевыполняют транзакции, так-же как в без кластерном варианте... я не буду цикл стаей делать, бета кластера доступна и бесплатна.
Ванильный постгрес со всеми транзакциями
Переезд на кластер и обратно, без копирования данных
Почти линейная масштабируемость
Извините, но это не так.
просто добавить
Итог
в условие, или поле версии - инкрементМного читать, еле осилил, но так и не нашел:
- Master-Master, подразумевает возможность записи на любой мастер. У вас один вход в прокси.
- в двух словах - САР теорему как решили?
Сравнивать и не упоминать https://jepsen.io/analyses ?
Ключ от
квартирыкошелькавам положил, или полмира?
положил девелопер, ну бывает
полмира - только и исключительно 'эффективные' манагеры, в первую очередь из микрософта
Ответ на ваш вопрос: gtihub -> owner/commiters
со 'все', я наверное погорячился, извините
Никто не знает, но все им пользуются?!
парадокс
Во-первых: они все зависят друг от друга. Дальше по тексту "Product Service" относится к Core, и если задуматься, от него (почти) все зависят
Во вторых: модульная система, сделает то-же самое разделение ответственности, и даже hot-redeploy можно прикрутить.
Приведите хотя-бы один положительный момент от внедрения микросервисов, который без микросервисов не возможен. (Про резюме и job security, не надо, я это выше уже написал)
в резюме классно выглядит!
Имхо, будет верно и такое, что нормальным людям важнее иметь репутацию, желательно децентрализованную, чем анонимность. Наличие анонимности тоже не плохо, но репутация будет гораздо важнее.
https://www.youtube.com/watch?v=vB9dJt9j-5M
"ИИ" не смог 9.11 и 9.9 сравнить. И проблема не в том, что это пофиксили быстро, а в том, что такое элементарное знание вообще вызвало ошибку! А сколько еще ошибок осталось?
"Что компенсирует?" ВСЕ!
Выгоден работодателю на длительном периоде. Но не выгоден менеджеру - увеличение эффективности работников нужно показать здесь и сейчас. Чтоб будет с компании после принятия предложенных манагером 'эффективных' решений, манагера не волнует.
Как у вас с эффективностью параллельного выполнение запросов?
Если сделать ванильные RO async реплики и FDW partition, то можно SQL аналитические запросы гонять к большим данным за приемлемое время?
Бенчмарки никто не делал вертикальный VS горизонтальный scale?