Распределенное и реплицированное хранилище данных для небольших объемов данных под Windows

Question

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

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

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

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

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

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

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

CouchDB

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

Cassandra

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

* * 1 042 SAN

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

Репликация DFS

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

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

Answer 1

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

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

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

Answer 2

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