?

Log in

No account? Create an account
avlasov's Journal
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in avlasov's LiveJournal:

[ << Previous 20 ]
Sunday, January 28th, 2018
9:21 pm
Психологические основы либеразма
Уже лет наверное под 30 я (и не только) сталкиваюсь с любителями рыночной экономики. В какой-то момент возник вопрос - откуда они берутся? Поначалу оно вобщем-то понятно: народ в СССР в плане рыночной экономики был непуганный почти что совсем. Поэтому не удивляет, что всякие красивые идеи о рынке и проч массово вошли в неопытные мозги наших соотечественников (включая и мои).

Я правда довольно-таки быстро (ну там в течении нескольких лет) стал недоумевать, с хера этот бред кто-то еще хавает? Ну наебали, прогнали всякую хуету, но за несколько лет-то можно было разобраться, что к чему! Дык нет же, это бред продолжает цвести в мозгах дорогих россиян уже который десяток (не знаю просто откуда читать). Поначалу я списывал это на глупость. Но потом выяснилось, что довольно много умных людей этим страдает, и они даже скорее к этому склонны. Тогда я списывал на неопытность, оторванность от жизни. Но кагбэ 30 лет на это трудно списывать. Да и как-то вобщем стало понятно, что либеразмом страдают умные и умудренные опытом деловой активности.

Сейчас у меня появилось более-менее целостное объяснение сему феномену. В рассиянском либеразмическом дискурсе существует такое утверждение, что рынок это типа в сущности вобщем-то система добровольных сделок. Когда я ее первый раз прочитал, то подумал, что ожидалось, что я видимо услышав эту сокровенную мудрость, упаду на спинку, и начну дрыгать ножками от щасся. Как же, добровольные сделки! Я как-то не мог долго понять, чем же так добровольность радует любителей рыночной экономики.

Но вобщем-то если проанализировать любителей рыночной экономики, то для них характерен страх насилия. Т.е. они там постоянно его как-то осуждают, особливо государственное, но не только конечно (хотя кто-то наверное только государственное, но я не запоминаю таких подробностей). Соответственно, возникает гипотеза, что их психика просто не сумела адаптировать к дикому росту насилия 90х, возможно усугубленных всеразличными страшилками про то, как Сталин лично расстрелял миллиарды ни в чем не повинных людей. Точнее, она сумела адаптироваться, но путем выработки некоего символического убежища от насилия - того самого пресловутого рынка как "системы добровольных сделок". Т.е. на рынке усе хорошо, там щассе, рай типа. Это роднит либеразм с религией, т.е. как неспособность примирится с существованием (и неизбежностью) смерти ведет к идее загробной жизни, так и неспособность примириться с существованием (и даже вездесущием) насилия требует от психики создания некоего идеального конструкта - рынка, где эта проблема разрешается.

Конечно, при достаточно интенсивном общении с любителями рыночной экономики, рано или поздно догадаешься, что рынок, в их понимании, это объект, который в природе не существует (как же, настоящий рынок же мгновенно ресурсы перераспределяет! а в реальности оно все же как никак какого-то времени требует). Однако, что это некая конструкция, которая стабилизирует психику - и от того любители рыночной экономики весьма ожесточенно относятся к нападкам на их любимый рынок - до этого я допер только вот совсем недавно.
Sunday, January 7th, 2018
12:25 am
Из серии "Машин Дёрнинг на Удафф.ком"
Сижу себе, делаю topic modelling починяю примус, внезапно обнаруживаю в результатах такой топик:
'0.145*"fuck" + 0.144*"shit" + 0.134*"ass" + 0.093*"y’all" + 0.059*"damn" + 0.053*"bitch" + 0.035*"hell" + 0.027*"bad" + 0.018*"asian" + 0.013*"fuckin" + 0.011*"got" + 0.011*"hoe" + 0.010*"like" + 0.010*"kick" + 0.010*"bullshit" + 0.009*"nigga" + 0.008*"caus" + 0.006*"real" + 0.006*"gonna" + 0.006*"face"'
Saturday, September 2nd, 2017
1:51 am
Мини-учебнег по распределенным системам/протоколам. Репликация, дублирование и веб-системы
Будем различать дублирование и репликацию. Для устранения SPOF или для увеличения производительности мы можем дублировать устройства и/или процессы, т.е. какие-то типы запросов могут обрабатывать разные дивайсы. Точно также мы можем делать копии данных, как с целью устранения SPOF так и увеличения производительности. Дублирование данных назовем репликацией. Будем различать горизонтальную и вертикальную репликацию. Горизонтальная - это когда мы делаем однородные копии, ну например записываем данные на несколько дисков, или в память нескольких процессов. А вертикальная - это копии данных на разных типах носителей, например, кэш - это копия данных, которые храняться, положим на диске (или в удаленной или в более медленной памяти). Бэкап - тоже пример вертикальной репликации.

