Как делать много проверок?

Question

[Кирилл Горелов]

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

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

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

Как решают задачи подобные задачи?
Просто либо нужно много делать запросов, либо в памяти много данных держать...

Comments

[FanatPHP]

да

[Константин Б.]

Вопрос необходимо конкретизировать)

[Vitsliputsli]

Кирилл Горелов, читайте порциями, кол-во данных в порции подбирайте экспериментально.

[Кирилл Горелов]

Константин Б., oxidmod, ThunderCat

Что касается конкретики, была задача, принять от апи список "кликов" и список "конверсий". ID конверсий и ID кликов в своих таблицах повторялись, и их нужно было не добавлять.

Я брал из таблицы список id, и уже проверял есть или нету.

Хотя мне прям сейчас пришла идея, что можно было бы хранить в таблице, id с уникальным значением, и каждый раз выкидывать исключение, если такая запись есть.... То есть сама mysql выдавала бы ошибку.....

Но это достаточно простой вариант, что если нужно не проверить проверить уникальность записи в таблице, а например что например сумма значений кликов больше или меньше суммы конверсий??

Answer 1

[ThunderCat]

запихнуть в БД, но при этом сначала сверить.

Что и с чем?

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

Наихудший из возможных вариантов, конечно же, не зависимо от того что вы там сверяете - это полный ахтунг.

Но проблема появляется, когда такая таблица разрастается и одновременно данных много приходит.

Логично и ожидаемо

Делать каждый раз проверку, напрямую в БД, мне кажется, что тоже не особо рационально,

Сильно зависит от проверки, как и от задачи в целом, которую вы так и не озвучили, что вы там проверяете...

Как решают задачи подобные задачи?

По разному, немного конкретики сильно поможет подобрать верный алгоритм работы.

Comments

[ThunderCat]

@Kirill-Gorelovчто

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

Насчет уникального id - да, чаще всего так и делается, из апи в таблицу вносится уникальный id, после чего в запросе достаточно указать что дублирующиеся ключи надо игнорировать/апдейтить, а если внесение подразумевает логику с вычислением - не нужно хранить все это в памяти, есть group by + count(), sum() и другие агрегирующие функции, выборка по которым будет быстрой и вернет 1-2 значения, а не всю таблицу.

Answer 2

[Stalker_RED]

Хотя мне прям сейчас пришла идея, что можно было бы хранить в таблице, id с уникальным значением, и каждый раз выкидывать исключение, если такая запись есть.... То есть сама mysql выдавала бы ошибку.....

INSERT ... ON DUPLICATGE KEY IGNORE

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

Но ведь это нужно делать не во время вставки?

SELECT count(*) FROM `my_tbl` WHERE `date` BETWEEN(...) AND type='conversion'
SELECT count(*) FROM `my_tbl` WHERE `date` BETWEEN(...) AND type='click'

Ну и если таких данных будет реально много, то можете посмотреть в сторону специализированных решений типа clickhouse.