Fix typos
Alex Voitau
parent
e975d51da9
commit
226c6bbfae
|
|
@ -14,7 +14,7 @@ jobs:
|
|||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Download mdlm
|
||||
run: curl -o- https://raw.githubusercontent.com/markdown-localization/mdlm-sh/v0.0.18/install.sh | bash
|
||||
run: curl -o- https://raw.githubusercontent.com/markdown-localization/mdlm-sh/v0.0.20/install.sh | bash
|
||||
|
||||
- name: Sync status - ru
|
||||
run: |
|
||||
|
|
|
|||
201
README-ru.md
201
README-ru.md
|
|
@ -19,6 +19,7 @@ l10n:p -->
|
|||
|
||||
<!-- l10n:ignore start -->
|
||||
[](https://github.com/voitau/system-design-primer/actions?query=workflow:l10n-sync-ru)
|
||||
<!-- maintained with https://github.com/markdown-localization/mdlm-sh -->
|
||||
<!-- l10n:ignore end -->
|
||||
|
||||
<p align="center">
|
||||
|
|
@ -34,11 +35,11 @@ l10n:p -->
|
|||
> Prep for the system design interview.
|
||||
l10n:p -->
|
||||
|
||||
## Мотивация
|
||||
## Для чего это нужно
|
||||
|
||||
> Узнайте, как проектировать крупномасштабные системы.
|
||||
> Чтобы узнать, как проектировать крупномасштабные системы.
|
||||
>
|
||||
> Подготовьтесь к собеседованию по проектированию системы.
|
||||
> Чтобы подготовиться к собеседованию по проектированию систем.
|
||||
|
||||
<!-- l10n:p
|
||||
### Learn how to design large-scale systems
|
||||
|
|
@ -52,9 +53,9 @@ l10n:p -->
|
|||
|
||||
### Научитесь проектировать крупномасштабные системы
|
||||
|
||||
Умение проектировать масштабируемые системы поможет вам стать лучшим инженером.
|
||||
Умение проектировать масштабируемые системы поможет улучшить ваши инженерные навыки.
|
||||
|
||||
Проектирование систем - это широкая тема. В сети есть **огромное количество ресурсов** по принципам проектирования систем.
|
||||
Проектирование систем - это обширная тема. В сети есть **огромное количество ресурсов** по принципам проектирования систем.
|
||||
|
||||
Этот репозиторий представляет собой **организованную коллекцию** ресурсов, которые помогут вам научиться создавать системы на большом масштабе.
|
||||
|
||||
|
|
@ -90,7 +91,7 @@ l10n:p -->
|
|||
|
||||
### Подготовка к собеседованию по проектированию систем
|
||||
|
||||
В дополнение к интервью по написанию кода, проектирование систем является **обязательным компонентом процесса технического интервью** во многих технологических компаниях.
|
||||
Наряду с интервью по написанию кода, проектирование систем является **обязательным компонентом процесса технического интервью** во многих технологических компаниях.
|
||||
|
||||
**Практикуйте общие вопросы по проектированию систем** и **сравнивайте** свои результаты с **примерами решений**: обсуждения, код и диаграммы.
|
||||
|
||||
|
|
@ -124,7 +125,7 @@ l10n:p -->
|
|||
<p align="center">
|
||||
<img src="images/zdCAkB3.png">
|
||||
<br/>
|
||||
</p>motivation
|
||||
</p>
|
||||
|
||||
Предоставленные [карточки Anki](https://apps.ankiweb.net/) могут быть использованы для повторения и запоминания ключевых концепций проектирования систем.
|
||||
|
||||
|
|
@ -132,8 +133,6 @@ l10n:p -->
|
|||
* [System design exercises deck](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/System%20Design%20Exercises.apkg)
|
||||
* [Object oriented design exercises deck](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/OO%20Design.apkg)
|
||||
|
||||
Отлично подходят для использования на ходу.
|
||||
|
||||
<!-- l10n:p
|
||||
### Coding Resource: Interactive Coding Challenges
|
||||
|
||||
|
|
@ -158,7 +157,7 @@ l10n:p -->
|
|||
<br/>
|
||||
</p>
|
||||
|
||||
Посмотрите другой репозиторий [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges), который тоже содержит колоду карт Anki:
|
||||
Посмотрите другой репозиторий [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges), который тоже содержит набор карт Anki:
|
||||
|
||||
* [Coding deck](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg)
|
||||
|
||||
|
|
@ -190,7 +189,7 @@ l10n:p -->
|
|||
* Добавление новых разделов
|
||||
* [Перевод](https://github.com/donnemartin/system-design-primer/issues/28)
|
||||
|
||||
Контент, который нуждается в некоторой полировке, помещается в раздел [В разработке](#в-разработке).
|
||||
Контент, который нуждается в некоторой доработке, помещается в раздел [В разработке](#в-разработке).
|
||||
|
||||
Ознакомьтесь с [Принципами содействия](CONTRIBUTING.md).
|
||||
|
||||
|
|
@ -386,7 +385,7 @@ l10n:p -->
|
|||
- [Безопасность](#безопасность)
|
||||
- [Приложение](#приложение)
|
||||
- [Таблица степеней двойки](#таблица-степеней-двойки)
|
||||
- [Время выполнения, которое должен знать каждый программист](#время-выполнения-которое-должен-знать-каждый-программист)
|
||||
- [Время выполнения задач, которые должен знать каждый программист](#время-выполнения-задач-которые-должен-знать-каждый-программист)
|
||||
- [Визуализация выполнения](#визуализация-выполнения)
|
||||
- [Дополнительные вопросы на интервью по проектированию систем](#дополнительные-вопросы-на-интервью-по-проектированию-систем)
|
||||
- [Архитектуры действующих систем](#архитектуры-действующих-систем)
|
||||
|
|
@ -448,13 +447,13 @@ l10n:p -->
|
|||
То, что вас будут спрашивать на интервью, зависит от:
|
||||
|
||||
* Вашего опыта - сколько времени и чем вы занимались
|
||||
* Должности, на которую вы собеседуетесь
|
||||
* Компания, в которую вы собеседуетесь
|
||||
* Удача
|
||||
* Должности, на которую вы проходите собеседование
|
||||
* Компании, в которую вы проходите собеседование
|
||||
* Как повезёт
|
||||
|
||||
Ожидается, что более опытные кандидаты в общем случае знают больше о проектировании систем, а архитекторы и руководители команд знают больше, чем индивидуальные разработчики. Топовые IT компании скорее всего будут проводить один или более этапов собеседования по проектированию систем.
|
||||
|
||||
Начинайте широко, и углубляйтесь в некоторые области. Это поможет узнать больше о различных темах по проектированию систем. Корректируйте ваш план в зависимости от того, сколько у вас есть времени, какой у вас опыт, на какую должность вы собеседуетесь и в какие компании.
|
||||
Начинайте широко, и углубляйтесь в некоторые области. Это поможет узнать больше о различных темах по проектированию систем. Корректируйте ваш план в зависимости от того, сколько у вас есть времени, какой у вас опыт, на какую должность вы проходите собеседование и в какие компании.
|
||||
|
||||
* **Короткий срок** - настраивайтесь на **широту** покрытия тем. Тренируйтесь отвечать на **некоторые** вопросы.
|
||||
* **Средний срок** - настраивайтесь на **широту** и **немного глубины** покрытия тем. Тренируйтесь отвечать на **многие** вопросы.
|
||||
|
|
@ -463,8 +462,8 @@ l10n:p -->
|
|||
| | Малый срок | Средний срок | Длительный срок |
|
||||
|---|---|---|---|
|
||||
| Смотрите [Содержание](#содержание), чтобы получить общее понимание, как работают системы | :+1: | :+1: | :+1: |
|
||||
| Почитайте несколько статей из блогов компаний, в который вы собеседуетесь - [Блоги инженерных компаний](#блоги-инженерных-компаний) | :+1: | :+1: | :+1: |
|
||||
| Посмотрите несколько [Архитектур действующих систем](#архитектуры-действующих-систем) | :+1: | :+1: | :+1: |
|
||||
| Почитайте несколько статей из блогов компаний, в которые вы проходите собеседование - [Блоги инженерных компаний](#блоги-инженерных-компаний) | :+1: | :+1: | :+1: |
|
||||
| Изучите несколько [Архитектур действующих систем](#архитектуры-действующих-систем) | :+1: | :+1: | :+1: |
|
||||
| [Как отвечать на вопросы на интервью по проектированию систем](#как-отвечать-на-вопросы-на-интервью-по-проектированию-систем) | :+1: | :+1: | :+1: |
|
||||
| [Вопросы на интервью по проектированию систем с решениями](#вопросы-на-интервью-по-проектированию-систем-с-решениями) | Немного | Много | Большинство |
|
||||
| [Вопросы на интервью по объектно-ориентированному программированию с решениями](#вопросы-на-интервью-по-объектно-ориентированному-программированию-с-решениями) | Немного | Много | Большинство |
|
||||
|
|
@ -504,7 +503,7 @@ l10n:p -->
|
|||
|
||||
### Шаг 1: определите сценарии использования, ограничения и допущения
|
||||
|
||||
Соберите требование и оцените рамки задачи. Задавайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите допущения.
|
||||
Соберите требования и оцените рамки задачи. Задавайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите допущения.
|
||||
|
||||
* Кто будет использовать решение?
|
||||
* Как его будут использовать?
|
||||
|
|
@ -513,7 +512,7 @@ l10n:p -->
|
|||
* Что система получает на вход, и что должно быть на выходе?
|
||||
* Какое количество данных система должна обрабатывать?
|
||||
* Сколько ожидается запросов в секунду?
|
||||
* Какое соотношение количества операций на чтение и запись?
|
||||
* Какое соотношение количества операций чтения и записи?
|
||||
|
||||
<!-- l10n:p
|
||||
### Step 2: Create a high level design
|
||||
|
|
@ -548,7 +547,7 @@ l10n:p -->
|
|||
|
||||
### Шаг 3: Спроектируйте основные компоненты
|
||||
|
||||
Детализируйте каждый компонент. Например, если вас попросили разработать [design a url shortening service](solutions/system_design/pastebin/README.md), обсудите следующие моменты:
|
||||
Детализируйте каждый компонент. Например, если вас попросили разработать [сервис сокращения URL](solutions/system_design/pastebin/README.md), обсудите следующие моменты:
|
||||
|
||||
* Генерация и хранения хэша оригинального URL
|
||||
* [MD5](solutions/system_design/pastebin/README.md) и [Base62](solutions/system_design/pastebin/README.md)
|
||||
|
|
@ -599,7 +598,7 @@ l10n:p -->
|
|||
|
||||
* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
|
||||
* [Таблица степеней двойки](#таблица-степеней-двойки)
|
||||
* [Время выполнения, которое должен знать каждый программист](#время-выполнения-которое-должен-знать-каждый-программист)
|
||||
* [Время выполнения задач, которые должен знать каждый программист](#время-выполнения-задач-которые-должен-знать-каждый-программист)
|
||||
|
||||
<!-- l10n:p
|
||||
### Source(s) and further reading
|
||||
|
|
@ -645,7 +644,7 @@ l10n:p -->
|
|||
|
||||
> Распространенные задачи с обсуждением, кодом и диаграммами.
|
||||
>
|
||||
> Решение находятся в директории `solutions/`.
|
||||
> Решение находятся в папке `solutions/`.
|
||||
|
||||
| Задача на проектирование | |
|
||||
|---|---|
|
||||
|
|
@ -796,7 +795,7 @@ l10n:p -->
|
|||
|
||||
> Распространенные задачи с обсуждением, кодом и диаграммами.
|
||||
>
|
||||
> Решение находятся в директории `solutions/`.
|
||||
> Решение находятся в папке `solutions/`.
|
||||
|
||||
>**Внимание, этот раздел находится в стадии разработки**
|
||||
|
||||
|
|
@ -805,7 +804,7 @@ l10n:p -->
|
|||
| Хэш таблица | [Решение](solutions/object_oriented_design/hash_table/hash_map.ipynb) |
|
||||
| Кэширование с удалением давно используемых (Least recently used - LRU) | [Решение](solutions/object_oriented_design/lru_cache/lru_cache.ipynb) |
|
||||
| Центр обработки звонков | [Решение](solutions/object_oriented_design/call_center/call_center.ipynb) |
|
||||
| Колода карт | [Решение](solutions/object_oriented_design/deck_of_cards/deck_of_cards.ipynb) |
|
||||
| Набор карт | [Решение](solutions/object_oriented_design/deck_of_cards/deck_of_cards.ipynb) |
|
||||
| Парковка | [Решение](solutions/object_oriented_design/parking_lot/parking_lot.ipynb) |
|
||||
| Чат сервер | [Решение](solutions/object_oriented_design/online_chat/online_chat.ipynb) |
|
||||
| Циклический массив | [Добавить](#содействуйте) |
|
||||
|
|
@ -889,7 +888,7 @@ l10n:p -->
|
|||
|
||||
### Следующие шаги
|
||||
|
||||
Далее, изучим компромиссы в общем виде:
|
||||
Далее, рассмотрим компромиссы в общем виде:
|
||||
|
||||
* **Производительность** и **масштабирование**
|
||||
* **Задержка** и **пропускная способность**
|
||||
|
|
@ -897,7 +896,7 @@ l10n:p -->
|
|||
|
||||
Помните, что **везде необходимы компромиссы**.
|
||||
|
||||
Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы.
|
||||
Далее, рассмотрим более детально DNS, CDN, балансировщики нагрузки и другие темы.
|
||||
|
||||
<!-- l10n:p
|
||||
## Performance vs scalability
|
||||
|
|
@ -945,7 +944,7 @@ l10n:p -->
|
|||
|
||||
**Задержка** - это время, необходимое для выполнения действия или достижения некоторого результата.
|
||||
|
||||
**Пропускная способность** - это количество такие действий или результататов в единицу времени.
|
||||
**Пропускная способность** - это количество таких действий или результатов в единицу времени.
|
||||
|
||||
Обычно следует стремиться к **максимальной пропускной способности**, при этом сохраняя **задержку приемлемой**.
|
||||
|
||||
|
|
@ -1049,7 +1048,7 @@ l10n:p -->
|
|||
|
||||
## Шаблоны реализации согласованности
|
||||
|
||||
В распределённой системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиентским приложением, существует несколько подходов синхронизации этих копий. Вспомните определение согласованности из [Теоремы CAP](#теорема-cap) - каждая операция чтения возвращает либо самую записанную версию, либо ошибку.
|
||||
В распределённой системе может существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиентским приложением, существует несколько подходов синхронизации этих копий. Вспомните определение согласованности из [Теоремы CAP](#теорема-cap) - каждая операция чтения возвращает либо самую последнюю записанную версию, либо ошибку.
|
||||
|
||||
<!-- l10n:p
|
||||
### Weak consistency
|
||||
|
|
@ -1061,9 +1060,9 @@ l10n:p -->
|
|||
|
||||
### Слабая согласованность
|
||||
|
||||
После операции записи данных, операция чтения может увидеть эти данные, а может и не увидеть. Используется подход, при котором можно сделать как можно лучше, но с учетом данной ситуации.
|
||||
После операции записи данных, операция чтения необязательно вернёт эти данные сразу. Реализуется в системах это настолько, насколько представляется возможным.
|
||||
|
||||
Этот подход используется в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и игры реального времени на несколько игроков.
|
||||
Этот подход используется в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и многопользовательские игры реального времени. Например, если вы на звонке и на несколько секунд пропала связь, после восстановления связи вы не услышите, что говорили, пока связь отсутствовала.
|
||||
|
||||
<!-- l10n:p
|
||||
### Eventual consistency
|
||||
|
|
@ -1089,7 +1088,7 @@ l10n:p -->
|
|||
|
||||
### Сильная согласованность
|
||||
|
||||
После операции записи данных, операция чтения увидит эти данны. Данные реплицируются синхронно.
|
||||
После операции записи данных, операция чтения увидит эти данные. Данные реплицируются синхронно.
|
||||
|
||||
Такой подход используется в файловых системах и реляционных БД. Сильная согласованность хорошо подходит для систем, где требуются транзакции.
|
||||
|
||||
|
|
@ -1133,7 +1132,7 @@ l10n:p -->
|
|||
|
||||
В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
|
||||
|
||||
Время простоя определяется в каком состоянии находится пассивный сервер:
|
||||
Время простоя определяется состоянием, в котором находится пассивный сервер:
|
||||
|
||||
* горячее (hot) ожидание - сервер уже работает
|
||||
* холодное (cold) ожидание - сервер должен быть запущен.
|
||||
|
|
@ -1152,9 +1151,9 @@ l10n:p -->
|
|||
|
||||
#### Активный-активный
|
||||
|
||||
В таком режиме, оба сервера обрабатывают клиентские запросы, распределяют нагрузку между собой.
|
||||
В таком режиме оба сервера обрабатывают клиентские запросы, распределяя нагрузку между собой.
|
||||
|
||||
Если сервера имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если сервера находятся во внутренней сети, то клиентское приложение знать про оба сервера.
|
||||
Если серверы имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если серверы находятся во внутренней сети, то клиентское приложение должно знать про оба сервера.
|
||||
|
||||
Режим "активный-активный" также известен как "Master-Master".
|
||||
|
||||
|
|
@ -1292,6 +1291,7 @@ l10n:p -->
|
|||
Доступность (Общая) = 1 - (1 - Доступность (Foo)) * (1 - Доступность (Bar))
|
||||
```
|
||||
|
||||
Если `Foo` и `Bar` имеют доступность 99.9%, их общая доступность при параллельной связи будет 99.9999%.
|
||||
<!-- l10n:p
|
||||
## Domain name system
|
||||
|
||||
|
|
@ -1341,8 +1341,8 @@ DNS иерархична и имеет несколько корневых се
|
|||
|
||||
Такие сервисы, как [CloudFlare](https://www.cloudflare.com/dns/) и [Route 53](https://aws.amazon.com/ru/route53/) предоставляют полностью управляемые сервис DNS сервисы. Некоторые DNS сервисы могут направлять трафик, используя различные методы:
|
||||
|
||||
* взвешенный цикличекий ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)):
|
||||
* предотвращает попадания трафика на сервера, находящиеся на обслуживании
|
||||
* взвешенный циклический ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)):
|
||||
* предотвращает попадание трафика на серверы, находящиеся на обслуживании
|
||||
* балансирует трафик для кластера, размер которого может меняться
|
||||
* может использоваться для A/B тестирования
|
||||
* [на основе задержки отклика серверов](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency)
|
||||
|
|
@ -1401,7 +1401,7 @@ l10n:p -->
|
|||
<i><a href=https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/>Источник: Why use a CDN</a></i>
|
||||
</p>
|
||||
|
||||
Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которые доставляют содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой DNS сервер клиент должен делать запрос.
|
||||
Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которые доставляют содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой CDN сервер клиент должен делать запрос.
|
||||
|
||||
Раздача содержимого из CDN может значительно улучшить производительность по двум причинам:
|
||||
|
||||
|
|
@ -1420,6 +1420,7 @@ l10n:p -->
|
|||
|
||||
Содержимое Push CDN обновляется тогда, когда оно обновляется на сервере. Разработчик сайта загружает содержимое на CDN и обновляет соответствующие URL адреса, чтобы они указывали на CDN. Далее, можно сконфигурировать время жизни содержимого в CDN и когда оно должно быть обновлено. Загружается только новое или обновленное содержимое, минимизируя трафик и увеличивая объем хранящихся данных в CDN.
|
||||
|
||||
С таким типом CDN хорошо работают сайты с небольшим трафиком, либо сайты с содержимым, которое редко обновляется. Содержимое размещается в CDN один раз, вместо того, чтобы регулярно обновляться.
|
||||
<!-- l10n:p
|
||||
### Pull CDNs
|
||||
|
||||
|
|
@ -1448,7 +1449,7 @@ l10n:p -->
|
|||
|
||||
### Недостатки CDN
|
||||
|
||||
* Стоимость CDN может быть высока и зависит от объема трафика, но стоит иметь в виду и дополнительные расходы, которые будут если CDN не использовать.
|
||||
* Стоимость CDN может быть высока и зависит от объема трафика, но стоит иметь в виду и дополнительные расходы, которые будут, если CDN не использовать.
|
||||
* Содержимое в CDN может оказаться устаревшим, если оно будет обновлено до того, как истечет время жизни (TTL).
|
||||
* Исходные URL ссылки должны быть изменены и указывать на CDN.
|
||||
|
||||
|
|
@ -1542,7 +1543,7 @@ l10n:p -->
|
|||
|
||||
### Layer 4 балансировка
|
||||
|
||||
Для распределения запросов балансировщики 4го уровня используют [Транспортный уровень](#взаимодействие) модели OSI. Обычно, используются IP адрес и порт источника и получателя из заголовков пакетов, но не из их содержимого. Балансировщики этого уровня перенаправляют сетевые пакеты с серверов, используя [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/).
|
||||
Для распределения запросов балансировщики 4-го уровня используют [Транспортный уровень](#взаимодействие) модели OSI. Обычно, используются IP адрес и порт источника и получателя из заголовков пакетов, но не из их содержимого. Балансировщики этого уровня перенаправляют сетевые пакеты с серверов, используя [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/).
|
||||
|
||||
<!-- l10n:p
|
||||
### Layer 7 load balancing
|
||||
|
|
@ -1554,7 +1555,7 @@ l10n:p -->
|
|||
|
||||
### Layer 7 балансировка
|
||||
|
||||
Для распределения запросов балансировщики 7го уровня используют [Прикладной уровень](#взаимодействие) модели OSI. Для этого могут быть задействованы заголовок, сообщение и куки. Балансировщики на этом уровне прерывают сетевой трафик, сканируют сообщение, принимают решение, куда отправить запрос и открывают соединение с выбранным сервером. Например, они могут отправить запрос на видео на видео-сервер, а запрос на биллинг - на сервера с усиленной безопасностью.
|
||||
Для распределения запросов балансировщики 7го уровня используют [Прикладной уровень](#взаимодействие) модели OSI. Для этого могут быть задействованы заголовок, сообщение и куки. Балансировщики на этом уровне прерывают сетевой трафик, сканируют сообщение, принимают решение, куда отправить запрос и открывают соединение с выбранным сервером. Например, они могут отправить видео запрос на видео-сервер, а биллинг запрос - на серверы с усиленной безопасностью.
|
||||
|
||||
Балансировка на 4м уровне быстрее и требует меньше ресурсов, чем на 7м уровне, но имеет меньшую гибкость. Хотя на современном аппаратном обеспечении эта разница может быть незаметна.
|
||||
|
||||
|
|
@ -1596,7 +1597,7 @@ l10n:p -->
|
|||
|
||||
* Балансировщик нагрузки может стать узким местом в производительности системы, если он неправильно настроен или его аппаратное обеспечение слишком слабое.
|
||||
* Балансировщик нагрузки позволяет избежать единой точки отказа, но увеличивает совокупную сложность всей системы.
|
||||
* Единственный балансировщик становится единой точкой отказа, использование нескольких балансировщиком еще больше усложняет систему.
|
||||
* Единственный балансировщик становится единой точкой отказа, использование нескольких балансировщиков еще больше усложняет систему.
|
||||
|
||||
<!-- l10n:p
|
||||
### Source(s) and further reading
|
||||
|
|
@ -1656,13 +1657,13 @@ l10n:p -->
|
|||
<br/>
|
||||
</p>
|
||||
|
||||
Обратный прокси-сервер - это веб-сервер, который централизует внутренние сервисы и предоставляет унифицированный интерфейс для доступа из публичной сети. Клиентские запросы перенаправляются на сервер, который их будет обрабатывать, и затем обратный прокси возвращает ответ клиенту.
|
||||
Обратный прокси-сервер - это веб-сервер, который централизует внутренние сервисы и предоставляет для них унифицированный интерфейс для доступа из публичной сети. Клиентские запросы перенаправляются на сервер, который их будет обрабатывать, и затем обратный прокси возвращает ответ клиенту.
|
||||
|
||||
Дополнительные преимущества:
|
||||
|
||||
* **повышенная безопасность** - скрывает информацию о бэкенд-серверах, блокирует IP адреса, ограничивает допустимое количество соединений на клиента
|
||||
* **повышенная масштабируемость и гибкость** - клиентское приложение знает только IP адрес прокси-сервера, таким образом можно менять количество серверов или изменять их конфигурацию
|
||||
* **SSL терминация** - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-сервера не тратят свои ресурсы на эти потенциально трудоемкие операции
|
||||
* **SSL терминация** - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-серверы не тратят свои ресурсы на эти потенциально трудоемкие операции
|
||||
* нет необходимости устанавливать [X.509 сертификаты](https://ru.wikipedia.org/wiki/X.509)
|
||||
* **Сжатие** - сжатие ответов сервера клиенту
|
||||
* **Кэширование** - возвращает ответы для закэшированных запросов
|
||||
|
|
@ -1684,7 +1685,7 @@ l10n:p -->
|
|||
|
||||
* Использование балансировщика нагрузки полезно при наличии нескольких серверов. Часто балансировщики направляют трафик на сервера, выполняющие одинаковую функцию.
|
||||
* Обратный прокси-сервер может быть полезен даже при использовании одного веб-сервера или сервера приложений, предоставляет преимущества, описанные в предыдущей секции
|
||||
* Такие решения, как NGINX и HAProxy могут поддерживать как реверс-прокси 7го уровня, так и балансировку нагрузки
|
||||
* Такие решения, как NGINX и HAProxy могут поддерживать как обратный прокси-сервер 7го уровня, так и балансировку нагрузки
|
||||
|
||||
<!-- l10n:p
|
||||
### Disadvantage(s): reverse proxy
|
||||
|
|
@ -1736,7 +1737,7 @@ l10n:p -->
|
|||
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Source: Intro to architecting systems for scale</a></i>
|
||||
</p>
|
||||
|
||||
Разделение веб-уровня и уровня приложения (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложение, но необязательно на веб-уровне. **Принцип единой ответственности** подразумевает создание небольших и автономных сервисов, который работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.
|
||||
Разделение веб-уровня и уровня приложения (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложения, но необязательно на веб-уровне. **Принцип единственной ответственности** подразумевает создание небольших и автономных сервисов, который работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.
|
||||
|
||||
Worker-сервера на уровне приложений позволяют поддерживать [Асинхронность](#асинхронность).
|
||||
|
||||
|
|
@ -1752,7 +1753,7 @@ l10n:p -->
|
|||
|
||||
[Микросервисная архитектура](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0) может быть описана как набор независимо развёртываемых, небольших, модульных сервисов. Каждый сервис работает как независимый процесс и взаимодействует на основе предустановленного легковесного протокола для обслуживания бизнес задачи. <sup><a href=https://smartbear.com/learn/api-design/what-are-microservices>1</a></sup>
|
||||
|
||||
Микросервисы Pinterest могут включать: профиль пользователя, подписчик, лента, поиск, загрузка фото и т.д.
|
||||
Примеры микросервисов в Pinterest: профиль пользователя, подписчик, лента, поиск, загрузка фото и т.д.
|
||||
|
||||
<!-- l10n:p
|
||||
### Service Discovery
|
||||
|
|
@ -1762,7 +1763,7 @@ l10n:p -->
|
|||
|
||||
### Обнаружение сервисов (Service Discovery)
|
||||
|
||||
Ведя учет зарегистрированных имен, адресов и портов, такие системы как [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest), и [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) помогают сервисам находит друг друга. Проверки состояния [Health checks](https://www.consul.io/intro/getting-started/checks.html) позволяют убедиться в работоспособности сервера с помощью [HTTP](#http-hypertext-transfer-protocol) запросы. Consul и Etcd имеют [Хранилище типа ключ-значение](#хранилище-типа-ключ-значение), которое может быть полезно для хранения конфигурации и других общих данных.
|
||||
Ведя учет зарегистрированных имен, адресов и портов, такие системы как [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest), и [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) помогают сервисам находить друг друга. Проверки состояния [Health checks](https://www.consul.io/intro/getting-started/checks.html) позволяют убедиться в работоспособности сервера с помощью [HTTP](#http-hypertext-transfer-protocol) запроса. Consul и Etcd имеют [Хранилище типа ключ-значение](#хранилище-типа-ключ-значение), которое может быть полезно для хранения конфигурации и других общих данных.
|
||||
|
||||
<!-- l10n:p
|
||||
### Disadvantage(s): application layer
|
||||
|
|
@ -1835,7 +1836,7 @@ l10n:p -->
|
|||
|
||||
* **Атомарность (Atomicity)** - каждая транзакция выполняется либо целиком, либо не выполняется совсем (откатывается)
|
||||
* **Согласованность (Consistency)** - любая транзакция переводит базу данных из одного правильного состояния в другое правильное состояние, сохраняя согласованность данных
|
||||
* **Изолированность (Isolation)** - параллельное выполнение транзакцией должно иметь такие же результаты, как и их последовательное выполнение
|
||||
* **Изолированность (Isolation)** - параллельное выполнение транзакций должно иметь такие же результаты, как и их последовательное выполнение
|
||||
* **Стойкость (Durability)** - после завершение транзакции, данные должны остаться сохранёнными
|
||||
|
||||
Существует ряд подходов для масштабирования реляционных баз данных:
|
||||
|
|
@ -1845,7 +1846,7 @@ l10n:p -->
|
|||
* федерализация
|
||||
* шардирование
|
||||
* денормализация
|
||||
* SQL тюнинг
|
||||
* оптимизация SQL запросов
|
||||
|
||||
<!-- l10n:p
|
||||
#### Master-slave replication
|
||||
|
|
@ -1880,7 +1881,7 @@ l10n:p -->
|
|||
##### Недостатки репликации master-slave
|
||||
|
||||
* Для переключения ведомого сервера в ведущий необходима дополнительная логика
|
||||
* См. [Недостатки репликации](#недостатки-репликации) для пунктом, характерных для подходов "Master-Slave" и "Master-Master".
|
||||
* См. [Недостатки репликации](#недостатки-репликации) для особенностей, характерных для подходов "Master-Slave" и "Master-Master".
|
||||
|
||||
<!-- l10n:p
|
||||
#### Master-master replication
|
||||
|
|
@ -1896,7 +1897,7 @@ l10n:p -->
|
|||
|
||||
#### Репликация Master-Master
|
||||
|
||||
Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестают работать, система может продолжать работать на чтение и запись.
|
||||
Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестаёт работать, система может продолжать работать на чтение и запись.
|
||||
|
||||
<p align="center">
|
||||
<img src="images/krAHLGg.png">
|
||||
|
|
@ -1917,7 +1918,7 @@ l10n:p -->
|
|||
|
||||
* Необходим балансировщик нагрузки или понадобиться изменить логику приложение для определения куда будет идти запись.
|
||||
* Большинство систем "Master-Master" либо слабо согласованы (нарушая ACID) либо имеют большую задержку из-за необходимости синхронизации.
|
||||
* При возрастании количества серверов на запись (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
|
||||
* При возрастании количества серверов для записи данных (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
|
||||
* См. [Недостатки репликации](#недостатки-репликации) для пунктом, характерных для подходов "Master-Slave" и "Master-Master".
|
||||
|
||||
<!-- l10n:p
|
||||
|
|
@ -1933,7 +1934,7 @@ l10n:p -->
|
|||
##### Недостатки репликации
|
||||
|
||||
* Существует риск потери данных, если ведущий сервер перестает работать до того, как новые данные будут реплицированы на другие сервера.
|
||||
* Операции записи реплицируются на ведомый сервера. Если совершается много операций на запись, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций на чтение.
|
||||
* Операции записи реплицируются на ведомый сервера. Если совершается много операций записи, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций чтения.
|
||||
* С ростом количества ведомых серверов увеличивается объем репликации, что приводит к задержке репликации.
|
||||
* На некоторых системах, запись на ведущем сервере может делаться в несколько потоков, выполняемых параллельно. Запись на ведомых серверах происходит последовательно в один поток.
|
||||
* Репликация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
|
||||
|
|
@ -1986,7 +1987,7 @@ l10n:p -->
|
|||
|
||||
* Федерализация неэффективна, если схема базы данных требует больших функций или таблиц.
|
||||
* Необходимо изменить логику приложения, чтобы определить, с какими базами данных работать.
|
||||
* Операция соединения данных (JOIN) становится сложнее [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers).
|
||||
* Операция соединения данных (JOIN) становится сложнее с [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers).
|
||||
* Федерализация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
|
||||
|
||||
<!-- l10n:p
|
||||
|
|
@ -2023,9 +2024,9 @@ l10n:p -->
|
|||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
Шардирование распределяет данные между разными базами данных так, что каждая база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые сервера (шарды).
|
||||
Шардирование распределяет данные между разными базами данных так, что каждая база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые серверы (шарды).
|
||||
|
||||
Аналогично [Федерализации](#федерализация), шардирование уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшение производительность и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увеличивая пропускную способность.
|
||||
Аналогично [Федерализации](#федерализация), шардирование уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшению производительности и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увеличивая пропускную способность.
|
||||
|
||||
Распространённый подход шардирования таблицы пользователей основан на разделении по имени или местоположению.
|
||||
|
||||
|
|
@ -2073,11 +2074,11 @@ l10n:p -->
|
|||
|
||||
#### Денормализация
|
||||
|
||||
Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываются в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которые выполнюят задачу хранения избыточных данных и поддержку их согласованности.
|
||||
Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываются в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которое выполняют задачу хранения избыточных данных и поддержку их согласованности.
|
||||
|
||||
При использовании [Федерализации](#федерализация) и [Шардирования](#шардирование), данные становятся распределенными. В результате выполнение операций соединения данных, которые могут находится в разных дата-центрах, усложняется. Денормализация может позволить избавиться от необходимости в сложных JOIN запросах.
|
||||
|
||||
В большинстве систем, количество операций на чтение значительно больше операций на запись (100:1, или даже 1000:1). Операция на чтение в результате сложного соединения данных может быть очень ресурсоемкой и требовать значительного времени, потраченного на операции c жестким диском.
|
||||
В большинстве систем, количество операций чтения значительно больше операций записи (100:1, или даже 1000:1). Операция чтения в результате сложного соединения данных может быть очень ресурсоемкой и требовать значительного времени, потраченного на операции c жестким диском.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): denormalization
|
||||
|
|
@ -2116,9 +2117,9 @@ It's important to **benchmark** and **profile** to simulate and uncover bottlene
|
|||
Benchmarking and profiling might point you to the following optimizations.
|
||||
l10n:p -->
|
||||
|
||||
#### SQL тюнинг
|
||||
#### Оптимизация SQL запросов
|
||||
|
||||
SQL тюнинг - это обширная тема, описанная во многих [книгах](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning)).
|
||||
Оптимизация SQL запросов - это обширная тема, описанная во многих [книгах](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning).
|
||||
|
||||
Очень важно проводить **бенчмарки** и **профилирование** для имитации и обнаружения узких мест.
|
||||
|
||||
|
|
@ -2149,7 +2150,7 @@ l10n:p -->
|
|||
* Используйте `TEXT` для больших фрагментов текста (например, блог-посты). `TEXT` позволяет делать булевый поиск. Использование поля типа `TEXT` приводит к хранению указателя на диске, которые используется для поиска этого блока.
|
||||
* Используйте `INT` для больших чисел до 2^32.
|
||||
* Используйте `DECIMAL` для денежных единиц для избежания ошибок, связанных с представлением в формате с плавающей точкой.
|
||||
* Избегайте хранения больших `BLOBS`, вместо этого хранение указателя на место хранения объекта.
|
||||
* Избегайте хранения больших `BLOBS`, вместо храните указатель на объект.
|
||||
* Установите ограничения `NOT NULL`, где возможно, для улучшения производительности ([improve search performance](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)).
|
||||
|
||||
|
||||
|
|
@ -2167,9 +2168,9 @@ l10n:p -->
|
|||
|
||||
* Запрос столбцов (включая операторы `SELECT`, `GROUP BY`, `ORDER BY`, `JOIN`) может быть быстрее с индексами.
|
||||
* Индексы обычно представляют собой самобалансирующиеся [B-деревья](https://ru.wikipedia.org/wiki/B-%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE), которые хранят данные отсортированными, позволяют поиск, последовательный доступ, вставку и удаление с логарифмической сложностью.
|
||||
* Создание индексы может потребовать хранения данных в памяти, требуя больше места.
|
||||
* Добавление индекса может потребовать хранения данных в памяти, требуя больше места.
|
||||
* Операции записи могут быть медленнее, так как индекс тоже необходимо обновлять.
|
||||
* При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции; индексы в таком случае обновляются после загрузки данных.
|
||||
* При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции. индексы в таком случае обновляются после загрузки данных.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Avoid expensive joins
|
||||
|
|
@ -2179,7 +2180,7 @@ l10n:p -->
|
|||
|
||||
##### Избегайте больших объединений
|
||||
|
||||
* [Денормализаруйте](#денормализация), если необходимо повысить производительность.
|
||||
* [Денормализируйте](#денормализация), если необходимо повысить производительность.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Partition tables
|
||||
|
|
@ -2233,12 +2234,12 @@ l10n:p -->
|
|||
|
||||
### NoSQL
|
||||
|
||||
NoSQL - это набор данных, представленных в виде **базы ключ-значение**, **документориентированной базы данных**, **колоночной базы данных** или **графовой база данных**. Данные денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойств транзакий и характеризуются [согласованностью в конечном счете](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5).
|
||||
NoSQL - это набор данных, представленных в виде **базы ключ-значение**, **документориентированной базы данных**, **колоночной базы данных** или **графовой база данных**. Данные денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойства транзакций и характеризуются [согласованностью в конечном счете](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5).
|
||||
|
||||
Для описания свойств NoSQL баз данных используют **BASE** свойства. Согласно [Теорема CAP](#теорема-cap), BASE придерживается доступности данных, а не их согласованности.
|
||||
Для описания свойств NoSQL баз данных используют **BASE** свойства. Согласно [Теореме CAP](#теорема-cap), BASE придерживается доступности данных, а не их согласованности.
|
||||
|
||||
* **В целом доступные** - система гарантирует доступность.
|
||||
* **Неокончательное (soft) удаление** - состояние ситемы может со временем измениться, даже без дополнительный операций.
|
||||
* **Неокончательное (soft) удаление** - состояние ситемы может со временем измениться, даже без дополнительных операций.
|
||||
* **Согласованность в конечном счете (eventual consistency)** - данные в системе станут согласованными в течение некоторого времени, если в течение этого времени не будут приходить новые данные.
|
||||
|
||||
Вместе с выбором между [SQL или NoSQL](#sql-или-nosql), надо сделать выбор типа NoSQL базы данных, которая подходит для вашего сценария использования. В следующей секции представлены **базы ключ-значение**, **документориентированные базы данных**, **колоночные базы данных** или **графовые база данных**.
|
||||
|
|
@ -2401,7 +2402,7 @@ l10n:p -->
|
|||
|
||||
В графовой базе данных, каждый узел это запись, а ребра это связь между двумя узлами. Графовые базы данных оптимизированы для представление сложных связей с множеством внешних ключей или связей многих ко многим.
|
||||
|
||||
Графовые базы данных имеют высокую производительность для моделей данных со сложными связями, как в социальных сетях. Они относительно новые и не пока не используются широко. Может быть сложно найти средства и ресурсы для их разработки. Получить доступ ко многим графам можно только с помощью [REST API](#rest-representational-state-transfer).
|
||||
Графовые базы данных имеют высокую производительность для моделей данных со сложными связями, как в социальных сетях. Они относительно новые и пока не используются широко. Может быть сложно найти средства и ресурсы для их разработки. Получить доступ ко многим графам можно только с помощью [REST API](#rest-representational-state-transfer).
|
||||
<!-- l10n:p
|
||||
##### Source(s) and further reading: graph
|
||||
|
||||
|
|
@ -2504,7 +2505,7 @@ l10n:p -->
|
|||
|
||||
Примеры данных, хорошо подходящих для NoSQL:
|
||||
|
||||
* Скоростное сохранение clickstream данных и данных журналирования (logs)
|
||||
* Быстрое сохранение данных потоков кликов (clickstream) и данных журналирования (logs)
|
||||
* Список лидеров или общий счет
|
||||
* Временные данные, например, корзина
|
||||
* Таблицы с частым доступом (горячие таблицы)
|
||||
|
|
@ -2544,7 +2545,7 @@ l10n:p -->
|
|||
<i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Источник: Scalable system design patterns</a></i>
|
||||
</p>
|
||||
|
||||
Кэширование улучшает время загрузки страницы и может уменьшить нагрузку на сервера и базы данных. При таком подходе, диспетчер вначале проверяет, делался ли запрос ране, чтобы найти ответ, который уже на него возвращался, сократив при этом время выполнения текущего запроса.
|
||||
Кэширование улучшает время загрузки страницы и может уменьшить нагрузку на серверы и базы данных. При таком подходе, диспетчер вначале проверяет, делался ли запрос ранее, чтобы найти ответ, который уже на него возвращался, сократив при этом время выполнения текущего запроса.
|
||||
|
||||
Базы данных работают оптимальным образом при равномерном распределении операций чтения и записи между их партициями (partitions). Популярные элементы могут нарушить равномерность распределения, создавая узкие места. Добавление системы кэширование перед базой данных может позволить сгладить неравномерность поступающего трафика.
|
||||
|
||||
|
|
@ -2576,7 +2577,7 @@ l10n:p -->
|
|||
|
||||
### Кэширование на веб-сервере
|
||||
|
||||
[Обратные прокси-сервера](#обратный-прокси-сервер-reverse-proxy) и системы такие системы кэширование как [Varnish](https://www.varnish-cache.org/) могут выдавать как статический, так и динамический контент. Веб-сервера тоже могут кэшировать запросы, возвращая ответы не обращаюсь к серверам приложений.
|
||||
[Обратные прокси-сервера](#обратный-прокси-сервер-reverse-proxy) и такие системы кэширования как [Varnish](https://www.varnish-cache.org/) могут выдавать как статический, так и динамический контент. Веб-серверы тоже могут кэшировать запросы, возвращая ответы не обращаюсь к серверам приложений.
|
||||
|
||||
<!-- l10n:p
|
||||
### Database caching
|
||||
|
|
@ -2586,7 +2587,7 @@ l10n:p -->
|
|||
|
||||
### Кэширование в Базах данных
|
||||
|
||||
База данных обычно включает какое-то кэширование в конфигурации по умолчанию, которое оптимизировано для стандартных сценариев использования. Настройка этих параметров для конкретных шаблонов использования данных может еще больше увеличить её производительность.
|
||||
Базы данных в конфигурации по умолчанию обычно уже включают кэширование, которое оптимизировано для стандартных сценариев использования. Настройка этих параметров для конкретных сценариев использования данных может еще больше улучшить её производительность.
|
||||
|
||||
<!-- l10n:p
|
||||
### Application caching
|
||||
|
|
@ -2610,7 +2611,7 @@ l10n:p -->
|
|||
|
||||
### Кэширование в приложениях
|
||||
|
||||
Системы кэширования в памяти (например, Memcached и Redis) являются хранилищами типа "ключ-значение", которые находятся между вашим приложением и хранилищем данных. Они обычно быстрее, так как данных хранятся в оперативной памяти, а не на жестком диске, как это обычно бывает в случае с базами данных. Количество оперативной памяти имеет больше ограничений, чем жесткий диск, поэтому [алгоритмы очистки кэша](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F), как например [вытеснение давно неиспользуемых (Least recently used, LRU)](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F#Least_recently_used_(%D0%92%D1%8B%D1%82%D0%B5%D1%81%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%B2%D0%BD%D0%BE_%D0%BD%D0%B5%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D0%BC%D1%8B%D1%85)) помогают удалять из кэша "холодные" записи и оставлять в памяти "горячие".
|
||||
Системы кэширования в памяти (например, Memcached и Redis) являются хранилищами типа "ключ-значение", которые находятся между вашим приложением и хранилищем данных. Они обычно быстрее, так как данныe хранятся в оперативной памяти, а не на жестком диске, как это обычно бывает в случае с базами данных. Количество оперативной памяти имеет больше ограничений, чем жесткий диск, поэтому [алгоритмы очистки кэша](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F), как например [вытеснение давно неиспользуемых (Least recently used, LRU)](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F#Least_recently_used_(%D0%92%D1%8B%D1%82%D0%B5%D1%81%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%B2%D0%BD%D0%BE_%D0%BD%D0%B5%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D0%BC%D1%8B%D1%85)) помогают удалять из кэша "холодные" записи и оставлять в памяти "горячие".
|
||||
|
||||
Redis включает дополнительную функциональность:
|
||||
|
||||
|
|
@ -2637,10 +2638,10 @@ l10n:p -->
|
|||
|
||||
### Кэширование на уровне запросов в базу данных
|
||||
|
||||
При таком подходе результат сохраняется с ключом, которым является вычисленное хэш-значение для запросы в базу данных. Такой подход имеет ряд недостатков:
|
||||
При таком подходе результат сохраняется с ключом, которым является вычисленное хэш-значение для запроса в базу данных. Такой подход имеет ряд недостатков:
|
||||
|
||||
* Тяжело удалить закэшированный результат сложных запросов
|
||||
* Если меняется значение одной ячейки данных, необходимо удалить все запросы, который могут содержать эти данные
|
||||
* Если меняется значение одной ячейки данных, необходимо удалить все запросы, которые могут содержать эти данные
|
||||
|
||||
<!-- l10n:p
|
||||
### Caching at the object level
|
||||
|
|
@ -2663,7 +2664,7 @@ l10n:p -->
|
|||
При таком подходе данные рассматриваются как объекты, аналогично объектам в коде приложения. Приложение собирает данные из базы в объект класса или структуру(ы) данных:
|
||||
|
||||
* Объект удаляется из кэша, если структура данных, которую он представляет, изменилась
|
||||
* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версий закэшированных объектов
|
||||
* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версии закэшированных объектов
|
||||
|
||||
Что можно кэшировать как объекты:
|
||||
|
||||
|
|
@ -2742,7 +2743,7 @@ def get_user(self, user_id):
|
|||
|
||||
Обычно так используется [Memcached](https://memcached.org/).
|
||||
|
||||
Последующие запросы на чтение данных, находящиейся в кэши, выполняются быстро. Также такой подход известен как ленивая загрузка. Только запрашиваемые данные попадают в систему кэширование, и не происходит его заполнения данными, которые не запрашиваются.
|
||||
Последующие запросы на чтение данных, находящихся в кэше, выполняются быстро. Такой подход также известен как ленивая загрузка. Только запрашиваемые данные попадают в систему кэширование, и не происходит её заполнения данными, которые не запрашиваются.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): cache-aside
|
||||
|
|
@ -2798,7 +2799,7 @@ l10n:p -->
|
|||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
Приложение использует систему кэширования, как основной источник данных, считывая и записывая данные в него. Система кэширования в свою очередь записывает и считывает данных из БД:
|
||||
Приложение использует систему кэширования, как основной источник данных, считывая и записывая данные в него. Система кэширования в свою очередь записывает и считывает данные из БД:
|
||||
|
||||
* Приложение добавляет и обновляет элемент в системе кэширования
|
||||
* Система кэширования синхронно записывает данные в БД
|
||||
|
|
@ -2829,7 +2830,7 @@ l10n:p -->
|
|||
|
||||
##### Недостатки кэширование Write through
|
||||
|
||||
* Когда добавляется новый сервер из-за отказа другого, либо масштабирование, его кэш не содержит никаких элементов, пока данные не обновятся в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы
|
||||
* Когда добавляется новый сервер из-за отказа другого, либо в результате масштабирования, его кэш не содержит никаких элементов, пока данные не обновятся в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы
|
||||
* Большая часть записываемых данных может вообще не использоваться. Использование времени жизни данных (TTL) может смягчить последствия этой проблемы.
|
||||
|
||||
<!-- l10n:p
|
||||
|
|
@ -2896,7 +2897,7 @@ l10n:p -->
|
|||
|
||||
При таком подходе можно настроить автоматическое обновление закэшированных данных, к которым недавно обращались, не ожидая истечения их срока действия.
|
||||
|
||||
Кэширование методом "предварительного обновление" может уменьшить задержку, по сравнению с кэшем, который делает сквозное чтение, если можно точно определить, какие элементы могут быть запрошены в будущем.
|
||||
Кэширование методом "предварительного обновления" может уменьшить задержку, по сравнению с кэшем, который делает сквозное чтение, если можно точно определить, какие элементы могут быть запрошены в будущем.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): refresh-ahead
|
||||
|
|
@ -3009,7 +3010,7 @@ l10n:p -->
|
|||
|
||||
### Очереди задач
|
||||
|
||||
Очереди сообщений принимают задачи и связанные с ними данные, выполняют их, и затем доставляет их результаты. Они могут поддерживать планирование и использоваться для выполнения задач, которые требуют высоких вычислительных мощностей, в фоне.
|
||||
Очереди задач принимают задачи и связанные с ними данные, выполняют их, и затем выдают их результаты. Они могут поддерживать планирование и использоваться для выполнения задач, которые требуют высоких вычислительных мощностей, в фоне.
|
||||
|
||||
Планирование есть в **[Celery](https://docs.celeryproject.org/en/stable/)**, который в основном поддерживается на Python.
|
||||
|
||||
|
|
@ -3021,7 +3022,7 @@ l10n:p -->
|
|||
|
||||
### Обратное давление
|
||||
|
||||
Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэши, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) может помочь, ограничивая размер очереди и поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с [экспоненциальной выдержкой](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0).
|
||||
Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэше, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) может помочь, ограничивая размер очереди и поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с [экспоненциальной выдержкой](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0).
|
||||
|
||||
<!-- l10n:p
|
||||
### Disadvantage(s): asynchronism
|
||||
|
|
@ -3031,7 +3032,7 @@ l10n:p -->
|
|||
|
||||
### Недостатки асинхронности
|
||||
|
||||
* Для простых вычислений и процессов реального времени лучше подойдут синхронные операции, так как введение очередей добавит задержку и усложняет систему.
|
||||
* Для простых вычислений и процессов реального времени лучше подойдут синхронные операции, так как введение очередей может добавить задержку и усложнить систему.
|
||||
|
||||
<!-- l10n:p
|
||||
### Source(s) and further reading
|
||||
|
|
@ -3089,7 +3090,7 @@ l10n:p -->
|
|||
|
||||
### HTTP (Hypertext transfer protocol)
|
||||
|
||||
HTTP - это метод для кодировки и передачи данных между клиентом и серверов. Этот протокол основан на модели запрос/ответ: клиенты делают запросы, сервера отвечают на них с соответствующим контентом и информацией о состоянии завершения запроса. HTTP самодостаточен, позволяя запросам и ответам свободно передаваться через множество маршрутизаторов и серверов посредников, которые выполняют балансировку, кэширование, шифрование и сжатие.
|
||||
HTTP - это метод для кодировки и передачи данных между клиентом и серверов. Этот протокол основан на модели запрос/ответ: клиенты делают запросы, серверы отвечают на них с соответствующим контентом и информацией о состоянии завершения запроса. HTTP самодостаточен, позволяя запросам и ответам свободно передаваться через множество маршрутизаторов и серверов посредников, которые выполняют балансировку, кэширование, шифрование и сжатие.
|
||||
|
||||
Стандартный HTTP запрос состоит из глагола (метода) и ресурса (конечной точки (endpoint)). Ниже приведены распространенные HTTP методы:
|
||||
|
||||
|
|
@ -3153,7 +3154,7 @@ l10n:p -->
|
|||
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Источник: How to make a multiplayer game</a></i>
|
||||
</p>
|
||||
|
||||
TCP - это протокол с установкой соединения, работающих поверх [межсетевого протокола IP](https://ru.wikipedia.org/wiki/IP). Соединение устанавливается и завершается с помощью [рукопожатия](https://en.wikipedia.org/wiki/Handshaking). Гарантия доставки пакетов в оригинальном порядке и без искажений получателю основана на:
|
||||
TCP - это протокол с установкой соединения, работающий поверх [межсетевого протокола IP](https://ru.wikipedia.org/wiki/IP). Соединение устанавливается и завершается с помощью [рукопожатия](https://en.wikipedia.org/wiki/Handshaking). Гарантия доставки пакетов получателю в оригинальном порядке и без искажений основана на:
|
||||
|
||||
* номерах последовательности и [полем контрольной суммы](https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%81%D1%83%D0%BC%D0%BC%D0%B0_(Checksum))
|
||||
* [подтверждении](https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#%D0%9D%D0%BE%D0%BC%D0%B5%D1%80_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F) пакетов и автоматической повторной передаче.
|
||||
|
|
@ -3162,7 +3163,7 @@ TCP - это протокол с установкой соединения, ра
|
|||
|
||||
Для поддержки высокой пропускной способности, веб-сервера могут содержать большое количество открытых TCP соединений, что приводит к использованию большого количества оперативной памяти. Ресурсозатратным можем быть поддержание большого количества открытых соединений между потоками веб-сервера и, например, сервером [Memcached](https://memcached.org/). В этом случае может помочь использование [пула соединений](https://en.wikipedia.org/wiki/Connection_pool) и UPD там, где он может быть применим.
|
||||
|
||||
TCP полезен для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.
|
||||
TCP подходит для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.
|
||||
|
||||
Используйте TCP (а не UDP) в случаях, когда необходимо:
|
||||
|
||||
|
|
@ -3212,16 +3213,16 @@ l10n:p -->
|
|||
|
||||
#### Источники и дополнительные ссылки по TCP и UDP
|
||||
|
||||
UPD не требует соединения. Датаграммы (по аналогии с пакетами данных) гарантированы только на уровне датаграммы. Датаграммы могут быть доставлены в другом порядке (отличном от того, в котором они были отправлены), либо не доставлены совсем. UDP не поддерживает контроля перегрузок. Из-за отсутствия гарантий TCP, обычно UDP является более эффективным.
|
||||
UPD не требует соединения. Датаграммы (по аналогии с пакетами данных) гарантированы только на уровне датаграммы. Датаграммы могут быть доставлены в порядке, отличном от того, в котором они были отправлены, либо не доставлены совсем. UDP не поддерживает контроля перегрузок. Из-за отсутствия гарантий TCP, обычно UDP является более эффективным.
|
||||
|
||||
UDP поддерживает широковещательную передачу данных, отправляя датаграммы всем устройствам подсети. Это полезно использовать вместе с [DHCP](https://ru.wikipedia.org/wiki/DHCP), так как с клиентом, который еще не получил IP адрес, нельзя установить TCP соединение.
|
||||
|
||||
UPD менее надежный, но работает хорошо для приложений реального времени, например, VoIP, видеочатов, потоковой передачи данных и мультиплеерных игр реального времени.
|
||||
UDP менее надежный, но работает хорошо для приложений реального времени, например, VoIP, видеочатов, потоковой передачи данных и мультиплеерных игр реального времени.
|
||||
|
||||
Используйте UPD (а не TCP) в случаях, когда:
|
||||
Используйте UDP (а не TCP) в случаях, когда:
|
||||
|
||||
* вам необходима минимальная задержка передачи данных
|
||||
* данных, которые пришли поздно, хуже, чем потеря данных
|
||||
* данные, которые пришли поздно, хуже, чем потеря данных
|
||||
* вы хотите сами реализовать исправление ошибок
|
||||
|
||||
<!-- l10n:p
|
||||
|
|
@ -3276,7 +3277,7 @@ l10n:p -->
|
|||
<i><a href=http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview>Источник: Crack the system design interview</a></i>
|
||||
</p>
|
||||
|
||||
При использовании RPC, клиент вызывает выполнение процедуры в другом адресном пространстве, обычно на удаленном сервере. Эта процедура запрограммирована для использования, как локальный вызова, абстрагируя детали взаимодействия сервера и клиенского приложения. Удаленные вызовы обычно медленнее и менее надежны, чем локальные вызовы. Поэтому полезно различать удаленные вызовы от локальных. Популярными RPC фреймворками являются [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), и [Avro](https://avro.apache.org/docs/current/).
|
||||
При использовании RPC, клиент вызывает выполнение процедуры в другом адресном пространстве, обычно на удаленном сервере. Эта процедура запрограммирована для использования, как локальный вызов, абстрагируя детали взаимодействия сервера и клиентского приложения. Удаленные вызовы обычно медленнее и менее надежны, чем локальные вызовы. Поэтому полезно отличать удаленные вызовы от локальных. Популярными RPC фреймворками являются [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), и [Avro](https://avro.apache.org/docs/current/).
|
||||
|
||||
RPC - это протокол на основе запроса и ответа:
|
||||
|
||||
|
|
@ -3325,7 +3326,7 @@ l10n:p -->
|
|||
* клиентские приложения RPC становятся сильно связанными с сервисной реализацией.
|
||||
* необходимо делать новое API для каждой новой операции или сценария использования.
|
||||
* отладка (debug) вызов RPC может быть непростой.
|
||||
* вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что [RPC запросы закэшированы]((http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)) на серверах системах кэширования таких, как [Squid](http://www.squid-cache.org/).
|
||||
* вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что [RPC запросы закэшированы]((http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)) на серверах систем кэширования таких, как, например, [Squid](http://www.squid-cache.org/).
|
||||
|
||||
<!-- l10n:p
|
||||
### Representational state transfer (REST)
|
||||
|
|
@ -3371,7 +3372,7 @@ PUT /someresources/anId
|
|||
{"anotherdata": "another value"}
|
||||
```
|
||||
|
||||
REST ориентирован на предоставление данных. Он снижает связанность между клиентом и сервером и часто используется для публичных API. REST использует обобщенный и унифицированный метод предоставления ресурсов через URI, [представление через заголовки](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), и действия с помощью методов, таких как GET, POST, PUT, DELETE и PATCH. Не имея состояния, REST хорошо подходит для горизонтального масштабирования и партицирования.
|
||||
REST ориентирован на предоставление данных. Он снижает связность между клиентом и сервером и часто используется для публичных API. REST использует обобщенный и унифицированный метод предоставления ресурсов через URI, [представление через заголовки](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), и действия с помощью методов, таких как GET, POST, PUT, DELETE и PATCH. Не имея состояния, REST хорошо подходит для горизонтального масштабирования и партицирования.
|
||||
|
||||
<!-- l10n:p
|
||||
#### Disadvantage(s): REST
|
||||
|
|
@ -3384,10 +3385,10 @@ l10n:p -->
|
|||
|
||||
#### Недостатки REST
|
||||
|
||||
* Учитывая, что REST ориентирован на предоставление данных, этот подход может не подойти, если ресурсы недостаточно организованы или их можно получить в виде простой иерархии. Например, возвращение всех обновленных за последних час записей, соответствующих определенному набору событий не так просто представить в виде пути. Скорее всего, в таком случае реализация будет включать сочетание пути URI, параметров запросы и, возможно, тело запроса.
|
||||
* Учитывая, что REST ориентирован на предоставление данных, этот подход может не подойти, если ресурсы недостаточно организованы или их можно получить в виде простой иерархии. Например, возвращение всех обновленных за последних час записей, соответствующих определенному набору событий не так просто представить в виде пути. Скорее всего, в таком случае реализация будет включать сочетание пути URI, параметры запросов и, возможно, тело запроса.
|
||||
* REST обычно полагается на несколько методов (GET, POST, PUT, DELETE и PATCH), что не всегда может подходить для вашего сценария использования. Например, нет определенного метода для представления перемещения документов с истекшим сроком в архивную папку.
|
||||
* Получение сложных ресурсов с вложенными иерархиями требует нескольких повторных запросов между клиентов и сервером, например, получение контента записи в блоге и комментариев к этой записи. Для мобильных приложений, которые функционируют в условиях переменного качества сети, эти повторные запросы являются крайне нежелательными.
|
||||
* С течением времени, больше полей может добавляться в ответ API, и более старые клиенты будут получать все новые поля, даже те, которые не нужны. В результате, увеличивается размер пересылаемых данных, что приводит к увеличению задержки передачи данных.
|
||||
* С течением времени, больше полей может добавляться в ответ API, и более старые клиенты будут получать все новые поля, включая даже те, которые не нужны. В результате, увеличивается размер пересылаемых данных, что приводит к увеличению задержки передачи данных.
|
||||
|
||||
<!-- l10n:p
|
||||
### RPC and REST calls comparison
|
||||
|
|
@ -3493,7 +3494,7 @@ l10n:p -->
|
|||
|
||||
## Приложение
|
||||
|
||||
Вас иногда могут попросить сделать оценку по времени "на салфетке". Например, определить, сколько времени понадобится для генерации 100 миниатюр изображений с жесткого диска, или сколько памяти потребует структура данных. **Степеней двойки** и **Время выполнения задач, которые должен знать любой программист** могут в этом помочь.
|
||||
Вас иногда могут попросить сделать оценку по времени "на салфетке". Например, определить, сколько времени понадобится для генерации 100 миниатюр изображений с жесткого диска, или сколько памяти потребует структура данных. **Таблица степеней двойки** и **Время выполнения задач, которые должен знать любой программист** могут в этом помочь.
|
||||
|
||||
<!-- l10n:p
|
||||
### Powers of two table
|
||||
|
|
@ -3576,7 +3577,7 @@ Handy metrics based on numbers above:
|
|||
* 2,000 round trips per second within a data center
|
||||
l10n:p -->
|
||||
|
||||
### Время выполнения, которое должен знать каждый программист
|
||||
### Время выполнения задач, которые должен знать каждый программист
|
||||
|
||||
```
|
||||
Время выполнения
|
||||
|
|
@ -3619,7 +3620,7 @@ l10n:p -->
|
|||
|
||||
l10n:p -->
|
||||
|
||||
#### Визуализация выполнения
|
||||
#### Визуализация времени выполнения задач
|
||||
|
||||
|
||||
|
||||
|
|
@ -3759,7 +3760,7 @@ l10n:p -->
|
|||
|
||||
* Определите основные принципы, общие технологии и шаблоны, которые встречаются в этих статьях
|
||||
* Изучите, какие проблемы решаются каждым компонентом, где это работает, а где нет
|
||||
* Обратите внимание секции, описывающие полученный опыт и работу над ошибками
|
||||
* Обратите внимание на секции, описывающие полученный опыт и работу над ошибками
|
||||
|
||||
| Тип | Система | Ссылки |
|
||||
|---|---|---|
|
||||
|
|
|
|||
Loading…
Reference in New Issue