Блог

Мы ищем хорошее решение проблемы кэширования. Мы хотели бы распределить относительно небольшой объем данных (возможно, 10 гигабайт) между кластером веб-серверов таким образом, чтобы:

1. Данные реплицируются на все узлы
2. Данные являются постоянными
3. К данным можно получить доступ локально

Наша мотивация для решения проблемы кэширования заключается в том, что в настоящее время у нас есть единственная точка отказа: база данных SQL Server. К сожалению, мы не можем настроить отказоустойчивый кластер для этой базы данных. Мы уже в значительной степени используем Memcached, но мы хотим избежать проблемы, при которой, если узел Memcached выйдет из строя, у нас внезапно возникнет большое количество пропусков в кэше и, следовательно, возникнет огромное количество запросов к одной конечной точке.

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

1. Проверьте наличие данных в Memcached. Если его там нет…
2. Проверьте наличие данных в локальном постоянном хранилище. Если его там нет…
3. Извлекайте данные из базы данных.

При изменении данных ключ кэша становится недействительным на обоих уровнях кэширования.

Мы рассмотрели множество потенциальных решений, но ни одно из них, похоже, не соответствует именно тому, что нам нужно:

CouchDB

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

Cassandra

Это решение, похоже, в основном ориентировано на пользователей с большими требованиями к хранилищу. У нас большое количество пользователей, но небольшие объемы данных. Cassandra, похоже, способна поддерживать n количество узлов для отказа, но 100% репликация между узлами, похоже, не то, для чего она предназначена; вместо этого, она больше ориентирована только на распространение.

SAN

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

Репликация DFS

Простой поиск в Google показал это. Похоже, оно делает то, что мы хотим; оно синхронизирует файлы на всех узлах кластера репликации. Но в рекламном тексте создается впечатление, что это скорее система для обеспечения копирования документов в разные офисные расположения. Кроме того, у него есть ограничения, такие как максимальное количество файлов, которые нам не подошли бы.

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

Мы уже несколько месяцев успешно используем Riak в рабочей среде для решения проблемы, которая несколько похожа на то, что вы описываете. Мы также оценивали CouchDB и Cassandra ранее.

Преимущество Riak в такого рода проблемах imo заключается в том, что распределение и репликация данных лежат в основе системы. Вы определяете, сколько копий данных в кластере вам нужно, и оно берет на себя все остальное (это, конечно, немного сложнее, чем это, но в этом суть). Мы добавляли узлы, удаляли узлы, у нас были проблемы с узлами, и это оказалось на удивление устойчивым.

В других вопросах это очень похоже на Couch — ориентированный на документы, интерфейс REST, Erlang.

Вы можете проверить hazelcast. Оно не сохраняет данные, но обеспечивает отказоустойчивую систему. Каждый узел может иметь несколько узлов для резервного копирования своих данных на случай сбоя узла.