Cassandra @JEEConf  March 21, 2011 (Kiev, Ukraine)
Upcoming SlideShare
Loading in...5
×
 

Cassandra @JEEConf March 21, 2011 (Kiev, Ukraine)

on

  • 2,886 views

 

Statistics

Views

Total Views
2,886
Slideshare-icon Views on SlideShare
1,531
Embed Views
1,355

Actions

Likes
1
Downloads
26
Comments
0

4 Embeds 1,355

http://jeeconf.com 1350
http://twitter.com 2
url_unknown 2
https://www.google.ru 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • Cassandra как продукт успешного совмещения идей из двух спецификаций: Bigtable по авторством Google (2006) и Dynamo от Amazon (2007), которые первоначально преследовали совсем разные цели - Google пытался построить хранилище данных на основе своей распределенной файловой системы, а Amazon пошел по совсем другому сценарию и больше смотрел в сторону распределенности и P2P сетей. Facebook’y было необходимо хранилище данных, которое бы отличалось высокой доступностью и легкой маштабируемостью, так и возликла Cassandra. Способ организации данных был взят у Bigtable, а модель маштабирования у Dynamo. В 2008 Facebook передал её Apache coобществу.\n
  • В реляционных базах для того чтобы поменять имя или тип колонки приходилось выполнять операцию на всей таблице, на что за частую уходило просто огромное количество времени и ресурсов системы.\n\nTradeoff который предоставляет Cassandra - отсутствие какой-либо схемы БД, можно добавлять, переименовывать или удалять колонки когда это необходимо. Полная свобода действий. \n
  • Многие крупные компании уже используют кассандру в продакшен, такие как Netflix, OpenX, SimpleGeo, Ooyala, Facebook, Reddit и т.д. как видите задачи у них совсем разные и использование Cassandra говорит о том, что она подходит для очень широкого круга задач, начиная от простого хранения, к примеру логов, до сильно структурированных данных, как например гео-локации. Самый большой кластер из тех которые мне известны на данный момент, пренадлежит компании Digital Reasoning и включает в себя более 400 машин.\n
  • Реляционные БД не проектировались для горизонтального масштабирования, поэтому требуют использования дополнительных средств (таких как cache или репликация) для достижения приемлемой производительности, но оба этих стредства являются не более чем “хаками”.\n\nДля записи и чтения с применением Б-деревьев необходимо сначала “пройтись” по цепочке индексов до конечных данных. Так как эта структура находится на диске - для каждого чтения индекса приходиться делать “seek” что существенно уменьшает производительность.\n\n
  • Cassandra способна:\n - хранить большие обьемы данных - до 2х (двух) гигабайт данных на каждый ключ;\n - Обслуживать большое количество параллельных запросов на чтение и запись.\n\nЧто может быть легче для масштабирования, чем простое добавление новой машины в кластер? Обо всём остальном Cassandra позаботиться за вас.\n\nИспользование CAP теоремы позволяет вам самим решать какой быть Cassandra: различные уровни согласованности данных при чтении и записи, tradeoff - доступность или высокая согласованность (и быстрота).\n\nВ пакет входят утилиты для администрирования кластера + сторонние утилиты, например, Datastax OpsCenter for Cassandra.\n \n
  • Keyspace - можно осоциировать с “базой данных” в реляционных БД, хранилище для множества ColumnFamily\n\nColumnFamily - таблица в реляционных БД, сохраняет в себе набор строк (Row)\n\nRow - строка таблицы, с ней ассоциирован ключ (уникальный идентификатор строки) и набор колонок.\n\nСolumn - самая мелкая структура, хранит в себе три поля - имя, значение и время создания.\n\nSuperColumn - используется для хранения колонок, у нее есть только имя/ключ, можно представить как простой массив для хранения логически ассоциированных колонок.\n
  • В отличие от реляционных БД Cassandra для записи использует структуру “The Log-Structured Merge-Tree” (первое упоминание в документе от Google - Bigtable: A Distributed Storage System for Structured Data). В процессе записи данные сначала попадают в “Memtable” - структуру, которая полностью находится в памяти и в “Commitlog”, который используется для восстановления при сбое (Commitlog всегда пишется напрямую на диск, данные в него записываются всегда последовательно, соотвественно это очень быстро). При наполнении очередного “Memtable” данными (размер задаётся в настройках) все данные, одной большой последовательной операцией, записываются на диск в SSTable, специально структурированный файл (в отличие от традиционных реляционных БД для записи в которые необходимо произвести предварительное чтение из-за использования Б-деревьев). Для чтения используются как “Memtable”, так и ранее созданные SSTable файлы. Каждая ColumnFamily имеет свой собственный набор Memtable/SSTable файлов.\n
  • Запись ОЧЕНЬ быстрая, не производиться никаких операций которые бы её замедляли (так же записть всегда производиться последовательно что при отдельном жестком диске для “Commitlog” позволяет добиться максимальной производительности), Cassandra не использует транзакций, но гарантирует атомарность записи/обновления в пределах ColumnFamily (либо все колонки будут записаны, либо ни одной из них). \n
  • Чтение данных может осуществляться различными способами - по ключу или диапозону ключей, по имени или диапозону имен колонок, при чтении не используется никаких блокировок как это происходит в реляционных базах данных. Существуют две методики кэширования - по целой строке или по ключу, что позволяет увеличить производительность системы: при кэшировании целых строк внутренние колонки хранятся в памяти, что полностью избавляет от необходимости читать что-ли ещё. При использовании кэширования по ключу опускается чтение индекса с диска, что позволяет сэкономить врямя на один “seek” из двух необходимых для чтения строки. Оба эти подхода к кэшированию можно комбинировать (в конфигурации для каждой Column Family их можно задавать как в числовом, так и в процентном соотношении). Хорошая стратегия при использовании кэшей - использовать большой key cache, он не занимает много места в памяти и избавляет от накрузки связанной с GC в отличие от row cache не правильно увеличив который можно попасть в ситуацию когда GC будет его постоянно убивать.\n
  • При добавлении ключи сортируются, а сами данные записываются отсортированными по ключу, получется своего рода стек из элементов - ключ/данные (колонки), -//-, ... . Так что если кто-то Вам сказал что Cassandra это колонко-ориентированная база данных - он просто не знает о чем говорит. Это краткое описание пригодится нам чуть позже при рассмотрении репликации и записи данных в кластер.\n
  • Все ноды (серверы) организованы в так называемое кольцо - все они равнозначны, так что если случиться сбой на одной из нод, это не повлияет на работу остальных (no single point of failure). При организации кольца важную роль игруют так называемые “токены” - это уникальные числовые идентификаторы каждого из серверов, токены так же играют важную роль в распределении данных по кольцу - каждая из нод отвечает за свой интервал токенов, к примеру нода А отвечает за диапозон (W, A], а нода Т за (L, T]. Чем меньше диапозон между нодами, тем больше вероятность того, что данные будут распределны по кольцу равномернее (при использовании RandomPartitioner). Как правило токены начинаются с 0 (нуля) и заканчиваются 2 в 160 степени.\n
  • Допустим пользователь пытается записать данные в кластер: Cassandra сначала преобразует ключ в токен, затем найдет ноду, которая отвечает за диапозон, в который входит полученный токен, и перешлет запрос на запись на эту ноду. В зависимости от используемого Parititioner (задаётся в настройках кластера) данные могут распределяться по кольцу в произвольном порядке (RandomPartitioner) или в строго определенном лексическом порядке (ByteOrderedParitioner).\n
  • При добавлении нового сервера в кольцо пересчитываются диапозоны токенов у серверов по его обе стороны, в нашем случае - A и L. Новоприбывший F будет отвечать за диапозон (A, F] и в процессе входа в кольцо на этот сервер будет передан соответствующий диапозон данных с сервера L. Как видно на слайде - новый сервер позволяет снизить нагрузку на сервере L за счет уменьшения диапозона его ответственности. Изменение токенов сервера одного из серверов так же может использоваться для балансировки кластера - при переходе на новую позицию в кольце этот сервер снизит нагрузку на соседе слева. Если для нового сервера в конфигурации не указан токен, то при входе в кольцо для него будет автоматически выбран такой токен, который снимет половину нагрузки на самом нагруженном сервере из уже присутствующих в кольце (под нагрузкой имеется ввиду количество реальных данных записаных на сервере).\n
  • При записи данных в обновленный кластер (когда сервер F находится в процессе входа), запросы будут отправляться как на сервер F, так и на сервер L, чтобы обеспечить постоянную доступность данных.\n
  • Так как все сервера входящие в кольцо равнозначны едиственная возможность добиться полной неработоспособности это сбой на всех серверах одновременно, пока хотя бы один сервер “жив” продолжается нормальная работа. Так как проблемы случаются как в пределах датацента так и в пределах отдельной стойки, например выход из строя свича или перебой в электроснабжении, Cassandra может обеспечить необходимую схему репликации как между различными датацентрами так и между различными стойками в пределах одного датацентра.\n
  • После записи данные реплицируются между серверами в кластере, каждый сервер отвечает за диапозон данных вычисляемый по формуле - 1/(общее кол-во физ. серверов).\n
  • После записи данные реплицируются между серверами в кластере, каждый сервер отвечает за диапозон данных вычисляемый по формуле - 1/(общее кол-во физ. серверов).\n
  • После записи данные реплицируются между серверами в кластере, каждый сервер отвечает за диапозон данных вычисляемый по формуле - 1/(общее кол-во физ. серверов).\n
  • Если к примеру при репликации данных один из серверов (в нашем случае L) недоступен, то данные реплицируются со специальными мета-данными о том что по приходу L их нужно на него доставить, этот механизм называется HintedHandOff.\n
  • Если к примеру при репликации данных один из серверов (в нашем случае L) недоступен, то данные реплицируются со специальными мета-данными о том что по приходу L их нужно на него доставить, этот механизм называется HintedHandOff.\n
  • Существует так же другая методика востановления целосности при репликации - StreamingRepair (AntiEntropy) - сервер F пошлет специальный запрос на получение, грубо говоря, “снимка” данных на реплецирующие серверы и сгенирирует локально свой “снимок”, при получении F поочередно сравнит снимки и произведет востановление данных (запрашивая их с того сервера) если это необходимо, в качестве этого “снимка” используется структура данных под названием MerkleTree, которая позволяет снизить количество передаваемых данных в процессе подготовки к востановлению.\n
  • Существует так же другая методика востановления целосности при репликации - StreamingRepair (AntiEntropy) - сервер F пошлет специальный запрос на получение, грубо говоря, “снимка” данных на реплецирующие серверы и сгенирирует локально свой “снимок”, при получении F поочередно сравнит снимки и произведет востановление данных (запрашивая их с того сервера) если это необходимо, в качестве этого “снимка” используется структура данных под названием MerkleTree, которая позволяет снизить количество передаваемых данных в процессе подготовки к востановлению.\n
  • Допустим сервера в нашем кластере физически находятся в различных датацентрах - отмеченны различным цветом, и мы хотим записать данные в кластер...\n
  • При этом мы можем эксплицитно указать как и куда мы хотим реплицировать данные, к примеру - 2 реплики должны быть в красном датацентре и одна в синем, данная возможность увеличивает устойчивость кластера к сбоям на уровне как датацентра так и отдельной стойки что в свою очередь существенно повышает общую надежность системы и делает утверждение что “Cassandra не может использоваться для хранения важных данных” в корне неверным.\n
  • Согласованность описывает остаётся ли система в согласованном состоянии после окончания операции. В распределенных информационных системах, как Cassandra, это обычно означает, что как только данные записанны, все получатели сразу же смогут увидеть эту запись.\n\nВ отличие от сильной согласованности используемой в реляционных БД (ACID Atomicity Consistency Isolation Durability) Cassandra использует (BASE for Basically Available Soft-state Eventual consistency). Малая согласованность в Cassandra представлена в форме “eventual consistency” это означает что база в какой-то момент времени достигнет согласованного состояния (но не возможно определить в какой именно). По мере того как данные реплицируются в кластере, обновленное значение может появиться на одном из серверов, но в тоже время старая версия этих же данных может находиться на всех остальных, но в какой-то момент времени данные будут сихранизированы на всех серверах.\nR=кол-во реплик для чтения, W=кол-во реплик для записи, N=фактор реплиции, Q=QUORUM (Q = N / 2 + 1)\nIf W + R > N, данные согласованы\nW=1, R=N\nW=N, R=1\nW=Q, R=Q где Q = N / 2 + 1\n\nВы получитете согласованность всего кластера при R + W > N (кол-во реплик для чтения + кол-во реплик для записи > фактор репликации). ConsistencyLevel ONE значит что R или W равно 1 (в зависимости от производимой операции). ConsistencyLevel QUORUM значит что R или W равно больше чем половине серверов в кластере. ConsistencyLevel ALL значит что R или W равно N. Так что если Вы хотите записать данные с ONE и после этого получить те же данные при чтении, то Вам нужно будет использовать ConsistencyLevel ALL.\n\n\n\n
  • Как видите каждая строка может представлять собой фиксированный набор колонок, а некоторые из них можно добавить дополнительную колонку Site.\n
  • CLI является отличным инструментом для начальной работы с базой, поставляется в комплекте с БД и не требует знания какого либо языка программирования, просто запустите ./bin/cassandra-cli и первой командой задайте - help. \n\nНа данном слайде приведен пример команды, которая создаст таблицу users. \n\nОбратите пожалуйста ваше внимание на способ создание индекса - нужно указать тип индекса и его название. Данный пример демонстрирует создание таблицы пользователей с указанием типов имен и значений колонок, за проверку которых пользователь отвечает сам.\n
  • Как Вы можете видеть добавление и чтение с помощью CLI очень простая операция - нужно указать название таблицы, ключ, имя и значение колонки. В данном примере мы добавляем колонки name и site в ключ xedin и с помощью команды GET читаем все колонки, которые соответствуют ключу - xedin. Команда LIST используется для чтения всех ключей и пренадлежащих им колонок.\n
  • С Cassandra 0.7 так же возможно индексирование по значениям колонок. Помните: индексирование имеет лишь одно ограничение - любой запрос со вторичным индексом (т.е. по значению) должен содержать хотя бы одно условие ”равенство”.\n
  • На данный момент БД позволяет хранить огромное кол-во колонок в одной суперколонке или под одним ключем - единственное органичение: операционная система одновременно может отобразить в память максимально 2 Гб (получение значений колонок по частям в данный момент не поддерживается на уравне протокола Thrift, а не только самой БД), данных, так что хороший совет по поводу размера строк/колонок - делайте их ”толстыми”, но до разумных пределов.\n\nТак же интересная возможность представленная в новой версии базы - колонки с предопределенным временем жизни - это полезно если вам, к примеру, необходимо сделать ленту коментариев за определенный период и не нужно держать её сохраненной, Вы просто помечаете время жизни для колоки как время оставшееся до начала следующих суток и БД всё остальное сделает за Вас.\n\nВ версии 0.8 будут добавленны так же колонки счетчики - больше не нужно писать собственный тип чтобы считать, к примеру, кол-во посещений и просмотров страниц.\n
  • Существует два возможных пути тюнинга производительности - тюнинг записи и тюнинг чтения. Сначала поговорим про запись.\n
  • Cassandra из коробки использует оптимальную схему записи - никакого чтения, а значит и seek’ов, запись всегда в конец файла (последовательно), самый хороший совет по оптимизации - использование отдельного физического диска только для Commitlog - этот диск будет всегда вращаться в одном направлении что максимально ускорит запись в Commitlog.\n\nК сожалению это тяжело сделать если вы работаете в “облаке” потому как, к примеру, rackspace предоставляет только один логический диск, который на нижнем уровне упирается в RAID. Но если у вас отдельные физические машины, лучше всего потратить немного денег и купить отдельный диск. \nЧастое заблуждение состоит в том что если увеличить кол-во Memtable до записи на диск это увеличит произвотельность записи - это ошибочное суждение, потому как это повлияет только на чтение и компановку, но не на запись.\n
  • Перед тем как оптимизировать чтение необходимо провести предварительную подготовку, определить как именно и что вы читаете - это небходимо для настройки кеширования. \n\nНапример: если Вам постоянно нужен небольшой обьем данных, который вы читаете постоянно, то стоит увеличить row cache на значение размера этого обьема - это заметно ускорит работу.\n\nRow cache - как я говорил ранее это кэширование строк целиком в память, а key cache - только позиций ключей в индексном файле.\n\nОбе методики кэширования задаются для отдельной ColumnFamily как в числовом виде, так в процентом соотношении. \n\nЧтение происходит след. образом:\n - row cache\n - key cache \n - disk\n\nИзбегайте задания слишком большого размера для row cache это может повлечь за собой то, что GC будет постоянно его убивать. Лучше всего использовать большой размер для кэша ключей, потому что они не занимают много места в памяти и позволяют избежать одного из 2х “seek”ов необходимых для чтения данных, по есть позволяют снизить нагрузку на диск в 2а раза.\n\nРекомендуется так же использовать JNA - это позволит использовать системные фунции ОС Linux, что может существенно увеличить производительность системы.\n\nТак же можно полагаться на кэш операционной системы, который не нужно настраивать, в нем будут храниться уже прочитанные куски файлов - это позволяет ускорить работу если оба верхние кэша не справляются, при включенном JNA Cassandra будет пытаться оптимально использовать данный кэш самостоятельно.\n
  • Это цена, которую, в конечном итоге, приходиться платить за быструю запись - это процесс компановки SSTable файлов в один большой файл - операция, которая характерируется большой нагрузкой на I/O подсистему, так что если при мониторинге вы начали замечать что скорость чтения резко уменьшилось - то скорее всего это как раз Compaction. Compaction - непрерывный процесс, так что если он начинает мешать Вам жить лучше всего добавить дополнительный сервер в ваш кластер. В версии 0.8 этот процесс был переработан, что позволило производить его параллельно и уменьшить обьем одновременно компануемых данных, так же в рамках версии 1.0 производиться разработка механизма, который ещё больше снизит удар по производительности. Так же минимиризовать эффект поможет увеличение кол-ва Memtable перед их записью на диск и преобразованием в SSTable.\n
  • \n
  • Cassandra использует JMX для предоставления детальной информации о системе, с помощью этой технологии можно производить мониторинг различных компонентов системы, таких как - Compaction Manager, Storage Service, а так же выполнять необходимые действия - запуск востановления (repair), компановки (compaction) или loadbalance и других.\n\nDataStax OpsCenter for Cassandra это продукт, который позвоняет легко упралять Вашим кластром с использованием веб-интрефейса: добавление новых серверов, анализ кол-ва данных/нагрузки на отдельно взятой машине, балансировка, создание keyspace’ов и ColumnFamily при необходимости, а так же многие другие дейстия.\n\nJMX даёт прекрасную возможность построить свой собственный мониторинг: Roll your own!\n
  • \n
  • Существует множество клиентов для базы данных, которые предоставляют различный уровень абстракции, например, Thrift - это самый нижний уровень общения с БД, на его базе строится Hector, а над ним в свою очередь расположен Hector object mapper.\n\nCQL - это псевдоязык запросов вдохнавленный языком SQL, он будет включен в БД вместе с выходом версии 0.8.\n
  • \n

