The latest articles on DEV Community by Mikhail (@zabelin). https://dev.to/zabelin https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1188280%2F3d8086a0-9c06-4058-8b81-abdd51a97c89.png https://dev.to/zabelin en Mikhail Tue, 06 Feb 2024 22:14:20 +0000 https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-5-siektsionirovaniie-1p91 https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-5-siektsionirovaniie-1p91 <h2> Основное </h2> <p>Секционирование - это разбиение данных на секции, чтобы каждый элемент данных был в каждой секции (в отличиее от репликации, где каждый элемент данных хранится в каждом узле). Основная цель секционирования - масштабируемость, так как увеличивается пропускная способность на кол-во запросов, так как секции независимы. </p> <p>При этом секционирование и репликация используются чаще всего вместе, так как первое дает масштабирумость и второе - отказоустойчивость. На каждом узле хранится несколько секций (но не обязтельно все). И для одних секций один и тот же узел может быть ведущим, а для других секций - ведомым (что лишний раз показывает независимость секций).</p> <h2> Подходы к секционированию </h2> <h3> Секционирование по диапазону ключей </h3> <p>Этот подход заключается в том, чтобы закрепить за каждой секций диапазон значению ключа. Например, за секцией 1 - значения от А до В, за секций 2 - от Г до Е и т.д. При этом внутри самой секции используются SS-таблицы (под капотом самобалансирующиеся структуры данных - AVL дерево, например), благодаря которым значения отсортированы и становися просто искать по диапазону.</p> <p>Однако такой подход имеет недостаток - вероятность "горячей точки". Это значение, по которому осуществлено секционирование, по которому слишком много данных (например, в декабре кол-во транзакций гораздо больше, чем в другие месяцы). В результате секция может быть перегружена данными.</p> <h3> Секциоинирование по хэшу ключа </h3> <p>Этот подход решает проблему "горячих точек". Хорошая хэш-функция возвращает равномерно распределенные значения для разных ключей. Можно каждоый секции сопоставить диапазон значения хэш функции. Однако теряется возможность быстрого поиска по диапазону, так как близкие по значению ключи лежат теперь уже в разных секциях. Также стоит иметь в виду, что данный подход не защищает от крайнего случая "горячей точки", когда все операции происходит по одному и тому же ключю.</p> <h2> Секционирование и вторичные индексы </h2> <p>Вторичные индексы в отличие от ключей не идентифицируют однозначно запись - а значит, нельзя им поставить в соответствие определенную секцию. Но есть 2 варианта, как использовать вторичный индекс.</p> <h3> Секционирование вторичных индексов по документам </h3> <p>Этот подход заключается в том, что внутри каждой секции строится свой независимый индекс. Поэтому при добавлении/изменении данных в секции меняется только этот индекс. Поэтому его еще называют локальным.</p> <p>Минусом такого подхода является то, что при поиске приходится делать запросы во все секции и объединять полученные результаты, что весьма затратно по времени.</p> <h3> Секционирование вторичных индексов по термам </h3> <p>Этот подход заключается в том, что индекс секционирован по нескольким узлам. Например, поле color - значениям цвета, начинаяющимся с буквы a до r, соответствует секция 1. А цветам от s до z - секция 2.</p> <p><a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fwqowdlmpeyuhoyhcsxex.png" class="article-body-image-wrapper"><img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fwqowdlmpeyuhoyhcsxex.png" alt="Image description" width="777" height="312"></a></p> <p>Благодаря такому подходу скоросить поиска сильно возрастает по сравнению с индексом по документу. Однако скорость записи наоборот, падает, так как при этом подходе секции становятся связанными, ведь индекс по термам может содержать ссылку на данные из другой секции.</p> <h2> Маршрутизация запросов </h2> <p>Когда клиент делает запрос, откуда он знает, к какому узлу обратиться (какие секции какому узлу соответствуют)? Есть несколько вариантов:</p> <ul> <li><p>сами узлы могут знать - тогда при обращении на узел, он может отправить на другой, если у него нет требуемой секции</p></li> <li><p>использование gateway, у которого есть эта информация</p></li> <li><p>хранить эту информацию на самом клиенте</p></li> </ul> высоконагруженныеприложения клеппман книги Mikhail Fri, 02 Feb 2024 19:42:09 +0000 https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-5-rieplikatsiia-58p2 https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-5-rieplikatsiia-58p2 <h2> Основное </h2> <p>Репликация - это хранение копий одних и тех же данных по нескольким серверам, соединенным по сети. Репликация служит для нескольких целей:</p> <ul> <li><p>Доставка контента из географически близкого к пользователю сервера</p></li> <li><p>Чтобы система продолжала работать при отказе некоторых серверов БД</p></li> <li><p>Для горизонтально масштабирования по чтению</p></li> </ul> <p>Говоря о репликация, пользуются термином узел (синоним сервера). Узел при репликации может быть ведущим (куда может осуществляться и запись, и чтение) и ведомым (только для чтения).</p> <p>Репликация бывает следующих видов с точки зрения узлов:</p> <ul> <li><p>Репликация с одним ведущим узлов. Клиенты пишут в один узел. После этого записи отправляются в ведомые узлы. Есть риск чтения устаревшых данных с узлов, куда данные по какой-то причине не дошли.</p></li> <li><p>Репликация с несколькими ведущими узлами. Клиенты могут писать в разные узлы. После этого записи отправляются с ведущего на другие ведущие и ведомые. Доступность выше чем в варианте с одним узлов, однако появляется вероятность конфликтов при записи, когда после нескольких записей в разные ведущие узлы на них хранятся разные версии одной и той же записи и непонятно, какая итоговая.</p></li> <li><p>Репликация без ведущего узла. Название немного не отражает сути - ведь все узлы ведущие. Клиенты могуть писать в любые узлы. Данные в этот момент не отправляются в другие узлы. Только при чтении происходит проверка всех узлов в поиске самой последней версии. Отдаются свежие данные и во время/после этого актуализируются остальные ноды.</p></li> </ul> <p>Репликация бывает следующих видов в точки зрения момента отправки записей с одного узла на другой:</p> <ul> <li><p>Синхронная. Гарантирует согласованность данных на всех узлах. Клиент всегда будет читать свежие данные. Однако обладает низкой доступностью, так как один недоступный узел влечет неуспех записи на остальных узлах, так как повлечет откат. И скорость записи снижается, так как клиент должен дождаться, пока данные скопируются на все узлы.</p></li> <li><p>Асинхронная. Не гарантирует согласованности, поэтому есть вероятность чтения устаревшых данных. Обладает высокой доступностью, так как копирование с одного узла на другой происходит уже после того, как клиент получил "успех" при записи. Скорость записи высокая.</p></li> <li><p>Смешанная. Не гарантирует абсолютной согласованности и обладает средней доступностью. На какие-то узлы репликация синхронна. После этого запись для клиента считается "успешной". Затем в фоне происходит копирование на остальные ведомые узлы.</p></li> </ul> <p>Как раз смешанный вариант на практике показывает селя лучше всего.</p> <h2> Реализация репликации </h2> <ul> <li><p>Операторная. Заключается в том, что с ведущего узла на ведомые передаются sql операторы. Однако в таком виде недерменированные функции (now(), rand()) возвращали бы на разных узлах разные результаты. Аналогично с счетчиками, которые должны для каждой записи выполняться строго в том же порядке, что и на ведущем узле. Поэтому на практике команды передаются немного в измененном виде - вызов недерменированных функция заменен на их результат на ведущем узле.<br> Раньше такая репликация использовалась в MySQL.</p></li> <li><p>Перенос WAL журнала<br> Все записываемые данные заносятся в журнал упреждаюей записи. Этот журнал хранится в бинарном виде. Можно этот журнал отправлять на ведомые узлы. Недостаток в том, что есть привязка к внутренней структуре бинарного файла (к уровню физического представления), которая от версии к версии субд может меняться. Поэтому во первых, на всех узлах должны быть СУБД одинаковой версии, а обновление СУБД становится головной болью.<br> Этот метод репликации используется в PostgreSQL.</p></li> <li><p>Логическая репликация. Подразумевает использование логического журнала, в котором в утвержденном формате хранятся строки, однозначно описыващие операции с данными. Например, для обновления это идентификатор, список измененных полей и их новых значения. Для удаление - только идентификатор. С ведущего узла на ведомые передается записи из логического журнала. Формат этих записей не привязан к версии СУБД и может легко парсится внешними приложениями</p></li> </ul> <h2> Проблемы задержки репликации </h2> <p>Как уже написал, использование асинхронной репликации может приводить к несогласованности данных между узлами. Рассмотрим возможные проблемы и пути их решения.</p> <h3> Чтение своих же устаревшых записей </h3> <p>Это очень частый сценарий - пользователь точно знает, какие данные вставлял или модифицировал. Поэтому, если отдадутся устаревшие данные, пользователь это сразу заметит. Вариантов решения несколько:</p> <ul> <li><p>"свои" данные читать только с ведущего узла (например, информация о своем профиле) - в большинстве случаев невозможен, так как таких данных может быть очень много. Да и вообще на корню рушит идею высокой доступности, ради которой затевалась идея с репликацией.</p></li> <li><p>отслеживать время последней модификации данных - на первое время читать с ведущего, а все остальное время с ведомого.</p></li> <li><p>развитие предыдущего пункта - передавать при чтении метку времени последней записи, и если напротив записи в БД метка меньше (т.е. изменения еще не дошли), то читать с ведущего</p></li> </ul> <p>В идее с меткой времени также стоит помнить, что клиент может заходить с разных устройств, и информацию о времени последней модификации нужно хранить в централизованном месте (этим снижается доступность).</p> <h3> Монотонное чтение </h3> <p>Есть вероятность, что при каждом чтении пользовател будет видеть данные в разном порядке.<br> Возможное решение - дать пользователю возможность читать только с какой-то одной реплики (которая присваиватся пользователю по хэшу ид пользователя, например). Тогда есть гарантия, что чтения будут в неименающимся порядке порядке (но гарантии чтения самых актуальных данных нет, так как данные по присвоенного ведомого узла могли не дойти). Также нет гарантии, что пользователь будет видеть записи в том порядке, в котором они были при записи (для этого при чтении можно делать сортировку).</p> <h3> Согласованное префиксное чтение </h3> <p>Есть вероятность потери причинно-следственных связей, если на реплику более новая запись попала раньше более старой (например, сначала ответ, затем - чтение). Гарантия согласованного префиксного чтения гарантирует, что данные будут прочитаны в том же порядке, в котором были записаны. Для этого можно использовать метки времени, читая в отсортированном виде.</p> <h2> Репликация с несколькими ведущими узлами </h2> <h3> обработка конфликтов </h3> <p>Предположим, что есть 2 ведущих узла - 1 и 2. И есть пользователь 1 и 2, и записывают они данные в таком порядке 1 -&gt; 1, 2 -&gt; 2. Первый пользователь меняет запись A на B на ведущем узле 1, второй - A на C на ведущем узле 2. Возникает конфликт при попытке реплицировать изменения с одного ведущего на другой. Возможное решение - изменение одной и той же строки делать через один и тот же узел. Если узел выходит из строя, менять на другой. Если такой возможности нет, то можно напротив строчки ставить метку времени и при конфликте выигрывает значение с самым большим значением этой метки.</p> <h3> Топология репликации с несколькими ведущими узлами </h3> <p>Сущестуют следущие топологии</p> <ul> <li><p>Колько</p></li> <li><p>Звезда</p></li> <li><p>Каждый с каждым</p></li> </ul> <p><a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fr4pzt7pd9lqdzfpgb1fe.png" class="article-body-image-wrapper"><img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fr4pzt7pd9lqdzfpgb1fe.png" alt="Image description" width="676" height="192"></a></p> <p>Топология "каждый с каждым" самая общая и надежная. Топология "звезда" подразумевает использование центрального узла, через которой идет коммуникация, что снижает надежность. Топология "кольцо" самая ненадежная (и несмотря на это, используется в MySQL), так как узел может получить запись строго от конкретного узла. И если один узел вышел из строя, то репликация до узлов, следующих за ним, встанет.</p> <h2> Репликация без ведущих узлов </h2> <p>При записи какие-то узлы могут быть недоступны. Пусть есть n узлов, на w узлов усуществилась запись и с r узлов читают. Тогда гарантией, что всегда при такой конфигурации будут читаться актульные данные, является условие w + r &gt; n (это условие показывает, что узлы для записи и чтения пересекаются) - тогда операции записи и чтения называются операциями по кворуму. Тогда можно считать итоговый результат операции записи или чтения неуспешным, если не выполняется условие выше.</p> высоконагруженныеприложения клеппман книги Mikhail Tue, 14 Nov 2023 17:55:39 +0000 https://dev.to/zabelin/highload-junior-1-highload-dlia-nachinaiushchikh-c6m https://dev.to/zabelin/highload-junior-1-highload-dlia-nachinaiushchikh-c6m <h2> Проблематика </h2> <p>Высокая нагрузка - это нагрузка, с которой по какой-то причине не справляется железо (не хватает CPU или памяти). </p> <p>На данный момент с развитием железа проблемы его нехватки отпали, если приложение тормозит, то в 99% случаев это косяк в архитектуре.</p> <p>Расммотрим рядовую операцию на бэкенде </p> <ol> <li>Прием данных по сети</li> <li>Парсинг полученных данных</li> <li>Взаимодействие с БД</li> <li>Формирование ответа</li> <li>Отправка ответа клиенту</li> </ol> <p>Самый простой способ реализовать эту операцию - использовать один поток на один запрос. Но тогда быстро упремся в кол-во обрабатываемых запросов в секунду. <br> Далее можно увеличить кол-во используемых котоков или процессов, распределить нагрузку между несколькими серверами. <br> Однако все это не даст значительного прироста в RPS - он останется в пределах нескольких сотен.</p> <p>При этом если проанализировать, сколько времени выполняется каждый из пунктов в операции на бэкенде, то увидим, что:</p> <ul> <li><p>Прием данных по сети - 15к в сек</p></li> <li><p>Парсинг полученных данных - 15к в сек</p></li> <li><p>Взаимодействие с БД - 60к в сек</p></li> <li><p>Формирование ответа - 100к в сек</p></li> <li><p>Отправка ответа клиенту - 15к в сек</p></li> </ul> <p>Если этого все сложить по формуле</p> <p>1/sum(1/freq(i))</p> <p>то получим 6к запросов в секунду, а не условно 500.</p> <p>В таких случаях нужно заняться профайлингом. Тогда увидим, что код выполняется процессором от силы 10% всего времени, а остальное времени идет ожидание от БД и сети.</p> <h2> Событийно-ориентированная архитектура </h2> <p>Решить предыдущую проблему поможет изменение парадигмы программирования.</p> <p>Событийно-ориентированная архитектура подразумевает, что выполнение программы определяется событиями, на которые осуществилась "подписка". То есть мы говорим, что когда поступит событие успешного сохранения в БД, сделай то-то. <br> Это то-то определяем в колбеке, который передаем отдельным аргументом. Из-за этого придется менять основную часть кодовой базы, которая крутится вокруг взаимодействия по сети.</p> <p>Также приходится решать проблемы, связанные со сменой парадигмы.</p> <ul> <li><p>сохранение контекста между колбеками</p></li> <li><p>обработка исключений</p></li> </ul> <p>Чтобы было нагляднее, традиционную парадигму с потоками можно сравнить с обувным магазином, где покупатель часто находится в ожидании, когда ему принесут обувь.<br> А событийно-ориентированную парадигму - с продуктовым магазином, где продавец всегда при деле находится и обслуживает очередь.</p> <h2> Green Threads </h2> <p>Если брать обычные потоки, то их переключением занимается планировщик в составе операционной системы.<br> Однако можно написать собственный планировщик, который бы управлял зелеными потоками (эмуляция многопоточной среды - подпрограмма), переключаясь между ними в момент ожидания операций ввода/вывода в одном.<br> Соответственно, если операция сугубо процессорная, то профита не будет.</p> <p>Тогда если соединить вместе друг с другом свой планировщик и машину событий, то получим таком порядок выполнения операции:</p> <ol> <li>Регистрация событий в машине состояний</li> <li>Передача управления планировщику</li> <li>При наступлении события планировщик будит зеленый поток</li> <li>Программа работает с данными от события, которое наступило в пред. пункте</li> </ol> <p>Т.е. зеленый поток усыпляется до тех пор, пока не наступает событие.</p> <p>Такой подход подразумевает использования библиотеки для использования зеленых потоков и написания кода-оберток над БД и сетевых вызовов.</p> highload article highloadjunior Mikhail Mon, 13 Nov 2023 21:36:24 +0000 https://dev.to/zabelin/glava-4-kodirovaniie-i-evoliutsiia-26oh https://dev.to/zabelin/glava-4-kodirovaniie-i-evoliutsiia-26oh <h2> Введение </h2> <p>С течением времени приложение меняется. Однако данные, с которыми работает новая версия приложение, могли быть созданы еще при старой версии приложения.<br> Тем не менее приложение должно уметь работать как со старым форматом данных, так и с новым. Это называется <em>обратной совместимостью</em>.</p> <p>Также бывает нужно, чтобы старая версия приложения умела работать с данными, созданными более новой версией приложения.<br> Например, при плавающем обновлении, когда на некоторых нодах развернута уже новая версия приложения, а где-то старая. Это называется <em>прямой соместимостью</em>.</p> <h2> Форматы кодирования данных </h2> <p>Для разных целей одни и те же данные могут представляться по-разному. Для хранения использоваться один формат, а для пересылки по сети - другой.<br> Преобразование из формата для хранения в формат для пересылки называется кодированием, маршаллингом или сериализацией. Обратное преобразование, когда получатель получил данные - декодированием, демаршаллингом или десериализацией.</p> <h3> Форматы, ориентированные на ЯП </h3> <p>В большинстве языков программирования есть "нативная" сериализация, достигаемая минимумом кода (например, java.io.Serializable в Java). Однако такие реализации имеют много минусов:</p> <ul> <li><p>Она заточена под один язык программирования. А значит, программы, написанные на разных ЯП, не смогут "общаться".</p></li> <li><p>Как правило, низкая эффективность по скорости и размеру потребляемой памяти.</p></li> <li><p>Проблемы с безопасностью - если подложить для декодирования вредоносные данные, то после декодирования будет в памяти объект, способный выполнять вредные вещи.</p></li> <li><p>Плохо продуманы вопросы, касающиеся совместимости.</p></li> </ul> <h3> Текстовые форматы данных </h3> <h4> XML </h4> <p>Многословный текстовый формат, часто применяющийся к корпоративных приложениях, особенно, если они были написаны в 90-е и 2000-е. В XML нет типов данных как таковых. Все можно считать строкой.<br> Но можно подключить схему валидации (своего рода костыль). Для XML использование схем валидации частое явление.</p> <h4> JSON </h4> <p>Текстовый формат, часто применяющийся в современных приложениях. Менее многословный, чем XML. Также поддерживает схемы валидации, однако для JSON они на практике очень редко используются.<br> Зато есть поддержка типов данных (boolean, string, int64). Однако есть проблема с большими числами - числа более 2^53 кодируются с неточностями из-за представления числа с плавающей точкой по стандарту IEEE-754.</p> <p>Также есть двочные кодирования для JSON - BSON, MessagePack и др. Но они редко использутся и дают не настолько сильный выигрыш в снижении объема данных, чтобы терять в удобочитаемости. Я встречал в БД его использование.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--llLSC0vV--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b4butcc77hc72z72sght.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--llLSC0vV--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b4butcc77hc72z72sght.png" alt="Image description" width="800" height="604"></a></p> <p>Стоит отметить, что оба формат не поддерживают работу с бинарными строками. Поэтому использутся костыль в виде base64 кодирования, который примерно на 30% увеличивает объем данных.</p> <h3> Двоичные форматы данных </h3> <p>Apache Thrift и Protocol Buffers - популярные библиотеки для кодирования данных. Оба требуют предварительно иметь на отправителе и получателе схему.<br> Отчасти благодаря тому, что часть необходимой для кодирования/декодирования данных информации зашита в схему, достигается сильное снижение объема данных.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--a2oyAU49--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6h7duy91iclsbsb9raoc.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--a2oyAU49--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6h7duy91iclsbsb9raoc.png" alt="Image description" width="505" height="144"></a><br> Apache Thrift</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--QgF1R0_3--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7dw0ips7zub5ii8au48x.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--QgF1R0_3--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7dw0ips7zub5ii8au48x.png" alt="Image description" width="492" height="124"></a><br> Protobuf</p> <p>Так как protobuf популярнее, рассмотрим его устройство подробнее.</p> <p>Вместо названия полей в protobuf в закодированных данных хранятся тип значения (число), теги полей - числа (что-то вроде псевдонимов для полей), длина (для строки) и сами данные.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--yRcpIFaB--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sm81lcjd72dyb0r5p5i2.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--yRcpIFaB--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sm81lcjd72dyb0r5p5i2.png" alt="Image description" width="800" height="413"></a></p> <p>В итоге данные, которые в JSON весили 84 байта, в protobuf весят 33. </p> <p>Однако что с совместимостью у бинарных форматов?</p> <p>Как видно, закодированная запись это просто конкатенация закодированных полей.</p> <p>Если поле добавляется, то чтобы новый код мог работать со старыми данными, новое поле должно быть необязательным или иметь дефолтное значение - тогда новая версия приложения может читать старые данные.<br> Если поле удаляется, то чтобы старый код мог работать с новым форматом поле удаляемое поле должно быть необязательным изначально и тег для него нельзя будет использовать для новых полей.</p> <h2> Способы обмена данными </h2> <p>Теперь рассмотрим способы отправки данных в форматах, описанных ранее.</p> <p>Существует 3 способа обмена данными между процессами на одной ноде или разных:</p> <ul> <li><p>через общую БД</p></li> <li><p>через REST или RPC</p></li> <li><p>асинхронный обмен через очередь сообщений</p></li> </ul> <h3> Общая БД </h3> <p>Самый примитивный способ интеграции приложений, дающей сильное связывание между компонентами. Однако есть и плюс - актуальная схема данных хорошо видна.<br> Для достижения прямой совместимости нельзя допускать, чтобы старая версия приложения целиком перезаписывала всю строку.</p> <h3> REST и RPC </h3> <p>RPC - удаленный вызов процедур. В коде приложения это выглядит как вызов локальной функции. Популярный паттерн коммуникации в SOA (сервис ориентированной) архитектуре.<br> Чаще всего RPC реализуется через SOAP протокол. В его основе лежит протокол HTTP. Однако SOAP не использует никакие его возможности, такие как использование кодов ответов, заголовков.<br> API сервиса, поддерживающего общение по SOAP, описывается на XML через WSDL схему. На основе этой схеме генерируются нужные методы на языках программирования. </p> <p>REST - подход к проектированю систем, общающихся по http и по-максимому использующих его возможности. В качестве формата данных могут использоваться разные форматы, однако чаще всего это JSON.</p> <h3> Очереди сообщения </h3> <p>RPC - синхронный способ обмена сообщениями.</p> <p>БД - асинхронный, но изначально предполагающий использование в качестве хранилища данных.</p> <p>Очередь - тоже асинхронный способ, но изначально предполагающий использование для обемена сообщениями. Поэтому имеет такие сущности как топик, смещение, издатель и подписчик. Благодаря этим абстракциям обмен данными многими с многими упрощается.</p> <p>Преимущества ипользования очередей по сравнению с RPC:</p> <ul> <li><p>очередь является буфером, смягчающим скачки нагрузки на приложение</p></li> <li><p>уменьшает связанность компонетов системы (отправителю не нужно знать адрес получателя)</p></li> <li><p>автоматически повтор отправки в случае сбоя</p></li> </ul> <p>Примеры часто использующихся брокеров сообщения: RabbitMQ, Apache Kafka, NATS.</p> клеппман высоконагруженныесистемы книги Mikhail Sun, 12 Nov 2023 20:56:32 +0000 https://dev.to/zabelin/glava-3-podsistiemy-khranieniia-i-izvliechieniia-dannykh-5afb https://dev.to/zabelin/glava-3-podsistiemy-khranieniia-i-izvliechieniia-dannykh-5afb <h2> Вступление </h2> <p>Журнал - самая простая структура для хранения данных в принципе. Она позвляет дописывать данные только в конец.<br> Если рассмотреть данные вида ключ-значение, то при вставке записи с тем же ключом в журнале будут дублирующие данные.<br> Сложность поиска по журналу - O(n). Это много.<br> Для более эффективного поиска данных используются вспомогательные структуры, производные от основных данных - индексы.<br> Поддержка индексов приводит к более быстрому поиску, но более медленной вставке и удалению, так как индексы тоже подлежат обновлению.<br> Поэтому на усмотрение разработчика выбор индексов.</p> <h2> Индексы </h2> <h3> Журнал + хэш карта </h3> <p>Самый простой вариант индекса для данных вида ключ-значение - хэш карта. Она будет хранить смещение в файле данных.<br> Однако эта реализация с журналом имеет недостаток - файл с данными будет постоянно увеличиваться на диске.<br> Поэтому можно придумать оптимизацию - разделить журнал на сегменты и фоном выполнять уплотнение сегментов, убирая "старые" значения для ключей. Этот процесс называется уплотнением журнала.<br> У каждого сегмента будет свой индекс - своя хэш таблица.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--f3rvyHoY--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/791bc5lt1kotbd8wx9yl.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--f3rvyHoY--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/791bc5lt1kotbd8wx9yl.png" alt="Image description" width="800" height="262"></a></p> <p>Чтобы уплотнение не мешало основным операциям с данными, можно совершать уплотнение, оставляя старые сегменты и только после успешного уплотнения переключать запросы на "новые" сегменты.</p> <p>Плюсы:</p> <ul> <li><p>быстрое чтение O(1) поиск по индексу + перемещение на позицию в файле.</p></li> <li><p>реализация конкурентного доступа упрощается, так как данные идемпотентны, ведь любое изменение записи ведет к созданию новой записи</p></li> <li><p>добавление в конец и слияние - очень быстрые операция на SSD и особенно на HDD дисках</p></li> <li><p>благодаря слиянию достигается лишь небольшая фрагментация данных</p></li> </ul> <p>Минусы:</p> <ul> <li><p>запись может осуществляться в одном потоке, так как запись идет всегда в коней файла. Это замедляет параллельную запись.</p></li> <li><p>нет возможности поиска по интервалу</p></li> </ul> <p>Также нужно обдумать следующие вопросы:</p> <ul> <li><p>удаление данных - можно добавить каждой записи в сегменте метку признака удаления</p></li> <li><p>восстановление после сбоя - так как индекс (хэш карта) хранится в оперативной памяти, то после сбоя придется ее восстанавливать, проходя через все сегменты, что займет много времени. Можно периодически делать снэпшоты хэш карты на диск</p></li> </ul> <p>Описываемый метод исользуется в подсистеме BitCask NoSQL БД RiakDB</p> <h3> Sorted String Table + хэш карта </h3> <p>Журнал обладал тем минусом, что данные в нем не были отсортированы. Поэтому объединение сегментов там выполнялось за O(n^2), а для поиска по интервалу требовалось для каждого значения из интервала осуществлять отдельный поиск.</p> <p>Поэтому эффективнее держать часть данных в оперативной памяти, а часть - на диске.<br> В памяти удобно держать сбалансированную структуру данных (данные в ней отсортированы - при вставке происходит ребаланс),<br> которую бы можно было при достижении определенного размера скидывать на диск в виде Sorted String Table (отсортированная строковая таблица), которая в фоне уплотняется, как в сортировке слиянием - O(n).</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--Wevt2Lqo--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x0l3nnxmvhnhql9g00hn.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--Wevt2Lqo--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x0l3nnxmvhnhql9g00hn.png" alt="Image description" width="800" height="510"></a></p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--rmUlOGcN--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pq4f40bqb225k8wczxur.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--rmUlOGcN--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pq4f40bqb225k8wczxur.png" alt="Image description" width="800" height="355"></a></p> <p>Благодаря этому больше нет необходимости хранить в индексе смещение для данных по всем ключам, так как, например, если известно смещение для ключей a и c, то смещение для ключа b будет где-то между ними.</p> <p>Описываемый метод используется в БД LevelDB</p> <h3> В-деревья </h3> <p>B-деревья - самый распространенный тип индекса.<br> В отличие от журнала, основой которого является сегмент данных переменного размера, в B-деревьях данные разделяются на страницы фиксированного размера (обычно 4кб). Диски тоже разбиваются на блоки фикс. размера.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--nrhkOBxo--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v8c3vquqtho0ejsil2dp.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--nrhkOBxo--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v8c3vquqtho0ejsil2dp.png" alt="Image description" width="800" height="360"></a></p> <p>Все страницы, кроме страниц в листях, указывают на другие страницы B-дерева на диске. В листьях страницы содержат ссылку на страницу со значением в основной таблице с данными.<br> Кол-во ссылок на дочерние страницы называется коэффициентом ветвления. На практике он равен нескольким сотням.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--X6kp6Toz--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6tia5wi06iyigr6pyam8.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--X6kp6Toz--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6tia5wi06iyigr6pyam8.png" alt="Image description" width="800" height="423"></a></p> <p>Если на странице нет места, то создается 2 новых полупустых страницы, куда копируются данные из старой таблицы и со стороны родителей перевешиваются указатели на новые страницы.</p> <p>B-дерево - сбалансированное дерево. Его высота и сложность поиска - O(log(n)).</p> <p>На практике дерево содержит высоту 3-4 уровня. </p> <p>Чтобы сделать бд с индексом на основе B-дерева отказоустойчивой, используются журнал упреждающей записи (WAL - write ahead log),<br> в который записывается действие - только после этого происходит изменение самого B-дерева (а само изменение из-за ребаланса может быть значительным).</p> <p>Оптимизации:</p> <ul> <li><p>можно хранить на страницах не полные значение ключей, а часть (актуально, если ключ - строка), ведь во внутренних узлах при сравнении используется лишь часть ключа.</p></li> <li><p>вместо wal журнала можно делать копию узлов b дерева, которые связаны с измененной страницей. Это полезно при конкурентном доступе.</p></li> </ul> <p>По итогу SS таблицы быстрее при записи, но медленнее при чтении, чем B-деревья.</p> <h3> Хранение в памяти, а не на диске </h3> <p>До этого все рассматриваемые структуры данных использовались для хранения данных на диске. Ранее стоимость места на диске была сильна ниже, чем в оперативной памяти, чей объем был к тому же ограничен.</p> <p>В данный момент идет тенденция, что в большинстве случаев объема оперативной памяти достаточно для хранения всех данных, а отказоустойчивость осуществляется с помощью репликации по сети и питания от аккумуляторов.</p> <p>Поэтому в последнее десятилетие активно развивается направление in-memory баз данных, например, Memcached.</p> <p>Однако не всегда можно заметить разницу между использованием БД, использующих диск и ОП, так как операционная система имеет свой кэш, куда сохраняются наиболее часто используемые страницы диска.</p> <h2> Паттерны использования БД </h2> <p>Существует 2 сценария использования БД - обработка транзакций в реальном времени (OLTP) и аналитика данных (OLAP). Первый используется обычными пользователями, а второй - аналитиками данных.<br> При обработке транзаций в реальном времени обычно ищется небольшое кол-во записей по ключу (а общий размер всех данных от гб до тб). При аналитике происходит агрегация больших объемов данных (от тб до пб).</p> <h3> Поступление данных в OLAP и OLTP. </h3> <p>Поступление данных в OLTP хранилища происходит через какие-то бизнес процессы (работы клиента с системой обслуживания или работа с POS терминалом). Соответственно, требуется высокая доступность БД и низкая задержка в ответе.</p> <p>Поступление данных в OLAP хранилища осуществляется через групповой испорт (ETL - extract transform load) или потоковую загрузку.</p> <h3> Схемы для аналитики </h3> <p>В аналитике популярна схема звезда и ее развитие - снежинка. </p> <p>В звезде имеется таблица с фактами - запись с внешники ключами на таблица с атрибутами (концы звезды)</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--dgr0MtNk--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x5rml5t2yvfqzc40qj57.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--dgr0MtNk--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x5rml5t2yvfqzc40qj57.png" alt="Image description" width="800" height="806"></a></p> <p>В снежинке точно так же, только измерения разделяются на подизмерения.</p> <h2> Столбцовое хранение </h2> <p>В таблице могут быть триллионы строк и петабайты данных. Значения соседних полей одной строки лежат рядом на диске. В аналитике обычно требуются не все поля, но все строки. Поэтому удобно хранить данные не по строкам, а по столбцам.<br> Тогда можно на диске иметь свой файл под каждое поле.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--X602HUtj--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oqfk6y4lop5j2dlemepc.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--X602HUtj--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oqfk6y4lop5j2dlemepc.png" alt="Image description" width="800" height="513"></a></p> <p>Для оптимизации хранения полей, у которых фикисрованный набор значений, можно использовать битовые маски.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--A2Jw_jK0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/blkmbb9blrcto56enfhj.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--A2Jw_jK0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/blkmbb9blrcto56enfhj.png" alt="Image description" width="800" height="484"></a></p> Mikhail Sat, 04 Nov 2023 19:37:59 +0000 https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-2-modieli-dannykh-i-iazyki-zaprosov-hgk https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-2-modieli-dannykh-i-iazyki-zaprosov-hgk <h2> Вступление </h2> <p>Модель данных - это способ представления некоторых данных. Данные можно представить на разных уровнях, поэтому между собой модели данных образуют иерархию, когда одна модель данных выражается через другую на языке более низкого уровня. Например:</p> <ol> <li><p>Выражение процесса в окружающем мире через некоторые структуры данных, а действие с ними через API. Это самый высокий уровень.</p></li> <li><p>При необходимости сохранять эти данные можно выбрать текстовый вид, например в виде json или xml.</p></li> <li><p>Способ внутреннего представления json или xml в БД (на уровне последовательности байт), благодаря чему становятся возможными операции с этими данными, такие как поиск, вставка, обновление, удаление части данных.</p></li> <li><p>Выражение байт в терминах эл. тока. Аппаратный уровень.</p></li> </ol> <p>Таким образом, верхний слой инкапсулирует сложность нижестоящего слоя.</p> <p>Уровень 1 можно представить для хранения данных через 3 модели данных:</p> <ul> <li>Документоориентированная модель (иерархическая)</li> <li>Реляционная</li> <li>Графовая</li> </ul> <p><strong>Документоориентированная</strong> хорошо подходит для хранения иерархических данных со связями 1 ко многим. Однако связь многие ко многим и многие к одному с ее помощью нельзя реализовать. В соответствие с этой моделью данные представляются в виде единого документа. Некоторые из NoSQL баз данных являются представителями этой модели. Получили широкое распространение в 2010-х годах. Данные не имеют четкой структуры. </p> <p>Плюсы - можно получить за раз все части документа, обеспечивают лучшую локальность данных, лучшую пропускную способность по записи, лучше подходят для выражения некоторых моделей данных (отсюда менее лаконичные запросы) и легко масштабируются</p> <p>Минусы - в память грузится весь документ. И меняется он тоже весь, что затратно по времени. Реализации этой модели чаще не дают гарантий, которые дает реляционная модель.</p> <p>Пример - хранения документов в виде json в MongoDB.</p> <p><strong>Реляционная модель</strong> - самая универсальная из трех.</p> <p>Плюсы: поддерживает все виды соединений и могут представлять иерархические и графовые модели данных (через таблица с ребрами и вершинами и рекурсивные запросы через common table expressions). Также современные реляционные БД позволяют хранить неструктурированные документы json и xml и производить с ними манипуляции.</p> <p>Минусы: запросы получаются громоздкими, а сами данные организованы сложно для понимания. Пример - PostgreSQL c языком SQL.</p> <p><strong>Графовая модель</strong> является самой узкоспециализированной. Подходит для случаев, когда потенциально любые данные могут быть взаимосвязаны. Для этого вершины еще могут хранить тип сущности. Например, есть пользователь и его место жительства. Пользователь связан с городом. Город связан с регионом. Регион со страной. И все этой разные типы сущностей.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--MdyOHz6d--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8yh6gxiczqe4tv5x3lpe.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--MdyOHz6d--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8yh6gxiczqe4tv5x3lpe.png" alt="Image description" width="725" height="415"></a></p> <p>Представляется в виде вершин (сущности) и ребер (связи).</p> <p>Вершины имеют:</p> <p>идентификатор<br> множество ид входящих ребер<br> множество ид исходящих ребер<br> метаинформация в виде пар ключ-значение (json)</p> <p>Ребра имеют:</p> <ul> <li><p>ид вершины-начала</p></li> <li><p>ид вершины-конца</p></li> <li><p>идентификатор</p></li> <li><p>метаинформация в виде пар ключ-значение (json)<br> Данные не имеют четкой структуры. Пример - Neo4j с языком запросов Cypher.</p></li> </ul> <h2> Особенность языков запросов к хранилищам </h2> <p>Если рассмотреть языки запросов, которые используют реализации этих трем моделей, до обнаружим, что все они декларативные, когда мы указывает результат, к которому хотим прийти, а вся логика по достижению этого результата определяется оптимизатором.</p> highload книги клеппман высоконагруженныеприложения Mikhail Sat, 04 Nov 2023 19:25:42 +0000 https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-1-nadiezhnyie-masshtabiruiemyie-i-udobnyie-v-soprovozhdienii-prilozhieniia-1phm https://dev.to/zabelin/vysokonaghruzhiennyie-sistiemy-glava-1-nadiezhnyie-masshtabiruiemyie-i-udobnyie-v-soprovozhdienii-prilozhieniia-1phm <p>Приложения могут быть высоконагруженными данными и высоконагруженными вычислениями. </p> <p>Приложения, высоконагруженные данными, строятся из стандартных блоков:</p> <p>Долговременное хранение данных (базы данных)<br> Запоминание на небольшой как правило промежуток времени ресурсоемкой операции (кэши)<br> Поиск в хранилище данных, фильтрация (поисковые индексы)<br> Обработка данных без задержек (потоковая обработка)<br> Обработка накопленных данных (пакетная обработка)<br> Однако существует много инструментов внутри каждого из блоков, отличающихся друг от друга. Поэтому не все так просто.</p> <p>Если вкратце, то есть 3 наиболее важных вопроса, которые необходимо рассмотреть при проектировании высоконагруженного приложения:</p> <p>Надежность (при программных/аппаратных сбоях система должна продолжать работать корректно для пользователя)<br> Масштабируемость (при росте нагрузки должно быть легко модифицировать системы, чтобы она продолжала справляться с возрошей нагрузки)<br> Удобство сопровождения (нужно предусмотреть, как системой будут пользоваться рядовые пользователи и ее сопровождения - у него должна быть возможность быстро расследования инцидентов)<br> Надежность<br> Надежность - это способность системы продолжать работать корректно при определенных сбоях. Сбои по причинам на 3 группы:</p> <p>Аппаратные (выход из строя плашки ОЗУ или диска). Выход - использование избыточного кол-ва аппаратного обеспечения, чтобы не наступил уже отказ всей системы.<br> Программные (провайдер перестал отвечать, процесс исчерпал ресурс). Выход - изначальное продумывание возможных проблем и путей их недопущение, использование средств для ручного мониторинга и алертинга. Автоматический перезапуск системы после фатального сбоя. <br> Человеческий фактор (неправильная настройка приложения или необработанная ошибка при каком-нибудь пользовательском сценарии). Выход - проектирование с учетом того, чтобы правильные действия было легко сделать, а неправильные - сложно. Грамотно спроектированное API. Зрелый CD (Continious Delivery), когда есть возможность быстрого отката изменения сервиса или конфига и канареечные релизы. Настроить телеметрию приложения для обнаружения проблем на ранней стадии до массового недовольства потребителей.<br> Масштабируемость<br> Масштабируемость - способность системы справлять с возрастающими нагрузками. Эта способность измеряется ответами на следующие вопросы:</p> <p>Насколько сильные изменения нужно произвести с системой, чтобы она стабильно выдерживала в 10 раз большую нагрузку<br> Каким образом можно увеличить вычислительные ресурсы чтобы системы выдерживала в 10 раз большую нагрузку.<br> У нагрузки есть параметры, тип которых разнится в зависимости от устройства системы. Это может быть RPS (кол-во запросов в секунду), кол-во одновременных пользователей, делающих что-то, отношение кол-ва операций чтения к кол-ву операций записи в БД.</p> <p>Пример с Twitter<br> Например, рассмотрим архитектуру Twitter. Там есть 2 основных действия - публикация твита и просмотр ленты. В данном случае сложность в масштабировании представляет сильная степень разветвления (пользователь подписан на многих и сам имеет много подписчиков). Это и есть параметр масштабирования.</p> <p>Twitter сначала на каждую операцию обновления делал выборку постов через join авторов постов с теми, на кого подписан пользователь. Это самый примитивный вариант, который довольно скоро оказался нерабочим из-за возросшей нагрузки.</p> <p>Затем придумали вариант "кэша" для ленты пользователя, когда при публикации твита он попадал в ленты всех пользователей, которые подписаны на его автора. Однако из-за масштабов (особенно для авторов с миллионами подписчиков) проходило много времени между фактической публикации и тем, когда подписчик видел твит в своей ленте.</p> <p>Поэтому в итоге Twitter остановился на промежуточном варианте, когда твиты знаменитостей подгружаются именно при обновлении ленты и сливаются с "закэшированными" данными от менее популярных авторов.</p> <h3> Описание производительности системы </h3> <p>После описания нагрузки нужно описать производительность. Для этого нужно ответить на 2 вопроса:</p> <p>Как изменится производительность системы, если параметры нагрузки увеличить в N раз<br> Насколько нужно увеличить ресурсы, чтобы при увеличении параметров нагрузки в N раз производительность останется той же.<br> Время обработки запроса - хорошая метрика производительности. При этом есть время отклика (общее время, которое ждет клиент, отправивший запрос) и время ожидания (время, пока запрос ожидает свой обработки сервером). Время отклика важно смотреть в контексте тысяч запросов, чтобы получить распределение времени запросов и иметь общую картину того, что будет происходить в проде. Медиана, 90-й, 95-й, 99-й процентили обычно берут. 99-й процентиль - это такое время отклика, что 99% запросов выполнялись меньше этого времени.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--JyRVHb_r--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/piqg11siu5sn7b2bdcnq.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--JyRVHb_r--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/piqg11siu5sn7b2bdcnq.png" alt="Здесь по оси x - время обработки запроса, а по оси y - кол-во запросов, выполнившихся в определенном коридоре времени" width="788" height="856"></a></p> <p>Здесь по оси x - время обработки запроса, а по оси y - кол-во запросов, выполнившихся в определенном коридоре времени.</p> <p>Такие значения обычно прописываются в требованиях к уровню предоставления сервис (SLA), что 99% запросов должны выполняться меньше 200мс, а 50% - менее 100мс.</p> <h3> Как справиться с нагрузкой </h3> <p>Есть 2 варианта:</p> <p>Вертикальное масштабирование (увеличение мощности одной машины, на которой работает сервис)<br> Горизонтальное масштабирование (увеличение кол-ва маломощных машин, на которых работают экземпляры сервиса)<br> Там, где нужно хранить состояние (например, БД), горизонтальное масштабирование плохо подходит. Горизонтальное масштабирование идеально подходит под "числодробилки", которые состояния не имеют.</p> <h3> Удобство сопровождения </h3> <p>Если коротко, то это грамотно написанный код системы без сильного зацепления модулей для их быстрой модификации и хороший мониторинг.</p> highload книги клеппман высоконагруженныеприложения