Кассандра против упругого поиска против любых других дизайнерских предложений - PullRequest
Новая
       15

Кассандра против упругого поиска против любых других дизайнерских предложений

0 голосов
/ 31 мая 2019

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

alm(id,name,cli, group_id, con_id ...)
group(id, type,timestamp ...)
con(id,ip,port ...)

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

Теперь мы хотим запускать запросы агрегации, такие как: 

select name from alm, group, con where alm.group_id=group.id and alm.con_id=con.id group by name, group.type, con.ip

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

Пока чтоварианты, которые мы рассматриваем, перемещаются в Cassandra, Elasticsearch или Dynamo db, чтобы агрегация была быстрее.Может кто-нибудь подсказать, как решить эту проблему?Или какие-то крошки опыта?Кто-нибудь знает, какие технологии имеют серьезные преимущества перед другими?

Ответы [ 2 ]

1 голос
/ 31 мая 2019

Cassandra и DynamoDB довольно сильно отличаются от ElasticSearch. И все три очень отличаются от предложений реляционных баз данных.

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

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

Если у вас большие объемы данных и вам требуется агрегирование, у вас есть два варианта:

  1. если вы можете обойтись без автономной аналитики, то распределенные структуры обработки данных, такие как Spark, могут очень эффективно получить необходимые вам ответы

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

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

0 голосов
/ 31 мая 2019

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

В последнее время Яндекс ClickHouse становится очень популярным, и есть сервис, ориентированный на столбцы от Amazon - Redshift . Также есть несколько других решений

...