Выбор первичного ключа для максимальной производительности колоночных таблиц
В отличие от строковых таблиц YDB, колоночные таблицы партиционируют данные не по первичным ключам, а по специально выделенным ключам — ключам партицирования. При этом внутри каждой партиции данные распределяются в порядке первичного ключа таблицы.
Поэтому для эффективной работы с колоночными таблицами YDB необходимо правильно выбирать первичный ключ и ключ партицирования.
Так как ключ партицирования определяет партицию, в которой хранятся данных, то его следует выбирать так, чтобы Hash(partition_key) приводил к равномерному распределению данных по партициям. Оптимально, если ключ партицирования содержит в 100-1000 раз больше уникальных значений, чем число партиций в таблице.
Ключи, у которых существует большое количество уникальных значений, называются высококардинальными, и, наоборот, если уникальных значений мало, то такие ключи называются низкокардинальными. Если в качестве ключа партицирования используется низкокардинальный ключ, данные могут распределиться по партициями неравномерно, перегрузив часть партиций. Перегрузка партиций приведет к неоптимальной производительности запросов и/или ограничениям на максимальный поток вставляемых данных.
Первичный ключ определяет порядок хранения данных внутри партиции, поэтому при выборе первичного ключа необходимо учитывать не только эффективность сценария чтения данных из партиции, но и эффективность вставки данных в партицию. Оптимальный сценарий вставки — запись данных в начало или в конец таблицы с редкими локальными обновлениями уже вставленных данных. Например, эффективен сценарий хранения журналов работы приложений, когда данные хранятся по временным меткам, а новые записи добавляются в конец партиции за счет использования текущего времени в первичном ключе.
Важно
В настоящий момент необходимо таким образом выбирать первичный ключ, чтобы в качестве первой колонки первичного ключа использовалась высококардинальная колонка. Примером эффективной первой колонки является колонка с типом Timestamp (временная метка). Примером неэффективной первой колонки является колонка с типом Uint16 и 1000 уникальных значений.
В настоящий момент колоночные таблицы не поддерживают автоматического репартицирования, поэтому важно указывать правильное число партиций при создании таблицы. Оценить необходимое количество партиций можно по предполагаемому объему добавляемых в таблицу данных. Средняя пропускная способность партиции на добавление данных — 1 МБ/c. При этом пропускная способность в первую очередь определяется выбранным первичным ключом (необходимостью сортировки данных внутри партиции при добавлении новых данных). Для небольших потоков данных не рекомендуется задавать больше 128 партиций.
Пример:
При потоке данных в 1 ГБ/с оптимально использовать аналитическую таблицу с 1000 партиций. При этом создавать таблицы со значительным запасом партиций не стоит, т.к. это приведет к росту потребляемых ресурсов в кластере и итоговому замедлению скорости выполнения запросов.