В октябре 2011 года в Москве проходила ежегодная конференция разработчиков высоконагруженных проектов HighLoad++. 
Данный текст — продолжение серии статей, в которых я рассматриваю структуру (предположительно) готовящейся к выходу в этом году распределенной сети Telegram Open Network (TON). В предыдущей части я описал её самый базовый уровень — способ взаимодействия узлов между собой.
На всякий случай напомню, что к разработке этой сети я отношения не имею и весь материал почёрпнут из открытого (хотя и непроверенного) источника — документа (ещё к нему есть прилагающаяся брошюра, излагающая вкратце основные моменты), появившегося в конце прошлого года. Объем информации в этом документе, на мой взгляд, свидетельствует о его подлинности, хотя никаких официальных подтверждений тому нет.
Сегодня посмотрим на основной компонент TON — блокчейн.
Для начала — определимся, что в принципе подразумевает термин, звучащий, как шардинг.
Введение
В большинстве современных протоколов блокчейна каждый участник цепи скачивает и проверяет каждую транзакцию. Это естественным образом ограничивает сверху количество транзакций, которые протокол может выполнять за единицу времени: не больше, чем может скачать и выполнить средний участник цепи.
Ключевая идея шардинга заключается в том, что вместо того, чтобы каждая транзакция в сети была выполнена каждым участником, только подмножество участников выполняют каждую транзакцию. Для достижения этой цели все состояние цепи (аккаунты, контракты, данные) разбиваются на несколько непересекающихся интервалов, которые называются “шардами”; каждый участник сети назначается на один или больше шардов, и скачивает и выполняет только транзакции, относящиеся к своим шардам.
Когда участникам сети приходится взаимодействовать с шардом, на который они не назначены, они в общем случае не могут получить и проверить всю историю этого шарда.
Это приводит к потенциальной проблеме: без загрузки и проверки всей истории участник не может быть уверен, что состояние, с которым он взаимодействует, — это результат валидной последовательности блоков и что такая последовательность действительно является канонической цепочкой в этом шарде. В прошлой статье я показывал, почему этой проблемы нет в нешардируемых блокчейнах.
Сначала мы разберем простое решение этой проблемы, которое предлагают многие протоколы, затем проанализируем, как оно может быть скомпрометировано, и опишем, какие способы устранения этой проблемы предлагаются, их сильные и слабые стороны.
МойОфис продолжает цикл публикаций (1, 2) о разработке корпоративной почтовой системы нового поколения Mailion, которая реализуется при грантовой поддержке РФРИТ. В состав Mailion входит объектное хранилище DOS; в предыдущей статье мы рассмотрели его общую архитектуру и ключевые оптимизации, повышающие экономическую эффективность хранения данных. Сегодня мы переходим к одной из самых сложных и увлекательных тем в области разработки баз данных — проблеме масштабирования.
А не пора ли нам шардить коллекции?
Не-е-е:
В принципе, для большинства проектов вcё оправдано. Это может быть еще прототип или круг пользователей ограничен… Да и не факт, что проект вообще выстрелит.
Откладывать можно сколько угодно, но если проект не просто жив, а еще и растет, то до шардинга он доберется. Одна беда, обычно, бизнес логика не готова к таким "внезапным" вызовам.
А вы закладывали возможность шардинга при проектировании коллекций?
Эта статья для продвинутых разработчиков.
Для тех, кто планирует шардинг своего кластера.
Для тех, кто уже шардировал кластер ранее, но админы все еще плачут.
Для тех, кто руками перемещал jumbo-чанки.
Сначала, мы будем учится жить со слонами.
Потом, мы их победим, но не сможем вернуться назад.
"Размышления без практики приводят к заблуждению, практика без размышления приводит к затруднению."
Мы ведём войну с индивидуальностью у шардов в кластере MongoDB. Это продолжение статьи Шардинг от которого невозможно отказаться, а это значит, что наступила пора конкретики.
Как я и обещал, здесь мы рассмотрим подробнее:
В этой статье мы запустим кластер InterSystems IRIS с помощью docker и файлов Merge CPF (CMF) — новой функции, позволяющей легко конфигурировать серверы InterSystems IRIS. В UNIX и Linux вы можете изменить стандартный iris.cpf с помощью декларативного файла Merge CPF. Файл Merge CPF — это частичный CPF, который устанавливает нужные значения для любых параметров при запуске InterSystems IRIS. С помощью Merge CPF легко можно запускать сложные конфигурации InterSystems IRIS.