Горячие точки Bigtable - изменение наименее значимого ключа строки

У меня есть таблица, в которой я храню информацию о товарах. Формат ключа строки: UUID подразделения + идентификатор продукта + серийный номер продукта. Каждый из ключевых компонентов строки имеет фиксированную байтовую длину.

Запись в таблицу будет происходить пакетами (возможно, 100 КБ записей) с постоянным UUID BU, но либо с идентификатором продукта, либо с серийным номером, либо с обоими более или менее случайными изменениями.

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

Мой вопрос: будет ли исправление идентификатора BU ID во время пакетной записи привести к переходу в точку доступа определенного узла или планшета? Я понимаю, что со мной все должно быть в порядке, поскольку общее значение ключа строки не увеличивается монотонно, но я хочу быть уверенным.


google-cloud-bigtable bigtable
person Dave McCullough    schedule 13.06.2018    source источник
comment
Были ли у вас проблемы или вы активно испытываете проблемы? В вашей ситуации могут возникнуть горячие точки, в зависимости от многих переменных. Команда Cloud Bigtable предоставляет некоторые инструменты для обнаружения горячих точек, которые могут помочь с вашей спецификой. Вы можете подать заявку в службу поддержки, чтобы добавить вас в белый список инструмента.   -  person Solomon Duskis    schedule 14.06.2018
comment
Я не испытываю серьезных проблем, но просто задаюсь вопросом, плох ли мой ключевой дизайн априори. Я просмотрел статью Google о временных рядах и понял, что проблема заключается в постоянно растущем ключевом значении. У моего ключа нет этой проблемы, но есть свойство, что в большинстве случаев изменяются только наименее значимые байты ключа. Мне просто интересно, приведет ли это к появлению горячих точек.   -  person Dave McCullough    schedule 14.06.2018

Ответы (1)


arrow_upward
3
arrow_downward

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

Bigtable попытается динамически перебалансировать так, чтобы пространство ключей было равномерно распределено между его серверами, но вы можете увидеть лучшие результаты, если примените метод соления, описанный в документации по проектированию схемы временных рядов: https://cloud.google.com/bigtable/docs/schema-design-time-series#ensure_row_tkey_yaboids а>

В общем, мы рекомендуем попробовать это и по возможности поэкспериментировать. Вы можете создать нагрузку, а затем использовать Cloud Key Visualizer (https://cloud.google.com/bigtable/docs/keyvis-overview), чтобы проверить, не возникают ли у вас точки доступа, если у вас достаточно данных для выполнения анализа (https://cloud.google.com/bigtable/docs/keyvis-getting-started#Viewing-scan).

Вы также можете найти этот доклад, представленный на Google Cloud Next 2018, полезным: https://www.youtube.com/watch?v=3QHGhnHx5HQ

В нем описан подход к созданию итеративной схемы с помощью Cloud Key Visualizer.

person Ramesh Dharan    schedule 13.02.2019