Лучшая практика чтения новейших строк из базы данных

Question

У меня есть таблица, в которой хранится местоположение моего пользователя очень часто. Я хочу часто запрашивать эту таблицу и возвращать новые строки, которые я не читал.

Что было бы лучшим способом для этого. Мои идеи:

1. Добавить флаг boolean, запросить все результаты там, где это ложь, вернуть их, а затем обновить их ВСЕ. Это может замедлить работу с дополнительной записью
2. Сохраните идентификатор последней строки чтения на стороне клиента и запросите строки, большие, чем это. Только проблема в том, что мой клиент может потерять свое место
3. Некоторого поток данных

есть, в конечном счете быть несколько users и readers из мест, так что это не будет несколько масштабироваться

Answer 1

Если то, что у вас есть это база данных SQL, в которой хранятся строки вещей. Я бы предложил что-то вроде варианта 2.

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

У этого есть проблема «потерять свое место». Если клиент ДОЛЖЕН читать каждую опубликованную строку, я бы либо удалил их после обработки, либо имел флаг в базе данных, чтобы указать, что они были обработаны. Если клиенту просто нужно перезапустить чтение текущих данных, тогда я сделаю так, как указано выше, но инициализирую время с самой последней существующей строкой.

Если вы ДОЛЖНЫ обрабатывать каждую запись, не ограничиваясь только базой данных, то о чем вы говорите, это очередь сообщений. Если вам нужно иметь доступ к отдельным точкам данных после обработки, то одним шагом обработки сообщений может быть вставка в базу данных для последующего запроса (в дополнение к тому, что это делается при чтении данных).

Редактировать в комментариях:

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

С другой стороны, когда я делал подобное, у меня был хороший успех, используя MQTT для передачи данных и для «живых» обновлений. Это протокол pub/sub messaging. У вас может быть процесс подписки на задний конец и пересылка данных в базу данных, в то время как то, что хочет данные, часто может подписаться непосредственно на поток данных для живых обновлений. Существует также возможность удерживать последнее опубликованное сообщение и пересылать его новым подписчикам, чтобы вы не начинали полностью пустым.