Наверх ▲

Introducing Riak: the most powerful open-source, distributed database you'll ever put into production

Ian Plosker Ian Plosker

Техлид компании-разработчика БД Riak "Basho Technologies".

Introduction to riak ian plosker
View more presentations from Ontico.

Ведущий: Коллеги! Я хочу представить вам Яна Плоскера. Ян приехал к нам из Майями. Работает в компании "Basho", которая известна всем разработчикам, интересующимся Erlang'ом. Они много сделали для комьюнити. Я думаю, один из самых больших вкладов NoSQL база данных Riak, о которой нам расскажет Ян.

 

Ян Проскер (Ian Plosker), техлид компании-разработчика БД Riak "Basho Technologies" (записано со слов переводчика):

– Здравствуйте! Прежде чем начну, хотел бы спросить: кто слышал о Riak? Кто-нибудь вообще слышал о Riak что-нибудь? Хорошо. Надеюсь, после моего выступления кое-какие представления у вас появятся.

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

Я являюсь техническим сотрудником, возглавляющим отдел международных операций.

Что такой "Basho"? Это эксперты по распределенным системам.

Что такое Riak? Riak – новая база данных с открытым кодом.

У нас есть лицензия Apache2.

Лицензия, которая очень много позволяет. Фактически, с ней можно делать все, что угодно.

Здесь у нас кластерная конфигурация по умолчанию. Можно иметь сколько угодно узлов.

Riak не имеет master-сервера, slave-сервера и так далее – они все на одном уроне.

Riak также имеет черту толерантности к сбоям – отказоустойчивость.

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

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

Из любопытства хочу спросить: кто из вас знаком с Erlang? Кто использует его профессионально? Только один человек.

Erlang – функциональный язык программирования. Он был разработан компанией "Ericsson" в конце 1980-х – начале 1990-х годов и был предназначен для телекоммуникационных сетей с нулевым временем простоя по приложениям.

Erlang – очень специфичный язык. Он предназначен для многих параметров работы с вычислительными системами. Прежде всего, он имеет свойство отказоустойчивости или толерантности к сбоям. Он нам был очень полезен при построении распределенной системы с минимальным кодированием. Кроме того, мы использовали C/C++. Мы объединили Erlang с этим языком.

Riak – система с высокой доступностью. Мы всегда принимаем команды read и write (то есть, чтение запись).

Кто из вас знает о теореме CAP? Несколько человек знает, поэтому я не буду очень долго на ней останавливаться. Часто ее неправильно понимают. Самое главное, что в ней имеется в виду: база данных может иметь только две из последующих характеристик. Я имею в виду распределенную базу данных. Она может иметь целостность (воспроизводимость), может иметь доступность и устойчивость к разделению. Это три черты, которые входят в CAP (Consistency, Availability, Partition tolerance).

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

целостность + устойчивость, доступность + устойчивость.

Но есть настройки, которые вы можете подстроить.

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

Конечно, нам необходимо обращать внимание на целостность, потому что все репликации должны устойчиво воспроизводиться, какое-то время требуется для проведения транзакций и так далее. Если вы выбираете латентность, например, как ведущий параметр, здесь надо будет выполнить определенное число операций. Не всегда будет достигнута согласованность и целостность данных.

Вы можете сказать: "Я жду только выполнения одной репликации, чтобы была успешность записи". Это по умолчанию делается. В результате вы настаиваетесь в рамках латентности. Это действительно доступность, и доступность имеет смысл, если можно найти компромисс с устойчивостью. В любых сценариях можно обеспечить здесь доступность.

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

Здесь ключевой параметр – это не просто хранение в колонках, это касается диагностики.

Какие составляющие сюда входят. Это бинарный блок, который сюда включается. XLM дает (неразборчиво, 76:19). Это преимущество хранения XML: как вы храните документы обычно. А также есть альтернативные механизмы. Ключевой параметр – что здесь действительно есть автоматизированная система Riak.

Riak – это база данных, по сути.

Итак. Давайте немного поговорим о дизайне Riak.

Как мы выстраиваем Riak и каким образом он создается.

Вдохновителем Riak является Amazon's Dynamo. Вы знаете, Amazon занимается базой данных. Но в Dynamo немного другой параметр для базы данных.

