Приветствую, коллеги. Интересует способ оптимизации следующей задачи:
С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL

Здравствуйте, MegaMozg, Вы писали:

MM>Приветствую, коллеги. Интересует способ оптимизации следующей задачи:
MM>С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL

Добавить уникальный констрейнт в базу?

Завести какой-нибудь [unordered] set, для хранения последних пяти символов и проверять перед сохранением.

Здравствуйте, Muxa, Вы писали:

M>Завести какой-нибудь [unordered] set, для хранения последних пяти символов и проверять перед сохранением.

Причем, если символы однобайтные, то их можно засунуть в инт64 и ключ у хеша станет тривиальным.

Здравствуйте, MegaMozg, Вы писали:

MM>Приветствую, коллеги. Интересует способ оптимизации следующей задачи:
MM>С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL
фильтр Блума прикрутите.

Здравствуйте, MegaMozg, Вы писали:

MM>Приветствую, коллеги. Интересует способ оптимизации следующей задачи:
MM>С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL

Выше написали, чем UNIQUE не нравится? База за тебя сама проверять будет, она это умеет.

Здравствуйте, MegaMozg, Вы писали:

MM>Приветствую, коллеги. Интересует способ оптимизации следующей задачи:
MM>С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL

добавить поле 5 символов. добавить UNIQUE INDEX
при вставке хвост новой строки копируете в это поле(или просто ищите есть или нет в базе).
если не вставляется значит не уникально.

MM>С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL
для решения этой задачи используют хэши. А уж выбор конкретной реализации за тобой (уникальность, коллизии, поиска и хранения).

Здравствуйте, Vzhyk2, Вы писали:

MM>>С определенной периодичностью (допустим, раз в секунду) по сети приходит текстовая строка. Это строку мы помещаем в некую структуру (как значение поля в экземпляре класса) и пишем в БД. Суть проблемы: перед записью в БД эту строку нужно сравнить на уникальность со всеми предыдущими (сравнивать можно 5 последних символов – это уникальный хвост). Сравнение прямым перебором быстро приводит к потере производительности. Система должна работать сколько угодно времени и обрабатывать десятки тысяч строк. СУБД: SQLite или MS SQL
V>для решения этой задачи используют хэши. А уж выбор конкретной реализации за тобой (уникальность, коллизии, поиска и хранения).
Ну, а если у тебя последние 5 байт уникальны, то вот тебе готовый хэш на 40 бит (можешь поизвращаться и ужать до 32, например, или не страдать и отвести на хеш 64 бита).

Здравствуйте, kov_serg, Вы писали:

_>фильтр Блума прикрутите.

Как-то меня смущает:

При этом существует возможность получить ложноположительное срабатывание (элемента в множестве нет, но структура данных сообщает, что он есть)

Т.е. у топик-стартера приедет строка, блум скажет "оно есть" и отбросит. А в базе такого нет реально.

Здравствуйте, vaa, Вы писали:

vaa>добавить поле 5 символов. добавить UNIQUE INDEX
vaa>при вставке хвост новой строки копируете в это поле(или просто ищите есть или нет в базе).
vaa>если не вставляется значит не уникально.

более того можно например добавить ON DUPLICATE и увеличивать счетчик если нужно

Здравствуйте, Mr.Delphist, Вы писали:

MD>Т.е. у топик-стартера приедет строка, блум скажет "оно есть" и отбросит. А в базе такого нет реально.

После "оно есть" можно проверить наверняка. Отсеивает лишние (дорогие) обращения к субд.

Здравствуйте, kov_serg, Вы писали:

_>фильтр Блума прикрутите.

бессмысленное усложнение. Хэш функция на 5 символов, как уже было указано, даёт гарантированное отсутствие ложноположительных и отрицательных срабатываний. Да и хеш мапу не надо "прикручивать", она есть из коробки во многих языках. А фильтр Блума с ростом количества элементов в наборе будет всё чаще выдавать ложноположительные срабатывания. Короче, минусов много, плюсов не обнаружено.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Т.е. у топик-стартера приедет строка, блум скажет "оно есть" и отбросит. А в базе такого нет реально.

SVZ>После "оно есть" можно проверить наверняка. Отсеивает лишние (дорогие) обращения к субд.

У ТС сейчас ручная проверка плюс вставка в БД. Вы предлагаете добавить ещё третью проверку, после которой ещё раз проверять на наличие записи. Потому что ложноположительный ответ для ТС хуже, чем ложноотрицательный.

Здравствуйте, flаt, Вы писали:

SVZ>>После "оно есть" можно проверить наверняка. Отсеивает лишние (дорогие) обращения к субд.

F>У ТС сейчас ручная проверка плюс вставка в БД. Вы предлагаете добавить ещё третью проверку, после которой ещё раз проверять на наличие записи. Потому что ложноположительный ответ для ТС хуже, чем ложноотрицательный.

Я вообще ничего не предлагаю
Я комментирую, зачем нужен Блум.