Местоположение
Польша, Krakow, Krakuszowice

Достижения

Все достижения (69)

Наибольший вклад в теги

Все теги (503)

Лучшие ответы пользователя

Все ответы (2482)
  • Что эффективней, чтение из файла или массив?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Вопрос не глупый а вполне себе хороший.

    Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
    1) Пока памяти хватает (массив) - используй смело память
    2) Диск - больше и дешевле памяти
    3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
    Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
    4) Разные диски имеют скорость на порядки разную.
    5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
    Ее очень любят обсуждать админы баз данных.
    6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
    7) Диск - переживает выключение питания.
    8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
    9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
    SQLite например.
    10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
    при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
    для журналирования событий.

    В принципе если современный программист просто будет использовать только оперативную память
    то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
    сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
    могут быть каким-то значимым аргументом.
    Ответ написан
    3 комментария
  • Хорошая ли стратегия разбивать монолит джанго на микросервисы джанго?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
    Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
    или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
    проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
    Конвей про это писал еще.

    И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
    тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
    того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
    перформанса
    . Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
    накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
    на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

    И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
    И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

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

    Но имеет смысл сделать модуляризацию монолита. Например что там...
    application
    - sales
    - hiring
    - userprofiles

    Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
    контроль за изменениями.
    Ответ написан
    6 комментариев
  • Зачем надо закрывать курсор при работе с БД?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Дело в том что курсор может потреблять ресурсы. Например вы захотели взять первые 10 строк из 10000000 выборки но предварительно отсортировали. Выбрали 10 строк и не сделали финализирующие протокольные действия в Python. База данных будет удерживать в памяти алгоритмы и структуры данных для снапшота результата этого запроса до тех пор пока не придет явный CLOSE с вашей стороны либо интеллекуальный драйвер который еще и обладает логикой уборки мусора сам не догадается что Statement уже вышел из scope вашего использования и может быть удалён GC.

    Я был свидетелем ситуации когда крупное ent-приложение Java/Oracle переполняло память из-за неверной обработки Exception и плодила много незакрытых курсоров в БД. Java от этого не сильно страдала (GC всё убирал) но страдал Oracle. Потому что уборка происходила слишком поздно. Пофиксилось тогда переписыванием с try на try-with-resources.

    Поэтому если вы неряшливо обращаетесь с курсорами (явными и неявными (обычный select к примеру может прождать неявный курсор)) то не ваше приложение а база данных почувствует себя плохо. Как быстро и какие ошибки вы будете получать - зависит от настроек вашей БД.
    Ответ написан
    Комментировать
  • В чем можно хранить около триллиона значений key=>value?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Давайте прикинем объем который понадобится. Что такое триллион?
    Это 12 нулей. Или 1 000 000 000 000 элементов. Какая у нас data-row?
    8 + 64 символов типа ASCII (байт подходит чтоб покрыть все символы).
    Итого 72 байта на строку. Там можно еще поужимать биты в байтах но только
    сложность повышает а большой пользы для дела не дает. Пускай будет ASCII == 1 байт.

    Вобщем такой расчет

    72000000000000 байтов на весь сегмент данных когда таблица загружена.
    Или 65 терабайт. А сколько магнитных блинов надо прикупить? Возьмем популярный магнитный
    Western Digital Purple 10TB 7200rpm 256MB WD102PURZ 3.5" SATA III при цене 290$
    Порядка 7 штук надо. Вобщем готовте котлету денег 290$ * 7 = 2030$

    По поводу DBMS. Да key-value здесь подходит. Можно начинать с LevelDb или RocksDb но у них
    расход дисковой памяти на 1 строчку может быть больше чем я посчитал. Я ведь считал эконом-эконом
    вариант в виде бинарного типизированного файла где все записи строго по 72 байта. Сколько именно
    захватит РоксДб или ЛевлДб - чорт его знает. Вряд-ли документация об этом что-то говорит.
    Но берите 1% датасета. Загружайте
    и аппроксимируйте сколько выйдет после полной прогрузкуи. Это - надежный способ оценки.
    Ответ написан
    12 комментариев
  • Почему современные языки отказываются от ООП?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Они не отказываются. Скорее происходит отказ от "парадигмы" разработки. Языки стали мульти-парадигменные. Посмотрите на С++20 или Scala. Их невозможно положить в коробочку ООП или ФП. В них есть почти полный набор фич и оттуда и отсюда. И с каждым годом число фич растет и граница размывается. Нашим потомкам будет вообще непонятно где идет раздел.

    По поводу golang. Это язык ограниченной разработки. Его создавали специально чтобы порог вхождения был низкий. Фактически делали лайтовый С++ которому можно обучить школьника за 14 дней. Но с перформансом выше чем у Питона. Поэтому выражать какие-то сложные конструкции на типах там скорее всего не получится. У golang есть свой манифест. Я забыл как он называется и где он. Вобщем там довольно четко обоснованно почему такие принципы и почему такая идеология.
    Ответ написан
    1 комментарий

Лучшие вопросы пользователя

Все вопросы (23)