Плохо ли хранить члены JSON в Redis GEOADD?

Question

Мое приложение должно обрабатывать множество объектов (100 000 и более) с местоположением и должно отображать их только в пределах заданного радиуса. Я в основном храню все в SQL, но использую Redis для кеширования и оптимизации (в основном GEORADIUS).

Я добавляю объекты, как в следующем примере (не совсем так, я использую Laravel Framework со встроенным фасадом Redis, но он делает то же, что и здесь, в фоновом режиме):

GEOADD k 19.059982 47.494338 {\"id\":1,\"name\":\"Foo\",\"address\":\"Budapest, Astoria\",\"lat\":47.494338,\"lon\":19.059982}

Это плохая практика? Или это окажет негативное влияние на производительность? Должен ли я хранить только идентификаторы в качестве члена и сделать следующий запрос, чтобы получить соответствующие объекты?

Answer 1

Это вопрос требований. Нет ничего плохого в том, чтобы хранить необработанные данные в виде элементов, пока они уникальны (и уникальны, учитывая поле "id"). На самом деле это и просто, и эффективно, поскольку все данные возвращаются одним запросом (при условии, что это действительно нужно).

Тем не менее, есть по крайней мере два соображения для хранения данных вне Geoset, и просто "ссылки" на них, когда члены отражают некоторую форму имен своих ключей:

1. Одна структура данных, такая как Geoset, ограничена ресурсами одного сервера Redis. Для хранения большого количества данных и членов может потребоваться больше памяти, чем может обеспечить один сервер, что ограничит масштабируемость этого подхода.

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

3. Когда требуется обновить данные, попытка обновить (например, ZDEL, а затем GEOADD) небольшие его части может стать слишком дорогой. Иметь все снаружи, возможно, в хэше (или, может быть, что-то вроде ReJSON) имеет больше смысла.