13 млрд счётчиков и 220 000 RPS на запись: проектируем Key-Value-хранилище для Спамообороны

[xztv]

Интересно было бы узнать, как часто встречается в письмах ссылка с первой картинки на dqw4w9wgxcq и как часто пользователи переходят по ней :)

[tea-mur]

😄

[BloodyR00t]

Довольно изящное решение.. Уточните пожалуйста, 200 тысяч обновлений счётчиков в секунду, это ведь get+put (т.е. именно операций 400К+) или только put? И сколько серверов держит такую нагрузку?

[PrinceKorwin]

Из статьи

Он умеет накручивать и возвращать счётчики

Также в статье сказано, что туда передаётся на обновление не новое значение, а на сколько увеличить счетчик.

Таким образом, думаю, у них get+put сделан за одну атомарную операцию. Точнее increment+get.

[BloodyR00t]

Не уверен что Lucene умеет такое. Думаю там что-то вроде такого:

Query query = new TermQuery(new Term("shingleId", shingleId));
IndexSearcher searcher = new IndexSearcher(DirectoryReader.open(writer));
TopDocs results = searcher.search(query, 1);
Document doc;
if (results.totalHits.value > 0) {
    doc = searcher.doc(results.scoreDocs[0].doc);
    long currentCount = doc.getField("count").numericValue().longValue();
    long newCount = currentCount + incrementValue;

    doc.removeField("count");
    doc.add(new StoredField("count", newCount));
} else {
    doc = new Document();
    doc.add(new Term("shingleId", shingleId));
    doc.add(new StoredField("count", incrementValue));
}
writer.updateDocument(new Term("shingleId", shingleId), doc);

Вообще это кстати интересно почему именно Lucene был выбран для такого неатомарного инкремента (если он действительно такой) , кроме того что там быстрые запросы по интервалу, так как другие БД тоже могут в это.

[tea-mur]

Привет, попробую ответить на твои вопросы. 200 тысяч запросов — это только на запись. И столько же на чтение, соответственно. Как я писал в статье, у нас при записи используется временный буфер в памяти, который агрегирует запросы на запись за последнее время. А для чтения дополнительно используем кэш. Так что итоговая нагрузка на индекс ощутимо меньше.

Что касается Lucene, не буду, положа руку на сердце, гарантировать оптимальность такого выбора, перформанс-тестов мы не проводили. Из опыта работы с Lucene мы были более менее уверены, что с такой нагрузкой он справится, и его настройка обошлась нам дёшево. Так что тут я делюсь нашим позитивным опытом внедрения

[BloodyR00t]

Понятно, спасибо за уточнение.

[buriy]

1) ну я бы сказал что Lucene с его сегментами медленный, и LSM базы получше будут, но на 220к запросов в секунду я конечно не тестировал.
2) а так в целом всё это напоминает наивный байесовский подход, потому что все фичи независимые друг от друга и не коррелируют друг с другом.
3) для массовой фильтрации писем технология хорошая, но что если конкретному пользователю надо больше писем помечать как спам (не из-за редкости, а из-за въедливости и раздражительности)? Будете его разметку игнорировать, потому что глобально большинство спама не такое? Или же у вас ещё есть мини-байес для этого конкретного пользователя для донастройки?

[tea-mur]

Привет. Как ты правильно подметил, эта технология используется у нас именно для борьбы с массовыми атаками, где статистика даёт хороший сигнал. В случае конкретного пользователя мы, конечно, учитываем его поведение, но делаем это с помощью других механизмов, агрегируя информацию о жалобах пользователя (нажатия "Это спам", перекладка между папками). В схему с шинглерами мы байес не включаем