Можно сказать, что Dynamo – это база данных. Я думаю, слышали, пользовались? Кто-то использовал больше параметров. Кажется, в 2006 – 2007-м году "Amazon" опубликовал данные по внутреннему использованию базы данных. Это не было новшеством само по себе, но показывало, каким образом можно воспроизводить базы данных.

Что интересно в отчете Dynamo.

Здесь были созданы модели бизнеса. Модель каким образом описывалась? Это было создано для "Amazon". Когда вы кликаете, дополнительные моменты латентности задействованы. Они преобразуются в другие параметры, которые связаны с убытками, с потерями.

Каким образом сократить латентность? Когда вы кликаете на этой части, это будет происходить непосредственно – пользовательский интерфейс очень быстрого реагирования. Вы можете представить, каким образом обеспечить устойчивость (в миллисекундах обычно).

Если вы это делаете, таким образом репликацию можно восстанавливать очень быстро. Вы устойчивость создаете как очень важный элемент. По сути, вы заботитесь о соответствии того, что у вас есть, когда читаете, что у вас есть.

Мы говорим об устойчивости и неустойчивости. Когда мы говорим о низкой латентности, Amazon's Dynamo позволяет выбирать низкую латентность и устойчивость. Riak был создан на основе отчетности "Amazon". Он был реализован, с оглядкой и на другие базы данных: например, Cassandra. А также Dynamo вдохновляло нас. Это хранение базы данных, которое люди ожидали получить.

Я не знаю, знали ли вы об этом, но такая реализация осуществлена. Riak сейчас работает на аспектах Dinamo. То, что есть здесь – это отчет о том, как Riak работает. Есть дополнительные возможности: возможность поиска индексов, карты отображения. Мы поговори об этом позже.

Итак. Создан для выбора. Что я подразумеваю под этим. Riak использует(?) CDP. Это интерфейс. Вы можете работать с открытым ресурсом. Это не так просто, как работает web-сервер, как в структуре web-сайта.

Это приблизительно такого рода: вы видите кэшинг. Дизайн похож на web-сервис для Riak. Очень легко управлять Riak, потому что он действует как web-сервер.

Я хочу поговорить о некоторых чертах Riak. Помимо основных ключевых моментов, я говорил о HTTP API.

HTTP API CPU действительно является проблемой для базы данных.

У нас есть протокол для API, он был сделан для "Google". В основном это пакет различных инструментов, по сути, на всех языках, которые только существует. Очень компактный. CPU эффективно работает. Мы считаем протокол буферов API эффективным. Он может быть намного быстрее, чем (неразборчиво, 82:24), намного быстрее, чем HTTP. Если вы работаете на VPN-сервере, есть небольшая разница.

Riak имеет API, который очень легко реализовать. Клиент просит, чтобы это было сделано просто – это можно очень легко написать. Записывается эта функция для API. Когда у вас есть новый клиент, это очень легко сделать, на разных языках можно реализовать.

Есть Erlang (это собственная черта для клиента).

JAVA клиентоориентированная. Они помогают выстраивать приложения.

(Неразборчиво, 83:36) как инструмент также имеет решение проблем конфликтоустойчивости, соответствия и доступности. Можно делать записи и переписывать данные одновременно. Riak не теряет эти данные. Мы не теряем никаких данных – доступны для всевозможных записей. Любая информация может быть записана.

В случае с платежной картой(?) вам нужно адаптировать две единицы, и они прекрасно работают. Реализация решается, и клиент очень легко разбирается с конфликтами.

Есть ряд других интересных черт. Разрабатывает JavaScript/Node.JS, Haskell, С++, Clojure, Scala. Это очень интересные клиенты (я видел разные примеры языков), если это клиент, который постоянно работает и используется.

Я интересуюсь для себя: кто является функциональным программистом? Несколько человек. Какие языки вы применяете? Haskell. Интересно.

Я упоминал альтернативные механизмы запросов. Есть три таких механизма.

Первое. Riak search. Поиск в Riak – это так же, как API Riak. Что делает поиск? Вы можете хранить данные в XML, Riak индексирует эти данные. А также существуют полные тексты. Очень хорошо, когда есть огромные корпуса текстов, и вы можете их легко находить.

Я должен упомянуть, что поиск в Riak не выполняется так же, как (неразборчиво, 86:30). Это распределенная система, как и Riak. Распределение несколько иначе выглядит, несколько короче, но используется очень простой механизм. Характеристики производства несколько другие. Очень важно понять, что характеристики по работе очень нужны.

