Приложение ExpressJS, которое получает около 70 запросов в секунду - медленная производительность Cassandra

Question

Это не вопрос, связанный с кодом, а скорее с производительностью сервера и вещами, которые я должен проверить. Итак, у меня есть сервер ExpressJS, который подключен к базе данных Cassandra (1 начальный узел и 2 узла на 1 кластере, то есть всего 3 узла). API работает на том же сервере, что и начальный узел cassandra db. У меня всего 3 сервера в локальной сети.

Таким образом, структура выглядит следующим образом -

на сервере 1 работает API и начальный узел кассандры. На сервере 2 работает узел Кассандры. на сервере 3 работает узел кассандры.

Каждый сервер имеет 8 ГБ оперативной памяти и 2,5 ГГц ЦП.

По умолчанию каждую секунду поступает около 70 запросов, которые выполняют следующее:

1) Вызывает функцию, которая считывает данные из таблицы с кассандры (используя материализованное представление). 2) Читает другую таблицу из Кассандры БД (используя материализованное представление). 3) Отправляет данные в третью таблицу на кассандре.

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

Пропорциональная разница между функцией, вызываемой каждую секунду, примерно в 30 раз больше, чем вызывается функция 1 (которая выполняет 2 чтения и 1 публикацию), и примерно в 40 раз вызывается функция 2 (которая выполняет 1 чтение и 1 публикацию).

Все было бы замечательно, но время ожидания запросов скачкообразно время от времени, иногда это занимает около 10 мс, но каждые 5 - 10 секунд оно увеличивается до 3-30 секунд. Также кажется, что кассандра нестабильна - в период, когда время запроса составляет 3-30 секунд, кажется, что кассандра истекает по некоторым запросам.

Что было бы первым, что я должен проверить? Нужны ли мне дополнительные узлы и как я могу выяснить, достаточно ли у меня узлов для объема данных, отправляемых в cassandra db? Должен ли я отделять API от узлов Кассандры - таким образом, держать сервер API на отдельном сервере, например, на сервере 4?

Answer 1

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

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

Первый вариант, который я хотел бы изучить, - это денормализовать и создать отдельную таблицу для первой функции, поэтому вы будете выполнять одно чтение вместо двух.

В моем ответе много спекуляций, так как в структуре и схеме вашей таблицы много неизвестных; если вы включите трассировку, вы сможете лучше понять, что в нашем случае мы получили хорошие результаты с openzipkin, как объясняет TLP