yopp
я бы исходил не из объёма, а из конкретных операций
yopp
потому что вставлять 3к документв в секунду это плевое дело
yopp
но вы же не просто их хранить хотите, да? вы хотите эти данные как-то обрабатывать
yopp
и вот эта обработка и есть самое узкое место
Dmitriy
но вы же не просто их хранить хотите, да? вы хотите эти данные как-то обрабатывать
да, я выше написал про агрегацию и аналитику
yopp
вы ничего конкретного не написали
yopp
это «мы будем обрабатывать данные»
Dmitriy
вот это " отсутствие нормальное работы с агрегацией данных"
Dmitriy
прошу прощения не перенес в требования
yopp
это ничего не говорит о том что конкретно вы хотите
Dmitriy
ок, я вас понял, например я хочу получить сводный отчет по кредиторской задолженности контрагента за период в полгода
yopp
и всё?
Dmitriy
или например аналитику по фрод активности плательщиков за какой-то период в разрезе контрагента и мерчанта
yopp
у вас есть план запросов?
Dmitriy
и всё?
вы хотите чтобы я расписал методологию расчета или что-то другое уточняете, или имеете в виду что это плевое дело?)
yopp
я хочу вас навести на мысль, что выбирать базу данных надо исходя сначала из бизнес-задач, а потом уже из технических требований
yopp
вероятно вам нужен какой-то многомерный olap
yopp
с вашим объёмом транзакций, вам нужен хороший олап, с хорошей поддержкой
yopp
а это не такой большой рынок :)
Dmitriy
вероятно вам нужен какой-то многомерный olap
не совсем, если бы мне нужен был олап, то я бы не спрашивал за монгу, у которой в помине нет этого. а брал бы пг у которого есть такие решения)
yopp
а звучит как olap
AstraSerg
@dd_bb Человек пришёл, что бы мы ему расписали "плюсы" монги, так как он её хочет, а коллеги - нет. А мы его отговариваем :)
yopp
наоборот же
Dmitriy
если упрощенно то мне нужно сделать так для примера:
SELECT sum(amount), format(date, 'Y-m') as date, count(id), project_id FROM table WHERE contractor = xxx AND date BETWEEN 'xxxx' and 'yyy'
GROUP BY date, project_id
HAVING BY count(id) > 100000;
yopp
yopp
не хотите, не берите :)
yopp
если упрощенно то мне нужно сделать так для примера:
SELECT sum(amount), format(date, 'Y-m') as date, count(id), project_id FROM table WHERE contractor = xxx AND date BETWEEN 'xxxx' and 'yyy'
GROUP BY date, project_id
HAVING BY count(id) > 100000;
такие вещи на AF сейчас элементарно делаются
Dmitriy
не хотите, не берите :)
я уже кажется писал, что мне пытаются ее насадить со стороны, а я как раз пытаюст понять на сколько этот насаждение обосновано
yopp
у вас процесс выбора решения сломан
AstraSerg
я уже кажется писал, что мне пытаются ее насадить со стороны, а я как раз пытаюст понять на сколько этот насаждение обосновано
это я в хорошем смысле, извините, если обидел :)
yopp
составьте план запросов, сделайте модельный датасет. выделите критерии оценки, соберите подходящие решения, прогоните план на модельном датасете и оцените по криетериям
AstraSerg
только, варнинг! В процесс тестирования, можете влюбиться :)
yopp
обычно наоборот
yopp
дергается глаз и теряется вера в человечество ;)
Nick
с такими требованиями не влюбятся))
Dmitriy
хороший план, жаль что требует массу времени, которого особо нет
yopp
хороший план, жаль что требует массу времени, которого особо нет
если у вас нет времени на объективный и основанный на данных выбор критического для бизнес решения, вам можно спокойно зарывать проект
Dmitriy
такс последний вопрос, реплика в монге может быть умной, т.е. скажем в процессе репликации изменять ряд данных или фильтровать их или это только через внешние решения?
yopp
вы путаете репликацию с чем-то ещё
Dmitriy
нет не путаю
AstraSerg
хороший план, жаль что требует массу времени, которого особо нет
Думаю, вы не найдёте веских причин ни "за", ни "против". Единственное существенное обоснование может появиться в результате тестирование, как говорит yopp.
Dmitriy
если у вас нет времени на объективный и основанный на данных выбор критического для бизнес решения, вам можно спокойно зарывать проект
да, я вас услышал спасибо. буду думать как это сделать и возможно ли это в данных реалиях или дешевле взять проверенные временем решения
yopp
по поводу изменения данных при репликации, нет, монга этого к счастью не умеет
yopp
вы скорее всего хотите потоковую обработку данных, но это не репликация
yopp
потоковую обработку можно сделать, с некоторыми оговорками
yopp
есть change streams
yopp
а вы, я так понимаю, хотите встроенный в субд ETL
AstraSerg
обиделся Дмитрий, похоже...
Dmitriy
нет, вдумчиво читаю что такое change streams)
Dmitriy
а вы, я так понимаю, хотите встроенный в субд ETL
не совсем, я хочу скорее логическую репликацию
AstraSerg
нет, вдумчиво читаю что такое change streams)
ну если вкратце, это есть у всех БД, подписка на поток изменений, то есть приложение может видеть op(erations)log
Nick
серьезно не воспринимать
но есть еще такая срань как кафка с ее кафка стримами и ksql и псевдотабличным представлением, может вам подойдет)
Dmitriy
серьезно не воспринимать
но есть еще такая срань как кафка с ее кафка стримами и ksql и псевдотабличным представлением, может вам подойдет)
не воспринял серьезно))) но улыбнулся точно)
yopp
т.е. реплицируется не хранилище, а документы
yopp
это позволяет в том числе иметь смешанные кластеры: разные версии, разные движки хранилища, разные настройки хранилища
Dmitriy
но не позволяет изменить данные в процессе репликации?
Dmitriy
или я не правильно понял вашу мысль выше?
yopp
если данные в процессе меняются, это уже не репликация
Dmitriy
прошу прощения за ссылку не в тему чата, но: https://www.postgresql.org/docs/10/static/logical-replication.html
если формально то я говорю сейчас за пункт: "Firing triggers for individual changes as they arrive on the subscriber."
yopp
да, я понял что вы говорите про этот ужас
yopp
но это уже не репликация
yopp
потому что если вы поменяете данные, у вас уже не копия данных будет, а новые данные
yopp
а зачем вам это надо?
Dmitriy
ок, я понял, но это уже софистика)
а подскажите пожалуйста еще за change streams, правильно я уловил мысль, что это механиз оповещения о изменение данных в документе?
т.е. условно говоря, приложение 1 записало/изменило данные в документе, в приложение 2 ушел лог изменений по вебсокету (пример взял с потолка, досконально не разбирался пока во всей механике)
yopp
в монге изменился документ, об этом будут уведомлены все клиенты которые подписались
yopp
через протокол монги
Dmitriy
а зачем вам это надо?
по pci dss данные карты плательщика могут хранится только в дмз, в которое может ходить только сертифицированное (читай не изменяемое или редко изменяемое и с соблюденийм всех регламентов приложение) и из которого не могут отображаться данные в вебе например.
соответственно для того чтобы отобразить эти данные кастомерам надо по минимуму: маскировать номер карты и убрать cvv из базы в которую будет ходить веб
Dmitriy
в монге изменился документ, об этом будут уведомлены все клиенты которые подписались
ну т.к. в общих чертах я правильно мысль уловил, спасибо
AstraSerg
прошу прощения за ссылку не в тему чата, но: https://www.postgresql.org/docs/10/static/logical-replication.html
если формально то я говорю сейчас за пункт: "Firing triggers for individual changes as they arrive on the subscriber."
Теоретически такое можно сделать: приложение слушает change stream; вносит изменения при необходимости; записывает данные в другой инстанс монги или другое место
Nick
наверное хочет при репликации сразу затирать секурные данные
Dmitriy
не очень понимаю причём тут монга
монга тут вообще не причем, я пытаюсь понять умеет ли она то что в пг называется логической репликой
Dmitriy
Теоретически такое можно сделать: приложение слушает change stream; вносит изменения при необходимости; записывает данные в другой инстанс монги или другое место
да, но это еще одно приложение, которое даст таймаут на обработке + которое надо дополнительно сертифицировать (читай платить деньги)
Dmitriy
так затирайте перед запись, хоть в браузере
нельзя, потом не сделать ребил и упрощенный платеж