• XSS.stack #1 – первый литературный журнал от юзеров форума

Архитектура для собственной БД утечек.

gina_turturro

HDD-drive
Пользователь
Регистрация
12.05.2025
Сообщения
46
Реакции
8
Всем привет.

Я хочу сделать для своих личных нужд базу данных утечек. За последние несколько лет я накопила утечки в разных форматах: SQL, txt, Cronos, JSON. Искать вручную в каждой из них неудобно. Я хочу сделать единый интерфейс запроса, и единый формат хранения. И в этом посте я прошу совета по архитектуре.

Я, время от времени, программирую на Python, так что реализовывать буду на нём. Имею опыт с SQLlite, поэтому в качестве СУБД буду использовать его. Я планирую сковертировать все базы в SQLLite и написать простенький ГУЙ для итеративного поиска по базам. ОС - Linux.

В проектировании баз я плохо разбираюсь и имела мало опыта.

Что мы имеем на входе: базы в разных форматах, с похожими полями, но со своими особенностями.
Что надо получить на выходе: универсальный формат хранения в базе SQLlite чтобы переконвертировать в него все имеющиеся базы.

Вопросов у меня много. Но для начала такие?
1. Как сконвертировать Cronos в SQLlite? Есть ли готовые решения, открытый код?
2. Хранить ли разные утечки поотдельности, или делать одну большую базу, обогащая исходную базу новыми данными из других утечек?
3. Поиск по каким данных сделать в этой системе? Например, ФИО, Адрес, Дата рождения, номер авто, идентификаторы мессенжеров, телефоны, кадастровый номер, IP адреса, ИНН, СНИЛС, Паспорт и тп.?
4. Какие есть инструменты и алгоритмы удаления дублей и выявления сгенерированных данных?
5. Есть ли opensource реализации семантического поиска? Например, я ищу Марию, а в какой-то БД нужный мне человек записан как "Маруся". Хотело бы прикрутить такую семантику.

Отдельно стоят вопросы добавления новых утечек. Как проверять новую утечку на новизну и принимать решение о добавлении в базу?

Уверена, что у некоторых пользователей нашего форума уже есть своя собственная реализация того, что я хочу сделать. Поделитесь, пожалуйста, опытом. Киньте ссылок на мануалы как делать такие системы, пожалуйста. А так же на мануалы по архитектуре подобных систем.

Большие книжки по БД читать нет времени: слишко долгий старт и слишком много лишнего/общего.
 
Последнее редактирование:
Что мы имеем на входе: базы в разных форматах, с похожими полями, но со своими особенностями.


Я бы советовал отложить sqlite в сторону и посмотреть на что-то документориентированное, например mongodb
 
Последнее редактирование:
Я бы советовал отложить sqlite в сторону и посмотреть на что-то документориентированное, например mongodb
не работала с mongodb.
почему она лучше подходит для моей задачи?
 
ну sqlite плохое решение, она для embeded в основном предназначена, в один поток работает. Касательно базы и разметки я думаю можно шаблонами размечать датасеты как то. Делать тэгирование данных. Например csv "Петя Жуков|20.11.2009|+7911 123 12 12" можно было бы разметить типо "$firstname $lastname|$birthday|$phone", ну и так для остальных форматов баз, понятно что дату рождения можно хранить по разному, поэтому было бы удобно сделать функции форматирования, которые например принимают разные форматы дат: "09-05-1998" "1898-03-11" "2018-01-03Z0001.3" и т.д. и приводили бы их к общему формату, по которому уже после будет реализована фильтрация. В любом случае автоматически разметить базы не выйдет, так что лучше себе просто упросить этот процесс
 
В любом случае автоматически разметить базы не выйдет, так что лучше себе просто упросить этот процесс
Размечать новую базу утечки можно при её добавлении в БД. Я думаю это не проблема.
А вот как избавляться от дублей и проверять новую базу утечки на полезность?
 
Помимо этого тебе бы ещё сделать переход к оригинальной БД интересующей тебя строки, бывает много полезной информации, которую никак не засунуть в твою основную БД. Проверять на дубли так-ли необходимо? К примеру юзер у нас засветился в дампе 1 и дампе 2, данные все те же самые, но у 1 и 2 есть ещё интересные столбцы. Да и само понимание, что человек сидел на каком то ресурсе говорит уже о многом
 
Помимо этого тебе бы ещё сделать переход к оригинальной БД интересующей тебя строки, бывает много полезной информации, которую никак не засунуть в твою основную БД. Проверять на дубли так-ли необходимо? К примеру юзер у нас засветился в дампе 1 и дампе 2, данные все те же самые, но у 1 и 2 есть ещё интересные столбцы. Да и само понимание, что человек сидел на каком то ресурсе говорит уже о многом
Согласна. Я имела в виду полные дубли всех полей.
 
В любом случае автоматически разметить базы не выйдет, так что лучше себе просто упросить этот процесс
Я планирую запилить полноценный ETL с обогащением данных. Например, парсить текстовый адрес и конвертить его в ФИАС. И нормализовывать телефонные номера в international формат.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх