Как стать автором
Поиск
Написать публикацию
Обновить
49.51

Распределённые системы *

Нюансы проектирования распределенных систем

Сначала показывать
Порог рейтинга
Уровень сложности

[Санкт-Петербург] Андрей Ершов — CRDT. Бесконфликтная синхронизация данных

Время на прочтение2 мин
Количество просмотров3.4K


Уже в этот вторник, 23 мая, после долгого перерыва, в офисе DINO Systems состоится встреча CodeFreeze с Андреем Ершовым, специалистом по распределенным системам. Тема встречи — CRDT. Бесконфликтная синхронизация данных.
Читать дальше →

Всё, что вы не знали о CAP теореме

Время на прочтение7 мин
Количество просмотров164K
Во время моего первого опыта работы с распределенными системами я постоянно сталкивался с некой CAP-теоремой, пришлось изрядно покопать, чтобы изучить и осознать её со всех сторон. Я не являюсь мастером баз данных, но надеюсь, что мое маленькое исследование мира распределённых систем будет полезно для обычных разработчиков. В статье я расскажу о том, что такое CAP, его проблемы и альтернативы, а также рассмотрим некоторые популярные системы баз данных через CAP призму.
Читать дальше →

Bucardo: Multimaster репликация

Время на прочтение7 мин
Количество просмотров27K
В процессе мучений перелопатил тонну статей и решил написать подробнокомментируемый мануал. Тем более, что информации по конфигурированию multimaster и на русском языке очень мало и она какая-то кусочная.

Немного вводной. Чтобы Bucardo заработал, мы должы:

1) Сказать ему какие базы-участники на каких серверах вообще существуют.

2) Сказать ему какие таблицы участвуют в репликации.

Внимание: если разработчики добавят в приложение новую таблицу, мы должны об этом сообщить bucardo. То же самое касается изменения схемы существующих таблиц.

3) Сказать ему какие группы таблиц существуют и какие таблицы попадают в какие группы. Группы нужны на тот случай, если между разными серверами надо реплицировать разные таблицы. Удобнее работать с группой, чем каждую отдельно указывать (очень похоже на группы в Nagios).

4) Сказать ему какие группы баз данных существуют. Цель — та же, что и для таблиц.
Читать дальше →

Кинетика больших кластеров

Время на прочтение10 мин
Количество просмотров5.5K

Краткое содержание


  1. Фатальная ошибка Мартина Клеппмана.
  2. Физико-химическая кинетика уделывает математику.
  3. Период полураспада кластера.
  4. Решаем нелинейные дифференциальные уравнения, не решая их.
  5. Ноды как катализатор.
  6. Предсказательная сила графиков.
  7. 100 миллионов лет.
  8. Синергия.

В предыдущей заметке мы подробно разбирали статью Брюера и его одноименную теорему. На этот раз займемся препарированием поста Мартина Клеппмана «The probability of data loss in large clusters».

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

Ответ приведен на этой картинке:
Читать дальше →

Страх и ненависть в распределённых системах

Время на прочтение21 мин
Количество просмотров81K


Роман Гребенников объясняет сложность построения распределённых систем. Это — доклад Highload++ 2016.

Всем привет, меня зовут Гребенников Роман. Я работаю в компании Findify. Мы делаем поиск для онлайн-магазинов. Но разговор не об этом. В компании Findify я занимаюсь распределенными системами.

Что же такое распределённые системы?

Мифы о CAP теореме

Время на прочтение13 мин
Количество просмотров33K

Введение


cap


Давно хотел написать про мифы о CAP теореме, но как-то все не доходили руки. Однако, почитав очередной опус, схватился за голову и решил разложить все по полочкам, чтобы в мозгах возникла стройная картина.


Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:


Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.

В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.


И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.

Читать дальше →

Тестирование распределенных систем, — интервью с Андреем Сатариным, Яндекс

Время на прочтение6 мин
Количество просмотров11K

Тестирование распределенных систем существенно отличается от тестирования централизованных. Немногие тестировщики могут похвастаться серьезными знаниями и опытом в этой области.

Я пообщался со спикером конференции Heisenbug 2016 Moscow Андреем Сатариным (twitter.com/asatarin). Андрей участвовал в проектах по тестированию в Mail.ru, в Лаборатории Касперского, в Deutsche Bank, а сейчас тестирует распределенные системы в Яндексе. Статья будет полезна не только людям, которые занимаются тестированием, но и разработчикам. Если вы ни разу не касались вопроса тестирования распределенных систем, добро пожаловать под капот.

Андрей Сатарин:

… они убивают ноды прямо в рабочее время и разработчики наблюдают за...
Читать дальше →

Асинхронная репликация без цензуры

Время на прочтение12 мин
Количество просмотров24K


Олег Царёв ( zabivator )


