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

mayton2019

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

  • Как правильно разрабатывать гибкую клиент серверную архитектуру и делать клиент серверные игры на Godot?

    mayton2019
    @mayton2019
    Bigdata Engineer
    По игровым технологиям тут нечего добавить. Все выглядит вполне себе норм.

    По поводу Mongo. Я-бы предложил ее заменить на что-то другое. Монга хороша для проектов
    где изначально не известна схема документа и надо грузить все что есть и как есть.
    При этом через некоторое время есть риск получить просто свалку документов где никто
    не знает схему данных. Или будет несколько параллельно живущих вариантов схем что
    само по себе не лучше.

    Если вы точно знаете схему (вы разрабатываете игру и весь игровой мир, инвентарь и локации)
    то вы точно знаете что у вас будет где лежать. Вообще для игр лучше брать любую key-value
    для которой есть API/ABI. Они все подходят.
    Ответ написан
    3 комментария
    3 комментария

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

    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 комментария