Следующее. Альтернативный механизм по поиску – это несколько индексов, которые помогают вам вводить тексты. Например, вы хотите понять, кто появляется на фотографиях. Тогда вы вбиваете, табулируете функцию. Есть несколько индексов для людей и поворотный ключ, который показывает все фотографии.

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

Еще один альтернативный механизм. Это механизм, связанный с картами. Кто знаком с этим? В основном Дюп(?), наверное, вам знаком. Это производитель карт. Кто использует Дюп(?)? Хорошо.

Прежде всего, мне хотелось бы сказать, что Riak умеет(?) производить карты. Применяет принципы Дюп(?), но в несколько других случаях. Способность Riak воспроизводить карты основаны на памяти, на запоминающей функции. Это просто запоминается, нацелено на практические запросы. Вы можете создавать карту очень быстро: мы говорим о сотне в миллисекунду.

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

Я хочу вам немного рассказать о практических кейсах. Есть практические ситуации, которые Riak не задействует (неразборчиво, 89:58).

Я не хочу передавать мою базу данных, перепродавать ее. Я хочу сказать, что для большинства людей Riak, может быть, и не имеет смысла. Если ваша база данных соответствует вашим пожеланиям, вы не(?) используете Riak. Если ваши клиенты не требуют латентности, тогда вам не нужна система Riak.

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

Вам нужно использовать Riak для кризисных ситуаций, для кризисного запроса. Есть sequel(SQL\сиквел?), если проблема достаточно маленькая – вам не нужно то, что предлагает Riak.

Теперь давайте перейдем к практическим примерам Riak. Прежде всего, это хранение сессии.

Все мы любим создавать репликации и храним их большое количество. Riak очень хорош для того, чтобы воспроизводить эти сессии. Сookie – вы можете посмотреть данные по параметрам оценки. Собственно, очень доступные в этом отношении, с прекрасными характеристиками хранения сессии.

То же самое для профилей юзера. Это ключевые свойства: e-mail, адрес. Мы можем сделать профиль юзера, и используется для него латентность.

Также на практике используется контент CDN, который позволяет как можно ближе доставлять данные юзеру. Массовое производство репликаций данных. Мы можем распределять функции записи и чтения. Это то, что нам позволяет ближе подойти к пользователям. В основном, вы можете использовать Riak как свою CDN.

Другие практические системы – это метаданные, системы файлов. Удаляются таблицы, например. Можно воспроизводить систему хранения. Относительно долго(?) можно хранить файлы. Вы храните ссылки(?), но вам нужно их состыковать с системой метаданных.

Это ключевая проблема.

Например, медицинские записи либо какие-то ключевые значимые данные. Идентификаторы имени человека, другие персональные данные. Данные истории болезни, прописанные лекарства и так далее. Все это находится в рамках таких систем, как CDN.

Когда мы ведем записи данных истории болезни, необходимо иметь возможность доступа к ним на определенный момент времени. Здесь не допустимы сбои.

Кэшинг – это еще один пример использования Riak. Что я имею в виду, когда говорю "кэшинг"? Зачем нам использовать Riak вместо Varnish, например, в этом случае? Мы используем Riak в ситуации, когда у нас есть разные участки web-сайта, которые применяются к разным пользователям. Например, блог может иметь разные сегменты страницы, которые будут кэшироваться по-разному.

В случае Varnish надо иметь разъединенную систему подключения, и там все будет очень сложно. Но можно использовать Riak для того, чтобы кэшировать посты в блоге отдельно от информации для пользователя и иметь высокодоступный кэш.

Я всеми этими примерами пытался подчеркнуть следующее: Riak соответствует решению проблем, которые опираются на ключевые параметры и их значимость. Если это важно для вашей базы данных, Riak хорошо подходит.

Давайте поговорим теперь о тех пользователях, которые оказываются в менее выгодной ситуации и все равно используют Riak. Им требуются дополнительные усилия. Необходимо манипулировать разными инструментами решения проблем. Придавать иную значимость проблемам, переводя их в ранг ключевых.

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

Что можно здесь сделать? Это time-boxing, который позволяет определить дополнительное время (например, дополнительный интервал в 15 минут) и хранение последовательностей временных событий по таким блокам 15-минутным, которые вы задали.