Есть мастер, мастер неожиданно упал, но система продолжает работать. Клиенты мигрируют на вторую базу. Нужно делать резервные копии базы. Если делать резервные копии на основной базе, мы можем получить какие-то проблемы производительности, увеличение времени отклика. Это плохо. Поэтому достаточно распространенный пример асинхронной репликации — это снятие резервной копии со слэйва. Другой пример — это миграция тяжелых запросов с мастера на слэйв, с основной базы на вторую. Например, построение отчетов.

Иногда бывает необходимо, чтобы приложение могло получать все обновления из базы и желательно в режиме реального времени. Этим занимается оpen source библиотека, которая называется libslave.
Читать дальше →

Эволюция структур данных в Яндекс.Метрике

Время на прочтение17 мин
Количество просмотров45K
Яндекс.Метрика сегодня это не только система веб-аналитики, но и AppMetrica — система аналитики для приложений. На входе в Метрику мы имеем поток данных — событий, происходящих на сайтах или в приложениях. Наша задача — обработать эти данные и представить их в подходящем для анализа виде.



Но обработка данных — это не проблема. Проблема в том, как и в каком виде сохранять результаты обработки, чтобы с ними можно было удобно работать. В процессе разработки нам приходилось несколько раз полностью менять подход к организации хранения данных. Мы начинали с таблиц MyISAM, использовали LSM-деревья и в конце концов пришли к column-oriented базе данных. В этой статье я хочу рассказать, что нас вынуждало это делать.

Яндекс.Метрика работает с 2008 года — более семи лет. Каждый раз изменение подхода к хранению данных было обусловлено тем, что то или иное решение работало слишком плохо — с недостаточным запасом по производительности, недостаточно надёжно и с большим количеством проблем при эксплуатации, использовало слишком много вычислительных ресурсов, или же просто не позволяло нам реализовать то, что мы хотим.
Читать дальше →

Большой ликбез: распределённые системы хранения данных в практической привязке для админов среднего и крупного бизнеса

Время на прочтение14 мин
Количество просмотров59K
Современные сети и дата-центры бодро шагают к полной и тотальной программно-определяемой схеме, когда фактически неважно, какое железо вы напихаете внутрь, всё будет на софте. У сотовых операторов это началось с того, что им не хотелось ставить по 20 антенн на дом (у них узлы переконфигурируются, меняют частоты и параметры просто обновлением конфига), а в дата-центрах сначала с виртуализации серверов, которая теперь мастхэв, а потом продолжилось и виртуализацией хранилищ.

Но вернёмся в Россию 2015 года. Ниже я покажу, как «из подручных средств» (x86 машин и любых «хранилок») сэкономить денег, повысить надёжность и решить ещё ряд типовых для сисадминов среднего и крупного бизнеса задач.


На этой схеме видны обе архитектуры, о которых пойдет речь. SDS — два красных контроллера в центре с любым бекэндом, от внутренних дисков до FC полок и облаков. И виртуальный SAN, на схеме Hyper-converged storage.

Самое главное:
  • Вам плевать, что за железо стоит: диски, SSD, зоопарк производителей, старые и новые модели… — всё это отдаётся оркестирующему софту, и он приводит это к той виртуальной архитектуре, которая вам нужна в итоге. Грубо говоря, объединяет в один том или позволяет нарезать как вам удобно.
  • Вам плевать, какие интерфейсы у этих систем. SDS построится сверху.
  • Вам плевать, какие функции ваши хранилки могли, а какие не могли (опять же, теперь они могут то, что надо: решает софт сверху).

Заодно рассмотрим пару типовых задач с конкретным железом и ценами.
Читать дальше →

Riak и Riak Search Yokozuna: Первое знакомство

Время на прочтение9 мин
Количество просмотров8.1K


В статье в ознакомительных целях рассматривается процесс создания простого хранилища простых текстовых документов на базе Riak версии 2.1.1 и организация поиска по ним с помощью Riak Search (Yokozuna). В качестве клиентской библиотеки используется официальный клиент для Erlang.

Для начала представим, что у нас есть огромное количество таких документов:
  • title — заголовок;
  • body — содержимое;
  • tags — тэги;
  • created_at — время создания;
  • smiles — количество смайликов (плюсиков, лайков, как хотите)

и огромное количество пользователей, желающих их изменять. Кому интересно, начнём.
Читать дальше →

Замечания о распределенных системах для начинающих

Время на прочтение14 мин
Количество просмотров31K
Здравствуйте все!

Пришло время рассказать вам о еще одной книге, которая вызвала у нас неподдельный интерес и серьезные дебаты.

Мы предположили, что и в сфере изучения алгоритмов для распределенных систем краткость — сестра таланта, поэтому проработка книги Уона Фоккинка «Распределенные алгоритмы. Понятный подход» является перспективным и благодарным делом, пусть даже объем книги — всего 248 страниц.



