Чому Кассандра рекомендує не створювати індекс на стовпцях високої кардинальності?

У документації Кассандри зазначено:

Не використовуйте індекс у таких ситуаціях:

• У стовпцях з високою кардинальністю, оскільки ви запитуєте величезний обсяг записів для невеликої кількості результатів. Див. Проблеми із використанням індексу стовпців високої кардинальності нижче.

Це продовжується,

Якщо створити індекс у стовпці з високою кардинальністю, який має багато чітких значень, запит між полями спричинить багато запитів за дуже мало результатів. У таблиці з мільярдом пісень пошук пісень письменника (значення, яке зазвичай є унікальним для кожної пісні) замість їх виконавця, ймовірно, буде дуже неефективним. Напевно, було б ефективніше підтримувати таблицю як форму індексу вручну, а не використовувати вбудований індекс Cassandra. Для стовпців, що містять унікальні дані, іноді досить зручно використовувати індекс для зручності, якщо об'єм запитів до таблиці, що має індексований стовпець, є помірним і не знаходиться під постійним навантаженням.

Але ніколи насправді не відповідає на питання: чому це неефективно? Я поняття не маю, що означає "вручну підтримувати таблицю як форму індексу". Але тоді це дещо суперечить самому собі "... іноді чудово ефективність використання індексу для зручності до тих пір, поки обсяг запиту є помірним ..."

Це просто намагаюся сказати мені використовувати ПК, коли і де я можу? У чому полягає неефективність? Я розумію, що запит, який би потрапив до індексу, повинен запитувати кожен вузол кластера, і тоді кожен вузол зробив би пошук у своєму локальному індексі, а результати отримали б агрегацію. Це не обов'язково дорого (кожен пошук індексу повинен бути досить дешевим), за винятком того, що ми платимо в мережевій затримці, оскільки нам потрібно чекати найповільнішого вузла партії. Я чогось тут пропускаю?

Але якщо у мене є колекція, яка містить мільйони предметів, які - рідко - потрібно шукати за іншим, але майже унікальним атрибутом ... це правильне використання, правда?

_{¹Всі? IDK, якщо реплікація означає, що це може вразити 1/3 кластера для коефіцієнта реплікації 3 чи ні?}

З індексом Кассандри ( тобто "вторинним індексом", на відміну від первинних ключів) кожен вузол повинен запитувати власні локальні дані для відповіді на запит (див. FAQ щодо вторинних індексів Кассандри ). Ці індекси також будуються за допомогою фонового процесу . Таке підґрунтя означає, що індекс може повертати помилкові негативи з точки зору звернень (або помилкових позитивних результатів з точки зору промахів).

Це означає, що в стовпці з високою кардинальністю швидкість змін ( тобто доповнень / вилучень) з цього стовпця може бути досить високою. Таким чином, якщо ця швидкість зміни швидша, ніж оновлення індексу за допомогою фонового процесу, то використання індексу є "неефективним" (індекс виконує більше роботи, ніж потрібно додатку, що часто може отримати неправильну відповідь) .

Більш ефективним підходом з точки зору точності запитів може бути підтримка другої таблиці , а не вторинного індексу. Таблиці, на відміну від індексів , трактуються так само, як і будь-яка інша таблиця. Вони більш імовірно , щоб дати вашому додатку результати запиту він очікує . Мінусом є те, що підтримка таблиці як індексу , порівняно з "вторинним індексом Кассандри", тепер є обмеженнями програми ( тобто ваш код програми тепер повинен знати, щоб вставити / видалити рядки з цієї таблиці "індекс", і щоб синхронізувати дві таблиці за допомогою "узгодження" на рівні програми.

Сподіваюся, це допомагає!

Деяка термінологія: батьківська таблиця - це таблиця, на якій створюється індекс. Вторинна таблиця індексів - це таблиця, створена для підтримки індексу в іншій таблиці.

Дані таблиці вторинних індексів зберігаються на тому ж вузлі, що і дані батьківської таблиці. Касандра-учасник не розділяє і не поширює дані таблиці індексу. Отже, якщо ви хочете здійснити пошук у стовпці індексу, всі вузли запитуються, а не лише вузли репліку, що містять дані. (вузол координатора не знає, де перебувають дані) https://www.datastax.com/dev/blog/cassandra-native-secondary-index-deep-dive

Для стовпців високої кардинальності, таких як ssn або якийсь інший унікальний ідентифікатор, буде відображатися один на один зі первинним ключем. Якщо ви створюєте індекс у такому стовпчику, дані розміщуються на кількості вузлів коефіцієнта реплікації, але виклик пошуку виконується на всіх вузлах. У кращому випадку координатор безпосередньо потрапляє на вузли, що містять дані. Після досягнення рівня узгодженості ви отримуєте результат. Найгірше, якщо дані, які ви шукаєте, відсутні в індексі, ви зачекаєте, поки всі вузли відгукуються, щоб виявити, що даних немає. Отже, для кожного виклику пошуку в таблиці вторинного індексу всі вузли потрапляють. Порівняйте це з лише коефіцієнтом реплікації, кількість вузлів, які отримують звернення для кожного виклику пошуку, у випадку, якщо таблиця є звичайною таблицею C *.