Распределенные структуры данных [часть 1, обзорная]24.05.2017 19:03

Комментарии (7)

  • 24 мая 2017 в 14:54

    0

    ↑

    ↓

    А что если нужно, в реальном времени, обрабатывать информацию о 100 миллионах клиентов,
    когда датасет занимает 100Тб, а каждую секунду нужно совершить 100+ тысяч операций?
    Вряд ли это возможно, даже на самом крутом современном железе, а если и возможно — только представьте себе его стоимость!

    А не лучше ли использовать Hadoop Map Reduce, Spark или Hive/Pig для таких задач?

    • 24 мая 2017 в 15:15

      +1

      ↑

      ↓

      Все перечисленные системы накладывают ряд ограничений связанных с парадигмой Map Reduce.
      В случае же с набором, описанным в статье, таких ограничений нет.
      Я бы, даже, сказал что это совершенно разные подходы к решению совершенно разных задач :)

      Например, у вас есть сервер и 1000 бакноматов, вам нужно чтобы все они дождались инициализации сервера.
      Очень простое, с точки зрения дизайна, решение (в одну строку!):
      Вы можете на каждом из них ждать latch.await (), а на сервере сделать latch.countDown ().

      • 24 мая 2017 в 15:20

        0

        ↑

        ↓

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

        • 24 мая 2017 в 15:31 (комментарий был изменён)

          +1

          ↑

          ↓

          Я говорю не про вычисления, а именно про операции над данными.
          А операции бывают разные,
          Например, возьмем, все те же, 1000 банкоматов и раз в час нужно разыграть приз — первый кто оплатит на сумму больше тысячи — победитель.
          Подвох в том, что человек должен узнать что он победитель сразу после завершения операции,
          Возможны ли подобные гарантии/способы синхронизации на описанных технологиях?

          • 24 мая 2017 в 15:40

            +1

            ↑

            ↓

            Тогда не понятно, зачем это должно обрабатываться одним кодом на сервере и банкоматах? Чем клиент-серверная архитектура не устраивает? Тем более что тысяча банкоматов для одного сервера — вообще не проблема. Может приведете более актуальный пример?

            • 24 мая 2017 в 15:47 (комментарий был изменён)

              +1

              ↑

              ↓

              Да, продолжим с 1000 банкоматов.
              С каждого из них может поступить запрос на перевод денег, но заранее известно что можно совершать не более 20 переводов одновременно (ограничение в договоре с платежной системой).
              Представим также, что сервер у нас не один, а 10 и к каждому из них приписано по 100 банкоматов.

              вариант

              semaphore.acquire ();
              doPayment (acc1, acc2, amount);
              semaphore.release ();

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

              • 24 мая 2017 в 15:49

                +2

                ↑

                ↓

                Вот теперь стало понятнее, спасибо

© Habrahabr.ru