Однако, чтобы участвовать в опросе было интереснее, мы для начала приглашаем вас под кат, где находится перевод интереснейшей статьи Джеффа Ходжеса, описывающей самые разнообразные проблемы, связанные с разработкой распределенных систем.
Читать дальше →

MaidSafe — распределённая система хранения и обработки данных

Время на прочтение8 мин
Количество просмотров24K

MaidSafe – интересная распределённая система передачи и хранения данных. Мне понравилась эта идея и я захотел поделиться с общественностью. Компания MaidSafe зарегистрирована в Шотландии, и разрабатывает свой проект при поддержке спонсоров.

Обзор платформы


MaidSafe состоит из двух главных компонентов – сеть и клиентские приложения. Сеть находится в разработке, и планируется к выходу к концу 2014 года (уже доступны исходники для компиляции на github. Также готовятся к выпуску приложения, которые на примере покажут использование SAFE API и позволят всем создавать свои собственные приложения.
Читать дальше →

Ближайшие события

Несколько фактов о CAP-«теореме»

Время на прочтение4 мин
Количество просмотров17K
В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.
Читать дальше →

Плавный переход к распределенному интернету?

Время на прочтение5 мин
Количество просмотров19K
После прочтения этой статьи, и ее обсуждения возникли некоторые мысли по поводу возможного развития интернета в сторону независимости, децентрализованности и анонимности. С этими мыслями я и хочу познакомить вас, уважаемые пользователи сего замечательного ресурса.
Читать дальше →

Консенсус в распределенных системах. Paxos

Время на прочтение7 мин
Количество просмотров42K
В последнее время в научных публикациях всё чаще упоминается алгоритм достижения консенсуса в распределенных системах под названием Paxos. Среди таких публикаций ряд работ сотрудников Google (Chubby, Megastore, Spanner) ранее уже частично освещенных на хабре, архитектуры систем WANdisco, Ceph и пр. В то же время, сам алгоритм Paxos считается сложным для понимания, хоть и основывается он на элементарных принципах.

В этой статье я постараюсь исправить эту ситуацию и рассказать об этом алгоритме понятным языком, как когда-то это попытался сделать автор алгоритма Лесли Лэмпорт.
читать далее

Чек-лист преодоления CAP-теоремы

Время на прочтение2 мин
Количество просмотров6.9K
Итак, вы ☐ твитнули, ☐ написали в блог, ☐ опубликовали пресс-релиз, ☐ написали в комментариях о том, что знаете способ преодолеть CAP-теорему. Ваша идея не сработает. И вот почему:

☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается
☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой
☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему
☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)
☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)
☐ вы на самом деле построили нераспределенную систему

А особенно в ваших планах плохо следующее:
Читать дальше →

Кейт Матсудейра: Масштабируемая веб-архитектура и распределенные системы

Время на прочтение32 мин
Количество просмотров85K
Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

The Architecture of Open Source Applications (Volume 2)

Масштабируемая веб-архитектура и распределенные системы


Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.


Читать дальше →

Как устроена apache cassandra

Время на прочтение13 мин
Количество просмотров244K
Кассандра
В этом топике я хотел бы рассказать о том, как устроена кассандра (cassandra) — децентрализованная, отказоустойчивая и надёжная база данных “ключ-значение”. Хранилище само позаботится о проблемах наличия единой точки отказа (single point of failure), отказа серверов и о распределении данных между узлами кластера (cluster node). При чем, как в случае размещения серверов в одном центре обработки данных (data center), так и в конфигурации со многими центрами обработки данных, разделенных расстояниями и, соответственно, сетевыми задержками. Под надёжностью понимается итоговая согласованность (eventual consistency) данных с возможностью установки уровня согласования данных (tune consistency) каждого запроса.

NoSQL базы данных требуют в целом большего понимания их внутреннего устройства чем SQL. Эта статья будет описывать базовое строение, а в следующих статьях можно будет рассмотреть: CQL и интерфейс программирования; техники проектирования и оптимизации; особенности кластеров размещённых в многих центрах обработки данных.
Дорогу осилит идущий...

NoSQL базы данных: понимаем суть

Время на прочтение9 мин
Количество просмотров596K
В последнее время термин “NoSQL” стал очень модным и популярным, активно развиваются и продвигаются всевозможные программные решения под этой вывеской. Синонимом NoSQL стали огромные объемы данных, линейная масштабируемость, кластеры, отказоустойчивость, нереляционность. Однако, мало у кого есть четкое понимание, что же такое NoSQL хранилища, как появился этот термин и какими общими характеристиками они обладают. Попробуем устранить этот пробел.


Читать дальше →