Какая может быть скорость работы ElasticSearch для заданного кейса и есть ли другие альтернативы?

Question

[Snowindy]

Здравствуйте, я новичок в ElasticSearch, хочу понять, подходит ли он мне для технической задачи, которую решаю.
Опишу данные и кейс.

record {
customerId: "id",      <---- индексируется
binaryData: "data"   <---- не индексируется
}

Ожидания:

• средний размер бинарных данных записи - 1-2 килобайта
  
• по одному customerId - до 100 записей
  
• количество записей - 500М
  
• паттерн записи №1: вставка одной записи за раз
  
• паттерн записи №2: батчами, можно в параллель, со скоростью не менее 20М record в час
  
• паттерн поиска №1: поиск всех записей по customerId
  
• паттерн поиска №2: поиск всех записей по группе customerId, можно в параллель, со скоростью не менее 10М customerId в час
  
• данные не самые важные, можно разменять некоторые аспекты надежности на скорость. Главное - насмерть не ложиться и системно не терять куски данных
  
• работать предполагаем в AWS/GCP - и самим админить систему не хочется точно
  

• Возможно ли достичь таких показателей скорости на ElasticSearch?
  
• Какие сервера для такой задачи могут пойти?
  
• Как дела вообще у ElasticSearch с надежностью? Можно ли ожидать хорошей надежности, если использовать облачные сервисы типа AWS с репликами в разных регионах?
  
• Может быть, есть другие системы, хорошо подходящие под такие требования?
  

Спасибо!

Answer 1

[Иван Шумов]

Вам не нужна поисковая система. Это задача для key-value storage. Можете использовать для этого AWS DynamoDB, например.

Comments

[Snowindy]

Спасибо!
DynamoDB билл считает по запросам, 20М запросов это 25 баксов. Короче, очень дорого выходит :)
Может быть, другие варианты KV стораджей приходят в голову?

[Иван Шумов]

Snowindy, я скажу больше - с указанным требованием отказоустойчивости и перфоманса ТАК дёшево ещё нигде не было

Answer 2

[Vitaly Karasik]

Согласен с Иван Шумов - нет смысла гонять ElasticSearch для key-value.
Вот хорошее интро в разные AWS варианты, и я бы начал проверять с DynamoDB:
https://cloudonaut.io/databases-on-aws/

Comments

[Snowindy]

К сожалению, DynamoDB билл считает по запросам, 20М запросов это 25 баксов. Получится слишком дорого..
Спасибо за ссылку, изучу

[Vitaly Karasik]

Кстати, увидел что вы пробовали RDS. А какой? Я недавно игрался с Postgres, и m5.8xlarge писал около 5000 записей в секунду (тоже маленькие записи, timeseries from IoT).

[Snowindy]

2TB SSD GP2, 64GB RAM 8 CPU
Упираемся в IOPS - 6К IOPS.

С вашими 5к в секунду это 20М в час. Но данные проще - это time series, т.е. элементы индекса (он же по времени, верно?) лежат очень рядом - и запись происходит в блоки кучно - и индекса и данных.

У меня customerId это довольно рандомное число, значит по индексу будем бегать и писать очень фрагментарно. Возможно случаются еще какие-то блокировки на индекс при записи конкурентно, это непросто расследовать..

Я даже отсортировал по customerId ASC, и индекс сделал не по конкретному customerId, а по префиксу, типа записи 11111185 и 11111186 будут попадать в один бакет "111111", а далее работать как hashmap, но даже так не выжимается более 1-2М записей в час.

[Vitaly Karasik]

С вашими 5к в секунду это 20М в час

да, я поэтому и вспомнил.

Упираемся в IOPS - 6К IOPS.

Если не жалко денег (осторожно, дорого!!!), можно купить provisioned IOPS, как минимум для PoC: https://aws.amazon.com/ebs/features/#SSD-backed_vo... , up to 64000 IOPS

Answer 3

[Dimonchik]

clickhouse

Comments

[Snowindy]

Не могли бы выпояснить какие архитектурные моменты кликхауса делают его хорошим выбором для этой задачи? Буду очень благодарен!

Answer 4

[d'Ivan]

паттерн поиска №1: поиск всех записей по customerId

это сценарий для СУБД key/value.
Но:

паттерн поиска №2: поиск всех записей по группе customerId,

это запрос вида

SELECT blob FROM table WHERE customerId IN (100, 101, 200)

Не уверен, что DynamoDB поддерживает такие запросы. Иван Шумов ?

Так что я пока голосую за RDS/Aurora. Вот только насчет этого надо протестировать:

паттерн записи №2: батчами, можно в параллель, со скоростью не менее 20М record в час

Comments

[Иван Шумов]

In не поддерживается, но для таких задач обычно и не используется

[Snowindy]

Сейчас у нас такая архитектура реализована в СУБД MySQL в AWS RDS.
Выжать более миллиона записей в час не очень выходит, упираемся в WRITE IOPS..

[d'Ivan]

Snowindy,

Сейчас у нас такая архитектура реализована в СУБД MySQL в AWS RDS.
Выжать более миллиона записей в час не очень выходит, упираемся в WRITE IOPS..

Сколько IOPS получается и какой потолок?
Какой тип инстанса выбрали?
А пробовали ли Aurora?

[d'Ivan]

Кроме того, чтобы освободить master от чтений во время интенсивных WRITE IOPS, можно использовать дополнительно реплики для чтения.

Если вариант с RDS и Aurora по каким-то причинам не прокатит (пока неясно насчёт вопросов, заданных выше), то остается также вариант держать RDS для более простых вещей, таких как таблицы отношений сущностей, а сами записи держать в DynamoDB.

[Snowindy]

Роман Мирр, 6К IOPS. 2TB SSD GP2, 64GB RAM 8 CPU
Аврору не пробовали пока что.

[d'Ivan]

Ну тогда попробуйте Аврору. Она позволяет больше IOPS, ничего не меняя в коде.