Collapse )
Friday, September 1st, 2017
11:54 pm
Мини-учебнег по распределенным системам/протоколам. Проблемы создания распределенных веб-систем
Сама по себе реализация распределенности на данный момент не представляет собой проблемы - есть целая куча библиотек и протоколов, для RPC, передачи сообщений по сети, сериализации/кодирования данных, обнаружения сервисов и проч. В случае веб-систем, увеличение производительности тоже не представляет собой принципиальной проблемы, в силу того, что запросы от разных пользователей можно обрабатывать более-менее независимо. Я бы сказал, что основная проблема это создание надежной, отказоустойчивой системы. Правда, бывает, что обработка запросов от разных пользователей имеет зависимости по данным, например, нужно учитывать запасы товара, которые могут зарезервировать покупатели. Или когда надо переводить деньги со счета на счет.

Collapse )
11:22 pm
Мини-учебнег по распределенным системам/протоколам. Stateful процессы
Вообще говоря, помимо Stateless+Shared Db+(Mem)Cache нужно рассмотреть более сложную архитектуру, где вместо простого кэша, используется полноценная память и/или сервис для синхронизации. Например, можно для синхронизации использовать ДБ. Это актуально, ибо простое кэширование не всегда приемлимо. Но я все же хотел бы рассматривать эти усложнения попозже, совместно с репликацией и обработкой сбоев.

Пусть у нас теперь процессам будет положено иметь состояние - Stateful схема. Будет использоваться shared DB или нет - это отдельный вопрос, но пусть для начала будет shared db. Stateful сервера позволяют сильно увеличить производительность обработки запросов - ведь можно хранить состояние на сервере, т.е. не надо ходить ни в мемкэш на другом хосте, ни в БД - разумеется, периодически надо будет, имеется в виду, что много запросов можно обслуживать, используя локальную память. Правда, тут желательно, чтобы процессы были многопоточными - ведь если на одном хосте будет много однопоточных процессов, то часть состояния будет дублироваться, что может привести к нежелательному расходу памяти.

Однако, в Stateful архитектуре возникает проблема синхронизации состояния в разных процессах. В принципе, в случае веп-процессов, это часто можно избежать. Рассмотрим сперва виды состояния. Можно грубо разделить состояние на три вида: состояние, актуальное для запроса - request-level, для веб-сессии (последовательности запросов) и для приложения в целом. В распределенной системе еще можно выделить состояние в контексте отдельного процесса и распределенного приложения в целом (единое на все процессы). Бывают и более хитрые контексты - например, может быть контекст для длительных транзакций/воркфлоу и ассоциированное с ним состояние. Но не суть важно.

Collapse )
9:40 pm
Мини-учебнег по распределенным системам/протоколам. Stateless+Shared DB+Cache
Дополним Stateless схему кэшированием. Вообще, кэширование применяется везде, есть много их всяких видов, в частности есть целая куча библиотек кэширования. Нужно уточнить о чем идет речь. В данном посте я буду вести речь прежде всего о кэшировании, которое разгружает Shared DB в контексте стейтлесс сервера. Т.е. вообще говоря, это паттерн не только для веп-систем. Хотя есть еще специфические для веба кэши, которые вобщем тоже разгружают веб-сервер, а косвенно и БД. Но пока именно о кэшах типа memcached, ибо это есть популярная схема.

