Отфильтровать массив строк, выбрав только хранящиеся в БД

яннп
ну отфильтруй свой массив по признаку «строка-в-бд»

отфильтруй свой массив

Вот об этом и вопрос. О самом механизме фильтрации.

Загрузить во временную таблицу и сджойнить?

ну а как ты определяешь, строка в бд у тебя или нет?

Никак еще. Я вот спрашиваю: что с этим справится лучше всего ( mysql, или, может redis, couchdb и т.д). Т.е. технология + методика применения.

пс А вообще, склоняюсь к рантайму.

1000 строк. Т.е тебе нужно всего сделать 1000 запросов? Зачем тут оптимизации? Или тебе постоянно такие вещи нужно делать?

Можешь попробовать select str from tbl where str in (?, ..., ?), но совет про временную таблицу скорее всего будет оптимальней.

Если ты делаешь такие операции часто, то сделай еще одну таблицу c двумя столбцами, если возможно укажи директиву чтобы была в памяти, если СУБД поддерживает. В первом идентификатор операции, уникальный какой-то номера, например UUID, во втором столбце твои строки. А потом уже какой-то JOIN. Данные легко вводить - batch. Легко потом почистить таблицу после операции - удалить все с текущим UUID

Да, это будет типичный запрос.

Ну.. 1000 запросов я в любом случае не планировал. Планировал как-то иначе, более эстетично.

Дополнение: в исходном массиве ~100..1000 строк. В базе ~100k..1kk

Как вариант, хранить со строками хэши и сравнивать но ним. Но вообще не понятно, почему нельзя просто сделать выборку по имеющимся строкам.

select str from tbl where str in (?, ..., ?)

Кстати было у нас на одном проекте, что по безалаберности программиста был запрос с выборкой по in с огромным списком. Это привело к тому, что на оракле при превышении размера списка в около 1000 элементов оракл отказывался его обрабатывать. Там у них даже отдельная ORA ошибка на эту тему есть. Это чисто FYI для ТС если он решит воспользоваться этим вариантом.

с выборкой по in с огромным списком

А что, кстати происходит, если попадутся несуществующие значения, ничего, или ошибка?

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

А сколько примерно времени возвращается выборка по in с огромным списком?

Зависит от многих аспектов, очевидно :) Правильный вопрос: насколько оно быстрее/медленнее других подходов.

Так, например, это будет быстрее, чем выполнять отдельно запрос для каждого значения. Про вариант с временной таблицей - не знаю, умозрительно кажется что тоже быстрее, но я советую погонять тесты на семпловых данных.

Если честно, я не очень понял принцип подхода с временной таблицей.. Мне предлагают записать 1000 строк что ли?

Я попробовал в рантайме, и там это порядка 2мс для 1к элемнтов массива входящих строк и 3кк строк в «БД» (руби). Требует ~600МБ ОЗУ, но 3кк и даже 1кк - это глубокая перспектива. А в других случаях какой примерно порядок величин..?

Если честно, я не очень понял принцип подхода с временной таблицей

По моему vertexua все понятно разъяснил. Создается временная таблица, в нее данные можно грузить как одиночным, там и множественным запросом, а можно подгрузить из файла (если файл на сервере СУБД), но нужно смотреть какие у СУБД для этого возможности. Потом просто джоинишь данные из БД и этой временной таблицы. Результат запроса - список строк, присутствующих в БД и во временной таблице. С джоинаим еще поиграться можно, чтобы, например, выводил все строки из временной таблицы + те строки, которые есть в БД.

в нее данные можно грузить как одиночным, там и множественным запросом

Но ведь это.. долго? Совершенно же неприемлемые величины по времени при указанных вначале темы параметрах.. (для типичного веб-запроса имеется ввиду).

делай асинхронно закидывай данные на сервер, запускай вёркер(как это по русски называется?), по завершении работы уведомляй пользователя

От задачи зависит. Если тебе просто проверить 1000 строк, как указано в ТС, то вообще не понятно почему возник вопрос. Но если предполагается какой-либо рост (как в объемах, так и в логике), то нужно смотреть на альтернативы. Вот загрузка файла во временную таблицу БД - это такая альтернатива. Если данные проверять приходится часто, а грузить редко, то грузить их можно и точечными инсертами. Мы твою задачу не знаем, мы предлагаем варианты.

Мы твою задачу не знаем, мы предлагаем варианты.

Задача: делать это в рамках ответа на пользовательский http запрос.

(Web-development же)

А кастаника спецов по всяким сфинксам и чему-то похожему. Возможно тебе подойдет вариант с поддержанием в актуальном состоянии части данных из БД, по которым нужно делать проверку, в специализированном решении для текстового поиска. Вот тут я точно ничего сказать не могу.

