Кстати, можно гугловский распознователь таблиц с русским языком или Azure. https://cloud.google.com/document-ai/docs/process-tables эти штуки лучше чем тессеракт. У них там на бесплатном тире от 1к до 5к распознаваний, должно хватить на всех. Я попробывал сейчас Azureовский, цифры в лет в табличном виде хватает.
Для каких-то сценариев и каких-то систем это может быть решение as-is, а для кого-то нужно будет его менять, как написали выше и исключать еще доп. информацию.
К сожалению, нет четкого понимания, что такое эти перс. данные. Их с точки зрения логики получается два: данные, которые идентифицируют человека (ФИО, паспортные данные), сведенья которые относятся к персоне (политические взгляды, мед. данные, количество детей и семейнное положени). По моему мнению закон затрагивает оба этих типа, но тут уже должны подключаться юристы.
Так как в этих запросах может передаваться персональные данные и вы правы, что может и не передаваться эта информация. Но закон вот так говорит, что такое персональные данные: "персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);" Другими словами это может быть и сведенья о ваших покупках в магазине, так как она относится к вам. Тут большая серая зона и поэтому в примере, который у меня намеряно сделан захват так широко. Разработчик или владелец системы может уже зная структуру запроса вычленять эти данные более гранулярно, но это уже будет конкретная имплементация.
А в чем тут противоречие? 1) Данные всегда актуальны и записываются все изменения. 2) Если есть срок хранения, то можно сделать автоматическое удаление. Сделать это можно по дате записи лога в PostgreSQL, лог фаил приэтом просто будет временным буфером.
Но в решении действительно не хватает части для последующего управлениями и просмотром этих данных. Но как я сказал, эту идею и реализацию можно брать за основу и уже адаптировать под свое приложение и сервис.
Спасибо за комментарий, попробую прокомментировать его:
Docker я намеряно не использовал, так как внутри база данных и придется тогда делать persistent volume, что несколько уже усложняет все это и от докера теряется смысл. Но ничего не мешает запустить скрипт внутри докера.
Базу данных было несложно добавить, поэтому как дополнительная галочка, то не помешает. А так же с помощью нее можно еще хранить и трансформировать changefeed в справочник персон и их данных. Как хороший задел для расширения.
«предусматривает удаление неактуальных данных» такого в законе нет, актуализация может быть произведена очень многими разными способами. Отзыв согласия как мне, кажется, есть в GDPR, а в ФЗ-152 такого я не помню.
Про США нужно дополнительно уточнять, про требования о странах подписавших эту конвенцию для передачи персональных данных, я слышу если честно в первый раз.
«не просто сохранять, но и ИЗВЛЕКАТЬ из БД на территории РФ», в законе явно сказано только:«При сборе персональных данных», а дальше уже перечислены операции в рамках этого процесса.
Если используется API gateway для lambda, что бы выставить ее во вне ввиде http, то можно заменить на новый облегченный HTTP API. latency меньше и цена на ~70% меньше
Если большой исходящий траффик до внутренней инфраструктуры то можно сделать direct connect в рамках него биллинг идет по другой логике и получается дешевле.
Если используются инстансы для работы в определенное время (ec2 и rds), то посмотрите на auto Instance Scheduler, можно выключать ночью, а так же включить еще Hibernate для ec2 и тогда будет не заметно что машина вообще выключалась.
static контент лучше раздавать через cloudfront это тоже помогает сократить расходы в различных сценариях. Но лучше это делать если конечные консьюмеры там где есть cloudfront pop точки
Цены на виртуалки в разных регионах разные и различаются бывает на десятки процентов. Поэтому если есть не критические ворклоды к latency лучше их поднимать в дешевых регионах
Не забывайте про inter az трафик он тоже стоит денег и всякие кросс az кластеры могут серьезно добавить в косты, поэтому если не сильна важна отказоустойчивость для некоторых сценариев, то возможно этим можно пожертовать.
ViewGA, похоже, это что-то вроде вот этого SIMULCAM www.youtube.com/watch?v=lyHa_0yJBlw впервые использовалось при сьемке аватара, кажется 2008 год. Стоимость $5к, а какая цена у ViewGA?
Кстати, можно гугловский распознователь таблиц с русским языком или Azure. https://cloud.google.com/document-ai/docs/process-tables эти штуки лучше чем тессеракт. У них там на бесплатном тире от 1к до 5к распознаваний, должно хватить на всех. Я попробывал сейчас Azureовский, цифры в лет в табличном виде хватает.
К сожалению, нет четкого понимания, что такое эти перс. данные. Их с точки зрения логики получается два: данные, которые идентифицируют человека (ФИО, паспортные данные), сведенья которые относятся к персоне (политические взгляды, мед. данные, количество детей и семейнное положени). По моему мнению закон затрагивает оба этих типа, но тут уже должны подключаться юристы.
"персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);"Другими словами это может быть и сведенья о ваших покупках в магазине, так как она относится к вам. Тут большая серая зона и поэтому в примере, который у меня намеряно сделан захват так широко. Разработчик или владелец системы может уже зная структуру запроса вычленять эти данные более гранулярно, но это уже будет конкретная имплементация.Но в решении действительно не хватает части для последующего управлениями и просмотром этих данных. Но как я сказал, эту идею и реализацию можно брать за основу и уже адаптировать под свое приложение и сервис.
Класс, какой обьем сейчас в s3 — дата лейке сумарно и сколько примерно выходит по деньгам: хранение и процессинг?
Мы в своем проекте вот это использовали и оно нормально отрабатывало https://pyscenedetect.readthedocs.io/en/latest/features/ не пробывали?
А есть ограничения по обьему даннах в такой конструкции?
Binding WPF такой же:)