Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Алексей Чумаков. Apache Cassandra на реальном проекте

4,512 views

Published on

Published in: Software
  • Be the first to comment

Алексей Чумаков. Apache Cassandra на реальном проекте

  1. 1. Алексей Чумаков achumakov@exadel.com Skype: alexey.chumakov
  2. 2. Вкратце • Немного о NoSQL вцелом • Что такое Apache Cassandra и для чего она может понадобиться • Как она устроена изнутри • Несколько примеров • Нюансы... • Администрирование
  3. 3. НЕМНОГО О NOSQL…
  4. 4. NoSQL. Зачем?
  5. 5.  Join, group by, count начинают работать медленно на больших объемах данных  BigData – данных много (не помещаются на один сервер) и они все нужны  Необходима репликация данных между датацентрами и их постоянная доступность (availability)  Partitioning/sharding вручную не всегда удобен  А еще хотим гибкую схему данных... NoSQL. Зачем?
  6. 6. Pull on Demand vs Push on Change
  7. 7. CAP-теорема http://blog.nahurst.com/visual-guide-to-nosql-systems
  8. 8. ЧТО ТАКОЕ APACHE CASSANDRA?
  9. 9. История Организация кластера (consistent hashing), hinted handoff, read repair Структура данных (SSTables), timestamps ?
  10. 10. Распределенная и горизонтально масштабируемая http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
  11. 11. Добавление новых нодов • Скачать и распаковать дистрибутив • Настроить IP • Указать seed nodes • Запустить 
  12. 12. Что-то еще? • Децентрализованная (кольцо, нет master node, нет single point of failure) • Репликация между нодами и дата-центрами • Настраиваемая Consistency (Tunable Consistency) • Низкий уровень вхождения в NoSQL благодаря CQL (Cassandra Query Language) • Поддержка Hadoop
  13. 13. И в чем подвох? • Нет ACID транзакций • Сложно гарантировать 100% consistency данных • Нет сложных запросов (никаких like, join, group by) • Схему данных приходится продумывать исходя из будущих запросов, а не наоборот
  14. 14. Когда имеет смысл использовать Apache Cassandra? • Количество операций записи больше, чем чтения • Данные должны быть постоянно доступны для чтения и записи, несмотря на потерю N нодов • Анализ поведения пользователя • Агрегаторы • Мониторинг
  15. 15. Когда не нужна C*? • Данные помещаются в память • Данные помещаются на одном сервере • Не предвидится серьезного роста объема данных • Данные редко модифицируется и возможно реализовать шардинг
  16. 16. КАК APACHE CASSANDRA УСТРОЕНА ИЗНУТРИ?
  17. 17. Организация кластера
  18. 18. Запись в любой доступный нод кластера
  19. 19. Hinted Handoff
  20. 20. Read repair
  21. 21. Anti-entropy repair • Что будет, если Coordinator Node умрет? • Лучше запускать по расписанию • bin/nodetool repair
  22. 22. Физическая организация данных • Нет B-Trees • Используются отсортированные в памяти таблицы фиксированного размера (SSTables) • SSTable последовательно записываются на диск, а потом объеденяются в отдельном потоке (compaction) • При удалении физически ничего не меняется, а ставится маркер (tombstone)
  23. 23. Физическая организация данных
  24. 24. ЛОГИЧЕСКАЯ СТРУКТУРА ДАННЫХ = Map<Key, Map<Column, Value>>
  25. 25. Map<Key, Map<Column, Value>>
  26. 26. При использовании CQL все очень похоже на RDBMS CREATE TABLE order_events ( order_id ascii, operation_time timestamp, operation_type ascii, waiter ascii, changed_menu_items list<ascii>, PRIMARY KEY (order_id, operation_time) );
  27. 27. Но в действительности все немного не так...
  28. 28. Идемпотентность • Повторная запись по тому же ключу c теми же значениями ничего не меняет • Insert == Update INSERT INTO NerdMovies (movie, director, main_actor, year) VALUES ('Serenity', 'Joss Whedon', 'Nathan Fillion', 2005); UPDATE NerdMovies SET director = 'Joss Whedon', main_actor = 'Nathan Fillion', year = 2005 WHERE movie = 'Serenity';
  29. 29. Распределенные счетчики • Работают с той же скоростью, что и обычный update • Не идемпотентны UPDATE UserActions SET total = total + 2 WHERE user = B70DE1D0-9908-4AE3-BE34-5573E5B09F14 AND action = 'click';
  30. 30. НЕСКОЛЬКО ПРИМЕРОВ...
  31. 31. Нагрузочное тестирование Black Box
  32. 32. Данные для каждой транзакции CREATE TABLE transactions ( transaction_id ascii, transaction_data map<text, text>, PRIMARY KEY (transaction_id) );
  33. 33. Данные для каждой транзакции CREATE TABLE transaction_metrics ( transaction_id ascii, tr_type ascii, time timestamp, PRIMARY KEY (transaction_id, tr_type) );
  34. 34. Статистика CREATE TABLE transaction_count ( stat_id ascii, time_string ascii, ops_count counter, PRIMARY KEY (detail_key, time_string) )
  35. 35. А теперь получаем нужный нам промежуток SELECT time_string, ops_count FROM transaction_count WHERE stat_id = ‘B_REQ|20140510' AND time > '2014051003' AND time <= '2014051015'
  36. 36. Что не стоит делать с C*? • Пытаться создать очередь на ее основе • Читать перед записью – в большинстве случаев можно воспользоваться счетчиками или идемпотентностью • Писать все в один Wide Row или часто удалять данные из него
  37. 37. НЮАНСЫ
  38. 38. Очень высокая загрузка CPU • Слишком большой HEAP • concurrent_reads/concurrent_writes • native_transport_max_threads • rpc_max_threads
  39. 39. Anti Entropy Repair • nodetool repair • Осбенно нужен в тех случаях, когда кластер оказался перегружен
  40. 40. Amazon EBS volumes
  41. 41. Слишком Wide Rows • Запись в Wide Row оказалась в 5 раз медленне, чем в row с разными ключами • Удаления из Wide Row требуют много памяти во время compaction (TombstoneOverwhelmingException) • Все записи из Wide Row физически находятся на одном ноде (и его репликах)
  42. 42. Синхронизация времени между нодами • Время на нодах (даже в AWS) может быть рассинхронизированно • Timestamps оказываются неверными • Данные в итоге тоже
  43. 43. Bugs Баги есть! ...но правят их быстро
  44. 44. Администрирование • Nodetool – command-line утилита, в которой есть все (или почти все) для администрирования кластера • DataStax OpsCenter – красивый веб-интерфейс для администрирования, есть Community Edition
  45. 45. Правильный выбор технологий VS
  46. 46. Q & A

×