Но что делать, если у вас имеется много баз данных, которые подходят к временным последовательностям. Когда вы создаете такие time-boxing'и в Riak, надо очень хорошо понимать, как вы будете это делать, чтобы это соответствовало смыслу ваших данных.

Аналитика. Сейчас все увлекаются аналитикой. Есть некоторые базы данных, которые очень хорошо соответствуют этой задаче. Когда вы имеете дело с аналитикой, вам не нужно заранее описывать, что вы будете делать с какой-то базой данных. Но в Riak вы это должны сделать.

Когда вы проводите аналитику, вы должны использовать HPAS(?), SQL и какие-то еще инструменты, которые обеспечивают очередность запросов. Необходимо формировать модель представления данных, чтобы она соответствовала модели базы данных по ключевой значимости событий.

Некоторые пользователи обеспечивают хранение основной информации в Riak, а клиентские приложения уже выстраивают на работу с аналитикой. Это позволяет учесть и требования по толерантности к сбоям, отказоустойчивость и производительность.

В завершении я хочу сказать несколько слов о некоторых системах хранения. У меня для этого нет слайдов. В Riak обеспечивается поддержка 5-ти backend'ов хранения.

Что я подразумеваю под backend'ами.

Дело в том, что Riak – это база метаданных. Она опирается на какие-то ключевые по значимости данные. Эти данные распределяются по разным локальным группам. Необходимо понимать, что здесь система предусматривает возможность разбиения на пять таких больших групп, которые я называют backend'ами. Необходимо иметь список ключевых параметров.

Например, какие-то разработчики могут сами расписывать распределение данных по backend'ам. Но в "Basho" у нас есть уже автоматизированные инструменты, чтобы это делать.

Bitcask – это разработка "Basho". Она относится только к формату хранения данных. Это профиль латентности. Он очень быстрый и очень плоский(?). Он имеет в памяти таблицу ключевых справок. Там вы можете быстро получить доступ к файлам, и через них уже производится поиск ключевых запросов.

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

Здесь могут быть множественные узлы в памяти. Поэтому не надо все размещать в одном узле. Это инструмент, который работает по всему кластеру. Но если вы храните, например, журнальные записи или записи о последовательных событиях и так далее – это массивы, которые могут расти безгранично. Здесь уже надо думать, какой инструмент применять.

База данных LevelDB – это разработка, которую мы завершили в прошлом году. В основном, LevelDB – это таблицы SS (sorted ring tables(?)). Они могут эффективно применяться, но надо помнить, что для каждого ключевого запроса или поиска есть вариабельные профили латентности или задержки.

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

Innostore – следующий инструмент. Я думаю, многие из вас с ним знакомы. Он у нас включен в NDB. К сожалению, его не поставляют, встроенным в Riak. Есть конфликт лицензирования, и вы должны сами его устанавливать. Его достаточно просто загрузить.

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

Мульти-backend – это последний backend. Он позволяет нам соотносить backend'ы по целому ряду подгрупп данных и так далее.

Это все, что я хотел вам рассказать. Подводя итог, хочу сказать.

Riak – это распределенная база данных с открытым кодом. Она характеризуется высокой доступностью, высокой отказоустойчивостью.

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

Когда вы говорите о Riak или другом инструменте, вы должны понимать, с какой базой данных вы собираетесь работать.

Когда начинают выстраивать какое-то приложение, иногда даже не имеют в виду базы данных. Мы сначала ориентировались на реляционную базу данных и на то, как мы себя позиционируем относительно SQL или NoSQL.

Дело в том, что мы не отрицаем реляционные базы данных. Но монокультура в этом отношении – плохо. Она не дает нам развиваться, не дает делать адекватный выбор при построении приложений – нужно иметь больше возможностей!

Спасибо большое за внимание.

(Аплодисменты).

 

Вопросы и ответы

Реплика из зала (перевод): Спасибо за очень интересную презентацию. Общий подход к таким проблемам – это соотнесение связанных запросов в 1-мэч(?). Можно здесь предусмотреть, как ключевые события будут распределяться между различными узлами или как они будут выстраиваться в очередь?

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

