DCE Cassandra 3.9 медленно создает вторичный индекс при присоединении к существующему кластеру

Question

У нас есть кластер кассандры с 32 узлами, средний размер узла составляет около 1 ТБ. Конфигурация узла 1xIntel Xeon E3-1271v3, оперативная память 32 ГБ, жесткий диск 2x3 ТБ. У нас есть одна БД с несколькими небольшими таблицами и одна большая таблица, которая составляет около 90-95% от общего размера кластера.

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

Я изменил конфигурацию cassandra, чтобы расширить пределы:

• concurrent_compactors: 4
• compaction_throughput_mb_per_sec: 0

Кассандра полный конфиг

схема

Около 1 года назад мы также добавили новые узлы в этот кластер и расширили его с 16 до 32 узлов, средний размер узла составлял 1 ТБ до расширения кластера. Кассандра версия была 2.1. Время соединения одного узла составляло 1-1,5 дня.

Итак, вопрос, как мы можем ускорить этот процесс? Мы что-то пропустили?

Благодарю.

Answer 1

Это немного длиннее, так что я не могу поместить это в комментарий... извините.

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

CREATE INDEX links_by_author_url_idx ON keyspace.links_by_author (url);


CREATE INDEX docs_url_idx ON keyspace.docs (url);


CREATE INDEX om_master_object_id_idx ON keyspace.om (master_object_id);


CREATE INDEX actions_pday_idx ON keyspace.actions (pday);


CREATE INDEX authors_yauid_idx ON keyspace.authors (yauid);

CREATE INDEX authors_login_lr_idx ON keyspace.authors (login_lr);

CREATE INDEX authors_login_idx ON keyspace.authors (login);

CREATE INDEX authors_email_idx ON keyspace.authors (email);

CREATE INDEX authors_name_idx ON keyspace.authors (name);

По сути, каждый имеющийся у вас индекс позволяет вам "искать" по базовым объектам, чтобы найти их по какому-либо условию. Большинство условий на самом деле довольно узкие, что является хорошей новостью. Но дело в том, что индексы станут массовыми (уже сделали), особенно на документах и ​​авторах. Но я думаю, что док более проблематично.

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

Проблема с присоединением узлов заключается в том, что, когда они получают новые данные, все данные в кластере должны быть перестроены... для каждого отдельного узла в кластере, и это стоит вам много времени. Таким образом, в основном вы теряете все преимущества "легкого объединения узлов", которыми обладает Кассандра.

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

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

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

Мой честный совет - держитесь подальше от индексов. Я знаю, это адски реорганизовать этот плюс, трудно найти время на рефакторинг:(Но я думаю, что это должно быть управляемым.