Azure: Redis и Table Storage для веб-кэша

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

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

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

Есть ли у кого-нибудь опыт использования хранилища таблиц таким образом или сравнения между 2.

Я должен добавить, что мы используем Redis очень минималистским способом получения/установки и ничего более, мы удаляем наши собственные данные и, если это не удается, оставляем удаление Redis, когда ему не хватает места.


azure caching azure-table-storage azure-redis-cache
person Simon    schedule 18.10.2016    source источник
comment
Я знаю, что это было давно - что ты здесь делал? Я обдумываю такой же ход. Стоимость Redis (подключения и хранилище) делает хранилище таблиц очень разумным вариантом (учетные записи хранения, таблицы и разделы позволяют легко обойти любые ограничения).   -  person Tony Basallo    schedule 21.11.2020
comment
Мы использовали таблицы хранения для кэширования, время отклика обычно составляет однозначные миллисекунды, поэтому этого было достаточно для наших нужд. Единственное, о чем следует помнить, это слишком много обращений к хранилищу, поскольку оно не имеет нормальной основы кеша с точки зрения автоматического истечения срока действия, подписки на изменения и т. д. вам нужно реализовать многое из этого самостоятельно в коде. Вам нужно тщательно продумать, как вы группируете, устареваете и устареваете данные, иначе это может привести к чрезмерным запросам на хранение.   -  person Simon    schedule 23.11.2020
comment
Но в конечном итоге, даже если срок истек, это звонок в сервис. Мой код по-прежнему вызывает Redis для объекта кеша, а затем Redis говорит, что нет, срок действия истек, после чего я вызываю базовую службу, а затем повторно заполняю Redis. Так что я не понимаю, как это можно свести к минимуму. Настоящим недостатком является автоматическое истечение срока действия, поэтому вы можете использовать недействительное хранилище, которое потребует некоторого обслуживания. Также сценарии pub/sub, в которых у меня нет банкомата. (и ограничения запросов для очень загруженных сайтов). Опять же, это проблема с Redis и требует $$$ для перехода на более крупные сервисы, поэтому я вижу там похожие проблемы.   -  person Tony Basallo    schedule 24.11.2020
comment
Да, извините, я имел в виду что-то родное для Redis, например автоматическое истечение срока действия, публикацию/подписку и т. д. Что касается группировки, я просто упомянул об этом, чтобы вы избежали первоначальных ошибок, которые мы сделали с точки зрения наличия элементов кэша, которые были слишком гранулированными, что привело к значительно большему количеству запросов кэша. чем нам было нужно. В то время мы были новичками в кэшировании, поэтому, оглядываясь назад, они были очевидными соображениями дизайна для тех, кто хоть раз в своей карьере занимался кэшированием веб-сайтов :-)   -  person Simon    schedule 24.11.2020

Ответы (3)


arrow_upward
17
arrow_downward

Это довольно широкий вопрос. Но с объективной точки зрения вот те атрибуты, которые следует учитывать при принятии решения о том, какие из них использовать:

  • Хранилище таблиц — это надежное хранилище ключей и значений. Таким образом, срок действия контента не истекает. Вы будете нести ответственность за очистку данных.
  • Хранилище таблиц масштабируется до 500 ТБ.
  • Redis масштабируется по горизонтали на несколько узлов (или масштабируется через службу Redis). Напротив, Table Storage обеспечивает до 2000 транзакций в секунду на секцию, 20 000 транзакций в секунду на учетную запись хранения, а для увеличения масштаба вам потребуется использовать несколько учетных записей хранения.
  • Хранилище таблиц будет иметь значительно меньшую стоимость, чем виртуальная машина или служба Redis.
  • Redis предоставляет функции, выходящие за рамки таблиц хранилища Azure (такие как публикация/подписка, вытеснение контента и т. д.).
  • И Table Storage, и Redis Cache доступны через конечную точку с множеством оболочек SDK для конкретных языков вокруг API.
person David Makogon    schedule 18.10.2016
comment
Привет, спасибо за ответ и информацию. Ключевым для меня является снижение затрат, но если это достигается при повышении производительности на 1000%, то это менее привлекательно. На самом деле не ищу мнения, больше надеясь на информацию от тех, кто, возможно, пробовал это или использовал оба и имеет приблизительное представление о том, как они сравнивают производительность. Доступность моего разработчика довольно ограничена, поэтому я хочу увидеть, по крайней мере, жизнеспособна ли она, тогда я начну с проверки концепции, но не хочу тратить драгоценное время, если это явно не начало. В частности, если есть какой-то ключевой момент, который я упустил из виду при использовании таблиц для веб-кэша, Ta. - person Simon; 18.10.2016
comment
Я действительно думаю, что это зависит от вас, чтобы сравнить, чтобы увидеть, какой из них лучше всего подходит для вас. Производительность будет зависеть от вашего приложения, размера вашей виртуальной машины/сервиса приложения и т. д. - person David Makogon; 18.10.2016

arrow_upward
5
arrow_downward

Я нашел несколько материалов о лазурном Redis и таблице, надеюсь, они помогут вам. the-Redis-Cache-Preview-with-Saurabh-Pant" rel="noreferrer">видео об Azure Redis, которое также включает демонстрацию для сравнения между хранилищем таблиц и Redis примерно с 50-й минуты видео. Возможно, это может быть как ссылка. Но производительность деталей зависит от вашего приложения, записей данных и так далее. Стоимость хранилища таблиц зависит от емкости хранилища таблиц, см. подробности. Это намного дешевле, чем redis.

person Tom Sun - MSFT    schedule 19.10.2016
comment
Привет, это интересно, так как в примере он использует Redis для получения раздела и ключа строки, а затем переходит к хранилищу таблиц, и это все еще очень быстро, учитывая вызов Redis+Table, и поскольку мы будем запрашивать хранилище таблиц по разделам и строкам и никогда не нужны более сложные запросы, которые делают скорость менее важной. Ваше здоровье. - person Simon; 19.10.2016

arrow_upward
1
arrow_downward

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

Поскольку Redis — это хранилище данных в памяти, оно довольно дорогое. Это сделано для того, чтобы вы могли получить низкую задержку. Ознакомьтесь с часто задаваемыми вопросами по планированию Azure здесь, чтобы получить общее представление о производительности Redis с точки зрения пропускной способности. Часто задаваемые вопросы по планированию Azure Redis

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

Хранилище таблиц Azure не является решением для кэширования. Это решение для постоянного хранения, которое постоянно сохраняет данные на каком-либо диске. Исторически (отказ от ответственности, я не искал последние и самые высокие показатели производительности) он имеет гораздо более высокую задержку чтения и записи. Кроме того, это строго модель хранилища "ключ-значение" (с ключами, состоящими из двух частей). Значения могут иметь свойства, но со многими строгими ограничениями, касающимися размера объектов, которые вы можете хранить, длины свойств и т. д. Эти ограничения негибкие и болезненные, если ваше приложение сталкивается с ними.

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

См. «Введение в Redis» (redis docs).

CosmosDB может стать еще одной альтернативой, если вы предпочитаете в первую очередь технологии Azure. Это довольно дорого, но достаточно быстро и многофункционально. Хотя в первую очередь он предназначен для постоянного хранения.

person Tim Lovell-Smith    schedule 11.01.2021