Условия использования сервиса Prezi.Com

На сайте Prezi.com представлено три тарифных плана:

— «Public FREE» — это бесплатный тариф, который позволяет создавать презентации онлайн и скачивать их к себе на компьютер. Объём места для хранения файлов на сервере Prezi — 100mb

— «Enjoy 59$/год». В этом платном тарифном плане есть дополнительные возможности: сделать презентации приватными, установить свой логотип вместо логотипа Prezi, получать поддержку от разработчиков на английском языке. Объем: 500mb Для преподавателей — бесплатно*

— «Pro 159$/год». Этот тарифный план позволяет, помимо перечисленного выше редактировать презентации на своём компьютере с помощью программы Prezi Desktop. Объем: 2000mb Для преподавателей — 59$/год

Для платных тарифных планов предусмотрен пробный 30-дневный периодиспользования.

4. Технология Redis

1. Вступление (краткая характеристика данной технологии (общее ознакомление слушателей); задачи и основное назначение использования; актуальность)

Redis — это высокопроизводительное нереляционное распределённое хранилище данных, которое хранит информацию постоянно (нереляционная высокопроизводительная СУБД). Redis используется в виде базы данных, очереди, кэш-сервера или всего вышеперечисленного вместе. Redis хранит все данные в памяти, доступ к данным осуществляется по ключу. Автоматически копия данных храниться на диске. Этот подход обеспечивает производительность, в десятки раз превышающую производительность реляционных СУБД, а также упрощает шардинг данных- работу с данными в БД и их разбиение, при необходимости.

Redis хранит весь набор данных в памяти и осуществляет доступ к ним по ключу, поэтому скорость обращения к данным просто сумасшедшая: 81 тысяча операций чтения в секунду, 110 тысяч операций записи в секунду. Время от времени данные записываются на диск в асинхронном режиме, либо каждое изменение записывается в файл, открытый только для добавления.

2. История создания(дата создания, первое основное предназначение)

Redis является продуктом (спонсируется), известной нам компании VMware и в тоже время относительно новым продуктом на рынке. Дата выхода первой версии 10 апреля 2009г. А совсем недавно Redis вышла с новым обновление 2.6 – 23октября 2012г. Это хранилище написано на языке C. Имеет библиотеки для работы со многими существующими языками программирования, такими как C, C++, C#, Clojure, Common Lisp, Erlang, Java, JavaScript, Lua, Perl, PHP, Python, Ruby, Scala, Go, Tcl.

Фактически Redis— написан на ANSI C и работает на большинстве POSIX-систем (Linux, MacOS X). Это бесплатное открытое ПО под BSD лицензией

3. Модель данных как основа для Redis (типы данных)

Redis с открытым исходным кодом структуры данных сервера, набор данных в памяти которая делает гораздо больше, чем просто хранения key/value благодаря построению типов данных.

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

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

String - основной тип данных, используемых в Redis, в котором можно хранить от нескольких символов к содержанию всего файла.

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

Hash - карта строк ключей и строк значений. Таким образом, вы можете представлять объекты (думаю о нем, как одного уровня объект JSON).

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

Sorted set  - частный случай типа набора данных. Разница в том, что каждый член имеет и связанный с ним счет, который использует порядок набора от самых маленьких до наибольший балл.

Есть команды, которые делают работу с данными в другие типы данных.

4.Способ организации (основные используемые структуры данных)

Строки реализованы с использованием библиотеки динамических строк C, так что мы не платим (говоря асимптотически) за выделение памяти в операциях добавления. Таким образом мы получаем сложность добавления O(N), вместо, например, квадратичной.

Списки реализованы как связные списки.

Множества и Хэши реализованы как хэш-таблицы.

Упорядоченные множества реализованы как списки с пропусками (особый тип сбалансированных деревьев)

