Ниже описал часть таблиц из БД. Стек: PostgreSQL + Symfony4 + PHP7. Рассматриваем вариант переноса операций в отдельную БД - ElasticSearch. Но возникает сложность с связью таблиц. Ниже привёл кейс.
Таблица Member
- ID
- FIO
- Email
- Phone
- Password
- Date
Таблица Операции
- ID
- Member_id
- Operation_type
- Value (true/false)
- Date
Таблица Operation_type
- ID
- Name
- Date
Кейс:
Пользователь Х зарегистрировался на сайте, создаётся запись в таблицу Member и запись операции (тип Регистрация) в таблицу операций. Позже админу выводится статистика операций в формате:
- Member_ID
- Member_fio
- Member_Email
- Member_Phone
- Member_Date
- Operation_type_id
- Operation_value
- Operation_date
Т.е. Данные операции в отчете операций содержат данные пользователя, который совершил операцию
Отсюда возникает вопрос, как организовать работу с BigData при условии, что есть связи между таблицами?
Рассматриваем такое решение:
1. Делать запись в таблицу операций вместе с данными пользователя, которые будут браться из таблицы пользователей. В этом случае, если пользователь изменит данные, они будут отличаться в отчетах
2. В момент формирования отчёта брать часть данных из одной БД, часть из другой. При этом в операциях должен быть идентификатор этого пользователя
Подскажите, какие решения могут быть и что будет оптимальным для описанного кейса?
RidgeA, спасибо за уточнение. У нас нет жёсткой привязки к эластике, нам главное быстро формировать отчеты, работать с фильтрацией данных, их выгрузкой. А почему бигдата, потому что объёмы данных большие и с ними надо работать. Но на самом деле нам без разницы как это можно назвать, главное кейс исполнить
blabs, понятней не стало.
Какого рода запросы? Можно ли их делать в фоне в наименее нагруженное время? Можно ли их кешировать ? Можно ли оптимизировать запросы? И т. д. Синхронизация данных между разными типами баз данных - весьма геморное занятие. Это уже должен быть крайний шаг, если ничего другого нельзя придумать. И с этим придется жить долго и нудно.
В общем в вопросе мало конкретики.
Синхронизация возможна несколькими путями, например :
0. Запись в базу данных осуществляется через 1 адаптер - он уже записывает данные в две базы - непонятно что делать если в одну записалось, а в другую - нет.
1. Аналогично предыдущему, но через очереди. Проблема та же + работа с очередью.
2. Отправка запроса из Postgresql на другую базу в тригере (через очередь, через прокси-сервис) и т. п. Не знаю, позволяет ли это сделать база данных (PG). Для mysql есть решения, которые позволяют отправлять http запросы, но там есть косяк в тригерах - срабатывает даже если транзакция откатилась - не знаю важно ли это и может уже и пофиксили.
В общем - варианты есть. Но надо основательно взвесить все против.
upd:
3 * 15 - 45 миллионов записей в месяц ((3 + (0,1 × 12 × 5))× 15 = 135 млн в месяц через 5 лет при указанном приросте). При правильном подходе - вообще не проблема. Можно писать в отдельные таблицы, например по дням, по месяцам...
Все достаточно просто, перестаньте думать таблицами и начните думать ДОКУМЕНТАМИ.
У вас есть всего два документа - два индекса. Индекс Пользователей, и индекс Операций.
Пользователь представляет из себя документ со всеми полями таблицы member. А Операция, состоит из конкатенации полей member-operation-operationtype. Да данные в индексе Операции будут дублировать некоторые поля из Пользователей, но это и не страшно, это правильно, так как это фактически лог.
Средний
Средний
Средний
