mayton2019

При данной постановке - безразлично где хранить. Можешь их писать в текстовый файл в формате даты + IP адреса.
Можешь писать в БД. Никто не скажет где здесь оптимум.

Пока ты сам не придумаешь какие запросы будут по этому хранилищу. И как долго ты согласен ждать выдачи
ответа. Вот с этого момента уже можно обсуждать Базы или форматы бигдаты.

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

На протяжении 20 лет я наблюдаю за базами данных и механизмами стриминга событий, слежениями
и прочее. Так вот. Это все НЕ РАБОТАЕТ. Не работает по причине идеологии ACID. Вы не можете операцию
DML считать основанием для генерации события. Потому что DML это не транзакция. Если мы фиксируем
DML commit/rollback операцией - то при этом неочевидно что должна видеть стриминговая платформа.

Она не может откатывать события в обратную сторону. Такой механизм технически дорог. Поэтому
основанием для стриминга событий может быть только событие внутри приложения. PHP, Node, Java e.t.c.
вот там и генерируйте события.

А база данных здесь вообще не помошник. Сканировать таблицу по скедулеру тоже не надо. Это дорого
и не реал-тайм.

В базах данных для обеспечения уникальности используются sequence.

UUID возникает в распределенных системах где нет координации между нодами кластера но
нужно хоть каким-то образом получить уникальность. Плюс там еще есть 4 типа этих UUID
или 4 разных алгоритма как они получаются.

Все это пока к безопасносни не имеет никакого отношения. Это просто продиктовано физической
архитектурой (1 база или кластер).

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

Нет запрета на использование маппингов на фронте. Но я-бы дополнительно проверил
что пользователь не имеет возможности каким-то образом влиять на этот маппинг
всякими инжекциями и попытками сломать логику и создать security issue.

Обыно для крупных проектов нет проблем с хранением DTO/Entities на многих слоях приложения.
Только тебе надо подняпрячся и один раз создать некий стандарт на хранение маппингов. Можно
даже не в коде а в виде json/yaml и использовать эти DSL для генерации кода на все другие слои.

А можно ли использовать отдельную табличку на hdfs для этих целей?

На самом деле вопрос звучит неправильно. HDFS это просто биг-датавская файловая система
и ей безразлично таблички на ней лижат или вообще какие-то рандомные файлы.

Для стриминга информации действительно подходит связка Graphana + Prometeus + InfluxDb.
Но тут дальше непонятно какой-такой посредник тебе нужен. Такие посредники существуют
для Kafka/Cassandra и они называются коннекторы. Они льют информацию из очереди
в таблички и наоборот (там есть правда условие). Но опять-же твою постановку надо грумить
очень глубоко вплоть до объемов данных и лагов и условий чтобы понять что на самом деле надо.

На hdfs есть табличка (обычно дергаю из неё данные в hive).

По роду постановки - это очень близко к микро-батчингу или стримингу. Но я пока не вижу
какой стек ты используешь. Обычно к стримингу ближе идут Spark/Databricks/Flink/Storm.
У них хотя-бы существует терминология стриминга. Вот а hive - это точно не про стриминг.

Колонки нельзя называть цифрами. Обычно дают имена начиная с латинских букв. id, c1, c2 например.
тогда
SELECT c2 WHERE id = 1
выдаст
C
Вообще твой вопрос не про базы данных а про матрицы в программировании. По крайней
мере ту картинку что ты нарисовал в чистом виде в БД никто не кладет.

А где проблема вообще? Ну будет 2 нотификации. Но они ведь нацеленные на своего потребителя?
Тот кому надо их и прочитает. Или тут экономят сетевой трафик? Короче непонятно.

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

Делай как тебе проще код писать. Наперед ни один архитектор не знает как лучше. Улучшение - это процесс итеративный. Но сначала тебе нужно поймать какой-то инцедент. Например performance issue. И уже начиная от этого улучшать.

Пока у тебя такого инцедента нет - делай максимально простой код и это будет правильное решение.

предполагается нагрузка на сервис где-то рпс 70-100к

c
Это не большая нагрузка. Oracle лет 20 назад заявлял 500K транзакций в секунду по результатам бенчмарков.

