У нас есть вариант использования для кэширования 300+ миллионов таких данных, каждая из которых имеет уникальный ключ.
Я знаю, что это неортодоксально, но в моей компании было предложено использовать DNS в качестве быстрого распределенного кеша для небольших (<512 байт) фрагментов данных.
Запись DNS будет выглядеть так: {Ключ}. {Модуль хешированного ключа} .mycompany.local.
то есть U5333145311.1.mycompany.local
Мы будем делать запросы со скоростью от 5000 до 7500 в секунду с 10 до 15 серверов.
Мы будем обновлять каждый DNS-сервер через файлы зоны.
Поскольку я программист, все это для меня в новинку
Спасибо
Обновление: данные представляют собой массив от 1 до 30 целых чисел (не 512 КБ, извините), поэтому он очень маленький. Моему техническому директору, который пришел из сетевых операторов, понравилось это решение, потому что это известная, зрелая система и встроенная отказоустойчивость, и он может использовать сетевые операторы для управления ею. Я очень подозрительный, но непредубежденный.
DNS имеет смысл в некоторых случаях:
Широко распространенные данные
Например, черные списки DNS эффективны, потому что инфраструктура кэширования уже существует рядом с пользователями (то есть их интернет-провайдером), или для крупных пользователей они могут легко запускать специальное программное обеспечение, такое как (rbldnsd). Однако дело в том, что он использует существующий широко распространенный протокол.
Небольшие ответы (около 500 байт максимум)
Самые интересные вещи, которые люди распространяют через DNS, невелики, и часто даже наличия или отсутствия записи достаточно (например, DNSBL сигнализирует о том, что IP-адрес плохой, или что-то, что сигнализирует о том, что контрольная сумма этого файла «плохая»).
Я написал это: https://dgl.cx/wikipedia-dns, и это в значительной степени расширяет пределы размеров ответов, которые вы можете безопасно выполнять в DNS. Не все реализуют или поддерживают EDNS0, и, как кто-то сказал, после того, как вы вернетесь к TCP, преимущества отсутствия состояния исчезнут.
Как говорили другие, мне кажется, что вам будет лучше с чем-то вроде memcached. Пытаться ограничить себя DNS кажется глупым, когда он предназначен для внутреннего использования. Если у вас есть контроль над клиентом, вы можете легко справиться с аварийным переключением и балансировкой нагрузки лучше, чем сам DNS.
Поскольку я технический директор скептика, я хотел бы немного раскрасить обсуждение.
Как упоминал Гэри, приложение должно иметь возможность публиковать очень большой манифест. Манифест будет разделен на несколько (30-100) групп. Каждый ключ имеет в среднем около 55 байтов, но может быть намного больше.
Какой бы продукт мы ни выбрали, он должен поддерживать следующее:
1) Полное резервирование и балансировка нагрузки 2) Большой объем транзакций (15-20 тысяч операций чтения / сек) с временем отклика менее 500 мс.
Приятно иметь: 1) Иерархическую структуру 2) Срок действия записи 3) Самоописывающуюся топологию.
DNS пришел в голову только после того, как подумал об использовании UDP вместо TCP для извлечения данных из распределенного кеша в памяти. Естественно, DNS - одно из самых старых и крупнейших приложений DNS.
Известно, что DNS поддерживает файлы зон с очень большим количеством записей. Например .com. в конце концов, это файл зоны (хотя и распределен по множеству серверов по всему миру). Также известно, что он поддерживает очень высокий уровень трафика.
Мы провели несколько предварительных тестов DNS. Мы загрузили файл одной зоны с 10M TXT-записями с репрезентативным объемом данных. Затем с другого сервера в той же локальной сети мы выполнили тестирование 300 000 запросов в многопоточном режиме и получили около 5 000 запросов в секунду. Сервер и клиент почти не дрогнули во время теста. Мы либо сталкиваемся с узкими местами в самом приложении для тестирования, либо в сетевом стеке на клиенте.
Меня заинтриговал DNS, потому что он изначально поддерживает все, что я хочу, и поддерживает это уже много лет. Мне нравятся следующие особенности:
Zone Delegation - we can define which server(s) handle particular partitions. For example 1.mycompany.local is handled by servers 10.1.1.1 and 10.1.1.2.
Redundancy - DNS was built with resiliency and redundancy in mind. It can also be easily load balanced.
Performance - Proven to support high request volumes
С учетом всего сказанного, DNS действительно звучит как странный инструмент для использования в качестве кеша. Если он в конечном итоге пройдет этап выбора, мы будем использовать его только во внутренней локальной сети, и он не будет находиться в том же DNS, что и любые другие наши внутренние или внешние системы DNS. С одной стороны, мы можем захотеть поделиться данными, которые мы храним, со сторонними партнерами. DNS - это хорошо известная сущность, от которой любой может легко запросить передачу зон.
Спасибо за ваш постоянный отзыв.
1 - возможно, но не рекомендуется
2 - странное поведение кеширования, небезопасно, нигде нет поддержки
3 - без понятия
По сути, в memcached есть готовое решение: http://www.danga.com/memcached/
В конце концов, это неплохая идея.
Если речь идет о производительности, убедитесь, что ответ подходит к одному пакету udp (в противном случае он вернется к более медленному tcp). Установите значения TTL с умом в зависимости от того, как часто вы хотите обновлять записи.
Существует (стандартный) способ динамического обновления записей, который может быть хорошим, если вы делаете это из программы.
если ваша запись в DNS - key.modulus, какие данные? IP-адрес? я что-то упускаю?
Используйте memcached. Он предназначен именно для этой цели. Если вы кэшируете данные, не стоит беспокоиться, когда данные сбрасываются. Если сервер исчезнет, клиенты продолжат использовать другие серверы, и это будет считаться промахом в кэше. Есть клиенты, которые будут повторно хешировать в случае отказа узла. Я думаю, last.fm кое-что поработал.
Если вам нужны надежные данные, вы можете посмотреть что-то вроде memcachedb, которое использует бэкэнд berkerleyDB, а не память и будет выполнять репликацию между двумя узлами.
это вообще возможно?
Да. Я предлагаю вам посмотреть записи TXT для хранения этой информации
какие подводные камни?
Точно сказать не могу
как мне определить размер DNS-серверов.
Не уверен, но насколько я понимаю, DNS - это сервис с довольно низкими требованиями, использующий UDP для обработки запросов и ответов - поэтому клиент должен определить, получил ли он ответ или нет, и повторно спросить, был ли он неудачным. .
Первым признаком того, что ваш DNS не работает, будут спорадические сбои поиска в масштабах всего предприятия.
Также обратите внимание, что почти каждая компьютерная система, делает эти запросы будут кэшировать результат в течение 30 минут или до значения ttl записей, если оно меньше 30 минут. Поэтому потребуется осторожное обращение с этими значениями.
Раньше я размещал меню столовой на сервере finger, чтобы все могли видеть меню дней
<сосать яйца> Я бы также посоветовал вам написать свою программу с учетом конкретных серверов / групп и не полагаться на DNS-сервер по умолчанию: O </ suck egg>
Дополнительная информация о требованиях к доступу / обновлению будет полезна для составления более информированного мнения.
По сравнению с самим DNS, он в основном оптимизирован для относительно статических данных, которые меняются редко / медленно. Кроме того, по большей части он настроен для работы с относительно небольшим объемом данных с точки зрения одного сервера / зоны. Масштабируемость он получает в основном за счет промежуточного кэширования (TTL), а также за счет распределенной древовидной структуры всемирной «базы данных» через серверы каждой организации. Дублирующиеся DNS-серверы нужны больше для повышения доступности ... а не для распределения рабочей нагрузки (хотя это может иметь место в некоторых приложениях).
Ваше приложение, похоже, противоречит структуре DNS в двух областях:
DNS можно заставить работать в вашем приложении, но я бы сказал, что он не оптимизирован для этого случая.
Хотя DNS отлично подходит для некоторых вещей, он не подходит для хранения значений размером 512 Кбайт, как бы вы его ни разрезали.
Если у вас есть 300 миллионов данных, которые намного меньше (скажем, 1000 байт), DNS (с пакетами по 1280 байт) может быть хорошей идеей.
Авторитарный сервер PowerDNS может быть отличным способом опубликовать такие данные, например, с помощью серверной части PIPE.
Но для данных размером 512 Кбайт DNS совершенно не подходит для ваших нужд.
Я никогда не тестировал DNS в такой степени, но я бы очень осторожно отнесся к этому подходу. Это, конечно, неортодоксально и достаточно безумно, чтобы это могло сработать, но подход похож на использование молотка для поворота винта - конечно, вы можете это сделать, если все настроите правильно, но это неподходящий инструмент для работы.
В худшем случае вы поставите DNS компании на колени, и кто-то должен будет объяснить генеральному директору, почему он не может получить свою электронную почту.
Я предлагаю распространяющийся кеш DNS, который просто сохраняет разрешенные адреса на ваш жесткий диск. В linux есть pDNSd и DNSmasq. Оба очень просты в установке и рекомендуются во избежание разрешения адресов на ваших серверах.