Задать вопрос
mayton2019

mayton2019

Bigdata Engineer
Ответы пользователя по тегу Highload

  • Что выбрать в качестве промежуточного хранилища в проекте?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Идея выгрузить все в Redis провалилась, так как на более 120К записей поиск начал тормозить сильнее прямого запроса к БД.

    Нужно более подробно изучить этот кейс. В момент "торможения" что происходило? Шла выгрузка?
    Redis упал в swap? Дело в том что структуры данных Redis спроектированы так что дают
    постоянный отклик почти на любом объеме данных лишь бы хватало памяти. Этот эффект
    который вы поймали говорит скорее всего о неверном использовании.

    Попробуйте value хранить в разных форматах. В JSON. В бинарном (protobuf). В gzip. Оптимизируйте
    бизнес данные. Я всегда находил способы не хранить длинные url. И заменить их на что-то.

    В качестве промежуточного хранилища можно использовать много чего. Apache Ignite, Hazelcast,
    LevelDb, RocksDb, CouchDb, Riak    . Но мне кажется что проблема ваша не в том какую
    dbms взять а как грамотно реплицировать бизнес-данные в слой кеширования.

    Поговорите с бизнесом какое отставание кеша от данных является приемлемым и исходите из этого.
    В некоторых случаях отставанее в сутки является норм. А иногда даже милисекунда - уже нельзя.
    Ответ написан
    Комментировать
    Комментировать

  • Какие есть инструменты и решения для экстремально быстрой online-аналитики потоковых данных?

    mayton2019
    @mayton2019
    Bigdata Engineer
    При расчете аналитики (min/max/avg) и прочих оконных функций сам алгоритм имеет лаг.
    Тоесть ты должен понимать что за 1 мс ты можешь анализировать данные в прошлом за окно
    размером к примеру в 100мс.

    Нельзя выводить точную аналитику на основе мгновенного значения.
    Ответ написан
    5 комментариев
    5 комментариев

  • Как лучше организовать очередь сообщений для их разбора по графику?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Я-бы разобрался с дублями. Если есть система которая продуцирует их - то наверное можно
    как-то решить этот вопрос на уровне источника. Это performance issue который нужно обусждать.

    Можно строить всякие архитектуры на базе очередей или идемпотентных баз но при этом главная
    причина (сетевой траф) будет непофикшена а по сути спрятана под ковер.
    Ответ написан
    4 комментария
    4 комментария

  • Какие можно почитать ресурсы для создания распределенных, реплицируемых, высокопроизводительных приложений?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Тема хорошая. Только вот градус амбиций я-бы сбросил. Попробуй просто написать сокетное приложение
    которое передает события из точки А в точку Б. И придумай механизм персистенции. И балансировщик. И кластер. Да. правильно написал про Raft. Не только Raft. Еще есть Paxos используется в Cassandra. И централизованный ZooKeeper.

    Где почитать - я даже не знаю. Спектр технологий такой широкий. Тут и сети. И многозадачность. И хранение информации.

    Кстати Кафки в дефолтной комплектации почти не бывает. Каждый кастомер конфигурирует для себя регуляторы скорость-надежность. Влево-вправо. Понимаешь? Поэтому до того как "убивать" Кафку надо просто понять что любое ее нагрузочное тестирование просто ставит другие вопросы. А что собстенно вы ходите. Доставить опционально но быстро. Или с гарантией что месседж сохранился. Или с гарантией что сохранился в основной кластер и в реплику. Каждый кастомер еще для себя придумывает partitioning strategy что является очень важным аспектом скорости Kafka. Тоесть еще до бенчмарка нужно все эти вопросы проговорить. Иначе выйдет сравнительное тестирование "бульдога" и "носорога". И любая система которая будет быстрее Кафки на самом деле будет просто системой заточенной на более узкие условия. Это как узкий UDP может быть быстрее чем TCP но ... как говорил Василий Иванович есть один "нюанс".
    Ответ написан
    Комментировать
    Комментировать

  • Как устроен поисковый индекс Google?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Google использует шаблон map-reduce. Это когда исходная выборка (индекс) может быть разрезана на беконечно большое число partitions. Можно резать по хешу от hostname. Это дает возможность запускать ваш поисковый запрос не на 1 хосте а сразу на 1000 hosts и потом просто выдать сортированный union первых top n релевантных результатов. Кроме того google может кешировать ответы. Это снижает нагрузку на дубли поисков.

    Этот шаблон известен. Просто google первый поставил задачу отказа от сверх-дорогих и ресурсоёмких серверов и перешел к использованию множества дешевых серверов но соединенных в поисковый grid. Кроме того файловые системы навроде hdfs дают возможность на обычных жлобских HDD делать бесконечно большую файловую систему. У этой ФС конечно есть недостатки. В частности она может быть не консистентна. Но для периодически обновляющегося текстового индекса - это норм. Типа eventual consistancy.
    Ответ написан
    Комментировать
    Комментировать

  • Как выбрать базу данных?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Есть такая старая поговорка из тайм-менеджмента - "что СРОЧНО - то не важно".

    Если есть некий источник который продуцирует записи со скоростью 10к в секунду и мы хотим писать их сразу (мгновенно) то наверное у нас есть такой-же потребитель который так-же быстро способен их потребить.

    А есть вообще такой? Мне сложно себе представить. Если это биг-дата со стримингом - то там надо использовать не постгрес а другие системы. Kafka+Spark например. Но я не буду давать таких советов потому что люди обычно сидят на консервативных системах типа реляционок и хотят делать на них все. Просто им так удобнее.

    Давайте немного арифметики. Если мы формируем 10к в секунду то за сутки у нас набегает 10000L * 60 * 60 * 24 = 864 000 000 или восемьсот миллионов строк. Это вот если загрузка будет постоянно такая.
    Ответ написан
    Комментировать
    Комментировать