Но когда списки, множества и упорядоченные множества небольшие, по количеству элементов и по размеру наибольших значений, используется другое, более компактное представление. Это представление различается для различных структур, но имеет следующую особенность: это компактный BLOB, часто имеющий сложность O(N) для каждой операции. Так как мы используем этот формат только для небольших объектов, это не проблема; проход по небольшому O(N) BLOB`у кэш-независим (cache-oblivious algorithm, прим. переводчика), практически говоря, это очень быстро, и как только элементов становится много, представление автоматически переключается на нативное (связный список, хэш, и т.д.).

Строки

Строки — это основная структура. Это одна их четырех базовых структур, а так же основа всех сложных структур, потому что Список — это список строк, Множество — это множество строк, и так далее.

Строки хороши во всех очевидных сценариях использования, когда вы хотите хранить HTML страницу, но так же они хороши если вы хотите избежать конвертирования уже закодированных данных. Например, если у вас есть JSON или MessagePack, вы можете просто хранить объекты как строки. В Redis 2.6 вы даже можете управлять этим видом структур на стороне сервера, используя скрипты на Lua.

Другое интересное использование строк — это битовые массивы, и вообще, случайный доступ к массивам байтов, так как Redis предоставляет команды доступа к произвольным диапазонам байтов, или даже к отдельным битам. В качестве примера, обратите внимание на этот хороший пост: Fast Easy real time metrics using Redis.

Списки

Списки хороши когда в основном вы работаете с крайними элементами: около хвоста, или около головы. Списки не лучший выбор для деления чего-либо на страницы, из-за медленного случайного доступа, O(N). Хорошим использованием списков будут простые очереди и стеки, или циклическая обработка элементов командой RPOPLPUSH, параметрами которой будет один и тот же список.

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

Множества

Множество — это не упорядоченный набор данных, оно эффективно когда у вас есть коллекция элементов, и важно очень быстро проверить присутствие элемента в коллекции, или получить ее размер. Еще одна «фишка» множеств — это возможность получить случайный элемент (команды SRANDMEMBER и SPOP).

Множества хорошо представляет отношения, например, «Каковы друзья пользователя X?» и тому подобное. Но, как мы увидим далее, есть и другие подходящие структуры для подобных вещей, упорядоченные множества.

Множества поддерживают сложные операции, такие как пересечение, объединение и так далее, это хороший способ использовать Redis в «вычислительной» манере, когда у вас есть данные, и вы хотите получить некоторый результат, выполняя преобразования над этими данными.

Небольшие множества кодируются очень эффективным способом.

Хэши

Хэши отличная структура для представления объектов, составленных из полей и значений. Поля хэшей могут быть атомарно инкрементированы командой HINCRBY. Если у вас есть объекты, такие как пользователи, записи в блоге, или другие виды элементов, хэши — это то, что вам нужно, если вы не хотите использовать свой собственный формат, такой как JSON или любой другой.

Однако, имейте в виду, что небольшие хэши в Redis кодируются очень эффективно, и вы можете использовать атомарные операции GET, SET или атомарно инкрементировать отдельное поле с большой скоростью.

Хэши так же могут быть использованы для представления связанных структур данных, с использованием ссылок.

Упорядоченные Множества

Упорядоченное Множество — это единственная структура данных, кроме списка, поддерживающая работу с упорядоченными элементами. С упорядоченными множествами можно делать много крутых вещей. Например, вы можете реализовать все виды Топа Чего-либо в вашем веб-приложении. Топ пользователей по рейтингу, топ постов по числу просмотров, топ чего угодно, и один экземпляр Redis будет обслуживать тонны вставок и запросов в секунду.

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

Упорядоченные множества хороши для очередей с приоритетами.

Упорядоченные множества — это что-то вроде более мощных списков, в которых вставка, удаление или получение элементов из середины списка так же быстро. Но они используют больше памяти, и являются O(log(N)) структурами.

5. Особенности данной технологии, возможности использования.

О возможностях использования можно говорить много, но хотелось бы прежде всего обратить на использование в ОС Windows, т.к именно эту систему использует абсолютное большинство. Итак, В настоящее время Redis основана на Linux, однако Microsoft много месяцев работала над обеспечением совместимости размещаемой в оперативной памяти (in-memory) базы данных Redis с ОС Windows. 26 апреля недавно сформированное дочернее подразделение Microsoft Open Technologies объявило о выходе новой версии данной технологии. Так что скоро все пользователи данной ос смогут открыто и по-полной применять Redis.

Пойдём дальше, одним важным преимуществом redis перед конкурентами является поддержка структурных данных и примитивов по управлению ими. Такими структурными данными являются наборы (индексированные элементы) и списки (стек элементов). Redis предоставляет возможность доставать эелементы, добавлять, удалять их и даже получать выборки с ограниченным смещеннием (это как LIMIT OFFSET в MySQL).

Из особенностей важно отметить, производительность:

110000 запросов SET в секунду, 81000 запросов GET в секунду на Linux-сервере начального уровня. Высокая скорость работы Redis обеспечивается тем, что данные хранятся в оперативной памяти и сохраняются на диск либо через равные промежутки времени, либо при превышении определённого количества не сохранённых запросов. Из этого вытекает, что используя Redis, вы можете потерять результаты нескольких последних запросов, что вполне приемлимо для большинства веб-приложений, учитывая, что обращение к Redis по скорости сравнимо с обращением к оперативной памяти. Тем не менее, потерь можно избежать через избыточность — Redis поддерживает неблокирующую master-slave репликацию.

Более того Redis обеспечивает Sharding. Тое есть может работать как распределённое хранилище на многих физических серверах. Такой функционал реализуется в клиентских библиотеках, и к сожалению, «из коробки» этот функционал реализован пока только в Ruby API, однако это не мешает вам хешировать ключ самостоятельно и получать ID сервера, к которому с этим ключом обращаться.

Хотелось бы обратить внимание и на сохранность данных, обеспечиваемую Redis.

В Redis доступны четыре основных стратегии для сохраненния полученных:

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

Периодически сохранять на диск: (по-умолчанию) момент, когда Redis решает сделать очередную копию (snapshot) данных на диске, зависит от времени создания предыдущей и количества измененных ключей. При настройках по-умолчанию это случается раз в несколько минут (1-15).

Лог транзакций: если потеря нескольких минут изменений данных неприемлема для приложения, есть опция синхронной записи каждого изменения в специальный append-only файл (лог).

Репликация: в Redis поддержка репликации достаточно примитивна — каждому серверу можно указать мастера (командой slaveof или одноименной строкой в конфигурации), все изменения на мастере будут воспроизводиться и на подчиненном. Это можно использовать для построения более сложных схем сохранности данных, например: мастер работает в режиме «только в памяти», а подчиненный — в режиме «лог транзакций». У каждого сервера может быть только один мастер, но неограниченное количество подчиненных.

Здесь же стоит упомянуть, что копия данных Redis на диске представляет собой бинарный файл (по-умолчанию dump.rdb), резервную копию которого можно сделать любыми средствами операционной системы, закинуть «в облако» наподобии Amazon S3 и.т.п. Восстановление происходит аналогичным образом скармливанием серверу файла в таком формате.

Хотеться сказать и о маштабируемости: проект предоставляет достаточно возможностей, чтобы масштабировать систему своими руками именно так, как представляется нужным конкретному проекту. Сразу хочется отметить, что не стоит бросаться воплощать все нижеизложенное в жизнь, если даже по самым оптимистичным прогнозам суммарный объем данных в Redis в вашем проекте не будет превышать 50-100 гигабайт. Какой-либо универсальной реализации нижеизложенного не существует, так как большая часть манипуляций осуществляется на стороне клиента, что потребовало бы реализации на всех возможных языках программирования.

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

Много процессов Redis на одном физическом сервере: процессы Redis однопоточны и если ваш проект работает на физическом не антикварном оборудовании, то для использования всех ресурсов процессора потребуется запускать несколько процессов Redis на разных портах. Еще одна особенность, подталкивающая в пользу такого подхода — существенно большее потребление оперативной памяти 64-битной сборкой Redis, так как удваивается длина указателей, которых используется очень большое количество. 32-битная же сборка позволяет держать в памяти лишь примерно 3 гигабайта данных. Альтернатива: много виртуальных машин с 1 ядром и 3 гигабайтами оперативной памяти.

Распределение данных по ключам: так или иначе, у всех данных в Redis есть уникальный идентификатор, от которого можно взять хэш, а от него взять остаток от деления на константу — получим номер сервера в статичном списке ip:port, на котором нужную структуру данных можно найти. На клиенте держится по соединению на каждый используемый сервер Redis, выбирается нужный и отправляется запрос.

Создание виртуальных баз данных (ВБД): у предыдущего подхода есть масса недостатков, связанных с перераспределением данных. Эту ситуацию можно решить введя понятие виртуальных БД, то есть брать в качестве константы для остатка не реальное число серверов, а достаточно большую степень двойки, скажем 65536 (будет удобно удваивать количество реальных серверов) — что далее будет считаться номером ВБД (который иногда удобно приписывать к ключу через разделитель). Виртуальные же базы необходимо по произвольному алгоритму распределить по запущенным процессам Redis и в простейшем случае указать это соотношение в конфигурационных файлах приложений-клиентов.

Маршрутизатор по виртуальным базам данных: в предыдущем приеме подразумевалось, что распределение виртуальных БД по серверам фиксированное, но очень скоро захочется иметь механизм для перераспределения данных в кластере. Это может потребоваться при неравномерности нагрузки (к какой-то ВБД существенно больше запросов, чем к остальным) или, опять же, при расширении парка используемых серверов. Для реализации потребуется некое общее хранилище для информации о физическом расположении ВБД, это может быть как отдельный «особый» процесс Redis, так и какая-то встраиваемая СУБД, расположенная в общедоступном месте, есть и другие варианты. Добавление такой прослойки для определения расположения данных немного увеличит время отклика, но позволит более гибко перераспределять данные.

Перераспределение данных: есть два подхода к переносу ВБД между двумя процессами Redis.

В лоб: некий процесс последовательно читает данные с сервера-источника и записывает в сервер-назначение, после окончания процесса отмечает в маршрутизаторе ВБД что данные теперь на новом сервере, удаляет данные на сервере-источнике. Просто в реализации, не особо быстро при больших объемах.

Через репликацию: существенно более хитрый вариант, о котором я услышал на одной из конференций от представителей команды Skype. Заключается в создании процесса, реализующего протокол репликации Redis с обоих сторон. То есть для сервера-источника он представляется подчиненным, а для сервера-назначения — мастером, при этом пропуская через себя только те ключи, которые относятся к нужной ВБД (требуется, чтобы её номер содержался в ключе). По окончании первичной репликации также отмечает в маршрутизаторе, что ВБД в новом месте. В протоколе репликация есть опция передачи начальной части данных бинарным файлом — этот вариант будет максимально быстрым, но потребуется разобраться с его форматом.

Использование репликации: помимо увеличения максимального объема данных, стоит задумываться и о надежности системы, а также сохранности данных. Как работает репликация мы уже обсуждали, как добавить её к одной из вышеизложенных схем — дело техники. Самый простой вариант — хранить в маршрутизаторе или конфигурационном файле два физических адреса для каждой ВБД, основной и запасной. Запасной же настраивать как подчиненного с логом транзакций, а основной как мастера в режиме кэша или с очень редким созданием копии на диске. Сложные варианты репликации можно «позаимствовать» у изначально-распределенных СУБД вроде Cassandra или Riak, например можно хранить первую копию по указанному в маршрутизаторе адресу, вторую по адресе, который указан для следующей ВБД, а третью — для через-следующей, но в такой схеме нельзя будет использовать репликацию напрямую, потребуется «прослойка», аналогичная описывавшейся в перераспределении данных через репликацию.

6.Примеры использования Redis

Транзакции: клиент может отправить команду multi, что означает начало транзакции. Все последующие команды не изменят данные, пока сервер не получит команду exec, либо можно отменить транзакцию командой discard.

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

Мониторинг: к каждому процессу Redis можно подключиться для просмотра всех поступающих команд или только тех, которые выполнялись больше N микросекунд.

А самым ярким примером использования редис является всем известное Instagram — всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Сегодня 40+ миллионов пользователей во многом благодаря redis. Так как забыли сделать favicon.ico до запуска — в первый же день логи пестрили ошибками 404. Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis). Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)

Количество фотографий продолжало расти и расти, даже самый большой инстансEC2 не справлялся. Следующим шагом стало горизонтальное разбиение данных (sharding):

Создали несколько тысяч логических баз данных.

И тут то и пришел на помощь REDIS: с некоторыми задачами он справляется лучше:

Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.

При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.

Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.

В Redis также хранится информация о сессиях.

Несколько фактов о Redis:

Так как все находится в памяти — очень быстрые операции записи и работы с множествами.

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

Redis хорош для структур данных, которые относительно ограничены.

Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например — счетчики, подмножества, проверка вхождения в множества).

Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.

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

В случае если Вам хватает предоставленного функционала — может выступать в качестве основной БД. В таком случае пропадает надобность в лишнем слое логики — кешировании, а в месте с ним пропадает огромный класс проблем в разработке. Вам больше не нужно будет при каждом обновлении данных сбрасывать нужные кеши, отлавливать ошибки связанные с тем что где-то Вы это забыли сделать. Все это будет брать на себя Редис. Просто работайте с базой данной и не о чем таком можете даже не думать. При этом скорость работы по многим тестам даже превосходит Memcached. Это отличная идея для высоко нагруженных проектов и я собираюсь некоторые из своих будущих проектов делать исключительно на Redis, а в уже существующие внедряю его там где он даст ощутимый прирост в производительности. Когда же появится достаточно производительная библиотека для PHP то думаю можно будет полностью отказаться от memcached в сторону Redis.

7. Особенности новой версии.

Ключевые улучшения, добавленные в Redis 2.6:

В Redis встроен интерпретатор Lua и добавлена поддержка написания работающих на стороне сервера скриптов на языке Lua. Для выполнения таких скриптов добавлена команда EVAL. Из скриптов можно обращаться к функциям Redis через использованием методов .call() и .pcall(). Преобразование типов данных Redis и Lua осуществляется автоматически;

Проведена большая работа по повышению стабильности и пригодности Redis для промышленного применения. Решены проблемы с отзывчивостью в условии одновременного завершения времени жизни большого числа элементов (использован новый неблокирующий алгоритм чистки устаревших элементов) или при использовании медленных жестких дисков. Добавлены средства самодиагностики для отслеживания внештатных ситуаций. Изменены настройки по молчанию: вторичные slave-системы теперь по умолчанию работают в режиме только для чтения, при выявлении нарушения целостности базы RDB по умолчанию прекращается приём запросов на запись;

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

Добавлена возможность определения таймаутов и времени жизни ключей с миллисекундной точностью. Добавлены новые команды PEXPIRE, PSETEX, PTTL, которые оперируют миллисекундами;

Сняты определённые в коде ограничения на максимальное число клиентов;

Ускорена работа режима записи AOF (append-only-file) за счёт поддержки перезаписи агрегатных типов данных. Расширена семантика для управления AOF-файлами;

Оптимизировано потребление памяти при работе с мелкими списками, zip-списками и хэшами, в ситуации когда в них используются небольшие целочисленные значения;

Добавлены новые битовые команды BITCOUNT и BITOP;

Поддержка задания для клиентов мягких и жестких лимитов на размер выходного буфера, позволяющих использование разные лимиты для разных классов клиентов;

Для всех директив redis.conf подготовлены аналогичные опции командной строки;

Увеличена производительности записи больших объектов;

Реализован встроенный тест памяти (redis-server --test-memory);

Добавлены команды INCRBYFLOAT и HINCRBYFLOAT;

Из продукта Redis Cluster портированы команды DUMP, RESTORE и MIGRATE;

Для RDB-файлов добавлена проверка целостности по контрольным суммам CRC64;

Улучшено поведение команды MONITOR, которая теперь выводит параметры команды до начала её исполнения;

Добавлена функция "Software Watchdog" для отладки проблем с отзывчивостью БД;

Переписана или реструктуризирована значительная часть ядра Redis, что позволило обеспечить формирование Redis Cluster на базе единого кода с Redis. Весь код для работы в режиме кластера временно удалён и будет возвращён в выпуске Redis 3.0, после доработки и стабилизации;

Расширены возможности утилиты redis-benchmark, добавлена поддержка запуска избранных тестов и возможность вывода результатов в CSV;

В команду SHUTDOWN добавлена поддержка необязательных аргументов "SAVE" и "NOSAVE";

Добавлена команда "INFO commandstats" для вывода статистики как часто выполнялись команды и сколько времени было потрачено на их выполнение;

Улучшена поддержка систем big endian и *BSD;

Расширены возможности системы сборки.

8.Заключение

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