Использование Cassandra для хранения неизменяемых данных?

Question

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

Требования:

1. Нам нужно хранить около 10 событий в секунду (но скорость будет увеличиваться). Каждое событие невелико, около 1 Kb.
2. Очень важным требованием является то, что нам нужно иметь возможность воспроизводить все события по порядку. Для нас было бы неплохо прочитать все данные в порядке ввода (например, сканирование таблицы), поэтому явный вид может не понадобиться.

Запрос данных любым другим способом не является главной проблемой, и поскольку Cassandra является схемой db, я не думаю, что это возможно, когда события бывают разных форм? Будет ли Кассандра хорошо подходить для этого? Если это так, то об этом нужно знать?

Answer 1

У меня были те же требования к «проекту» (скорее, инструмент) год назад, и я использовал Кассандру, и я не пожалел. В целом он очень хорошо подходит. Вы можете поместить довольно много данных в кластер Cassandra, и производительность впечатляет (хотя вам может потребоваться настройка), и естественный порядок - это хорошая вещь.

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

Вы должны подумать о своей схеме. Данные естественно упорядочены в пределах одной строки с помощью ключа кластеризации, в вашем случае это будет метка времени. Однако вы не можете заказывать данные между разными строками. Они могут быть заказаны после запроса, но это никоим образом не гарантируется, поэтому не думайте об этом. Был какой-то способ написать запрос до 2.1, я верю (используя order by и отключив пейджинг и разрешая фильтрацию), но это привело к плохой производительности, и я не думаю, что это возможно даже сейчас. Поэтому вы должны заказывать данные между строками на стороне запроса.

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

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

Эксперимент с вашими запросами сначала на фиктивном примере. Вы не можете произвольно использовать <, > или = в запросах. There are specific rules in SQL with filtering, or using the WHERE clause..

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

Не ожидайте слишком многого из коллекций внутри столбцов, их длина ограничена ~ 65000 элементами.

Не попадитесь в заблуждение, что заявления дозируемого быстрее (это один классический :))

Answer 2

Основываясь на требованиях, которые вы выразили, Cassandra может быть хорошо подходит, поскольку это хранилище данных с оптимизацией записи. Временные ряды - довольно общий шаблон, и вы можете определить порядок кластеризации, например, на отметке времени событий, чтобы получить все события по времени. Я нашел this article on Datastax Academy очень полезным, когда хотел узнать о временных рядах.

Переменная структура данных Это не проблема: вы можете хранить данные в BLOB, а затем анализировать их из своего приложения (т. Е. Хранить его как JSON и читать в своей модели), или вы даже можете хранить данные в a map, хотя коллекции в Кассандре имеют некоторые оговорки, о которых хорошо знать. Here you can find docs about collections in Cassandra 2.0/2.1.

Cassandra сильно отличается от базы данных SQL, и хотя CQL имеет некоторое сходство, существуют фундаментальные различия в шаблонах использования. Очень важно знать, как работает Cassandra и как моделировать ваши данные, чтобы добиться эффективности - замечательная статья из Datastax объясняет the basics of data modelling.

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