#azure #caching #azure-table-storage #azure-redis-cache
#azure #кэширование #azure-table-storage #azure-redis-cache
Вопрос:
В настоящее время мы используем Redis в качестве постоянного кэша для нашего веб-приложения, но из-за ограниченной памяти и стоимости я начинаю задумываться о том, является ли хранение таблиц жизнеспособным вариантом.
Данные, которые мы храним, представляют собой довольно простые данные json с четким ключом из 2 частей, который мы будем использовать для раздела и ключа строки в табличном хранилище, поэтому я надеюсь, что это будет означать быстрый запрос.
Я ценю, что один находится в памяти, а другой отсутствует, поэтому хранение таблиц будет немного медленнее, но по мере масштабирования я считаю, что только один процессор обслуживает данные из кэша Redis, тогда как с хранилищем таблиц у нас не было бы этой проблемы, поскольку это зависело бы от количества запущенных нами веб-серверов.
Есть ли у кого-нибудь опыт использования хранилища таблиц таким образом или сравнения между 2.
Я должен добавить, что мы используем Redis очень минималистичным способом get / set и ничего более, мы удаляем наши собственные данные и в противном случае оставляем удаление Redis, когда в нем заканчивается место.
Комментарии:
1. Я знаю, что прошло некоторое время — что вы здесь делали? Я рассматриваю тот же ход. Стоимость Redis (подключения и хранилища) делает хранение таблиц очень разумным вариантом (учетные записи хранения, таблицы и разделы позволяют легко обходить любые ограничения)
2. Мы использовали таблицы хранения для кэширования, время отклика обычно составляет однозначные цифры в миллисекундах, поэтому оно было достаточно быстрым для наших нужд. Единственное, о чем следует помнить, — это слишком много обращений к хранилищу, поскольку оно не имеет обычных основ кэша с точки зрения автоматического истечения срока действия, подписки на изменения и т. Д. многое из этого вам нужно реализовать самостоятельно в коде. Вам нужно тщательно продумать, как вы группируете, истекаете и устареваете данные, иначе это может привести к чрезмерным запросам на хранение.
3. Но в конечном итоге, даже если срок действия истек, это вызов службы. Мой код по-прежнему вызывает Redis для объекта кэша, а затем Redis сообщает «нет, истек», после чего я вызываю базовую службу, а затем повторно заполняю Redis. Так что я не понимаю, как это сведено к минимуму. Реальным недостатком является автоматическое истечение срока действия, поэтому может использоваться недопустимое хранилище, которое потребует некоторого обслуживания. Также сценарии pub / sub — которых у меня нет ATM. (и ограничения запросов для очень загруженных сайтов). Опять же, это проблема с Redis и требует $$$ для перехода на более крупные сервисы, поэтому я вижу похожие проблемы там.
4. Да, извините, я имел в виду что-то родное для Redis, например, автоматическое истечение срока действия, pub / sub и т. Д. Что касается группировки, я просто упомянул об этом, чтобы вы избежали первоначальных ошибок, которые мы допустили, когда элементы кэша были слишком детализированными, что привело к увеличению количества запросов кеша, чем нам нужно. В то время мы были новичками в кэшировании, поэтому, оглядываясь назад, они были очевидными соображениями дизайна для всех, кто хотя бы раз в своей карьере кэшировал веб-сайт
Ответ №1:
Это довольно широкий вопрос, требующий обсуждения. Но с объективной точки зрения это атрибуты, которые вы должны учитывать при принятии решения о том, какие использовать:
- Хранилище таблиц — это надежное хранилище ключей / значений. Таким образом, срок действия содержимого не истекает. Вы будете отвечать за очистку данных.
- Хранилище таблиц масштабируется до 500 ТБ.
- Redis масштабируется по горизонтали на нескольких узлах (или масштабируется с помощью службы Redis). В отличие от этого, хранилище таблиц обеспечивает до 2000 транзакций в секунду для раздела, 20 000 транзакций в секунду для учетной записи хранения, а для увеличения масштаба вам потребуется использовать несколько учетных записей хранения.
- Стоимость хранения таблиц будет значительно ниже, чем у виртуальной машины или службы Redis.
- Redis предоставляет функции, выходящие за рамки таблиц хранилища Azure (такие как pub / sub, удаление содержимого и т. Д.).
- Как хранилище таблиц, так и кэш Redis доступны через конечную точку с множеством оболочек SDK для API, зависящих от языка.
Комментарии:
1. Привет, ценю ответ и информацию. Ключевым моментом для меня является снижение затрат, но если это приведет к снижению производительности на 1000%, то это менее привлекательно. На самом деле я не ищу мнения, больше надеясь на информацию от любого, кто, возможно, пробовал это или кто использовал оба и имеет приблизительное представление о том, как они сравнивают производительность. Моя доступность для разработчиков довольно ограничена, поэтому я хочу посмотреть, является ли она хотя бы жизнеспособной, тогда я начну с проверки концепции, но не хочу тратить драгоценное время, если это явно не для начинающих. В частности, если есть какая-то ключевая вещь, которую я упустил из виду при использовании таблиц для веб-кэша, Ta.
2. Я действительно думаю, что это зависит от вас, чтобы проверить, какой из них лучше всего подходит для вас. Производительность будет зависеть от вашего приложения, размера вашей виртуальной машины / службы приложений и т. Д.
Ответ №2:
Я нахожу некоторые метрики о Azure redis и таблице, надеюсь, что это может вам помочь.Существует видео о Azure Redis, которое также включает демонстрацию для сравнения между хранилищем таблиц и redis примерно с 50-й минуты в видео. Возможно, это может быть в качестве ссылки. Но подробная производительность зависит от вашего приложения, записей данных и так далее. Стоимость хранилища таблиц зависит от емкости хранилища таблиц, пожалуйста, обратитесь к деталям. Это намного дешевле, чем redis.
Комментарии:
1. Привет, это интересно, так как в примере он использует Redis для получения ключа раздела и строки, а затем переходит в хранилище таблиц, и это все еще очень быстро, учитывая его вызов Redis Table, и поскольку мы будем запрашивать хранилище таблиц по разделам и строкам, и нам никогда не понадобятся более сложные запросы, это делаетскорость меньше проблем. Приветствия.
Ответ №3:
Существует много различий, которые могут вас заинтересовать, включая цену, производительность и набор функций. И, сохраняемость данных и согласованность данных.
Поскольку redis является хранилищем данных в памяти, это довольно дорого. Это сделано для того, чтобы вы могли получить низкую задержку. Ознакомьтесь с часто задаваемыми вопросами по планированию Azure здесь, чтобы получить общее представление о производительности redis в смысле пропускной способности. Часто задаваемые вопросы по планированию Azure Redis
В Redis есть дополнительная функция сохранения, которую вы можете включить, если хотите, чтобы ваши данные сохранялись и восстанавливались во время редких простоев серверов. Но у него нет надежной гарантии согласованности.
Хранилище таблиц Azure не является решением для кэширования. Это решение для постоянного хранения данных, которое постоянно сохраняет данные на каком-либо диске. Исторически (отказ от ответственности, я не искал последние и самые высокие показатели производительности) у него гораздо более высокая задержка чтения и записи. Это также строго модель хранилища ключ-значение (с ключами из двух частей). Значения могут иметь свойства, но со многими строгими ограничениями, такими как размер объектов, которые вы можете хранить, длина свойств и так далее. Эти ограничения являются негибкими и болезненными, если ваше приложение сталкивается с ними.
Redis имеет более широкий набор функций. Он может использовать ключ-значение, но также имеет множество других структур данных, таких как наборы и списки, и многие приложения могут найти способы извлечь выгоду из этой дополнительной гибкости.
См . раздел «Введение в Redis» (redis docs) .
CosmosDB может быть еще одной альтернативой, которую следует рассмотреть, если вы в первую очередь ориентируетесь на технологии Azure. Это довольно дорого, но довольно быстро и многофункционально. В то же время он в первую очередь предназначен для постоянного хранилища.