На десятом митапе Software Craftsmanship мы рассмотрим такую сложную тему, как распределенные транзакции. Мы увидим, почему возникает необходимость в распределенных транзакциях и какие бывают протоколы для реализации распределенных транзакций.
Микросервисная архитектура часто влечет за собой распределенные транзакции, и поэтому мы поговорим о том, как можно делать отдельные микросервисы максимально независимыми между собой.
Распределенные транзакции сложны эксплуатации, поэтому мы рассмотрим также и подходы, которые позволяют минимизировать или обойти необходимость в них, в то же время сохраняя необходимые бизнесу свойства приложения.
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Software craftsmanship 16: online building ml pipelinePavel Veinik
16й митап Software Craftsmanship пройдет онлайн и будет посвящен построению ML pipeline с точки зрения инженера-разработчика.
В последние год-два все чаще появляются вакансии, в которых инженеру необходимо выстроить ML pipeline. Такие вакансии получают название ML Ops.
В ML pipeline входят такие вещи, как построение моделей, хранение, сравнение качества моделей, поддержание версионность моделей, работа с feature storage, и само собой разумеется, применение модели в prod.
Модель обычно оформляется как микросервис, который можно просто разворачивать, масштабировать и поддерживать.
При этом, как правило, другими членами команды оказываются data scientists или ML engineers, которые сильны в своих областях, но не могут сделать простой масштабируемый REST API для своей модели. В рамках совместной работы с ними и приходится реализовывать ML pipeline.
На митапе мы коснемся того, для чего необходим ML pipeline, из каких шагов он состоит, и каким образом организована работа инженера в ML команде.
На десятом митапе Software Craftsmanship мы рассмотрим такую сложную тему, как распределенные транзакции. Мы увидим, почему возникает необходимость в распределенных транзакциях и какие бывают протоколы для реализации распределенных транзакций.
Микросервисная архитектура часто влечет за собой распределенные транзакции, и поэтому мы поговорим о том, как можно делать отдельные микросервисы максимально независимыми между собой.
Распределенные транзакции сложны эксплуатации, поэтому мы рассмотрим также и подходы, которые позволяют минимизировать или обойти необходимость в них, в то же время сохраняя необходимые бизнесу свойства приложения.
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Software craftsmanship 16: online building ml pipelinePavel Veinik
16й митап Software Craftsmanship пройдет онлайн и будет посвящен построению ML pipeline с точки зрения инженера-разработчика.
В последние год-два все чаще появляются вакансии, в которых инженеру необходимо выстроить ML pipeline. Такие вакансии получают название ML Ops.
В ML pipeline входят такие вещи, как построение моделей, хранение, сравнение качества моделей, поддержание версионность моделей, работа с feature storage, и само собой разумеется, применение модели в prod.
Модель обычно оформляется как микросервис, который можно просто разворачивать, масштабировать и поддерживать.
При этом, как правило, другими членами команды оказываются data scientists или ML engineers, которые сильны в своих областях, но не могут сделать простой масштабируемый REST API для своей модели. В рамках совместной работы с ними и приходится реализовывать ML pipeline.
На митапе мы коснемся того, для чего необходим ML pipeline, из каких шагов он состоит, и каким образом организована работа инженера в ML команде.
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Kubernetes is not needed to 90 percents of the companies.rusIvan Glushkov
Эйфория и хайп вокруг Kubernetes не дают всем компаниям возможности трезво взглянуть на сложности, проблемы и риски процесса перехода на Kubernetes.
Я попробую остудить пыл самых смелых и наивных, и показать, что этот путь очень тернист и опасен:
рассмотрю список стандартных проблем,
покажу, на что следует обратить внимание при планировании перехода,
и посоветую "ничего не трогать, пока работает".
Стандартно, банально, но может сэкономить вам массу нервов и денег.
Software craftsmanship meetup 21: CQRS что такое и для чего Pavel Veinik
Мы рассмотрим что такое CQRS, какие проблемы он может решить и какие проблемы создать, а также сопутствующие подходы и приемы, такие как event sourcing, предагрегация данных для чтения, использование in memory баз данных. Также разберем ситуации, в которых выгодно использовать CQRS, и назовем несколько систем, в которых он используется.
Также разберем вопросы data consistency в CQRS-архитектурах, и другие возникающие проблемы.
Какие бывают провайдеры услуг дата-центров и как выбрать оптимальный? / Игорь...Ontico
Все знают поговорку "два переезда равны одному пожару" и все понимают, что значит "перенос highload проекта с одного провайдера хостинга на другого с обеспечением непрерывности функционирования сервисов для пользователей".
Выбор "правильного" провайдера услуг дата-центров очень важен, но есть две проблемы:
1) "Все лгут" - маркетинг провайдера и реальность далеко не всегда совпадают, все провайдеры рассказывают о своих сильных сторонах и умалчивают о слабых;
2) "когда у вас в руках молоток - все вокруг превращается в гвозди" - все провайдеры услуг имеют свою специализацию и любую задачу клиента они стремятся решить так, как умеют, а не так как надо клиенту.
В своем докладе я постараюсь рассмотреть все аспекты вопроса выбора провайдера/провайдеров услуг хостинга/дата-центров.
Данный доклад ориентирован на широкую аудиторию и будет полезен всем, кому надо выбирать провайдера услуг хостинга/дата-центров для внутренних и/или внешних проектов.
В рамках доклада будут рассмотрены следующие вопросы:
1) формализация ТЗ на оказание услуг провайдерами или "а что нам надо";
2) классификация провайдеров дата-центров по спектру оказываемых услуг;
3) SLA - что это? какие SLA бывают? что подразумевают провайдеры и чего ожидаете вы в документе под названием Service Level Agreement;
4) магическое слово compliance, или что хочет государство;
5) чем отличаются одни провайдеры от других;
6) как проверить провайдера - uptime/связанность/рейтинги/спектр услуг;
7) пишем RFP - как сформулировать потребности так, чтобы потом результат не разочаровал.
Software craftsmanship 15 online: Reliability and ResiliencyPavel Veinik
Мы возобновляем после перерыва митапы Software Craftsmanship, и наш пятнадцатый митап будет посвящен надежности и устойчивости систем. Мы разберем stability, reliability, fault-tolerance, availability, resilience, узнаем как они связаны друг с другом и как можно их измерять, а также как разрабатывать устойчивые и надежные программы.
Также мы сформулируем принципы создания надежных систем, паттерны и антипаттерны надежности и устойчивости, отдельное внимание уделим устойчивости микросервисов в облаке.
План митапа:
Stability, reliability, fault-tolerance, availability, resilience, их связь и отличия
Архитектура и шаблоны availability
Шаблоны resilience
Техники fault tolerance
Устойчивости и надежность в облаке
Микросервисы, кто-то только слышал о них, кто-то пытался делать, кто-то уже использует в продакшене. Идеи, заложенные в концепцию микросервисов, не новы и основные постулаты уже звучали раньше. Так почему же в последнее время мы всё чаще слышим о микросервисах? Что такое микросервисы для нас и чем они отличаются от старого доброго подхода SOA? Как теперь разрабатывать enterprise-приложения с микросервисным подходом на нашем любимом языке программирования Java?
На эти и некоторые другие вопросы постараемся ответить во время встречи. Наши гости, Кирилл Толкачёв и Александр Тарасов, в режиме live coding попытаются создать небольшой стартап, попутно использовав новомодные подходы и инструменты.
На пути к релизу стартапа будут затронуты основные проблемы выбранных подходов в целом и технологий в частности:
Микросервис — что это, для чего и как с этим дальше жить. Где теория брат? ;)
На чём писать API: REST или RPC, и почему Thrift имеет право на жизнь в эпоху тотального распространения JSON-а. Упрощай и превозмогай с помощью Spring boot starter;
Какой стек выбрать для разработки, что выбрали мы и почему. Небольшое сравнение легковесных и не очень java фреймворков а так же сопутствующих инструментов;
Способы упаковки, дистрибуции и разворачивания микросервисов, как Spring Boot и Docker помогают нам в решении этих непростых для разработчика проблемах;
Как микросервисам найти друг друга, как готовить Spring Cloud и как обойти существующие проблемы и ограничения. Не доверяйте технологиям, доверяйте только себе;
API Gateway. Предохраняй и сохраняй свои микросервисы.
Так же речь пойдет о других распространенных проблемах распределенных систем и их решениях.
какие бывают типы микросервисных архитектур (распределенный монолит, слои микросервисов, feature-based микросервисы) и как именно микросервисы взаимодействуют друг с другом в рамках того или иного типа.
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Kubernetes is not needed to 90 percents of the companies.rusIvan Glushkov
Эйфория и хайп вокруг Kubernetes не дают всем компаниям возможности трезво взглянуть на сложности, проблемы и риски процесса перехода на Kubernetes.
Я попробую остудить пыл самых смелых и наивных, и показать, что этот путь очень тернист и опасен:
рассмотрю список стандартных проблем,
покажу, на что следует обратить внимание при планировании перехода,
и посоветую "ничего не трогать, пока работает".
Стандартно, банально, но может сэкономить вам массу нервов и денег.
Software craftsmanship meetup 21: CQRS что такое и для чего Pavel Veinik
Мы рассмотрим что такое CQRS, какие проблемы он может решить и какие проблемы создать, а также сопутствующие подходы и приемы, такие как event sourcing, предагрегация данных для чтения, использование in memory баз данных. Также разберем ситуации, в которых выгодно использовать CQRS, и назовем несколько систем, в которых он используется.
Также разберем вопросы data consistency в CQRS-архитектурах, и другие возникающие проблемы.
Какие бывают провайдеры услуг дата-центров и как выбрать оптимальный? / Игорь...Ontico
Все знают поговорку "два переезда равны одному пожару" и все понимают, что значит "перенос highload проекта с одного провайдера хостинга на другого с обеспечением непрерывности функционирования сервисов для пользователей".
Выбор "правильного" провайдера услуг дата-центров очень важен, но есть две проблемы:
1) "Все лгут" - маркетинг провайдера и реальность далеко не всегда совпадают, все провайдеры рассказывают о своих сильных сторонах и умалчивают о слабых;
2) "когда у вас в руках молоток - все вокруг превращается в гвозди" - все провайдеры услуг имеют свою специализацию и любую задачу клиента они стремятся решить так, как умеют, а не так как надо клиенту.
В своем докладе я постараюсь рассмотреть все аспекты вопроса выбора провайдера/провайдеров услуг хостинга/дата-центров.
Данный доклад ориентирован на широкую аудиторию и будет полезен всем, кому надо выбирать провайдера услуг хостинга/дата-центров для внутренних и/или внешних проектов.
В рамках доклада будут рассмотрены следующие вопросы:
1) формализация ТЗ на оказание услуг провайдерами или "а что нам надо";
2) классификация провайдеров дата-центров по спектру оказываемых услуг;
3) SLA - что это? какие SLA бывают? что подразумевают провайдеры и чего ожидаете вы в документе под названием Service Level Agreement;
4) магическое слово compliance, или что хочет государство;
5) чем отличаются одни провайдеры от других;
6) как проверить провайдера - uptime/связанность/рейтинги/спектр услуг;
7) пишем RFP - как сформулировать потребности так, чтобы потом результат не разочаровал.
Software craftsmanship 15 online: Reliability and ResiliencyPavel Veinik
Мы возобновляем после перерыва митапы Software Craftsmanship, и наш пятнадцатый митап будет посвящен надежности и устойчивости систем. Мы разберем stability, reliability, fault-tolerance, availability, resilience, узнаем как они связаны друг с другом и как можно их измерять, а также как разрабатывать устойчивые и надежные программы.
Также мы сформулируем принципы создания надежных систем, паттерны и антипаттерны надежности и устойчивости, отдельное внимание уделим устойчивости микросервисов в облаке.
План митапа:
Stability, reliability, fault-tolerance, availability, resilience, их связь и отличия
Архитектура и шаблоны availability
Шаблоны resilience
Техники fault tolerance
Устойчивости и надежность в облаке
Микросервисы, кто-то только слышал о них, кто-то пытался делать, кто-то уже использует в продакшене. Идеи, заложенные в концепцию микросервисов, не новы и основные постулаты уже звучали раньше. Так почему же в последнее время мы всё чаще слышим о микросервисах? Что такое микросервисы для нас и чем они отличаются от старого доброго подхода SOA? Как теперь разрабатывать enterprise-приложения с микросервисным подходом на нашем любимом языке программирования Java?
На эти и некоторые другие вопросы постараемся ответить во время встречи. Наши гости, Кирилл Толкачёв и Александр Тарасов, в режиме live coding попытаются создать небольшой стартап, попутно использовав новомодные подходы и инструменты.
На пути к релизу стартапа будут затронуты основные проблемы выбранных подходов в целом и технологий в частности:
Микросервис — что это, для чего и как с этим дальше жить. Где теория брат? ;)
На чём писать API: REST или RPC, и почему Thrift имеет право на жизнь в эпоху тотального распространения JSON-а. Упрощай и превозмогай с помощью Spring boot starter;
Какой стек выбрать для разработки, что выбрали мы и почему. Небольшое сравнение легковесных и не очень java фреймворков а так же сопутствующих инструментов;
Способы упаковки, дистрибуции и разворачивания микросервисов, как Spring Boot и Docker помогают нам в решении этих непростых для разработчика проблемах;
Как микросервисам найти друг друга, как готовить Spring Cloud и как обойти существующие проблемы и ограничения. Не доверяйте технологиям, доверяйте только себе;
API Gateway. Предохраняй и сохраняй свои микросервисы.
Так же речь пойдет о других распространенных проблемах распределенных систем и их решениях.
какие бывают типы микросервисных архитектур (распределенный монолит, слои микросервисов, feature-based микросервисы) и как именно микросервисы взаимодействуют друг с другом в рамках того или иного типа.
Андрей Николаенко, IBS. NVMf: 5 млн IOPS по сети своими рукамиIBS
Андрей Николаенко, системный архитектор в IBS, выступил на конференции HighLoad++ 2016.
Тезисы
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
NVMf: 5 млн IOPS по сети своими руками / Андрей Николаенко (IBS)Ontico
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Современные серверы DEPO Storm и системы хранения DEPO StorageDEPO Computers
Сергей Сенько, руководитель направления по серверной продукции компании DEPO Computers, обозначил тенденции в изменениях требований к инфраструктуре и серверному оборудованию ЦОД и презентовал новые модели серверов DEPO Storm с примерами решений для внедрения виртуализации и частного облака от десятков до тысяч пользователей.
Вебинар «Дедупликация vs Hеконтролируемый рост данных»
Подробнее о мероприятии http://www.croc.ru/action/detail/5668/
Презентация Дмитрия Дощаного, директора центра решений КРОК на базе технологий EMC
Ukraine, Kharkiv, Jave Club. (Day 2)
In this presentation you can find the brief overview of Clloud Computing development vs. desktop app. development. This presentation oriented to persons with general level of knowledge in such topics as:
Amazon AWS, cloud computing, CAP theorem, logical time.
Сейчас контейнеризация и Kubernetes в частности — стандарт де-факто для запуска приложений «в бою». И запустить-то приложение в «кубе» несложно, но как всегда есть нюанс и не один. Обсудим, что нужно разработчику и админу учесть и сделать для того, чтобы приложение работало быстро и надёжно, не требуя к себе особого внимания. Например, посмотрим, как работают requests и limits на ресурсы, чем должны отличаться liveness и readiness пробы, и на что следует обращать внимание в мониторинге и так далее.
Вступительная лекция по Java. История появления, идеи, сферы применения, место среди других языков, экосистема. Структурированная информация о Java, как о языке программирования.
Под эту лекцию имеется более развёрнутый материал. Кому интересно - пишите.
Конструктивная критика приветствуется.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Software craftsmanship meetup 20. транзакции и data constistency в микросерви...Pavel Veinik
Рассмотрим обеспечение транзакционности в микросервисах, от “транзакционной” отправки сообщений до “транзакционного” обновления данных в нескольких микросервисах. Рассмотрим и соответствующие типовые решения - шаблон Transactional outbox, двухфазные транзакции, а также шаблон Saga вместе с компенсирующими транзакциями.
СИ — это способ построить успешную систему и объединить всех людей на проекте в одно целое для продуктивного решения задачи любой сложности. Это неотъемлемая часть грамотного руководства проектом, именно поэтому по статистике зарплаты системных инженеров самые высокие в любой отрасли и IT не является исключением.
Software craftsmanship 14 online Splitting the MonolithPavel Veinik
Каждый развивающий бизнес на определенном этапе своего жизненного цикла сталкивается с задачей масштабирования. Для монолитного приложения эта задача может оказаться сложнее, чем написать с нуля масштабируемую систему - потому что нужно учитывать миграцию данных и пользователей, а также недостаточные ресурсы.
Мы попытаемся понять, в каких случаях монолит распиливать стоит, а когда можно применить более простые подходы. Рассмотрим преимущества и недостатки монолитной архитектуры и микросервисной. Разберем несколько стратегий распиливания монолита, а также аспекты, которые необходимо учесть во время этого процесса.
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Программирование и лингвистика: как понять язык и извлечь знания из текстовPavel Veinik
Knowledge extraction с помощью open source java технологий - что это такое, как, и для чего? На примере реального проекта докладчик расскажет о том, как создать систему извлечения знаний и как с ее помощью получать полный и минимальный обзор событий в интересующих областях.
Человеческий фактор в разработке, или ORM на noSql через JPA.Pavel Veinik
Зачем переводить работающий проект с RDBMS на noSql? Как это сделать, и как это нельзя делать? Что важнее для успеха пректа - технологическое преимущество или доверительные отношения в команде? Какова роль процесса в успехе проекта и что бывает, когда каждый член команды действует в соответствии со своими локальными интересами.
2. Зачем митапы?
Поделиться с разработчиками Splitmetrics
Поделиться со всеми разработчиками
Обкатать новый курс для техлидов
Пообщаться
3. Для кого митапы?
Для разработчиков
Для тестировщиков
Для сочувствующих и интересующихся
4. Что если я чего-то не знаю?
Ничего страшного, мы расскажем
Вообще, можно спросить у меня или у коллег
Все будет хорошо
5. План митапов
1. Software Craftsmanship & Agile.
Как не делать говно?
2. Принципы хранения данных
3. Обзор баз данных
4. Очереди сообщений
5. Кэши и файловые хранилища
6. План этого митапа
1. Алгоритмическая сложность
2. ACID vs BASE
3. И теорема CAP
4. Примеры применения ACID и BASE
5. 2 простых задания на архитектуру
7. Время cpu vs память
Найти x в массиве
Перебор
Поиск в отсортированном массиве
Хранение флага для любого x
Зачем это знать?
11. ACID
Atomicity
Сохраняется или вся транзакция, или ничего
Consistency
Транзакция завершается или откат к предыдущему состоянию
Isolation
Транзакции изолированы друг от друга
Durability
Завершенные транзакции сохраняются
13. Isolation. Проблемы
Non-repeatable read
Разные результаты одной и той же выборки. Др
транзакция успела обновить
Phantom read
Разные результаты одной и той же выборки. Др
транзакция успела добавить
18. Isolation. Уровни
Snapshot – иногда
Каждая транзация в своей «копии бд»
Гарантия – защита от dirty reads, non-
repeatable reads, phantom reads
Как будто все транзакции последовательны,
локи
20. А если много данных?
Как обеспечить ACID, если данных больше,
чем может вместить один сервер?
Как обеспечить ACID, если мы дублируем
данные между разными серверами?
22. Теорема CAP
Consistency
Данные не противоречивы во всех узлах в каждый момент
времени
Availability
Отклик системы корректен, но без гарантии совпадения данных в
узлах
Partition Tolerance
Разрезание системы на изолированные куски не приводит к
некорректности отклика
25. Теорема PACELC
В случае Partitioning выбираем
между Availability или Consistency
В случае не Partitioning выбираем
между Latency или Consistency
26. Что с ACID, если CAP?
Как выдержать ACID, если у нас
Partitioning?
27. Что с ACID, если CAP?
Basically Available
Ответ на любой запрос, но не факт что не ошибочный
Soft State
Несогласованность между узлами даже когда нет обновлений
данных
Eventual Consistency
Рано или поздно система придет в согласованное состояние
после прекращения обновления данных