А ещё можно сделать гигантские аккумуляторы и возить их на танкерах заряжаться «грязной» дешёвой электроэнергией в страны третьего мира. «Выработка электроэнергии на аутсорс»
It is based on academic research on JSON CRDTs, but the details of the algorithm in Automerge are different from the JSON CRDT paper, and we are planning to publish more detail about it in the future.
всё-таки статья была далеко от практической реализации, будем следить за развитием событий :)
Но как вы сами отметили, это не реализация JSON, если я правильно понял — там от него осталась только возможность конвертации из RON в JSON, так что ваш пример не совсем корректен.
Интересно, как я понял они вводят отношение порядка через uuid на каждое сообщение протокола и при этом на все CRDT применяют last write wins. Честно говоря, для меня не очень понятны цели этого проекта (всё-таки они предлагают и БД свою использовать — а это довольно серьёзное ограничение), было бы интересно пообщаться с автором.
Если вам интересно узнать про попытку реализации JSON — вот тут интересная статья, но она пока ещё в теоретическом статусе.
Если мы разрешаем счётчику сходится в -1, то как же он тогда может называться неотрицательным?
Это ответ ваш вопрос «Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?»
Понимаете, в случае с (S)EC вы уже не мыслите так категорично. Я вам предложил три варианта задачи — выбирайте любую. В любой разумной постановке (я же вам привёл примеры использования) этой задачи нет простого решения. Посмотрите — сколько вариантов реализаций множества придумано, каждый со своими особенностями.
Пример — количество здоровья у игрока во время битвы или банковский счёт когда идёт несколько списаний с разных точек. Кстати интересный факт — банкоматы могут (и кое-где так и есть) выдавать деньги в условиях network partitioning.
Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?
В случае независимых декрементов наш счётчик должен сойтись в -1.
т.е. нужно средствами CRDT гарантировать, чтобы на каждой реплике было неотрицательное значение?
Это как вы пожелаете. Предлагаю вам рассмотреть несколько вариантов
1) разрешать репликам временно уходить в минус (а что тогда делать клиентам, которые получили отрицательное? Значит ли это, что герой мёртв?), если при этом гарантировать, что целевое значение сходится в неотрицательное число (а как?)
2) запрещать репликам уходить в минус
3) разрешать итоговому значению временно уходить в минус (пример с банкоматами)
Честно говоря нет, в планах пока что закончить с репликами, пройтись по шардированию и кворумам. Я помню была какая-то статья от авторов, не очень большая, но скорее теоретическая (в том смысле что тяжело будет адаптировать в формат Хабра). Посмотрю что из других материалов есть по вашей теме для статьи, и попробую написать, если будет время.
Спасибо за предложение!
Спасибо за статью, уточните пожалуйста пару моментов:
Допустим, клиент прислал координатору запрос на открытие транзакции для такой-то сущности с таким-то первичным ключом. Координатор эту сущность блокирует и помещает в таблицу блокировок в памяти.
Блокирует на запись только, т.е. остальные клиенты могут читать?
Таким образом, клиент может прочитать собственные изменения, а другие клиенты эти изменения не видят, потому что хранятся они только в памяти координатора, в нодах Cassandra их еще нет.
А если ваш клиент в это время делает синхронный запрос в другой ваш сервис, которому надо получить из хранилища данные, актуальные относительно текущей транзакции?
И последний: R + W > N? на сколько нод пишете и со скольки читаете?
Некоторые должностные лица отнеслись к внедряемым изменения откровенно негативно — хотя при разговоре лицом к лицу или согласно кивали или просто молчали.
Мне кажется это такая прослойка менеджерского звена, которая «ни рыба, ни мясо». Они даже могут быть и линейными менеджерами, но по факту их роль выше, но ниже уровня, где можно принимать фундаментальные решения в их отделе. Такие должности могут возникать как в ответ на увеличение штата нижнего звена, так и под влиянием различных попыток хоть как-то исправить ситуацию.
В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек
Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
Так это что получается, можно дома заниматься выращиванием устойчивых бактерий и мазать ими поручни в метро? Или для такого эксперимента нужны какие-то уникальные условия?
В uk, например, не то, чтобы на анализ не направят, но и к терапевту только в порядке общей очереди (ждать примерно неделю-две).
Я как-то кашлял почти месяц, так меня отказались записать на приём, единственное что удалось — терапевт позвонил по телефону и попросил покашлять в трубку.
Конечно, мне была задана куча уточняющих вопросов, чтобы понять, записывать меня на приём или нет, и в особых случаях и скорая приедет. Но в целом я как-то стал менее чувствительно относиться ко всяким лёгким недомоганиям. Может, оно и к лучшему?
1. Я стараюсь разграничивать роли и обязанности, чего и вам советую. Если у меня есть плейбуки, в которых прописана логика работы с моим докер-окружением, значит у меня билд имаджа тоже в плейбуке. (см ниже про teamcity)
2.
Docker-compose делает тоже самое, что и настроенные ansible роли для контейнеров (
Таки нет. Этот модуль — обёртка над docker api. docker-compose в общем-то, простенькая утилита для удобного развёртывания/прибивания докер-окружения, которую, кстати, можно использовать в связке со swarm. Из приятных бонусов, как я уже упомянул — dns и изолированная сеть, а ещё не надо думать про имена хостов и контейнеров.
3. Если вынести весь management в ansible (чего я советую), то teamcity, как дорогой enterprise-продукт, становится избыточным. Я, честно говоря, не имею опыта использования teamcity как scheduler, возможно это как-то оправдано, но я бы порекомендовал использовать что-то другое, в зависимости от проекта.
Раз уж используете докер — то делайте сборку проекта в докере.
Почему не подошёл docker-compose? Точно такое же изолированное окружение со своей сетью и dns.
Прописываете * в днс на сервере и делаете поддомен на каждый новый бранч. Вот это поможет не плясать с бубном и не теребить docker inspect
Если ваше использование teamcity ограничивается вышенаписанным, то в конце заворачиваете всё в ansible и, в общем-то, teamcity становится не особо нужным.
Вообще тенденция развития docker inc слегка настораживает, уж больно сильно начинает пахнуть упором на платные enterprise-подписки и тотальным vendor lock-in.
elasticsearch почему-то перенёс имаджи в свой приватный репозиторий.
К счастью, разработчики Docker прекрасно понимают необходимость поддержки не только Linux в качестве базовой ОС.
Во второй половине 2016 года были выпущены официальные релизы Docker для Mac и Windows.
Немного настораживает
всё-таки статья была далеко от практической реализации, будем следить за развитием событий :)
Но как вы сами отметили, это не реализация JSON, если я правильно понял — там от него осталась только возможность конвертации из RON в JSON, так что ваш пример не совсем корректен.
Интересно, как я понял они вводят отношение порядка через uuid на каждое сообщение протокола и при этом на все CRDT применяют last write wins. Честно говоря, для меня не очень понятны цели этого проекта (всё-таки они предлагают и БД свою использовать — а это довольно серьёзное ограничение), было бы интересно пообщаться с автором.
Если вам интересно узнать про попытку реализации JSON — вот тут интересная статья, но она пока ещё в теоретическом статусе.
Это ответ ваш вопрос «Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?»
Понимаете, в случае с (S)EC вы уже не мыслите так категорично. Я вам предложил три варианта задачи — выбирайте любую. В любой разумной постановке (я же вам привёл примеры использования) этой задачи нет простого решения. Посмотрите — сколько вариантов реализаций множества придумано, каждый со своими особенностями.
В случае независимых декрементов наш счётчик должен сойтись в -1.
Это как вы пожелаете. Предлагаю вам рассмотреть несколько вариантов
1) разрешать репликам временно уходить в минус (а что тогда делать клиентам, которые получили отрицательное? Значит ли это, что герой мёртв?), если при этом гарантировать, что целевое значение сходится в неотрицательное число (а как?)
2) запрещать репликам уходить в минус
3) разрешать итоговому значению временно уходить в минус (пример с банкоматами)
Спасибо за предложение!
Спасибо, а внутри ДЦ?
Блокирует на запись только, т.е. остальные клиенты могут читать?
А если ваш клиент в это время делает синхронный запрос в другой ваш сервис, которому надо получить из хранилища данные, актуальные относительно текущей транзакции?
И последний: R + W > N? на сколько нод пишете и со скольки читаете?
Предполагаю, потому что если вы её покупаете и принимаете решение использовать — то проблемы с экологией перекладываются на вас.
Мне кажется это такая прослойка менеджерского звена, которая «ни рыба, ни мясо». Они даже могут быть и линейными менеджерами, но по факту их роль выше, но ниже уровня, где можно принимать фундаментальные решения в их отделе. Такие должности могут возникать как в ответ на увеличение штата нижнего звена, так и под влиянием различных попыток хоть как-то исправить ситуацию.
В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек
Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
Я как-то кашлял почти месяц, так меня отказались записать на приём, единственное что удалось — терапевт позвонил по телефону и попросил покашлять в трубку.
Конечно, мне была задана куча уточняющих вопросов, чтобы понять, записывать меня на приём или нет, и в особых случаях и скорая приедет. Но в целом я как-то стал менее чувствительно относиться ко всяким лёгким недомоганиям. Может, оно и к лучшему?
2.
Таки нет. Этот модуль — обёртка над docker api. docker-compose в общем-то, простенькая утилита для удобного развёртывания/прибивания докер-окружения, которую, кстати, можно использовать в связке со swarm. Из приятных бонусов, как я уже упомянул — dns и изолированная сеть, а ещё не надо думать про имена хостов и контейнеров.
3. Если вынести весь management в ansible (чего я советую), то teamcity, как дорогой enterprise-продукт, становится избыточным. Я, честно говоря, не имею опыта использования teamcity как scheduler, возможно это как-то оправдано, но я бы порекомендовал использовать что-то другое, в зависимости от проекта.
Если ваше использование teamcity ограничивается вышенаписанным, то в конце заворачиваете всё в ansible и, в общем-то, teamcity становится не особо нужным.
Вообще тенденция развития docker inc слегка настораживает, уж больно сильно начинает пахнуть упором на платные enterprise-подписки и тотальным vendor lock-in.
elasticsearch почему-то перенёс имаджи в свой приватный репозиторий.
На маке volumes нещадно тормозят, проблема открыта с марта 2016 года (актуально для Docker for Mac)
https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076
И даже подошло по смыслу :)