Комментарии 15
Но исходя из упоминания горутин можно предположить что так тщательно скрывали Go/Golang.
Как я понял все правила применяются в рамках одного водителя/клиента и это должно хорошо решаться запуском нескольких consumer
Этот вариант, безусловно, рассматривали, но аргументы были простыми в нашем случае.
1) Пока не перепишем модель запускать несколько consumer'ов опасно — быстрее положим базу.
2) На самой модели завязано порядка 70% кода.
3) Невозможно нормально параллелить независимые части одной проверки водителя/клиента или организовать какие то более сложные потенциальные зависимости.
То есть в итоге переписывание модели было неизбежно. Раз уж переписывать 70% кода, тогда можно переписать все сразу на Go и иметь возможности лучшего масштабирования в будущем.
Для построения отчетов по пойманным событиям нам нужна была OLAP подобная база в нашем случае. OLTP базу настраивать для аналитических целей всегда непросто: когда перед тобой десятки полей по которым хотят искать и агрегировать, то тяжело настроить правильно индексы. При необходимости быстрого поиска по новому полю, нужно делать альтеры.
Мы выбрали ElasticSearch как компромисс между OLTP и OLAP.
В эластике удобно: индекс по каждому полю, возможность агрегации и, как вы упомянули, full-text поиск, если он понадобится.
У меня нет опыта в администрировании Postgres, но кажется что маcштабировать ElasticSearch легче — так как его разработчики на старте продукта закладывали туда шардирование, реплицирование, алиасы и прочее.
MySQL конечно и есть OLTP, но он база монолита в первую очередь. Этот MySQL у нас источник данных — множество баз и таблиц. И работать по ним напрямую антифрод не может без риска положить их. Соответственно мы в начале переносим данные в ElasticSearch, а потом их же используем для анализа на фрод.
— сама СУБД должна быть достаточно продвинутая, с хорошим языком запросов (T-SQL, PL/SQL), ей должно быть выделено достаточно ресурсов для выполнения ХП. При этом надо надеяться, что процедуры таки выполняться именно параллельно, а не по одной в одном потоке, блокируя все намертво;
— в общем случае набор правил быстрее и удобнее всего писать прямо в виде кода процедуры (или нескольких). За пару месяцев эта процедура (или сотня процедур) становятся страшным монстром, в котором мало кто разбирается, а покрыть это все тестами совсем не просто;
— заказчик не может сам писать правила и должен все время дёргать программиста. Если же таки заказчику нужен интерфейс и логика для работы с правилами, то мы падаем в бездонную кроличью нору, разрабатывая либо собственный интерпретатор правил в хранимой процедуре, либо компилируя правила в SQL код, который потом включается в процедуру. Оба варианта съедают жуткое количество времени на разработку и отладку.
В итоге мы сидели над этими хранимками долгие месяцы и мечтали все переписать на людский язык программирования, пока проект благополучно не закрылся :)
Отдел работает на 3 с минусом.
Описываю ситуацию своего автопарка в системе ситимобил. id 12294 парка.
В один день подключились 2 человека под видом водителей, как привлеченные лица на своих машинах. Сделали по одному заказу за наличные средства. Каждый заказ длился несколько минут несмотря на то, что дальность поездки была 280 километров по 1 заказу. По второму меньше. По окончании поездки водитель сумел выплатить сдачу на счет клиента ( баланс водителя был нулевой) ))))
По итогу автопарк попал на комиссию ситимобил за поездки которых не было!!!
Выданную сдачу несуществующему клиенту))))))
Через пару часов мы уже поняли ситуацию и начали писать и звонить.
Отдел антифрода очень секретное подразделение и туда напрямую обратится нельзя, хотя мне кажется это важно для своевременного информирования системы о незаконных действиях.
По обращению в ситимобил письма и звонки 2 недели!!! Антифродовая проверка в карточке водите ляпоказывала- ВСЕ OK!!!
написано 5 обращений, по результату мы получили супер ответ:
«Добрый день!
Вернуть д/с за заказ возможности нет, т.к. клиент, который получил сдачу за заказ, потратил бонусы.
На данный момент идёт разработка методов борьбы с мошенническими действиями.»
Вообщем на словах все здорово и статья классная, на практике пофигизм и отсутствие работы. За свой непрофессионализм они расплатились деньгами таксопарка.
Как система показывала, что проверка антифродовая проведена и все ОК, если заказ 280 км длился менее 5 минут.?
Как систему ненасторожило проблемы с показаниями gps?
Как система позволила выплатить сдачу на счет клиента при 0 балансе водителя?
Вообщем сотрудникам данного отдела стоит подумать над своей работой
Как мы фрод из избы выносили