закинули данные, ушли со страницы, на другой странице получили уведомление что данные обработаны

в рамках ответа пользователь ставит задачу в очередь и получает сообщение об успехе или провале

Кстати, присоединяюсь к предложению сделать обработку асинхронной. Вот это реально тема для Web-development же.

Асинхронность это хорошо, но ты же не будешь ждать ответа неделю ^_^ Да и ресурсы надо расходовать не на обогрев помещений..

А чем вам не нравится рантайм? Запихнул миллион строчек в хэш (благо они небольшие), и проверяешь..

Где это асинхронность равна недельному ожиданию? Формируешь задание, которое забирает свободный обработчик, исполняет его, возвращает ответ. Тут дело даже не в том, что это долго, а в том, что тебе придется менять протокол взаимодействия с пользователем. Зато получаешь масштабируемость.

Не нравится тем, что однажды такое решение может не сработать. Выше приводили пример, когда оракл отказывался обрабатывать такой запрос. Если строки изменятся, это может хорошенько сказаться на производительности. Ты это обнаружишь не сразу, а пользователи сразу, т.к. у них страница будет подвисать. В асинхронном варианте пользователь может даже не ощутить проседания производительности. Короче, лучше продумай где ты можешь допустить деградацию производительности и используй эту возможность, чтобы упростить реализацию.

Выясни максимальную длину SQL запроса и максимальное количество значений для IN (...). Если размер массива строк для проверки превышает эти значения разбей на несколько запросов. Т.е. если например БД принимает максимум по 100 значений в IN (...) для 1,000 строк 10 запросов по любому быстрее (вероятно, в 100 раз быстрее) чем 1,000 запросов.

Много запросов к БД это очень медленно, я видел индусский код который выбирал по 100 items на страницу из таблицы и вместо JOIN'а добирал потом данные из другой таблицы в цикле. Всё подвисало на несколько секунд и это на тестовой машине где пользователей больше не было. После замены на 1 запрос загружалось моментально.

Но ведь INSERT намного медленнее SELECT, особенно в InnoDB.

Ещё не забудь добавить INDEX для column в котором содержатся строки.

Нет смысла использовать для временной таблицы InnoDB.

Ок, мы сделаем воркеры и балансировщик, теперь надо выяснить как именно будет работать воркер.

чем 1,000 запросов

Да не собирался я делать 1000 запросов. Но, может, типичные реляционные СУБД слишком тяжелы для данной задачи? Например http://redis.io/commands/hmget

в нее данные можно грузить как одиночным, там и множественным запросом

Но ведь это.. долго?

дык каждую строку так или иначе надо засунуть для проверки в СУБД. Оптом дешевле. Потому временная таблица быстрее всего (или также). Если конечно памяти хватит, если не хватит, придётся делать несколько временных таблиц, всяко лучше, чем по одному.

принимает максимум по 100 значений в IN (...)

а можно пример из практики для этого случая? А то я что-то не пойму, где у вас IN для 100+ значений нужен?

Так автору темы вроде как нужен.

Insert в память быстрее чего угодно. Подозреваю что InnoDB это поддерживает, хотя хз

Временная таблица + JOIN.

Разве INSERT с последующим JOIN'ом может быть быстрее чем просто SELECT .. IN (...)? Думаю уже по количеству запросов к DB такой подход проигрывает.

IN страдает тем, что многие БД ставят жесткое ограничение по количеству элементов. Если INSERT в память. То INSERT в память и JOIN теоретически ничем не отличаются от IN. А в реальной реализации нужно тестировать. Один Поттеринг знает что они там понаписывали

Судя по документации в MySQL оба запроса имеют одинаковое ограничение:

http://dev.mysql.com/doc/refman/5.1/en/comparison-operators.html#function_in

The number of values in the IN list is only limited by the max_allowed_packet value.

Какие оба запроса? INSERT может идти как BATCH. Но драйвер разделит его на несколько запросов если надо. А IN сработает или не сработает и все. Если бы элеметов было меньше, то может быть лучше было использовать IN, так как тогда у нас был бы один round-trip

Короче, я использую redis hash с одинаковым ключом и значением, и HMGET (соответственно).

Автор же написал что в исходном массиве до 1,000 строк.Если каждая строка по 255 символов получаем 255 * 1,000 == 0.24M. Щас глянул у меня в gentoo по default'у в /etc/mysql/my.cnf max_allowed_packet_size = 1M. Если не планируется использоваться скрипт на shared говнохостинге от godaddy разумнее увеличить это значение. Но вообще конечно no sql solution будет эффективнее, что автор и сделал, совершенно правильно.