Также надо расписать параметр задания MapReduce. Далее направляется запрос, но при этом указывается параметр. Например, тот 15-минутный интервал, о котором я говорил – распределение данных по временной последовательности. Вы эти 15-минутные интервалы можете внедрить в инструмент MapReduce.

Реплика из зала (перевод): Все версии данных я отправил в единый ключ. Далее они централизованно хранятся. Это так?

Ян Плоскер (перевод): Да. Riak не вводит никаких ограничений на размер объектов. Но 10 мегабайт – это реалистичное хорошее практическое правило и подход. Даже при этом уровень латентности (период задержки) может быть не оптимальным. Надо ограничить количество входов по каждому объекту. Например, 1000 записей – 1000 вводов. Здесь есть разные пути, как обойти те или иные ограничения.

Реплика из зала (перевод): Riak search (поиск в Riak). Есть у него внешняя совместимость, например, с анализаторами plug-in и так далее?

Ян Плоскер (перевод): У него есть анализаторы типа plug-in. Пять анализаторов. Они входят в систему Riak search. Это очень простая функция, ее легко реализовать.

Реплика из зала (перевод): Насколько трудно проводить анализ данных до перехода на Riak и осуществления поиска?

Ян Плоскер (записано со слов переводчика): Насколько трудно написать команды для анализаторов?

Реплика из зала (перевод): Предположим, у меня есть анализаторы для китайского языка, написанные на JAVA. Я хочу их использовать. Хочу анализировать данные, а потом информацию передавать в Riak.

Ян Плоскер (перевод): Это не трудно. Мы импортировали анализаторы Lusene – это делается достаточно просто.

Реплика из зала (перевод): Кто ваш основной конкурент из разработчиков баз данных?

Ян Плоскер (перевод): Я думаю, все на рынке баз данных (например, Oracle) – это наши конкуренты. Что касается технологических вопросов – возможно, Cassandra. У нас достаточно близкие архитектуры.

Также нашими конкурентами являются многие компании. Но мы подобно кораблям в синем море. Все мы пытаемся решить какие-то проблемы. Занимаемся своими разработками, идем своим курсом. Что-то мы делаем просто дешевле, чем Oracle. Но Oracle – основной конкурент.

Реплика из зала (перевод): Спасибо за презентацию. Вы вкратце рассказали о Riak MapReduce, но не рассказали о link walking (перемещение по ссылкам). Я хотел бы расспросить вас подробнее об этом.

Ян Плоскер (перевод): Да, я об этом не рассказал. Перемещение по ссылкам – это ситуация, когда в документе можно создать ссылку на другой объект.

Это однонаправленная ссылка. Второй объект не знает, что на него была сделана ссылка. Например, ситуация "друзья". Может быть профиль пользователя, от которого можно сделать ссылки на всех друзей. Это хорошо укладывается в MapReduce. Я ответил на ваш вопрос?

Реплика из зала (перевод): Что вы считаете идеальным случаем для такого перемещения по ссылкам? Я пытался заниматься этим, но у меня не очень хорошо получилось.

Ян Плоскер (перевод): Link walking (перемещение по ссылкам) – это создание своего рода графика. Это не график базы данных, а график вводов. Может быть, можно это уподобить альбому хранения. Например, у музыкантов есть альбомы – их очень легко по таким ссылкам организовывать.

Вы кликаете на ссылку. Страница, на которую вы делаете ссылку, не знает о наличии предыдущей страницы. Это специфика механизма link walking: вы можете перемещаться по множественным ссылкам. Например, вы можете определиться, что хотите увидеть друга друга друга человека Х – все эти промежуточные друзья также будут вам показаны. Но вы можете заказать третьего по ссылке друга, и вам этот объект будет представлен.

Ведущий: Если у вас нет больше вопросов, но если вдруг они появятся после, найдите Яна – он будет здесь весь день. Большое спасибо.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Вадим Макишвили

Вадим Макишвили

Руководитель группы вёрстки в компании "Яндекс", представитель украинского крыла WSG.

Вадим Макишвили (Яндекс) сделал развернутый доклад об ошибках в работе верстальщика, методах их исправления и самооценке специалиста.

Евгений Лисицкий

Евгений Лисицкий

Ведущий разработчик компании "Спорт Сегодня".

Евгений Лисицкий рассказывает о стремительно развивающейся технологии WebSocket, которая позволяет создавать веб-приложения, работающие в режиме, близком к реальному времени.