Итак, для упрощения масштабирования http layer'а (или еще из каких соображений) мы сделали web сервера стейтлесс, и все состояние храним в БД. И мы столкнулись с тем, что схема перестала масштабироваться - БД стала боттлнеком. И мы хотим ввести кэширование, чтобы разгрузить БД.

Collapse )
Thursday, August 31st, 2017
6:28 pm
Мини-учебнег по распределенным системам/протоколам. Stateless и Shared Disk/DB
Допустим на какой-то сайт ходит много народу и нужно увеличить производительность системы. Стандартный и весьма популярный способ - это Stateless веб-сервера. Т.е. такой стиль реализации веб-сервера, который не хранит у себя состояния. А раз не хранит состояние, то его можно очень просто размножить - ибо не возникает проблемы с конкурентным доступом к состоянию на разных серверах.

К сожалению, у данного подхода есть некоторые недостатки, ибо сей подход не решает принципиально проблему, а переносит ее в другое место. Что впрочем может быть вполне удовлетворительным вариантов. Например, обычно состояние храниться на сервере БД, но это означает, что сервер БД становится узким местом, которому нужно как-то уметь разруливать проблемы с конкурентным доступом к разделяемому состоянию. Но вендоры БД заботятся, чтобы уметь это делать, так что это действительно часто решает проблему до какой-то степени.
Collapse )
6:01 pm
Мини-учебнег по распределенным системам/протоколам. Распределенные веб-системы
Рассмотрим теперь особенности создания распределенных веб-систем. Как обычно, в данном случае, у распределенности могут быть три основных цели: повышение быстродействия, отказоустойчивость и распределение по нескольким дивайсам из каких-то других соображений. В качестве примера последнего, можно привести N-tier, впрочем, веб-приложения в своей основе содержат клиентскую часть, которая исполняется в браузере (обычно) на другом сетевом устройстве.

Рассмотрим сперва N-tier. Допустим мы разбиваем функциональность приложения по таким слоям: presentation layer, service layer, logic layer и data layer. Если мы presentation вынесем на клиента (Ajax и проч), то можем существенно снизить нагрузку на серверную составляющую, в частности, можем уменьшить кол-во веп-запросов, ибо какие-то функции можно реализовать на стороне клиента используя JavaScript. Иногда на клиент выносится и часть логики, или может быть даже какой-то аспект персистенса (т.е. часть инфы можно хранить на локальном диске клиента).
Точно так же, если мы выделим отдельный компьютер для базы данных (data layer), то она может исполнять больше запросов, чем ежели бы на ней еще гонялся веп-/апп-сервер(а).
Collapse )
Tuesday, August 29th, 2017
11:55 pm
Мини-учебнег по распределенным системам/протоколам. Усложнение MapReduce
Надо еще пожалуй обсудить некоторые проблемы MapReduce, а также развитие идеи, которые устраняют некоторые проблемы. Мне как-то всегда MapReduce казался интересной, но специфической идеей. Понятно, что далеко не все задачи хорошо ложаться на MR, и часто это будет медленно. Рассмотрим некоторые проблемы MR.

Collapse )
4:55 pm
Мини-учебнег по распределенным системам/протоколам. MapReduce как пример, оптимизации
Рассмотрим некоторые возможные оптимизации в той схеме, что мы рассмотрели ранее. Отмечу, что я рассматриваю общую схему, а не конкретную реализацию типа Hadoop MapReduce - т.е. в чем-то оно пересекается, а в чем-то и нет.

Map Reduce архитектура не совсем гибкая (нет итеративности, грубо говоря, графов задач), посему можно предположить что основное ее назначение - это обработка гигантских объемов данных. Конечно, ее и для Machine Learning умудряются использовать, но все же для этого у нее есть определенные недостатки. Таким образом, будем считать, что основной проблемой будет перемещение данных по сети, а не собственно вычисления - для вычислительно-емких задач имеет смысл использовать какие-то другие архитектуры (ну может тот же Hadoop Tez, в котором есть граф вычислений, или там Spark, или там еще чего). Итого основная задача - минимизация перемещения данных по сети (ну с диска на диск тоже). Так же считаем, что поскольку данных много, то в память они с большой вероятностью не помещаются, и рано или поздно мы их записываем на диск - либо локальный либо на диск на другой ноде в сети. На мой взгляд, если таких ограничений нет, то лучше использовать не Hadoop MR, а что-то другое. Посему примем за основу эти допущения.
Collapse )
Monday, August 28th, 2017
8:31 pm
Мини-учебнег по распределенным системам/протоколам. MapReduce как пример распределенной системы, ч.2
Сделаем некоторые выводы из предыдущего поста, ибо тут присутствуют важные паттерны.

