#apache-kafka
#apache-kafka
Вопрос:
У меня есть приложение, которое требует интересной координации между состояниями экземпляров, распределенных по географическим регионам, в сочетании с необходимостью масштабируемой распределенной базы данных.
На данный момент я думаю, что Kafka с уплотнением журналов будет соответствовать моим потребностям в обслуживании состояния и обмене сообщениями между экземплярами, а Cassandra будет соответствовать моим потребностям в большом объеме распределенных операций чтения и записи сохраненных данных.
Однако таким образом дублируется довольно много данных: многие данные, которыми обмениваются через Kafka, также должны быть сохранены в Cassandra для распределенного доступа к данным. Использование Kafka как для обмена сообщениями, так и для запросов и сохранения распределенных данных кажется заманчивым.
Поэтому мне интересно выяснить реальные плюсы и минусы, которые следует ожидать при использовании, например, функции pull queries в Kafka для использования ее в качестве распределенной базы данных [1].
Хотя я немного с подозрением отношусь к тому, чего ожидать от этого с точки зрения производительности и масштабируемости, особенно по сравнению с Cassandra, а также к неизвестным подводным камням.
Каковы компромиссы при использовании Kafka в качестве распределенной БД и что бы это сравнило по производительности с «родными» распределенными системами, такими как Cassandra?
[1] https://www.confluent.io/de-de/blog/pull-queries-in-preview-confluent-cloud-ksqdb /
Комментарии:
1. Ответ заключается в типах запросов, которые вы действительно хотите выполнить. Являются ли они KV-поисками или диапазонами? Будут ли они включать сканирование многих столбцов с разными типами?
2. Действительно, эта информация отсутствует. Извините. Это будет чистый поиск KV.
Ответ №1:
чистый поиск KV
Тогда хранилища состояний / интерактивные запросы Kafka могут работать, но с оговоркой, что если вы используете контейнеры и оркестратор, вам необходимо поддерживать состояние этих хранилищ где-то на постоянных томах. В противном случае, когда контейнеры перемещаются на новый хост, раздел журнала изменений потоков необходимо читать с самого начала, что создает проблему «холодного запуска», и вы не сможете выполнить запрос.
Использование любой базы данных (с постоянным хранилищем) не будет иметь этой проблемы и всегда сможет выполнить запрос немедленно.
Я не уверен, что я бы предложил Cassandra для строго данных KV.
Комментарии:
1. Спасибо за этот вклад, я буду исследовать эту проблему дальше. Какую другую базу данных вы бы предложили?
2. На мой взгляд, Couchbase хорошо спроектирована как распределенный кеш. В противном случае, Druid или Apache Pinot также имеют встроенные средства приема Kafka и используются командами обработки данных Netflix / Uber / LinkedIn