Cassandra @JEEConf  March 21, 2011 (Kiev, Ukraine) Cassandra @JEEConf March 21, 2011 (Kiev, Ukraine) Presentation Transcript

  • Cassandra как распределенная NoSQL база данных Павел Яскевичpavel@datastax.com / @pyaskevich
  • Dynamo, 2007Bigtable, 2006 OSS, 2008 Incubator, 2009 TLP, 2010
  • Twitter: “Fifteen monthsago, it took two weeks toperform ALTER TABLEon the statuses [tweets]table.”
  • Cassandra in production• Netflix: “Cassandra is best for cross-regional deployments and scaling with no single points of failure”• Digital Reasoning: NLP + entity analytics• OpenX: largest publisher-side ad network in the world• SimpleGEO: location-as-API• Ooyala: video analytics and business intelligence• ngmoco: massively multiplayer game worlds
  • Почему всё таки Cassandra?• Реляционные БД плохо масштабируются• Б-деревья (B-Tree) не лучший выбор
  • Почему всё таки Cassandra?• Большие обьемы данных• Устойчивость к нагрузкам• Легкая масштабируемость и репликация• CAP теорема• Низкая стоимость администрирования
  • Модель данныхKeyspace a.k.a Database ColumnFamily a.k.a TableRow Row Row - key - key - key Column Column Column - name - name - name - value - value - value - timestamp - timestamp - timestamp ... ... ...
  • Запись Reader Writer Memtable CommitlogThe Log-Structured Merge-Tree,Bigtable: A Distributed Storage Systemfor Structured Data
  • Атрибуты записи• Не используется чтение• Не используется “seek”• Атомарность в пределах ColumnFamily• Данные всегда записаны
  • Чтение• По ключу или диапозон ключей• По имени или диапозону имен колонок• Никаких блокировок (lock free)• Row Cache - для избежания использования (чтения) SSTable• Key Cache - для избежания поиска по индексу
  • Структура SSTable<key 1> <row data 1><key 2> ... <row data 2> <row data 3> ...
  • Маштабирование W A (T, W] (W, A] (L, T] (A, L] T L
  • Key “C” W A T L
  • W A (A, F] F (F, L]T L
  • Key “D” W A F T L
  • Надежность• No single point of failure• Поддержка многих датацентров• Легкость в мониторинге• Доступность в рамках одного датацентра• Доступность в рамкам многих датацентров
  • Y Key “C” A WU F T L P
  • Y Key “C” A WU F T L P
  • Y Key “C” A WU F T L P
  • Y Key “C” A WU F T L P
  • Y Key “C” W AU F T P X L
  • Y Key “C” W AU F T hint P X L
  • Y Key “C” W AU F T hint P X L
  • Y W AU F T L P
  • Y W AU F T L P
  • Y W AU F T L P
  • Y Key “C” A WU F T L P
  • Y Key “C” A WU F T L P
  • Настраемаемая согласованность• ONE, QUORUM, ALL (LOCAL_QUORUM, EACH_QUORUM)• R +W > N• Выбор между доступностью и согласованностью
  • Пример ColumnFamily users Name:driftx Password:* Brandon Name: Site:jbellis Password:* Jonathan datastax.com Site:xedin Password:* Name: Pavel datastax.com
  • Псевдокод (c использованием CLI)• Создание ColumnFamily users: CREATE COLUMN FAMILY users WITH key_validation_class=UTF8Type AND comparator=UTF8Type AND default_validation_class=UTF8Type AND column_metadata=[ { column_name:password, validation_class:UTF8Type }, { column_name:site, validation_class:UTF8Type, index_type:KEYS, index_name:SiteColIndex } ];
  • Псевдокод (c использованием CLI)• Добавление данных: ‣ SET users[xedin][name] = ‘Pavel’; ‣ SET users[xedin][site] = ‘datastax.com’;• Чтение данных: ‣ GET users[xedin]; ‣ GET users WHERE name = ‘Pavel’; ‣ LIST users;
  • Индексы Site: datastax.com jbellis xedin ...GET users WHERE site = ‘datastax.com’;
  • Динамическая ColumnFamily(миллиарды колонок)• Примеры: • Активность друзей (a lá twitter feed) • Лента комментариев за определенный период (час, день, месяц, год)
  • Тюнингпроизводительности• Два возможных пути - тюнинг записи - тюнинг чтения
  • Тюнинг записи• Перенести Commitlog на отдельный физический диск - Тяжело сделать в “Облаке”• Увеличить количество Memtable до записи на диск (по-умолчанию: 4)?
  • Тюнинг чтения! Определите свой паттерн чтения• key cache• row cache• OS file cache + JNA
  • Compaction - убийца скорости чтения
  • Производительность• MySQL ➡ write ~300 ms ➡ read ~350 ms• Cassandra ➡ write ~0.12 ms ➡ read ~15 ms
  • Мониторинг• JMX• DataStax OpsCenter for Apache Cassandra• Ваш собственный?
  • API•libpq •Thrift•JDBC •Hector•JPA •Hector object mapper• CQL (>= 0.8)
  • Вопросы