Comments 15
А какое у вас примерно количество записей в базе и рейт запросов по ним?
По каждому из индексов сейчас примерно:
по доменам 700 млн
по логинам 250 млн
по почтам 500 млн
Скорость записи примерно 30 сек на батч из 100к идентификаторов (как правило, выливается в 150-200к записей в базе)
Недурно! А скорость поиска? И какого размера кластер это добро обслуживает, если не секрет?
Это что, от 3-5k rps, простите, у вас на hdd?
Нет, под ней SSD. На таблицы есть еще ряд индексов, которые тоже нужно актуализировать при записи
Я пока не нашел годных подходов к профайлингу scylladb, чтобы хорошо понять, где еще можно ускориться по записи. Буду рад, если кто сможет подсказать.
Я делал несколько “подходов” к scylladb, на python каждый раз упирался в скорость до 15-20k rps, что меня не устраивало. Причем, при множестве воркеррв, регулярно получал timeout. У меня были подозрения, что проблема в реализации библиотек на python, так как публичные статьи про базу приводят высокую скорость записи(как по идеи и должно быть, например, писали, что реализация на go леко выдает 100k). Копать дальше не стал, был положительный опыт с mongodb, на ней и остался.
А не может быть дело еще и в размере кластера? Когда много нод, то можно писать быстрее просто потому что больше параллельных записей выполняется
За мысль насчет библиотеки спасибо, посмотрю в сторону либы на go. Будет интересно, если она реально ускорит процесс записи
С таймаутами от воркеров тоже сталкивались, поэтому и используем контроль параллельных потоков в префекте. Это позволяет закинуть в очередь много утечек на запись, они плавно будут записываться без таймаутов
Я тоже тестировал питон, потом плюнул и переписал на гошке, производительность резко скакнула с 20к до 400к rps, питончик в десериализацию упирался.
Ваше IF NOT EXISTS убивает всю производительность на запись.
CREATE TABLE idx_email (
domain VARCHAR,
value VARCHAR,
password VARCHAR,
raw_value VARCHAR,
leak_time int,
PRIMARY KEY(domain, value, password)
);-
То есть у вас таблица domain существует отдельно? Если нет, то получится ли сократить размер базы, если вынести столбец domain в отдельную таблицу?
Тут все хитрее, таблица 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, что утекли учетные данных их клиента, для этого запись будет в индексе по доменам
Как мы построили систему анализа утечек паролей с хранением в ScyllaDB