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

mayton2019

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

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

    mayton2019
    @mayton2019
    Bigdata Engineer
    Я знаю два сильных пути оптимизации в БД.

    1) Минимизация IOps. Тоесть уменшить число дисковых чтений. Для таблиц это достигается через
    partitions by date. Вычисляешь экспериментально оптимальный размер partition (например 1 неделя).
    И твои запросы по диапазону должны попадать в 1-2 partitions. Это исключает full-table-scan.
    Ну и индекс попробуй построить по предикатам фильтров.

    2) Материализация ответов. Для данных которые уже не будут изменяться ты строишь где-то такую
    табличку (матрицу по сути) где хранишь уже заранее расчитанные данные. Эта технология по разному
    может называться. Materialized View. OLAP cubes. Витрины данных. Но суть одна. 

    start_date    end_date     result 
01-02-2023    03-02-2023   { "1":"65", "2":"45" }


    И индекс по двум датам.
    Ответ написан
    Комментировать
    Комментировать

  • Фильтр по части строки?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Значит сразу скажу что у меня для вас - плохие новости. DynamoDb как и многие ему подобные облачные key-value решения расчитаны на выборку по сету ключевых полей. Обычно это хеш-ключ и ключ диапазона. В этом случае вы платите немного. Если вдруг вы решили выбирать по не-ключевым полям это уже будет другое тип запроса. Называется scan. Его можно писать на любом языке разработки но суть в том что будет выбрана ВСЯ таблица. Если она большая - то charge за текущий период вас неприятно удивит. Фиксить это почти невозможно. Это неправильный дизайн и неправильное использование AWS Dynamo. Вам следует вообще отказаться от использования Dynamo и думать над тем как НЕ делать сканов в будущем. Можете теоретически создать индекс по хвосту от строки. Но индекс с точки зрения Динамо - это копия таблицы просто по другому расположенная и реплицируемая. Вобщем не советую тоже.
    Ответ написан
    3 комментария
    3 комментария

  • Почему не используют NoSql решения на каждого пользователя?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Я думаю что твоя идея не лишена смысла. Можно на каждого пользователя поднимать экземпляр БД.
    Что здесь хорошо изоляция и безопасность. Что здесь плохо обилие linux-процессов на каждого пользователя. Например если у тебя чат на 10 000 человек - то поднять столько-же процессов на одном хосте сложнее. Любые операционки имеют какой-то минимальный футпринт памяти и ресурсов ОС на процесс. И переключение. Планировщик будет бегать между 10 тыщ процессов обслуживая их события. Что еще может быть плохо. Администрирование этого грида приложений. Бэкап проще делать имея 1 сущность процесса и 1 лог ошибок. А что делать с 10 тыщами логов. Отвественый девопс должен как-то просмотреть все логи? Или уже начать писать автоматизацию бэкапов. Кажется пустяк - но ты сядь и просто попробуй сам это сделать. Или мониторинг. Как проверить что все 10 тыщ не содержат в логах ошибок?

    Вообще маппинг между приложениями и БД всегда идет сложным образом. Обычно m : n. И очень редко удается сделать 1:1 или как-то по другому.
    Ответ написан
    2 комментария
    2 комментария