Данную задачу также можно решать со стороны CQRS / Event Sourcing. Тоесть посто фиксировать события гео-позиции в журналы (они могут быть распределенные) а потом уже накатывать в БД. Здесь я предполагаю что вам не требуется реал-тайм. (За 10 секунд вашего технического лага человек все равно успеет убежать за горизонт) и накинтье еще от 1 секунды до допустим 30 секунд время на фиксацию в основной БД. И получается система вполне себе почти реального времени. И в то-же время вам будет лего выдержать всплески информации и ничего не потерять.

Для выскоконагруженных интернет магазинов нет прямого доступа к категориям в БД.
Они (категории) кешируются на стороне приложения и NGinx.

Категории меняются редко. Ну вряд-ли в течение дня. Скорее всего на следующий день.
Поэтому форма хранения их в таблице должна выбираться из удобства внесения изменений.
Вот попробуйте Adjacency List. Самый первый и самый очевидный вариант.

И не надо быть перфекционистом и ковырять грязь из под ногтей. Просто потеряте кучу времени.

Семантические графовые базы данных скорее всего подходят под данную задачу. Типа RDF/Semantic Web.
В качестве языка запросов там могут быть использованы SparQL. В качестве платформы хранения.... а чорт
его знает. Там много форматов. И XML и JSON и есть бинарники и JDBC адаптеры.

Это вообще серебрянная пуля которая везде подходит. Даже реляционки можно также представить. Со своими
накладыми но можно.

Но есть несколько мыслей почему их применение может быть неудобным. Первая. Например - знания о том
как все внутри устроено - будут только у 1 человека. У создателя этой базы. И никто кроме автора
в этой базе ничего не найдет.

Вторая. В эпоху умных чятов такие базы знаний умерли очень быстро. Вернее сказать их полезность
сильно девальвировала. В 20м веке в такие базы много вкладывали. Делали ставку на то что системы
со строгими правилами позволят выводить новые правила и факты. Но не сбылось.

Возможно я ошибаюсь и автору нужно на самом деле другое? Что другое? Ну просто какой-то язык
разметки типа markdown language или вообще confluence где можно макросами расширить функционал
и просто делать ссылки на формулы. И может быть это автору будет достаточно.

Вобщем для более глубокого понимания хотелось-бы чтоб автор просто привел парочки примеров. Может
там реально все проще.

Для недорогих облачных хранилищ обычно используют
AWS/S3, MS-Azure BlobStorage, Google Cloud Storage.

Недостаточно информации. Обычно БД и модель таблиц затачиваются под типичный запрос.
Например. У нас есть публикации и и пользователи (те кто просматривают). Концептуально - это
матрица где по горзионтали - пользователи а по вертикали публикации. Если рассматривать во времени
то появляется третье измерение (куб) - ось времени. Где можно делать срез за последний день
или неделю или год. Каждую ось можно агрерировать (брать все данные) как бы для аналитики.

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

Работа - более экспериментальная. Делаешь симулятор запросов. И смотришь как оно работает.
Насколько быстро.

Не надо ничего в Nodepad делать. Загрузи это в базу и как-раз
7 и 8 колонки будут хранить то что тебе надо.
Далее - экспортируй в текст.

По поводу смыслов. Обычно с БД работают сущностями (entities). Я не специалист в Node и я не знаю
как у вас принято. Кажется в новых ecma-спецификациях уже ввели понятие класса.

В данном коде идет проверка на то что email существует. Но полезный эффект - слабый.
Я-бы сразу возвращал сущность пользователя. Чтоб не бегать потом в базу еще
раз когда надо поискать имя или дату регистрации. Ну идея такая что
если вы уж пошли в базу (это сетевой round-trip) то постарайтесь
за этот трип собрать максимум информации.

Вот это более рационально

export const findUserEntityByEmail = async (
  email: string
): Promise<User> => {
  try {
    const users = await db
      .query('SELECT * FROM accounts WHERE email = $1', [email])

Тоже самое относится к выборкам множества строк по множеству ключей.
Лучше сделать 1 callback который вернет коллекцию чем для коллекции
ключей дергать один несчастный метод который по штучке что-то достает.

Еще важне - join. Если соединяете сущности - то соединяйте сразу в БД
без попыток соединять в приложении. Это кстати еще бонус к компетенции
в части ACID.

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