Integration testing is hard, and often teams are tempted to do it in production. Testcontainers allows writing meaningful integration tests spawning Docker containers for databases, queue systems, kv-store, other services. The talk, a blend of slides and live code, will show how we are able to deploy without fear while integrating with a dozen of different datastores. Don't mock your database with fake data anymore, work with real data
Cgroups, namespaces and beyond: what are containers made from?Docker, Inc.
Linux containers are different from Solaris Zones or BSD Jails: they use discrete kernel features like cgroups, namespaces, SELinux, and more. We will describe those mechanisms in depth, as well as demo how to put them together to produce a container. We will also highlight how different container runtimes compare to each other.
Integration testing is hard, and often teams are tempted to do it in production. Testcontainers allows writing meaningful integration tests spawning Docker containers for databases, queue systems, kv-store, other services. The talk, a blend of slides and live code, will show how we are able to deploy without fear while integrating with a dozen of different datastores. Don't mock your database with fake data anymore, work with real data
Cgroups, namespaces and beyond: what are containers made from?Docker, Inc.
Linux containers are different from Solaris Zones or BSD Jails: they use discrete kernel features like cgroups, namespaces, SELinux, and more. We will describe those mechanisms in depth, as well as demo how to put them together to produce a container. We will also highlight how different container runtimes compare to each other.
RESTful API Testing using Postman, Newman, and JenkinsQASymphony
INCLUDE AUTOMATED RESTFUL API TESTING USING POSTMAN, NEWMAN, AND JENKINS
If you’re going to automate one kind of tests at your company, API testing is the perfect place to start! It’s fast and simple to write as well as fast to execute. If your company writes an API for its software, then you understand the need and importance of testing it. In this webinar, we’ll do a live demonstration of how you can use free tools, such as Postman, Newman, and Jenkins, to enhance your software quality and security.
Elise Carmichael will cover:
Why your API tests should be included with your CI
Real examples using Postman, Newman and Jenkins + Newman
An active Q&A where you can get your automated testing questions answered, live!
To get the most out of this session:
Download these free tools prior to the webinar: Postman, Newman (along with node and npm) and Jenkins
Read up on how to parse JSON objects using javascript
*Can’t attend the webinar live? Register and we will send the recording after the webinar is over.
As the API Integrations Specialist at iQmetrix, I’m a frequent user of Postman. Postman has helped me streamline our onboarding and integration processes. Working with pre-request scripts, I can create environment templates that can be quickly updated with the environment variables required for the rest of the flow. I have designed Postman Collections that include both iQmetrix and partner APIs, allowing me to work with the Postman Collection Runner. With these processes in place, tasks that once took hours now only take a few minutes to complete. Using these sharable tools, I am able to create resources, share them with other teams, and create clear documentation with examples for use in client training scenarios.
Presentation describes basic concepts of thread pool such as:
- interacting with queues,
- using pools from Executors class,
- task rejecting
- using ThreadFactory for thread creating
- Future and Callable interfaces,
- basic API
- possibilities for extending
PCD – Process Control Daemon is a light-weight system level process manager for Embedded-Linux based projects (consumer electronics, network devices, etc.).
PCD starts, stops and monitors all the user space processes in the system, in a synchronized manner, using a textual configuration file.
PCD recovers the system in case of errors and provides useful and detailed debug information.
An introduction to Linux Container, Namespace & Cgroup.
Virtual Machine, Linux operating principles. Application constraint execution environment. Isolate application working environment.
Proponemos dos formas de organizar un panel para tareas recurrentes (casos reales).
Hay temas y tareas que, por su naturaleza, son pre-definidos y recurrentes. Se repiten iguales (o casi) de acuerdo a una cierta planificación, que puede ser periódica (un día, una semana, dos meses, etc.). Forman parte de una rutina de trabajo (operaciones); por ejemplo, la necesaria para gobernar y mantener el “Bussines As Usual (BAU)” de una compañía. Ej.: un informe mensual de servicio, la monitorización de servidores, etc.
En éstos casos… ¿Cómo organizar un panel? ¿Cómo aplicar el visual management?
El típico enfoque del panel “ToDo – Doing – Done” aplica bien a las tareas de proyecto, que por su naturaleza empiezan, acaban y no vuelven. Sin embargo, no acaba de ser plenamente satisfactorio para las tareas recurrentes. Para gobernar las tareas recurrentes es útil (1) ver la planificación general y (2) hacer un seguimiento del estado de ejecución real.
Jenkins is a Continuous Integration (CI) server or tool which is written in Java. It provides Continuous Integration services for software development, which can be started via command line or web application server. Jenkins Pipeline is a suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins.
HTTP/2 for Developers: How It Changes Developer's Life?
by Svetlin Nakov (SoftUni) - http://www.nakov.com
jProfessionals Conference - Sofia, 22-Nov-2015
Key new features in HTTP/2
- Multiplexing: multiple streams over a single connection
- Header compression: reuse headers from previous requests
- Sever push: multiple parallel responses for a single request
- Prioritization and flow control: resources have priorities
Monte Carlo modeling in cloud - mc-modeling-sdkAlexey Bokov
This deck based on my financial modeling in Azure workshop. It starts with a little theory of Brewer theorem and Monte Carlo simulation and then goes to mc-modeling-sdk on C++ which is open sourced there https://github.com/abokov/mc-modeling-sdk/
RESTful API Testing using Postman, Newman, and JenkinsQASymphony
INCLUDE AUTOMATED RESTFUL API TESTING USING POSTMAN, NEWMAN, AND JENKINS
If you’re going to automate one kind of tests at your company, API testing is the perfect place to start! It’s fast and simple to write as well as fast to execute. If your company writes an API for its software, then you understand the need and importance of testing it. In this webinar, we’ll do a live demonstration of how you can use free tools, such as Postman, Newman, and Jenkins, to enhance your software quality and security.
Elise Carmichael will cover:
Why your API tests should be included with your CI
Real examples using Postman, Newman and Jenkins + Newman
An active Q&A where you can get your automated testing questions answered, live!
To get the most out of this session:
Download these free tools prior to the webinar: Postman, Newman (along with node and npm) and Jenkins
Read up on how to parse JSON objects using javascript
*Can’t attend the webinar live? Register and we will send the recording after the webinar is over.
As the API Integrations Specialist at iQmetrix, I’m a frequent user of Postman. Postman has helped me streamline our onboarding and integration processes. Working with pre-request scripts, I can create environment templates that can be quickly updated with the environment variables required for the rest of the flow. I have designed Postman Collections that include both iQmetrix and partner APIs, allowing me to work with the Postman Collection Runner. With these processes in place, tasks that once took hours now only take a few minutes to complete. Using these sharable tools, I am able to create resources, share them with other teams, and create clear documentation with examples for use in client training scenarios.
Presentation describes basic concepts of thread pool such as:
- interacting with queues,
- using pools from Executors class,
- task rejecting
- using ThreadFactory for thread creating
- Future and Callable interfaces,
- basic API
- possibilities for extending
PCD – Process Control Daemon is a light-weight system level process manager for Embedded-Linux based projects (consumer electronics, network devices, etc.).
PCD starts, stops and monitors all the user space processes in the system, in a synchronized manner, using a textual configuration file.
PCD recovers the system in case of errors and provides useful and detailed debug information.
An introduction to Linux Container, Namespace & Cgroup.
Virtual Machine, Linux operating principles. Application constraint execution environment. Isolate application working environment.
Proponemos dos formas de organizar un panel para tareas recurrentes (casos reales).
Hay temas y tareas que, por su naturaleza, son pre-definidos y recurrentes. Se repiten iguales (o casi) de acuerdo a una cierta planificación, que puede ser periódica (un día, una semana, dos meses, etc.). Forman parte de una rutina de trabajo (operaciones); por ejemplo, la necesaria para gobernar y mantener el “Bussines As Usual (BAU)” de una compañía. Ej.: un informe mensual de servicio, la monitorización de servidores, etc.
En éstos casos… ¿Cómo organizar un panel? ¿Cómo aplicar el visual management?
El típico enfoque del panel “ToDo – Doing – Done” aplica bien a las tareas de proyecto, que por su naturaleza empiezan, acaban y no vuelven. Sin embargo, no acaba de ser plenamente satisfactorio para las tareas recurrentes. Para gobernar las tareas recurrentes es útil (1) ver la planificación general y (2) hacer un seguimiento del estado de ejecución real.
Jenkins is a Continuous Integration (CI) server or tool which is written in Java. It provides Continuous Integration services for software development, which can be started via command line or web application server. Jenkins Pipeline is a suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins.
HTTP/2 for Developers: How It Changes Developer's Life?
by Svetlin Nakov (SoftUni) - http://www.nakov.com
jProfessionals Conference - Sofia, 22-Nov-2015
Key new features in HTTP/2
- Multiplexing: multiple streams over a single connection
- Header compression: reuse headers from previous requests
- Sever push: multiple parallel responses for a single request
- Prioritization and flow control: resources have priorities
Monte Carlo modeling in cloud - mc-modeling-sdkAlexey Bokov
This deck based on my financial modeling in Azure workshop. It starts with a little theory of Brewer theorem and Monte Carlo simulation and then goes to mc-modeling-sdk on C++ which is open sourced there https://github.com/abokov/mc-modeling-sdk/
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
SETCON'18 - Dzmitry Nichyparuk - Designing reliable softwareNadzeya Pus
По-настоящему надежное программное обеспечение всегда скептически настроено и готово к отказам. Другие системы оно держит на расстоянии, так как слишком тесное взаимодействие может быть небезопасным. Оно не доверяет даже себе устанавливая внутренние барьеры для защиты от сбоев.
Azure web apps - designing and debuggingAlexey Bokov
Проектирование и отладка веб приложений с использованием облака Microsoft Azure. Технологии для повышения отказоустойчивости и надежности веб приложений, в том числе при использовании своего хостинга.
Azure: Docker Container orchestration, PaaS ( Service Farbic ) and High avail...Alexey Bokov
Deep dive into Azure cloud technologies including common considerations about technology choices and then going deep into some of them. First we start from Azure Container Service and Docker containers orchestration by using Mesos or Swarm. Next part is about PaaS v2 which called Azure Service Fabric - crash course and deep dive into some parts of SF. After that we going through high Availability and Disaster Recovery in Azure:
- Azure DNS - cloud API for DNS records hosting
- Traffic Manager – load balancing and fault-tolerance on DNS level
- Azure Load Balancer – load balancing on transport level
-Application Gateway – load balancing on application level
Last part of deck is about IaaS based services and some updates for storage service:
* Azure Batch for computational tasks
* VM Scale sets
* Storage - managed disks and cool storage
Microsoft Azure intro - common information and blah blah blah about cloud computing, virtual machines - comparing A and D series by numbers ( performance CPU, RAM, storage ) and variability, Web apps ( ex-Web sites ).
1. CAP ( Brewer ) theorem and
distributed data processing
Alexey Bokov / abokov @ microsoft.com / twitter: @abokov
Senior Program Manager
Technical Evangelist and Development team
Microsoft Corp
2. CAP теорема и немного Эрика БрьюераCAP теорема указывает, что распределенная система может иметь максимум два свойства из трех
одновременно:
1. Согласованность (Consistency) (атомарность) - каждая операция чтения, должна возвращать
значение, установленное в последней операции записи: то есть у каждого узла есть актуальные
данные о определенном объекте ( или данные во всех узлах не противоречат друг другу )
2. Доступность (Availability ) = Каждый запрос, полученный исправным узлом, влечет за собой
ответ. Изначально было что : «почти все запросы должны получать ответы». Отсутствие ответа –
это неответ по таймауту, и все ошибки вроде “сервер занят”.
3. Устойчивость к разделению (Partition Tolerance) . Кластер сохраняет работоспособность при
условии потери произвольного количества сообщений, посылаемых между узлами сети.
Разделение означает, что все пакеты от узлов одной партиции не доходят до узлов другой
партиции
Опубликована в 2000, доказана в 2002.
@eric_brewer
4. CAP теорема как двигатель прогресса
CAP теорема в 2000х годах была воспринята ИТ индустрией на “ура”
Потому что теперь (наконец то, как раз в бум доткомов !) :
• Приложение стали больше использовать веб технологии, поэтому самое время перестать беспокоиться насчет
гарантированной целостности данных
• Доступность ( т.е. чтобы сайт работал ) для веб приложений совсем даже не подразумевает надежности
• Более того – гарантированная консистентность ( т.е. корретные данные на сайте ) это как раз то чего у нас
быть не может ( см. Теорему Брюера )
• Теперь любой у кого больше двух серверов может смело начинать интернет бизнес!
В 2002 году утверждение Брюера было формально доказано в MIT
5. Для начала это всё придумал не Брюер ;-)
4 июня 1976 году Sex Pistols выступили на сцене
в первой раз – это было доказательством того
что можно называться рок-группой и играть
песни в которых будет не больше 2 аккордов.
Наша группа знает 3 аккорда, но в
одной песне может быть только 2*
6. Всё придумал не Брюер ;-)
* в коде и припеве используется еще один аккорд из
основной тональности, но это не считается, т.к бас-
гитарист все равно обыгрывает только два из них
В последующем теорему 2 аккордов независимо доказали:
• 1976 – ‘Judy is a Punk’ by The Ramones (Eb5, Bb5 )
• 1980 – Atmosphere by Joy Division (A, D ) *
• 1985 – ‘Just Like Honey’ by Jesus and the Mary Chain (G#, D# )
• 1995 – Common People by Pulp (C, G) *
• 2007 – ‘505’ by Arctic Monkeys (Dm, Em)
• 2010 – ‘Bloodbuzz Ohio’ by The National (A, F#m ) *
В России это целое музыкальное направление:
7. IT теория vs IT реальность
• Сетевые соединения не надежны и часто падают
• Латентность всегда оказывает существенное
влияние на работу приложения
• Пропускная способность сети очень даже
конечна
• Сетевое соединение не безопасно
• Топология сети меняется очень часто, и чем
дальше узлы друг от друга, тем чаще меняется
топология
• У вашей системы множество администраторов,
которые делают одни и те же вещи по-разному
• Стоимость передачи данных бывает очень
высока
• Сеть гетерогенна – пакеты могут разделяться, их
атрибуты могут быть затерты, часть из них может
быть отфильтрована
• Сетевые соединения надежны
• Латентность связи всегда
нулевая
• Пропускная способность сети
бесконечна
• Сетевое соединение безопасно
• Топология сети не меняется
• У вашей системы всегда 1
администратор
• Стоимость передачи данных
нулевая
• Сеть гомогенна
Вернёмся обратно в IT
8. Вернёмся обратно в IT: важные замечания
Consistency подразумевает что при чтении мы получаем данные от _последней_ записи
Availability включает в себя понятие разумного ответа за определенное время – то есть если система не отвечает по таймауту или
выдает ответ вида “сервер занят”, или любой другой нерелевантный цели запроса ответ, то это приравнивается к неответу системы
Partition tolerance – устойчивость к разделению. Мы считаем потерянными также те сообщения, доставка которых превысила
определенный лимит времени.
• Если узел вышел из строя – это не ситуация разделения, потому что все равно есть только одна партиция ( а не 1 и N-1 как
можно полагать ).
• При выходе узла из строя система как раз может быть одновременно и согласованной и доступной, т.к. этот узел в любом
случае не обрабатывает запросы, а когда он восстановится и у нас будет 1 и N-1 это узел может быть инициализирован
актуальной репликой _всех_ данных.
Вывод: во время разделения мы выбираем либо доступность (минус
консистентность) либо конситентность ( минус доступность ).
9. Виды сервисов согласено CAP теореме
1) Доступность сервиса важнее всего = AP ( Availability + Partition Tolerance - best effort
availability) системы – отвечаем на запросы, однако возвращенные данные не всегда могут
быть актуальными и консистентными – например это DNS
2) Важнее всего целостность данных при разделении данных ( минус доступность ) =
CP ( Consistency + Partition tolerance ) системы – отвечают на запросы всегда с корретными
данными, но при проблемах с сетью, узлы могут не отвечать – Hbase, Google bigtable,
большинство noSQL БД
3) Важнее всего консистеность и доступность,но без возможности разделения
данных = AC ( Availability + Consistency ) – возвращают всегда корретные данные, однако не
имеют возможности разделения данных по сети при этом – примеры большинство реляционных
баз данных
10. На самом деле все сложнее
1) До тех пор, пока не наступила ситуация разделения система может вести себя как CA и
только в случае возникновения партиций ей нужно выбирать между согласованностью
и доступностью.
2) Свойства ( С, A, P ) на практике не являются бинарными :
1) Доступность, очевидно, может измеряться по времени прошедшем между
посылкой запроса и получением ответа.
2) Какие-то системы могут позволить себе долго отвечать на запрос, другие должны
сделать за определенный промежуток времени.
3) Свойство устойчивости к разделению напрямую зависит от того, каким образом
классифицировать сложившуюся ситуацию как разделение.
4) У консистентности данных тоже могут быть разные степени
11. Степени консистентности
1) Сильная/строгая согласованность (strong consistency). Операции чтения, произошешие
после выполнения операции записи, всегда возвращают результат последней
операции записи. Данный тип согласованности используется в CA системах, в частности
в классических реляционных базах данных
2) Слабая согласованность (weak consistency). При данном типе согласованности система
не гарантирует того, что операция чтения вернет результат последней операции
записи.
1) Существует ряд условий, необходимых для того, чтобы чтение вернуло самое последнее доступное
значение.
2) Период, в течении которого операция чтения возвращает устаревшие данные называется периодом
несогласованности.
12. Степени cлабой консистентности
Согласованность в конечном счете (eventual consistency) - если операций изменения объекта нет, то в конечном
счете операции чтения начнут давать наиболее актуальное значение. Наиболее популярной системой,
использующей согласованность в конечном счете, является DNS: изменения имени распространяются по
заданному алгоритму
Причинная согласованность: Если процесс А сообщил процессу Б, что А обновил объект, последующие запросы
на чтение к Б вернут актуальное состояние объекта.
Read-your-writes согласованность: процесс А, после того, как он обновил объект, всегда возвращает
обновленное состояние объекта.
Сессионная согласованность: процесс читает из системы хранения данных в контексте сессий. До тех пор, пока
сессия существует, система гарантирует read-your-writes согласованность.
Согласованность монотонной записи: в этом случае, система гарантирует, что запись будет произведена.
Данный тип согласованности является практически повсеместным.
13. Немного про разные варианты
R – колиство read узлов, W – количество write узлов, N – количество узлов которые хранят реплику данных
1) R+W>N – строгая консистенстность, всегда найдутся такие узлы системы, которые будут участвовать как в
операции записи, так и в операции чтения.
2) R = N/2, W=N/2 - когда операции записи и чтения имеют равную значимость для систем.
3) R->1, W->N - операция чтения выполняется намного чаще, чем операция записи, и перед системой не стоит
требования «запись должна осуществляться всегда». Конфигурация (R=1, W=N) обеспечивает высокую
доступность и устойчивость к разделению для операции чтения, т.к. узлу, чтобы возвратить ответ, не нужно
соединение с другими узлами.
4) R->N, W->1 - переносит нагрузку с операции записи на операцию чтения. (R=N,W=1) характеризуется высокой
доступностью и устойчивостью к разделению при операции записи, минус – отсутствие оптимистичкой
блокировки
5) R+W<=N, то есть вероятность того, что узлов, участвующих в операции чтения и в операции записи, не будет,
из чего следует, что система с такими настройками не может гарантировать сильную согласованность.
14. Время ответа – от CAP к PACELC
CAP теорема не учитывает время ответа узла системы на запрос в качестве свойства,
задержка и ситуация разделения тесно связаны друг с другом
Эту момент учитывает PACELC (in case of Partition, choose between Availability and
Consistency, else – between Latency and Consistency ) – в случае разделения данных
выбираем между CA ( доступностью и консистентностью ) и LC (задержкой и
консистентностью) (Абади):
1. Разделение между доступностью и устойчивостью к разделению нечеткое.
2. Исходя из наблюдений Абади, те базы данных, которые предпочитают
жертвовать консистетностью данных, имеют тенденцию жертвовать ей не только во время
разделения, но также и при обычном функционировании.
Вывод: в случае нормального функционирования системы, следует
выбирать между уменьшением времени ответа и согласованностью.
15. Минимизация эффектов
1) обработка ситуаций разделения как в вопросе обнаружения разделения
2) Процесс восстановления после разделения и поддержанию вариантов системы, которые могли
быть нарушены
• Для выполненных операций храним версионные векторы, представляющие собой пары узлов, на
которых они выполнялись, и времени, когда они выполнялись. если в системе будет две версии
объекта, система сможет узнать, какая из них актуальней. Иногда возможна ситуация, когда
актуальность определить нельзя – в таком случае считается, что некоторые изменения объекта
выполнялись параллельно (Amazon Dynamo, Voldemort, Apache Cassandra, Riak, MongoDB )
• Сегментирование архитектуры:
• По данным
• По операциям
• По требованиям к функционалу
• По пользователям
• По иерархии
16. Восстановление после разделения
Задачи:
1. Состояние объектов на всех узлах должно стать полностью консистентным
2. Компенсация ошибок, допущенных в результате разделения
Основным подходом к определению текущего состояния объекта является
пошаговое исследование операций, происходившими с данными с
момента начала разделения, и произведение корректирующих действий
на каждом шаге.
17. Компенсация ошибок
1) "последняя запись - финальная запись”
2) Перекладываем задачу на пользователя
Пример из реальной жизни - Примером процесса компенсации ошибок после разделения
является ситуация, когда на самолет было продано больше билетов, чем есть в наличии.
Процедура посадки может рассматриваться в данном случае как своего рода компенсация
ошибки - в самолет пройдет не больше, чем есть сидений
Архитектурное решение - выполнение рискованных операций в ситуации разделения
следует откладывать настолько, насколько это возможно
18. Выводы
Нет 100% работающего универсального решения, каким путем решать задачу обработки
запросов при возникновении расщепления распределенной системы – выбирать
доступность или же выбирать
Этот выбор может быть сделан только разработчиком, на основе анализа бизнес-модели
приложения.
Более того, этот выбор может быть сделан не для всего приложения в целом, а отдельно
для каждой его части:
• Согласованность для процедуры покупки и оплаты в интернетмагазине;
• Доступность для процедуры просмотра каталога товаров, чтения отзывов и т.п.
Можем смириться с несогласованностью, в случае коротких периодов (1-2 минуты)
разделения системы
20. Что дальше
Масштабируемость – опять же возвращаемся к выборы между масштабируемостью и консистентностью
Устойчивость к атакам - например DDoS не укладывется в модель разделения данных. DDoS атаки и прерывание
работы веб сервисов требуют другого понимания выбора между консистентностью и доступностью.
Мобильные сети – параметры мобильных сетей (огромная вариативность всех параметров сети – скорость,
доступность, задережки ) не укладываются в модель сетевого взаимодействия CAP теоремы:
Модель CAP теоремы предполагает что у нас есть относительно стабильные партиции которые
изменяется раз в несколько минут. Для беспроводных сетей изменения гораздо более сильные, потери пакетов и
изменение задержек.
Приложения в мобильных сетях больше ориентированы на геотаргетинг и социальное
взаимодействие, в то время как CAP теорема больше ориентирована на веб 2000-х – большие веб порталы и e-
commerce.
21. Примеры из практики – рисуем на флипчарте
1) Сайт большого спортивного соревнования
2) Онлайн ресурсы для школы
3) Поисковая система – архитектуры, неответы, золотой шард
4) Системы по продаже авиабилетов
Editor's Notes
У нас речь идет о асинхронной системе – нет возможности определить было сообщение не отправлено/не получиено или оно медленно идет из-за задержек
Важно - теорема доказана только в контексте асинхронных систем, характеризующихся отсутствием хронометража, вследствие чего узлы системы принимают решения, только исходя из получаемых сообщений и локальных расчетов, и в контексте частично синхронных систем.
Частично синхронные системы = обладают хронометражом, но совпадение времени на узлах не обязательно – главное, чтобы они одинаково учитывали скорость течения времени.
Согласованность в конечном счете (eventual consistency) - если операций изменения объекта нет, то в конечном счете операции чтения начнут давать наиболее актуальное значение. При отсутствии каких-либо поломок/критических ошибок в узлах системы, максимальный период несогласованности может быть определен по таким факторам, как задержки коммуникаций, нагрузка на систему, количество реплик, используемых для репликации. Наиболее популярной системой, использующей согласованность в конечном счете, является DNS: изменения имени распространяются по заданному алгоритму – после того, как изменения дойдут до всех узлов системы и обновятся кэши, все операции чтения будут возвращать актуальный адрес.
Типы согласованности могут быть скомбинированы.
1) К примеру, система может иметь согласованность монотонного чтения вместе с сессионной согласованностью одновременно. С практической точки зрения, эти свойства согласованность монотонного чтения и сессионная согласованность являются наиболее востребованными в системах с согласованностью в конечном счете, но не всегда обязательными. Они упрощают разработку приложения, одновременно позволяя системе хранения ослабить согласованность и обеспечить высокую доступность.
R+W>N – строгая консистенстность, всегда найдутся такие узлы системы, которые будут участвовать как в операции записи, так и в операции чтения. Из-за их участия в операции записи, они будут хранить наиболее актуальное значение, что, в свою очередь, повлияет на результаты последующего чтения.
R = N/2, W=N/2 - когда операции записи и чтения имеют равную значимость для системы, Таким образом, задержка, связанная с обеспечением согласованности, примерно равна.
R->1, W->N - операция чтения выполняется намного чаще, чем операция записи, и перед системой не стоит требования «запись должна осуществляться всегда». Это позволяет сократить издержки на операцию чтения до минимума, переложив всю нагрузку на операцию записи. Стоит заметить, что конфигурация (R=1, W=N) обеспечивает высокую доступность и устойчивость к разделению для операции чтения, т.к. узлу, чтобы возвратить ответ, не нужно соединение с другими узлами. Недостатком такой настройки является отсутствие устойчивости к разделению при операции записи, т.к. для успешного ее выполнения требуется связь со всеми узлами сети, которые имеют реплику
R->N, W->1 - переносит нагрузку с операции записи на операцию чтения. (R=N,W=1) характеризуется высокой доступностью и устойчивостью к разделению при операции записи, минус – отсутствие оптимистичкой блокировки
R+W<=N, то есть вероятность того, что узлов, участвующих в операции чтения и в операции записи, не будет, из чего следует, что система с такими настройками не может гарантировать сильную согласованность.
R – колиство read узлов, W – количество write узлов, N – количество узлов которые хранят реплику данных
R+W>N – строгая консистенстность, всегда найдутся такие узлы системы, которые будут участвовать как в операции записи, так и в операции чтения. Из-за их участия в операции записи, они будут хранить наиболее актуальное значение, что, в свою очередь, повлияет на результаты последующего чтения.
R = N/2, W=N/2 - когда операции записи и чтения имеют равную значимость для системы, Таким образом, задержка, связанная с обеспечением согласованности, примерно равна.
R->1, W->N - операция чтения выполняется намного чаще, чем операция записи, и перед системой не стоит требования «запись должна осуществляться всегда». Это позволяет сократить издержки на операцию чтения до минимума, переложив всю нагрузку на операцию записи. Стоит заметить, что конфигурация (R=1, W=N) обеспечивает высокую доступность и устойчивость к разделению для операции чтения, т.к. узлу, чтобы возвратить ответ, не нужно соединение с другими узлами. Недостатком такой настройки является отсутствие устойчивости к разделению при операции записи, т.к. для успешного ее выполнения требуется связь со всеми узлами сети, которые имеют реплику
R->N, W->1 - переносит нагрузку с операции записи на операцию чтения. (R=N,W=1) характеризуется высокой доступностью и устойчивостью к разделению при операции записи, минус – отсутствие оптимистичкой блокировки
R+W<=N, то есть вероятность того, что узлов, участвующих в операции чтения и в операции записи, не будет, из чего следует, что система с такими настройками не может гарантировать сильную согласованность.
Почему: 1. Разделение между доступностью и устойчивостью к разделению нечеткое. Данный пункт представляет собой следующий вопрос: что значит иметь свойство доступности, но не иметь свойство устойчивости к разделению и наоборот? Если произошло партицирование, то в чем разница поведений CA и CP баз данных? CA, согласно определениям свойств, прекращает работу, т.к. неустойчиво к разделению, а CP – становится недоступно, т.е. фактически тоже прекращает работу.
2. Исходя из наблюдений Абади, те базы данных, которые предпочитают жертвовать консистетностью данных, имеют тенденцию жертвовать ей не только во время разделения, но также и при обычном функционировании.
- требования, предъявляемые системой к различным операциям и данным, могут разниться: от одних операций/данных может требоваться наличие строгой согласованности, от других – наличие высокого показателя доступности. Возможно применение сегментирование операций и данных на компоненты, требующие различных гарантий:
Можно создать такой алгоритм разрешения конфликтов, который всегда будет выполняться в автоматическом режиме, что, однако, может повлечь за собой потерю информации, либо ввести определенные ограничения на операции, что, несмотря на уменьшение функциональности системы, что сделает создание неразрешимых конфликтов невозможным.