Не уверен что 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 был выбран для такого неатомарного инкремента (если он действительно такой) , кроме того что там быстрые запросы по интервалу, так как другие БД тоже могут в это.
Довольно изящное решение.. Уточните пожалуйста, 200 тысяч обновлений счётчиков в секунду, это ведь get+put (т.е. именно операций 400К+) или только put? И сколько серверов держит такую нагрузку?
Одной из ключевых проблем является чрезмерная зависимость от бенчмарков, которые не всегда отражают реальные условия работы в продакшне. Например, тесты Clickbench, используемые автором, оценивают производительность на ограниченных данных (до 100 ГБ), что далеко не всегда применимо к реальным задачам.
И хотя утверждается о значительном прогрессе в PostgreSQL 17, данные о производительности не подкреплены тестами с большим количеством пользователей и запросов. Также есть недостаток информации о конкретных сценариях, в которых определенные СУБД, такие как MongoDB или SQLite, могли бы превзойти Postgres в плане удобства или масштабируемости. Заявление о том, что Umbra превосходит PostgreSQL за счет своей архитектуры и хеш-таблиц, интересно, но требует большего числа реальных примеров использования.
Обзор бенчмарков также несколько ограничен, так как не охватывает разнообразие типов запросов и реальных нагрузок, что делает выводы о производительности не вполне объективными.
В целом классно что получилось достигнуть такой мощный прирост, за это респект. С другой стороны это размывание бизнес-логики между слоями приложения, в частности, между уровнем базы данных (DAO) и бизнес-логикой, например когда часть логики переносится непосредственно в SQL-запросы (например, через использование оператора EXISTS для проверки существования записей или объединение нескольких полей в один запрос) и тд. приводит к трудностями в тестировании и размыванию ответственности. Что вы думаете на этот счет?
Не понятно, это высокопроизводительное решение по сравнению с чем. Не могли бы вы предоставить конкретные результаты тестов производительности для описанных конфигураций Redis (Sentinel, Cluster, Pub/Sub)? Было бы полезно увидеть метрики, такие как время отклика и пропускная способность. А также сравнение с другими решениями, которые в этих же тестах были бы менее производительны.
Понятно, спасибо за уточнение.
Похоже на то, потому что расписывая алгоритм он поплыл)
Вероятно Llama просто не особо докручена, chatgpt последний не затупил)
Не уверен что Lucene умеет такое. Думаю там что-то вроде такого:
Вообще это кстати интересно почему именно Lucene был выбран для такого неатомарного инкремента (если он действительно такой) , кроме того что там быстрые запросы по интервалу, так как другие БД тоже могут в это.
Довольно изящное решение.. Уточните пожалуйста, 200 тысяч обновлений счётчиков в секунду, это ведь get+put (т.е. именно операций 400К+) или только put? И сколько серверов держит такую нагрузку?
Одной из ключевых проблем является чрезмерная зависимость от бенчмарков, которые не всегда отражают реальные условия работы в продакшне. Например, тесты Clickbench, используемые автором, оценивают производительность на ограниченных данных (до 100 ГБ), что далеко не всегда применимо к реальным задачам.
И хотя утверждается о значительном прогрессе в PostgreSQL 17, данные о производительности не подкреплены тестами с большим количеством пользователей и запросов. Также есть недостаток информации о конкретных сценариях, в которых определенные СУБД, такие как MongoDB или SQLite, могли бы превзойти Postgres в плане удобства или масштабируемости. Заявление о том, что Umbra превосходит PostgreSQL за счет своей архитектуры и хеш-таблиц, интересно, но требует большего числа реальных примеров использования.
Обзор бенчмарков также несколько ограничен, так как не охватывает разнообразие типов запросов и реальных нагрузок, что делает выводы о производительности не вполне объективными.
В целом классно что получилось достигнуть такой мощный прирост, за это респект. С другой стороны это размывание бизнес-логики между слоями приложения, в частности, между уровнем базы данных (DAO) и бизнес-логикой, например когда часть логики переносится непосредственно в SQL-запросы (например, через использование оператора EXISTS для проверки существования записей или объединение нескольких полей в один запрос) и тд. приводит к трудностями в тестировании и размыванию ответственности. Что вы думаете на этот счет?
Не понятно, это высокопроизводительное решение по сравнению с чем. Не могли бы вы предоставить конкретные результаты тестов производительности для описанных конфигураций Redis (Sentinel, Cluster, Pub/Sub)? Было бы полезно увидеть метрики, такие как время отклика и пропускная способность. А также сравнение с другими решениями, которые в этих же тестах были бы менее производительны.