В России хотят «поставить клеймо» на все товары



Слышали про Центр развития перспективных технологий? Нет? Конечно, это же не «Макдональдс». Но именно эта компания (где значительная часть капитала принадлежит Алишеру Усманову, про которого я недавно писал большой пост) – создает систему тотальной маркировки товаров.

Она решила вложить в это почти 206 миллиардов рублей за 15 лет.



Чипировать начали пару лет назад шубы, сейчас экспериментально маркируют табак. Эксперимент, судя по всему, удался, потому что в апреле этого года правительство решило замаркировать еще 10 категорий – обувь, парфюм, шины и тд. Так что далее – везде. «Пробу» будут ставить практически на всё подряд.



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

В теории прекрасно, только в бюджете на эту систему денег не предполагается – 200 с лишним млрд особенно сейчас не лишние. Поэтому решили, сделать проект на базе ГЧП, и выходит, что это будет первое и крупнейшее государственно-частное соглашение не стройку больницы или на дорогу, а на IT-систему. Проект уже закинули в минпромторг.

Зачем инвестировать тратить такие деньжищи? Затем, что в будущем эти инвестиции превратятся в прибыль. Откуда прибыль? От производителей.



За каждый код для товара инвесторы будут получать 50 копеек. Только лекарства, которые стоят менее 20 рублей будут маркировать бесплатно.

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

С одной стороны, рынок от этого должен стать цивилизованней, да и против борьбы с палью мало кто выступит, а с другой, осилят ли производители 50 копеек с каждого товара платить? Как считаете?

Реляционная не потянет, чисто по соотношению скорости и объёма данных. А если и потянет думать будет по полгода на каждую операцию. Можно конфиг на Spark + Hadoop + Elastic с очередями в Rabbit. Если не хотим заморские технологии можно Тарантул. Тогда ещё и 50 копеек за товар не потребуется. Обойдёмся 30-ю чтобы прибыль с проекта была.
Если есть привычное решение и правильное решение, то какое выберем? )) Может потянуть для одного конкретного шлюза, может потянуть на 1к шлюзов, а дальше? Аналитика Taobao работает на Спарке.

Простое решение 2 года назад - база на 3кк записей по 20 строк к записи в Монго с поиском из произвольного сочетания 9 полей, в которые внесены неизвестные текстовые данные отрабатывает за 10-15 мс. Второй год работает, было 2 профилактики. Один раз упал сервер по вине провайдера, второй - сами обновили не подумав php и вебморда стала писать function deprecated.

Второе решение год назад - статистическая система и скоринг (не банковский). Средний объём обновления около 1,5 гб в сутки и тоже сравнение по множественным признакам. Например, трафик из Метрики + трафик из ГА + отчёт по соцсетям + проверка обновлений Росстата + отчёт по трендам в целом. Выгрузка занимает часа два-три, пересчёт делается средствами БД за 15 минут и потом передаётся в R где собирается финальный отчёт и им обновляем базу.

Я допускаю, что плохо работаю с реляционными БД, но не соглашусь, что они провернут такой объём операций быстрее и эффективнее. :)
коллега, ты не находишь, что архитектура решения должна быть несколько иной, без всякого php и прочих web-морд?
достаточно web-сервисов, которые будет дергать приложение
и тут уже неважно, 10 или 15 миллисек, достаточно даже (будет посто супер) если ответ о корректности операции и фиксировании её в центральной БД будет приходить через 2-3 секунды, это вообще некритично не при розничных продажах, не при оптовых телодвижениях
даже если в очереди будет стоять тысяча транзакций в секунды РБД это переварит, процессинг сбера на оракле кушает 20 миллионов транзакций в сутки и не пищит
не говоря уже о биллингах сотовых операторов (у билайна тоже оракл), где транзакций на порядок больше
В целом согласен, коллега! Не соглашусь с тем, что при превышении определённого объёма запросов нужно продолжать использовать старую логику. У меня не вызывает отторжения всё что не NoSQL точно так же, как не пытаюсь везде применить php или py. Но когда мы говорим о глобальной системе, развивающейся системе, в которой могут на лету меняться требования и типы данных, мы должны уметь быстро её перестраивать. Желательно на уровне вебсервисов и без участия человека.

Реляционная БД по умолчанию имеет заранее определённую структуру и формат данных. Мы можем видеть на примере 1С. У меня устойчивая нелюбовь к продукту, но не могу отрицать ряд блестящих решений с точки зрения хранения данных и организации вывода. Однако, она морально устарела, а переписать продукт по-новому задача коммерчески почти неподъёмная.

Согласись, когда мы получаем в базу непрогнозируемый объём данных за период, мы должны а) сохранить б) проверить целостность в) обработать и получить из них промежуточные значения. Пока нам приходит ожидаемый набор данных, мы работаем комфортно. Как только прилетит неожиданный (медиафайл, например) - система его либо отобьёт, либо не сможет включить в известную ей структуру. NoSQL позволяет просто записать данные в том виде, в котором они переданы. Обработка на уровне БД тоже в разы эффективнее на NoSQL за счёт того, что они и строились больше как хранение всего и обработка его же.

Мне показалось или мы превращаем топик в филиал Хабра? )) Мне тема нравится, если что готов продолжить ))))))