Как мы построили систему анализа утечек паролей с хранением в ScyllaDB

[sgjurano]

А какое у вас примерно количество записей в базе и рейт запросов по ним?

[AlhimicMan]

По каждому из индексов сейчас примерно:

• по доменам 700 млн

• по логинам 250 млн

• по почтам 500 млн

Скорость записи примерно 30 сек на батч из 100к идентификаторов (как правило, выливается в 150-200к записей в базе)

[sgjurano]

Недурно! А скорость поиска? И какого размера кластер это добро обслуживает, если не секрет?

[AndrewFoma]

Это мизер для scylladb.

[AlhimicMan]

Скорость поиска пока не замеряли, но она по ощущениям приемлемая, то есть не чувствуется задержек при выполнении запросов

Размер кластера меньше, чем можно себе представить) Такое количество записей и правда очень мало для scylladb

[AndrewFoma]

Это что, от 3-5k rps, простите, у вас на hdd?

[AlhimicMan]

Нет, под ней SSD. На таблицы есть еще ряд индексов, которые тоже нужно актуализировать при записи

Я пока не нашел годных подходов к профайлингу scylladb, чтобы хорошо понять, где еще можно ускориться по записи. Буду рад, если кто сможет подсказать.

[Insurgent2018]

Я делал несколько “подходов” к scylladb, на python каждый раз упирался в скорость до 15-20k rps, что меня не устраивало. Причем, при множестве воркеррв, регулярно получал timeout. У меня были подозрения, что проблема в реализации библиотек на python, так как публичные статьи про базу приводят высокую скорость записи(как по идеи и должно быть, например, писали, что реализация на go леко выдает 100k). Копать дальше не стал, был положительный опыт с mongodb, на ней и остался.

[AlhimicMan]

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

За мысль насчет библиотеки спасибо, посмотрю в сторону либы на go. Будет интересно, если она реально ускорит процесс записи

С таймаутами от воркеров тоже сталкивались, поэтому и используем контроль параллельных потоков в префекте. Это позволяет закинуть в очередь много утечек на запись, они плавно будут записываться без таймаутов

[Insurgent2018]

Я пробовал писать из тредов, пробовал якобы async версию, все впустую, увеличиваю количество - сразу timeouts. Железо брал на тест, 3 ноды, rep.f 3, диски nvme.

[Insurgent2018]

Даже если у вас будет ну 10k, причем я так понимаю, что вы не пишете (upsert видимо) 24/7/365 - то все равно мало, на уровне «провала».

[sgjurano]

Я тоже тестировал питон, потом плюнул и переписал на гошке, производительность резко скакнула с 20к до 400к rps, питончик в десериализацию упирался.

[ViperRU]

Ваше IF NOT EXISTS убивает всю производительность на запись.

[wifage]

CREATE TABLE idx_email (
  domain VARCHAR,
  value VARCHAR,
  password VARCHAR,
  raw_value VARCHAR,
  leak_time int,
  PRIMARY KEY(domain, value, password)
);

-
То есть у вас таблица domain существует отдельно? Если нет, то получится ли сократить размер базы, если вынести столбец domain в отдельную таблицу?

[AlhimicMan]

Тут все хитрее, таблица idx_domain предназначена для учета, для какого домена известна учетка, а в таблице idx_email хранится запись пары почта + пароль. Например, в индексе по доменам записано, что почта employee_name@email_service.ru с паролем password123 использовалась для входа на clients.importantsite.ru. Для нее в таблице idx_email будет храниться запись domain=email_service.ru, value=employee_name, password=password123. Это позволяет выполнить поиск по почтам компании email_service.ru, чтобы уведомить, что найдена запись от почты их сотрудника, вдруг он этот же пароль использует для внутренней сети. Для этого поможет запись из таблицы idx_email . И также мы можем уведомить importantsite.ru, что утекли учетные данных их клиента, для этого запись будет в индексе по доменам