Входящие и исходящие сообщения

У нас всего одно входящее сообщение - запуск MapReduce Job'ы. Конечно, можно еще рассматривать и события типа отменить джобу, добавить ноду и проч. Но это уже детали.
Из этого сообщения, т.е. из описания джобы можно построить/восстановить граф задач. Т.е. там есть инфа где брать исходные данные, сколько мапперов/редьюсеров, откуда брать код, куда писать результат и проч.

Исходящее из системы сообщение у нас тоже одно - работа сделана (ну или обломилась). На самом деле, конечно, на практике будет сильно больше. Например, будут сообщения о статусе исполнения задачи и проч. Но с точки зрения восстановления после сбоев мы это можем игнорировать.

Collapse )
7:28 pm
Мини-учебнег по распределенным системам/протоколам. MapReduce как пример распределенной системы
Проанализируем теперь подробнее MapReduce фреймворк, который сильно облегчает создание распределенной системы, если ее работу можно описать последовательностью Map и Reduce операций. Точнее, там есть еще несколько промежуточных операций, но Map и Reduce - ключевые. Они весьма близки тем map/reduce операциям, что мы рассмотрели ранее, хотя есть и некоторые отличия.

Map - это не просто map, он преобразует пару элементов (key1, value1) в список list(key2, value2), т.е. это flatMap операция, и она работает не просто над элементами, а над парами ключ/значение.
Reduce - это чуть модифицированный reduce. Более точно, между Map и Reduce есть еще Shuffle фаза, т.е. результат работы Map операции группируется по ключам key2, и к каждой группе применяется Reduce. Т.е. это функция вида (key2, list(value2)) -> list(value3).
В-общем, идеология очень близка к тем операциям, что мы рассмотрели ранее, но по сути это map/groupBy/reduce который работает не на простых элементах, а на парах ключ/значение. Ну и доработанная под распределенную специфику.

Collapse )
Sunday, August 27th, 2017
12:39 am
Мини-учебнег по распределенным системам/протоколам. Map/reduce/fold/filter/group операции
Рассмотрим стандартные higher order функции из функционального программирования типа map, filter, fold, reduce etc. Это операции, которые весьма полезно понимать в контексте распределенного программирования да и программирования вообще. В частности, я хочу рассмотреть Hadoop MapReduce в качестве примера распределенной системы, и проиллюстрировать на нем сказанное ранее. Но для более сложных (с точки зрения распределенных протоколов), эти базовые операции тоже весьма полезны. Кроме того, мы сейчас очень часто встречаем программирование в терминах таких операций, например, в Java 8 добавили Streams, которые их и реализуют. Кроме того, они активно применяются в SQL, так что по сути знакомы большинству программистов. Одно из преимуществ в том, что их зачастую понятно как параллелизовать - и это весьма и весьма актуально для программирования параллельных и распределенных систем. Поэтому я должен сделать лирическое отступление и рассмотреть их подробнее.

Collapse )
Thursday, August 24th, 2017
7:23 pm
Мини-учебнег по распределенным системам/протоколам. Восстановление после сбоев, ч.2
Продолжим восстанавливаться после сбоев. В предыдущей части мы рассмотрели то, что происходит на границах системы: при получении сообщений извне и отправки их наружу. А также восстановление после сбоев с точки зрения каналов общения с внешним миров. Это очень важные моменты, ведь какое состояние нужно хранить в персистентном хранилище - и восстанавливать после сбоев, зависит от того, какую мы инфу выдали во внешний мир. А само состояние (во многом) определяется тем, какие события мы получили из внешнего мира. Основная мораль: прежде чем отправить инфу, нужно убедиться, что при сбое, мы эту инфу не "забудем". Эта формулировка простая, а вот более заумная: - то, состояние, что будет после восстановления после сбоя, будет консистентным с той картиной мира, которую мы сформировали у внешнего наблюдателя.
Collapse )
Tuesday, August 22nd, 2017
6:44 pm
Мини-учебнег по распределенным системам/протоколам. Восстановление после сбоев, ч.1
Рассмотрим теперь подробнее восстановление после сбоев в распределенной системе. Я выделил тут три пункта в одном из предыдущих постов:
— детерминированность обработки событий каждой нодой
— запись входящих сообщений
— output commit

