NoSQL в Netflix

Авторы: Netflix Technology Blog
Автор перевода: Д.В. Кубашевский
Источник (англ.): NoSQL at Netflix — The Netflix Tech Blog — Medium

Это Юрий Израилевский, директор облачной и системной инфраструктуры здесь, в Netflix. Так как Netflix перешёл на облака, нам нужно было найти соответствующий механизм, чтобы хранить и запрашивать данные в нашей высокораспределённой инфраструктуре. Наша цель — создать быстрые, отказоустойчивые системы в масштабе Интернета. Мы поняли, что для того, чтобы достичь эту цель, нам нужно было выйти за пределы ограничений традиционной реляционной модели. В распределённом мире, под управлением теоремы CAP Эрика Брюера, высокая доступность (т.е. лучший опыт работы с клиентами) обычно превосходит сильную согласованность. Есть мало возможностей для вертикальной масштабируемости или единственных точек отказа. И хотя это непросто, перепроектировать системы, чтобы не выполнять join-запросы или не полагаться на согласованность чтение-после-записи (эй, просто кэшируйте значение в вашем приложении!), мы преодолели новую границу распределённых NoSQL баз данных.

Наша облачная инфраструктура имеет множество различных вариантов использования, требующих структурированного доступа к хранилищу. Netflix — это использование правильного инструмента для работы. В этой статье я бы хотел затронуть причины нашего выбора из трёх таких NoSQL инструментов: SimpleDB, Hadoop/HBase и Cassandra.

Amazon SimpleDB был естественным выбором для ряда вариантов использования, когда мы перешли в облако AWS. SimpleDB — высокопрочное хранилище, с автоматической репликацией в зонах доступности в пределах региона. Оно также обладает некоторыми действительно удобными фунциями запроса и форматирования данных за пределами простого интерфейса ключ/значение такими, как несколько атрибутов на ключ строки, пакетные операции, последовательное чтение и т.д. Кроме того, SimpleDB — это хостинговое решение, администрируемое нашими друзьями в AWS. Нам нравится, когда другие делают недифференцированный тяжёлый подъём для нас; в конце концов, это была одна из причин, по которой мы перешли в облако в первую очередь. Если вы привыкли к другим продуктам и услугам AWS, использование SimpleDB это... ну, просто — одинаковый аккаунт AWS, знакомые интерфейсы, API, интегрированная поддержка, биллинг и т.д.

Для наших систем, основанных на Hadoop, Apache HBase — это удобное, высокопроизводительное колоночно-ориентированное решение для распределённой базы данных. С его моделью динамического разбиения, HBase упрощает рост кластера и перераспределяет нагрузку между узлами во время выполнения, что замечательно для управления нашими постоянно растущими потребностями в объёме данных и избегания горячих точек. Встроенная поддержка сжатия данных, диапазонные запросы, охватывающие несколько узлов, и даже нативная поддержка распределённых счётчиков делает его привлекательной альтернативой для многих наших вариантов использования. Модель сильной согласованности HBase может также быть удобной, хотя она поставляется с некоторыми доступными компромиссами. Возможно, самая большая польза заключается в возможности комбинировать запросы реального времени HBase с пакетными задачами map-reduce Hadoop, используя HDFS как платформу общего хранилища.

Последнее, но тем не менее важное, я хотел бы поговорить о нашем использовании Cassandra. Распространяемая под лицензией Apache, Cassandra — это NoSQL база данных с открытым исходным кодом, гибкая, масштабируемая и производительная. DataStax, компания, которая профессионально поддерживает Cassandra, отлично помогли нам быстро изучить и управлять системой. В отличии от решения распределённой базы данных с использованием MySQL или даже SimpleDB, Cassandra (как HBase) может масштабироваться горизонтально и динамически, добавляя больше серверов, без необходимости перезапуска. На самом деле, Cassandra стремится избежать лимитов вертикального масштабирования и эффектов бутылочного горлышка любого вида: нет выделенных узлов имён (все кластерные узлы могут быть такими), нет практичесих архитектурных ограничений на размер данных, количество строк/столбцов и т.д. Производительность высокая, особенно для пропускной способности записи. Особого упоминания заслуживает чрезвычайно гибкая модель данных Cassandra. Редкая архитектура двумерного "суперколоночного семейства" позволяет представить обширные модели данных (и лучшую производительность) за пределами только простого поиска ключ-значение. И здесь нет основных требований к формату хранения, таких как HDFS; всё, что вам нужно это файловая система. Некоторые из самых заманчивых возможностей Cassandra это её уникально гибкая согласованность и модели репликации. Приложения могут определять на уровне вызовов, какой уровень согласованности использовать для чтения и записи (одиночный, кворум или все реплики). Это, в сочетании с настраиваемым коэффициентом репликации и специальной поддержкой определения, какие узлы кластера обозначить как реплики, делает её особенно хорошо подходящей для кросс-датацентровых и кросс-региональных развёртываний. В результате, один глобальный кластер Cassandra может одновременно обслуживать приложения и асинхронно реплицировать данные по нескольким географическим местоположениям.

Причина, почему мы используем несколько NoSQL решений, заключается в том, что каждое из них лучше всего подходит для определённого набора вариантов использования. Например, HBase естественно интегрирована с платформой Hadoop, в то время как Cassandra лучше для кросс-регионального развёртывания и масштабирования без единых точек отказа. Принятие нереляционной модели в целом непросто, и Netflix платит крутой налог первопроходца, интегрируя эти быстро развивающиеся и всё ещё созревающие продукты NoSQL. Есть кривая обучения и операционные накладные расходы. Всё же преимущества масштабируемости, доступности и производительности модели NoSQL очевидны и уже окупаются и будут иметь решающее значение для нашей долгосрочной стратегии облачных вычислений.