Cassandra. Patterns.

Transcript

1. Cassandra. Patterns.
2. Для кого доклад Для разработчиков, которые уже знают что такое Cassandra, для чего она нужна и попробовали ее использовать.
3. Cassandra. Internals. Cassandra имеет внутри структуру хранения, похожую на lsm tree + wal. Верхний уровень - memtable (sorted by row key, btree-like). Нижний уровень - disk (sstable + bloom filter).
4. Cassandra. Java point of view. SortedMap<RowKey, SortedMap<ColumnKey, ColumnValue>>
5. Cassandra. Internals. Write path.
6. Cassandra. Internals. Read path.
7. Cassandra. Сильные стороны. • Почти линейная масштабируемость записи и чтения • Автоматическое восстановление консистентости данных после сбоев • Есть поддержка нескольких ДЦ • Настраиваемая модель (в терминах CAP) • Стабильный продукт с первоклассным community
8. • Нет ACID транзакций • Частое удаление данных это проблема • Нет хороших secondary index* * Индексы сейчас улучшаются: https://github.com/xedin/sasi и CASSANDRA-10661) Cassandra. Слабые стороны.
9. Лайки CREATE TABLE LikedByObject( user_id bigint, object_id bigint, created bigint, PRIMARY KEY (object_id, user_id) ); CREATE TABLE LikedByUser( user_id bigint, object_id bigint, created bigint, type_id int, PRIMARY KEY ((user_id, type_id), object_id) );
10. Лайки • Выбрать всех кто лайкал объект select * from LikedByObject where object_id = 42 • Выбрать все что лайкал пользователь select * from LikedByUser where user_id = 42 and type_id in (1, 2, 3)
11. Лайки Нет secondary index, используем materialized view. Почти всегда копирование данных более предпочтительно, так как самое затратное при чтении данных с диска это seek. Прочитать чуть больше данных, но из одного место быстрее, чем из двух.
12. Уведомления
13. Уведомления • Выбрать “страницу” уведомлений для одного пользователя select * from NotificationByUser where user_id = 42 and shard_part = '2016-06-01' and id < 13ef9680-0265-11e6-99a2-9f62c341220a order by id desc limit 20
14. Уведомления CREATE TABLE NotificationByUser ( user_id bigint, shard_part text, id timeuuid, type_id int, ..... PRIMARY KEY ((user_id, shard_part), id) ) WITH CLUSTERING ORDER BY (id DESC); CREATE TABLE NotificationByUserAndType ( ..... PRIMARY KEY ((user_id, type_id, shard_part), id) ) WITH CLUSTERING ORDER BY (id DESC); CREATE TABLE NotificationSeen ( user_id bigint, id timeuuid, value boolean, PRIMARY KEY (user_id, id) ) WITH CLUSTERING ORDER BY (id DESC);
15. Уведомления Уведомления всегда отсортированы по времени события, к которому они относятся. Используем clustering order, чтобы данные физически хранились в нужном порядке. Уведомления могут быть непросмотренные и просмотренные. Выделим мутабельную часть данных в отдельную cf. Это упрощает процесс обновления данных и API.
16. Уведомления • Пометить обновление как прочитанное update NotificationSeen set seen = True where user_id = 42 and id = 13ef9680-0265-11e6-99a2-9f62c341220a
17. Уведомления Прекрасно, но что делать если появилась кнопка, которая помечает все уведомления как прочитанные? Помечать все уведомления за всю историю не комильфо.
18. Уведомления CREATE TABLE NotificationByUser ( user_id bigint, shard_part text, id timeuuid, type_id int, ..... PRIMARY KEY ((user_id, shard_part), id) ) WITH CLUSTERING ORDER BY (id DESC); У одного пользователя может быть очень много уведомлений. Таким образом у нас могут появится wide rows. Их нужно избегать (OOM, additional seeks, вот это вот все). Добавим в partition key дату.
19. Partition keys Как правильно выбрать partition key? Распределение колонок внутри строки должно быть равномерным в идеале. В одной строке не должно быть слишком много данных (wide rows). Варианты: • Сам ключ • Ключ + timebased часть • Ключ + partition (n of partitions fixed or any)
20. Partition keys Лайки. У одного объекта очень редко бывает слишком много лайков. Object id хороший partition key. Уведомления. У одного пользователя может быть очень много уведомлений, так как они накапливаются со временем. User id плохой partition key. Нужно добавить что-то еще. User id + date. Можно также сделать предположение, что уведомления более- менее распределены по дням равномерно, поэтому date подходит.
21. Partition keys Лента постов по тегу. CREATE TABLE TagPosts ( tag text, partition int, post_id bigint, PRIMARY KEY((tag, partition), post_id) ) WITH CLUSTERING ORDER BY (post_id DESC); Просто tag взять нельзя, потому что распределение имеет выбросы (тренды) и длинный хвост. Date плохая идея, так как хвост и тренды не зависят от даты.
22. Partition keys Неестественное разбиение данных на любое количество partitions сложнее. При вставке нужно вычислять partition. CREATE TABLE TagPostsPartitions ( tag text, partition int, post_count counter, PRIMARY KEY (tag, partition) ) WITH CLUSTERING ORDER BY (partition DESC);
23. Partition keys Если вы уверены, что кол-во данных по каждому ключу примерно одинаково, то вычисление partition может быть простым: key % n partitions
24. Partition keys Вопрос: можно ли делать skinny partitions*? *skinny partition - в одной партиции одна строка Ответ: да, если паттерн доступа random и нет range queries. CREATE TABLE BlackList ( login text, created bigint, PRIMARY KEY (login) );
25. Вставка • Используйте batches, только если вам действительно нужна атомарность • Для производительности используйте асинхронные операции (в драйвере) с одиночными запросами* *http://lostechies.com/ryansvihla/2014/08/28/cassandra-batch-loading- without-the-batch-keyword/
26. Вставка • Используйте unlogged batches только в случае модификации одного partition key* *https://docs.datastax.com/en/cql/3.1/cql/cql_us ing/useBatch.html
27. Удаление CREATE TABLE Queues ( queue_id bigint, enqueued timeuuid, PRIMARY KEY (queue_id, enqueued) ); Классический anti-pattern!
28. Удаление Как и в любом log-structure merge tree engine, данные не удаляются физически в момент вызова операции удаления. Удаленные данные будут помечены, как tombstone, и через некоторое время (настраивается) будут физически удалены при очередном compaction. Операция DELETE по ключу выполняется за O(1). Операция выборки вида: select * from Queues where queue_id = 42 order by enqueued limit 1 может выполняться за O(n).
29. Удаление • Думайте про удаление заранее • Старайтесь удалять партиции целиком
30. Избегайте RMW • Чтение часто дороже записи, потому что есть, как минимум, один seek. • Могут быть проблемы с консистентностью
31. Избегайте RMW • Делайте операции идемпотентными и переписывайте данные • Используйте counter columns • Используйте транзакции осторожно, они уменьшают производительность и все равно не ACID
32. Вопросы https://facebook.com/denis.gabaydulin (messanger) gabaden@gmail.com