Суть такова, что есть сервис, который сдаёт в аренду помещения (их сейчас порядка ~50,000).
Каждое помещение клиент может арендовать на тот промежуток дней, который сам выберет (для этого есть календарь - т.е для каждого дня владелец помещения может назначать разные цены на его усмотрение).
Вся суть подсчёта цены: p = f( check_in, check_out, x ), где check_in, check_out - это даты чек-ина и чек-аута, соотвественно,
а x - число от 1 до 10.
Буквально недавно закончили со подключением достаточно сложных систем скидок и доп.услуг и теперь подсчёт цены как процесс стал очень нетривиальным - не стану даже описывать эти дебри, просто скажу, что всё печально.
А тут возникла надобность сделать систему сортировки по конечной цене на поисковой странице.
И вот тут я не знаю, что делать - описать все эти процессы в одном MySQL запросе я не смогу (раньше было именно так). Да даже если бы и мог - было бы медленно и неэффективно. Тем более, что цены не обновляются часто - никакого особого смысла их каждый раз считать нет никакого.
Появилась идея рассчитать цены на, скажем, год вперёд для всех помещений.
Т.е пересчитать все возможные комбинации (check_in, check_out, x), закешировать, и по надобности инвалидировать ключи.
Но тут встаёт вопрос - реально ли это вообще?. Быстренько посчитал на бумажке, и вышло, что потребуется порядка
33,580,500,000 ключей, если хранить в key-value хранилище: 366 * 367 / 2 * 10 * 50,000.
И где столько можно хранить?
Или есть какие-то другие, более эффективные решения? Тем более, что память не резиновая.
Может быть вам достаточно будет примерной сортировки.
Рассчитайте некий упрощенный ценовой индекс для каждого объекта и сортируйте по нему.
Можно усложнить и ценовой индекс сделать также зависимым от срока аренды и недели-месяца в году.
Задача во многом аналогична тому что делают многочисленные поисковики билетов, интересно как это делают они.
Простой