На самом деле, это не совсем точно, скорее это один из возможных подходов. Но если мы слишком сильно от него отступаем, у нас могут быть проблемы. Тем не менее, в зависимости от требований можно и нужно отступать. Рассмотрим все это дело более детально.

Допустим к нам пришло сообщение от клиента — внешнее входящее сообщение. Если мы подтверждаем клиенту его получение, то неплохо бы гарантировать, что если в системе произойдет сбой, то системе сообщение не забудет — т.е. перед отправкой подтверждения, сообщение от клиента будет помещено в персистентное хранилище.
Collapse )
Monday, August 21st, 2017
8:54 pm
Мини-учебнег по распределенным системам/протоколам. FIFO и RPC
Допустим мы более менее определились с требованиями к распределенной системе. Чтобы их реализовать, в условиях когда могут быть отказы оборудования, да и сеть может доставлять сообщения в разном порядке, нужно предпринимать дополнительные усилия, что бы обеспечить целостность и восстановление после сбоев. Просто так оно с неба не упадет, хотя конечно уже есть немало библиотек, фреймворков и протоколов, которые помогают решать эти проблемы. Начнем детальнее разбирать проблему целостности. И в частности разберем зачем нам нужны FIFO каналы и казуальный порядок доставки сообщений, и можно ли обойтись без них.

Рассмотрим канал между двумя нодами. Пусть он не модифицирует сообщения, но может их терять, дублировать и доставлять в разном порядке. В частности, это может быть вызвано сбоями на сетевом уровне. Допустим мы послали два сообщения, во время передачи первого был сбой, а второе дошло без проблем. Ну и чтобы дослать первое, сетевой уровень допустим послал сообщение по другому маршруту, и оно дошло но позже. Ну и т.д.

Collapse )
1:26 pm
Мини-учебнег по распределенным системам/протоколам. Требования к распределенной системе
В конце предыдущего поста я (нестрого) вывел 5 основных проблем, которые нужно решить при создании распределенной системы. Вообще говоря, они не строгие и могут ослабляться - в зависимости от требований к системе. Скорее это просто спискок ключевых проблем, которые нужно обдумать при проектировании системы. Рассмотрим сперва какие могут быть требования к распределенной системе, а потом детальнее посмотрим как можно решать эти пять проблем и можно ли их решать в ослабленной форме (например, решение может предоставляться уже доступном протоколом типа там TCP, RPC и т.д.).

Я бы выделил три основных случая почему нам может понадобиться распределенная система: отказоустойчивость, производительность и распределенность в узком смысле. Под распределенностью в узком смысле, имеется в виду ситуация, когда нам по тем или иным соображениям надо разместить систему на разных устройствах в сети. Например, мы хотим обрабатывать клиентские запросы по стадиям/tiers: веп-сервер, апп-сервер, сервер БД. Это типовый паттерн организации распределенных вычислений, хотя, вообще говоря, группировка серваков/процессов по функциональности вовсе не есть обязательное условие. Но так может быть понятнее устройство, плюс требования к серверам у разных групп разные, плюс там настройки сети или там безопасность можно лучше регулировать (типа какие-нить серваки можно вынести в DMZ). Т.е. на практике это достаточно важное требование, что какие-то компоненты распределенной системы должны быть на физически разных компьютерах, и это не обязательно вызвано требованиями производительности и отказоустойчивы (хотя оно конечно может совмещаться). Поэтому я выделяю три вида требований, конечно же, они могут совмещаться. Рассмотрим их подробнее.
Collapse )
Sunday, August 20th, 2017
11:54 pm
Мини-учебнег по распределенным системам/протоколам. Модель распределенной системы
Перейдем все-таки к распределенным системам. Уточним сперва модель распределенной системы. Будем считать, что система состоит из набора нод/процессов, которые коммуницируют только передачей друг другу сообщений. Будем считать, что на каждой ноде работает ровно один процесс, т.е. будем игнорировать различие ноды и процесса(ов). Каждая нода может послать сообщение любой другой ноде (в том числе и себе). Также будем считать, что единственный источник недетерминизма в системе - это сеть. Т.е. результат обработки последовательности событий, определяется только последовательностью событий и исходным состоянием, и всегда одинаков. Т.е. можно восстановить систему после сбоя, восстановив консистентное состояние всех нод и подать на каждую ноду события в той же последовательности, что и до сбоя.

