А не может быть дело еще и в размере кластера? Когда много нод, то можно писать быстрее просто потому что больше параллельных записей выполняется
За мысль насчет библиотеки спасибо, посмотрю в сторону либы на go. Будет интересно, если она реально ускорит процесс записи
С таймаутами от воркеров тоже сталкивались, поэтому и используем контроль параллельных потоков в префекте. Это позволяет закинуть в очередь много утечек на запись, они плавно будут записываться без таймаутов
Тут все хитрее, таблица 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, что утекли учетные данных их клиента, для этого запись будет в индексе по доменам
Я в своих идеях отталкивался как раз от необходимости строить доку на основании того, что получилось на выходе из разработки. Мне понравилось генерировать код для grpc, но все же при возможности я хотел бы писать структуры сам, сладить, что в них поменялось на выходе, в нужных местах заполнять поля. А не так, что "вот мы тебе сделали, теперь пойди угадай, что же поменялось и везде где надо поиспользуй поля". Может это мой пиьонячий подход играет
Мне кажется, мы как раз про разные подходы говорим, и ни один из них не лучше или хуже другого. Следовать строго оговоренное документации заранее приятно и удобно. И главное, что можно доверять друг другу, договорившись на берегу.
Но бывают случаи, когда нужно строить документацию на основании того, что получилось на выходе из разработки. Когда ты написал северную часть, сразу же показал фронту, он пошел на основании этого реализовывать свое. И любые изменения он тоже может отследить.
Правильный комментарий ниже, что это может быть моя травма от python. Но раз там так носят, значит и в Go можно. Кроме того, приведенные мной библиотеки в примерах имеющихся реализаций способны строить аннотацию по коду. Но делают это не самым удобным для меня способом
Но все же в статье рассмотрена только одна из сфер ИБ, хоть и наиболее интересная. Есть же еще, кроме многими нелюбимой сферы «бумажной безопасности», те же интеграторы, внутренние безопасники. И эти ребята совсем не про пентест, а про настройку средств защиты, беготни с соответствиями стандартам (как корпоративным, так и внешним: GDPR, ISO 27k). Для специалиста по ИБ, работающего в интеграторе, огромная сфера развития есть: масса классов решений, по каждому классу разные вендоры со своими подходами, масса сертификатов. Но для большинства почему-то ИБ сводится в основном к вебу (bug bounty) и пентесту в корпоративных сетях.
А не может быть дело еще и в размере кластера? Когда много нод, то можно писать быстрее просто потому что больше параллельных записей выполняется
За мысль насчет библиотеки спасибо, посмотрю в сторону либы на go. Будет интересно, если она реально ускорит процесс записи
С таймаутами от воркеров тоже сталкивались, поэтому и используем контроль параллельных потоков в префекте. Это позволяет закинуть в очередь много утечек на запись, они плавно будут записываться без таймаутов
Нет, под ней SSD. На таблицы есть еще ряд индексов, которые тоже нужно актуализировать при записи
Я пока не нашел годных подходов к профайлингу scylladb, чтобы хорошо понять, где еще можно ускориться по записи. Буду рад, если кто сможет подсказать.
Скорость поиска пока не замеряли, но она по ощущениям приемлемая, то есть не чувствуется задержек при выполнении запросов
Размер кластера меньше, чем можно себе представить) Такое количество записей и правда очень мало для scylladb
Тут все хитрее, таблица
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, что утекли учетные данных их клиента, для этого запись будет в индексе по доменамПо каждому из индексов сейчас примерно:
по доменам 700 млн
по логинам 250 млн
по почтам 500 млн
Скорость записи примерно 30 сек на батч из 100к идентификаторов (как правило, выливается в 150-200к записей в базе)
Я в своих идеях отталкивался как раз от необходимости строить доку на основании того, что получилось на выходе из разработки. Мне понравилось генерировать код для grpc, но все же при возможности я хотел бы писать структуры сам, сладить, что в них поменялось на выходе, в нужных местах заполнять поля. А не так, что "вот мы тебе сделали, теперь пойди угадай, что же поменялось и везде где надо поиспользуй поля". Может это мой пиьонячий подход играет
Мне кажется, мы как раз про разные подходы говорим, и ни один из них не лучше или хуже другого. Следовать строго оговоренное документации заранее приятно и удобно. И главное, что можно доверять друг другу, договорившись на берегу.
Но бывают случаи, когда нужно строить документацию на основании того, что получилось на выходе из разработки. Когда ты написал северную часть, сразу же показал фронту, он пошел на основании этого реализовывать свое. И любые изменения он тоже может отследить.
Правильный комментарий ниже, что это может быть моя травма от python. Но раз там так носят, значит и в Go можно. Кроме того, приведенные мной библиотеки в примерах имеющихся реализаций способны строить аннотацию по коду. Но делают это не самым удобным для меня способом
Насчёт более умных предсказаний Blocknative недавно выпустили статью о том, как они улучшили предсказания: https://www.blocknative.com/blog/base-fee-prediction-and-intelligent-max-fee