• Автоматическое разрешение конфликтов с помощью операциональных преобразований

      image

      Автоматическое разрешение конфликтов в среде с более, чем одним ведущим узлом (в данной статье под ведущим узлом понимается узел, который принимает запросы на изменение данных) – очень интересная область исследований. Существует несколько различных подходов и алгоритмов, в зависимости от области применения, и в данной статье будет рассмотрена технология Операциональных Преобразований (Operational Transformations, OT) для разрешения конфликтов в приложениях совместного редактирования, таких как Google Docs и Etherpad.
      Читать дальше →
    • Релиз Apache Ignite 2.5 — Memory-Centric Distributed Database and Caching Platform

        В мае вышла новая версия Apache Ignite — 2.5. В неё внесено множество изменений, с полным списком которых можно ознакомиться в Release Notes. А в этой статье мы рассмотрим ключевые новшества, на которые стоит обратить внимание.

        Apache Ignite — горизонтально масштабируемая платформа транзакционного хранения данных, а также распределенных вычислений поверх этих данных в режиме, близком к реальному времени.

        Ignite применяют в тех случаях, когда нужна горизонтальная масштабируемость и очень высокая скорость обработки данных. Последнее достигается также за счет оптимизации платформы под хранение данных непосредственно в RAM в качестве первичного хранилища, а не кеша (In-Memory Computing). Отличительными особенностями продукта являются полноценный движок запросов ANSI SQL 1999, дисковое хранилище, расширяющее RAM, большое количество встроенных интеграционных инструментов и Zero-ETL машинное обучение.

        Среди компаний, которые используют Apache Ignite такие фирмы, как Veon/Beeline, Сбербанк, Huawei, Barclays, Citi, Microsoft и многие другие.

        Новый вариант топологии: звезда вокруг ZooKeeper


        Одно из главных изменений в версии 2.5 — новый вариант топологии. Ранее в Ignite была лишь топология «кольцо», которая использовалась для обмена событиями внутри кластера и обеспечивала эффективную и быструю масштабируемость, на масштабе до 300 узлов.

        Новая топология предназначена для инсталляций из многих сотен и тысяч узлов.
        Читать дальше →
        • +20
        • 1,4k
        • 2
      • Периферийные вычисления: товарищеский матч «тумана» с «облаками»

          Один из главных трендов развития информационных технологий в последние 20 лет – перенос сложных вычислений с локального компьютера на удаленные серверы, которые соединены с ним через компьютерные сети. Начиналось всё с концепции «сетевого компьютера», которая затем переросла в облачные вычисления.

          И вот после этой логичной технологической эволюции мы снова слышим разговоры о том, что часть вычислений лучше всё-таки переносить на локальные устройства. Речь идёт о так называемых периферийных вычислениях, или Edge Computing. Что это — дальнейшее развитие технологий или разворот назад?
          Читать дальше →
        • Митап Сбербанка и IBM на тему HyperLedger Fabric

            Привет, Хабр!

            Вместе с нашими друзьями из IBM приглашаем на митап, где подробно расскажем про HyperLedger Fabric. Ждём всех: разработчиков, архитекторов, инженеров и просто тех, кто хочет разобраться, как работает Fabric.


            Читать дальше →
          • Выбрать мониторинг ДГУ легко!.. Или нет?

              Увы, но ответ неоднозначный – и да, и нет. Выбрать-то, конечно, легко, но запутаться еще проще. Так вот, о том, как не запутаться, и пойдет речь.

              ДГУ у вас или другое оборудование — универсального решения по дистанционному мониторингу и управлению, которое подходит всем, умеет все и стоит дешево, не существует. Ограничения есть всегда. Один вариант предлагает скудный набор функций, но за копейки, другой наоборот – требует высокой цены, но за большие возможности. А между ними будут бесчисленные вариации, сочетающие в себе функциональность и цену в разных пропорциях. И кажется, что можно легко потеряться в этом море решений. Хотя…



              Но на самом деле все проще, ведь вариантов решений всего 3, и в них можно разобраться.

              Читать дальше →
            • Нужен ли Вам Блокчейн? Управление цепочками поставок

              Привет Хабр! Предлагаю вашему вниманию перевод статьи «Do you need a Blockchain»

              Часть 1 (Управление цепочками поставок)


              Блокчейн был представлен как технологическая инновация способная привести к революции в общественных отношениях и торговле.Эта репутация частично относится к его свойствам позволяющим недоверяющим друг другу сторонам взаимодействовать и меняться финансовыми активами не опираясь на доверенную третью сторону.

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

              Мы различаем публичные (permissionless) Bitcoin \ Ethereum, и частные (permissioned) Hyperledger \ Corda блокчейны и противопоставляем их свойства свойствам централизованно управляемых баз данных. мы покажем структурированную методику для определения оптимальных технических подходов при решении конкретных прикладных задач. мы проанализируем три случая — Управление цепями поставок (Supply Chain Management), межбанковские и международные платежи (Interbank and International Payments), и Децентрализованные автономные организации (Decentralized Autonomous Organizations).
              Читать дальше →
            • Ой, у вас баннер убежал!

              Ну. И что?
              Реклама
            • Как Pusher Channels доставил уже 10.000.000.000.000 сообщений

              • Перевод

              Привет! Недавно я натолкнулся на довольно интересное описание архитектуры Pusher Channels и решил его перевести для вас. На мой взгляд, автор очень доступно описал подходы к построению высоконагруженной и масштабируемой архитектуры. Скорее всего, статья будет полезна новичкам, а также специалистам из смежных областей.


              В офисе компании Pusher у нас висит небольшой счетчик с постоянно увеличивающейся цифрой. Он показывает количество доставленных сообщений за всё время существования Pusher Channels. В пятницу в 22:20 по UTC число увеличилось на один разряд и достигло 10.000.000.000.000. В нём 13 нулей — 10 трлн.



              Вы можете подумать, что счётчик общего количества сообщений — бесполезная кичливая метрика. Но это число — ключевой индикатор успеха Pusher Channels, нашего продукта для коммуникации в режиме реального времени. Во-первых, данный счётчик отражает доверие, оказанное нам пользователями. Во-вторых, он измеряет масштабируемость нашей системы. Чтобы цифра увеличивалась, мы в Pusher должны сделать так, чтобы пользователи доверяли отправку сообщений нашему сервису, и мы должны быть уверены в том, что наша система способна обработать эти сообщения. Но что нам стоит доставить 10 трлн сообщений? Давайте посмотрим.

              Читать дальше →
            • LLTR Часть 0: Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима?

              КДПВ: LLTR Часть 0 - пневмотранспорт из Футурамы


              Как построить топологию сети на канальном уровне, если в нужной подсети используются только неуправляемые свитчи? В статье я постараюсь ответить на этот вопрос.


              Начну с причины возникновения LLTR (Link Layer Topology Reveal).


              У меня был один “велосипед” - синхронизатор больших файлов “на полной скорости сети”, способный за 3 часа целиком залить 120 GiB файл по Fast Ethernet (100 Мбит/с; 100BASE‑TX; дуплекс) на 1, 10, 30, или 200 ПК. Это был очень полезный “велосипед”, т.к. скорость синхронизации файла почти не зависела от количества ПК, на которые нужно залить файл. Все бы хорошо, но он требует знания топологии сети для своей работы.


              Подробнее в статье про него:

              Ладно, а зачем понадобилось “гонять” 120 GiB файл по сети на такое количество ПК?

              Этим файлом был VHD с операционной системой, программами, и т.п. Файл создавался на мастер‑системе, а затем распространялся на все остальные ПК. VHD был не только способом доставки системы на конечные ПК, но и давал возможность восстановления исходного состояния системы при перезагрузке ПК. Подробнее в статье: “Заморозка системы: история перехода с EWF на dVHD”.



              Можно продолжить цепочку дальше, но на этом я прервусь.


              Существующие протоколы обнаружения топологии канального уровня (LLDP, LLTD, CDP, …) для своей работы требуют соответствующей поддержки их со стороны всех промежуточных узлов сети. То есть они требуют как минимум управляемых свитчей, которые бы поддерживали соответствующий протокол. На Хабре уже была статья, как используя эти протоколы, “определить топологию сети на уровнях 2/3 модели OSI”.


              Но что же делать, если промежуточные узлы – простые неуправляемые свитчи?


              Если интересно как это можно сделать, то добро пожаловать под кат. Обещаю наличие множества иллюстраций и примеров.

              Читать дальше →
            • Гетерогенная конкурентная обработка данных в реальном времени строго один раз

                Конкурентная сосиска


                Аннотация


                Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.


                Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.


                Введение


                Разработчик распределенных систем проходит несколько стадий:


                Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.


                Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.


                Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

                Читать дальше →
                • +23
                • 5,4k
                • 4
              • The Messenger of Everything

                  У всех существующих мессенджеров есть свои плюсы и минусы, но каждый из них тянет одеяло на свою сторону из-за несовместимости с другими – и от этого страдают пользователи.


                  Единым стандартом мог бы стать XMPP, но он, в отличии от E-Mail, появился относительно поздно и не успел набрать достаточную аудиторию, чтобы корпорации не могли уже от него отказаться. Ведь там быстро поняли, что без удержания аудитории внутри собственной экосистемы много не заработать. Да и кроме того, надо признать, у XMPP было достаточно недостатков из-за обилия расширений, многие из которых, несмотря на свою важность, оставались в экспериментальном статусе, а какие-то и вовсе дублировали друг друга.


                  Пожив в «новом дивном мире» десятка мессенджеров в смартфоне, и ощутив все недостатки такого положения дел, мы наконец готовы к чему-то новому.


                  И да, нам нужен новый стандарт!

                  Читать дальше →
                Самое читаемое