Недетерминизм же заключается в том, что сеть может доставлять сообщения в разном поряке от случая к случаю. Будем также считать, что содержимое сообщений не меняется. Также будем считать, что канал передачи сообщений между двумя нодами не теряет сообщений, не генерирует дубли и доставляет их в том, порядке, что их отправили (это несложно реализовать с помощью нумерации исходящих сообщений) - FIFO канал. При этом порядок доставки сообщений разным процессам (т.е. через разные peer-to-peer каналы) не определен.

Collapse )
Saturday, August 19th, 2017
9:31 pm
Мини-учебнег по распределенным системам/протоколам. Оптимизации компилятора и процессора
Итак у нас есть иерархия памяти: регистры процессора, несколько уровней кэшей, общая память одного компьютера - и, возможно, распределенная память в том или ином виде (условный memcached). Оно все нужно для оптимизации - доступ в локальную память сильно быстрее нежели уровнем ниже. Так что если мы будем все операции чтения и записи распространять по всей иерархии памяти, это будет очень медленно. Особенно в распределенном случае - другой компьютер может ведь и сдохнуть. А пока мы обнаружим что он слишком долго не отвечает... При этом основная часть кода все же однопоточная. Так что нужно обеспечить высокую производительность однопоточного кода, иначе теряется смысл во всей этой многопроцессорности и распределенности (впрочем это все равно актуально для отказоустойчивости).

Поэтому по умолчанию и компиляторы, и система исполнения да и процессор, полагают, что код исполняется в однопоточном режиме. Чтобы они считали по другому, им обычно нужно давать специальные указания. В однопоточном режиме же можно делать кучу всеразличных оптимизаций, которые нельзя делать в случае, когда другие потоки управления могут параллельно читать или писать в те участки памяти, которые читает и пишет программа. Соответственно, специальные указания процессору и компилятору позволяют сообщить, что те или иные участки памяти разделяются между процессорами, ну или те или иные куски программы лазают в память, в которую могут лазить другие потоки управления. Например, если мы захватили блокировку, то это одновременно неявное указание компилятору и процессору, что мы сейчас будем читать и писать разделяемые данные. Точно так же, освобождение блокировки - это "намек", что мы закончили работать с разделяемыми данными. Но могут быть и явные указания на разделяемые доступ к даннам - например volatile модификатор в Java.

Collapse )
8:15 pm
Мини-учебнег по распределенным системам/протоколам. Вычислительная модель
Прежде чем говорить об моделях консистентности памяти, нужно поговорить о вычислительной модели, чтобы понимать иерархию памяти в многопроцессорных и распределенных системах и о методах оптимизации. Оптимизации и иерархия памяти все усложняют, но к сожалению без них трудно достичь высокой производительности, т.е. смысл в многих процессорах в значительной мере теряется или вообще сходит на нет.

Начнем с программы и памяти. Программа - это набор инструкций. А память - хранилище данных, куда можно чего-то записать или прочитать. Инструкции программы манипулируют значениями в памяти. Но сама программа не есть активный компонент - она исполняется на физическом вычислительном устройстве (процессоре, ядре, виртуальном ядре в случае SMT), в некотором контексте, называемом поток управления.

Collapse )
[ << Previous 20 ]
About LiveJournal.com