Які найкращі практики кешування сторінок, керованість яких може змінитись?

Яка найкраща практика кешування сторінок результатів пошуку, впорядкування / властивості яких можна змінити?

Скажіть, у моїй заяві хтось хоче побачити останні 20 тем для обговорення (із 10000). Запит буде надіслано до бази даних через servlet, щоб отримати перші 20 записів із таблиці дискусійних потоків як XML / JSON. Якщо вони хочуть побачити наступні 20, вони переходять на наступну сторінку результатів, і це запускає ще один запит на отримання наступного лоту (ліміт і зміщення = 20 і т.д.).

Щоб зменшити завантаження сервера та очікування клієнта, я хотів би кешувати попередні сторінки результатів. Однак у мене є два питання:

1. Таблиця, в якій відображені результати, може бути впорядкована за більш ніж одним атрибутом (наприклад, дата створення потоку, автор потоку, дата останнього після публікації). Це означає, що твердження типу "перші 20 результатів" не має сенсу без контексту (тобто, що ми замовляємо). Яким чином передня частина повідомляє бек-енду те, що вже завантажено? Моя перша думка полягала в тому, щоб використовувати ідентифікатори для кожного результату, але надсилання їх назад на сервер за подальшими запитами (і фільтрування результатів на їх основі) буде настільки ж трудомістким, як і повернення всього назад наосліп. Як я можу це зробити?
2. Що робити, якщо атрибут попередньо повернутого результату (тобто, найновіший-після-дати) змінився? Тоді нам потрібен спосіб перевірити кожен результат, щоб побачити, чи він був змінений на стороні сервера з моменту його створення. Як я можу це зробити?

Здається , що вам потрібно , це оболонка для всіх параметрів , які визначають сторінку (скажімо, pageNumber, pageSize, sortType, totalCountі т.д.) і використовувати цей DataRequestоб'єкт в якості ключа для вашого механізму кешування. З цього моменту у вас є кілька варіантів обробки кешу:

• Вкажіть якийсь механізм очікування, щоб оновити кеш (залежно від того, як часто змінюються дані).
• Попросіть слухача, який перевіряє зміни бази даних та оновлює кеш на основі вищевказаних параметрів.
• Якщо зміни здійснюються одним і тим же процесом, ви завжди можете позначати кеш як застарілий при кожній зміні і перевіряти цей прапор, коли запитується сторінка.

Перші два можуть включати механізм планування, який повинен спрацьовувати на певному інтервалі або на основі події. Останній може бути простішим, якщо у вас є одна точка доступу до даних.

Нарешті, як зазначав @DanPichelman, він може швидко стати надмірно складним алгоритмом, який переважає переваги, тому переконайтеся, що збільшення продуктивності виправдовує складність алгоритму.

Я б, мабуть, впорався з цим так:

1. Трактуйте різні впорядкування як різні послідовності разом. Додаткову бухгалтерію не варто буде відслідковувати, що має кожен клієнт (або надсилати її знову і знову).
2. Щоразу, коли сторінки користувача відображаються негайно з кешу, одночасно надсилаючи GET на сервер, що включає або хеш, або час останнього доступу. Сервер повертає повну сторінку лише у тому випадку, якщо щось змінилось.
3. Отримайте одночасно з сервера кілька сторінок інтерфейсу користувача. Наприклад, якщо у вашому інтерфейсі відображається 20 записів, запит 60. Мені потрібно протестувати цей, але я сподіваюся, що найефективніший розмір повернення зазвичай буде більшим, ніж середній обсяг даних, показаних на одній сторінці. Це також робить інтерфейс користувача дуже чуйним для деяких перегородок сторінок.
4. Попередньо виберіть результати, коли ви наближаєтесь до кордону. Це допомагає зберегти такі швидкі завантаження з кешу.

Просто думка - у своєму виклику сервера передайте звичайні параметри плюс масив хешей MD5, що представляють кешовані в даний час керовані раніше переглянуті сторінки даних.

Зворотний дзвінок міститиме всі звичні дані для нової поточної сторінки, а також оновлення для будь-яких застарілих раніше переглянутих сторінок. Ви можете використовувати старий хеш як ключ.

Я рекомендую спочатку багато тестів на ефективність та терміни - ваш код клієнта буде набагато складнішим, ніж це було б, якщо ви просто натиснете сервер для кожної сторінки даних. Будьте впевнені, що додаткова складність призводить до значного поліпшення.