HighLoad.org – блог о высоких нагрузках
HighLoad.org > Cassandra, как коммуникационная среда - инструмент регистрации и обнаружения сервисов

Cassandra, как коммуникационная среда - инструмент регистрации и обнаружения сервисов
2010-03-04 00:52 my_fess  
Несколько недель назад, обдумывая какую систему регистрации/обнаружения сервисов использовать для платформы развертывания масштабируемых приложений, я осознал, что для организаций среднего размера со сложным набором сервисов единственный вариант — построение с нуля. Я также обнаружил, что многие пользователи AWS/EC2 уже используют S3 и SimpleDB для публикации/обнаружения сервисов. Это исследование в конечном счете привело меня к рассмотрению Cassandra в качестве хранилища данных для реестра сервисов в корпоративной сети.
Здесь приведены некоторые мои наблюдения при использовании Cassandra в этом качестве. Приветствуется обратная связь от читателей, если вы думаете, что я делаю что-то неправильно или проект может быть улучшен.
  • Самая большая проблема, которую я заметил у Cassandra, отсутствие инвертированного индекса. Для этого существует воркэраунд, про который я уже писал в блоге. Позже я понял, что есть Lucandra, на которую стоит обратить внимание.
  • Я использовал очень простую структуру пространства ключей... (Несколько строк конфигурации для упрощения пропущены).
  • Использование «OrderPreservingPartitioner» выглядит важным для выполнения «range scans». OrderPreservingPartitioner" держит вместе объекты с похожими ключами, что позволяет объединять их чтение/запись. По умолчанию Cassandra случайным образом распределяет объекты по кластеру, что работает хорошо, если только у вас есть несколько узлов.
  • Я планирую использовать это приложение поверх двух датацентров. Лучший способ для зеркалирования данных между датацентрами в Cassandra — это использование «RackAwareStrategy». Если вы выберете эту опцию, Cassandra будет пытаться брать реплики каждого токена из разных датацентров/стоек. Алгоритм по умолчанию использует IP адреса для определения того, что 2 узла являются частью одной стойки/датацентра, но есть и другие интересные способы для этого.
  • Некоторые API существенно поменялись между версиями, которые я пробовал. Разработчики Cassandra напомнят вам, что ожидаемое в продукте, версия которого все еще 0.5. Однако, меня изумляет тот факт, что Facebook, Digg и теперь Twitter используют Cassandra в продакшене без согласования всего-всего.
  • В конце-концов я смог построить «тонкое» java веб приложение — фронтенд для Cassandra, который предоставляет REST/json интерфейс для регистрации/обнаружения служб. Также это приложение управляет инвертированными индексами.
    • Прямой доступ к Cassandra от удаленных сервисов был отключен по причинам безопасности/стабильности.
    • Приложение использует DNS для балансировки нагрузки между несколькими серверами.
  • Начальные тесты производительности на этом кластере не впечатляли, потому что я забыл, что все мои запросы обращались к одному и тому же узлу. Правильный способ для проверки пропускной способности Cassandra — это балансировка нагрузки между всеми узлами.
    • Также я обнаружил, что по умолчанию установлен очень подробный режим логирования «DEBUG». Его отключение значительно ускорило время отклика приложения.
  • Интересно было также поиграться с различными уровнями корректности чтения и записи, особенно когда я начал убивать узлы, просто чтобы увидеть сбой приложения. В этом и заключается настройка CAP.
  • Из-за интересной проблемы связанной с «eventual consistency», Cassandra не удаляет окончательно данные, которые были помечены для удаления или намеренно изменены. В конфигурации по умолчанию данные хранятся 10 дней до окончательного удаления из системы.
  • Некоторая документация по основным функциональным аспектам Cassandra существует, но было бы здорово, если бы ее было больше.
Cassandra разрабатывалась как масштабируемое, высокодоступное хранилище данных. Но благодаря таким интересным возможностям, как self-healing и «RackAware», она может также служить коммуникационной средой.

Автор статьи: Royans Tharakan Дата: 27 февраля 2010 Оригинал статьи


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD