Облачный ключ с историей на основе меток времени с использованием хеш - PullRequest
Новая
       26

Облачный ключ с историей на основе меток времени с использованием хеш

0 голосов
/ 23 января 2020

Я хотел бы сохранить полную историю записи в базу данных по указанной таблице c. Основное использование этой таблицы - чтение последних данных, но полная аудиторская проверка всех вставок и обновлений также является бизнес-требованием. Официальный документ Spanner здесь вызывает анти-паттерны схемы, а один из них о монотонно увеличивающихся данных, используемых в качестве первичного ключа. Это касается изменения порядка первичного ключа, может распределить нагрузку, а также предлагает использовать хеширование, осколок по модулю, UUID и т. Д. c.

Это сообщение в блоге Google Cloud упоминается использование ShardId вместо отметки времени. Предпочтительнее использовать ha sh.

Обратите внимание, однако, что использование простого ha sh сделает запросы по диапазону отметок времени очень медленными, так как получение диапазон временных меток потребует полного сканирования таблицы, чтобы охватить все хэши. Вместо этого мы рекомендуем генерировать ShardId из отметки времени.

В качестве примера настройки таблицы предоставляется запрос с использованием TimestampShardId. 

TimestampShardId = CRC32(Timestamp) % 100

CREATE TABLE Events (
     TimestampShardId INT64 NOT NULL
     Timestamp TIMESTAMP NOT NULL,
     event_info...
) PRIMARY KEY (TimestampShardId, Timestamp DESC)

Select * from Events
WHERE
   TimestampShardId BETWEEN 0 AND 99
   AND Timestamp > @lower_bound
   AND Timestamp < @upper_bound;

I'm не понимая, как это TimestampShardId делает сканирование быстрее, чем простое хеширование. Похоже, что для обоих подходов нужно сканировать всю таблицу - может кто-нибудь рассказать мне, почему предпочтительнее ShardId? Например, чтобы получить полную историю, возникнет ли проблема с таблицей истории с отметкой времени ha sh в качестве первичного ключа? Как насчет первичных ключей с UUID и отметкой времени?

1 Ответ

2 голосов
/ 23 января 2020

Идея состоит в том, что Cloud Spanner может избежать полной сортировки таблицы событий, выполняя распределенное объединение для каждого значения TimestampShardId, а затем считывая ключи для этого сегмента.

Считайте это сложностью слияния N отсортированных списков по сравнению с выполнением полной сортировки. Если N мало, объединение будет относительно эффективным. С другой стороны, когда N приближается к количеству элементов в списке, производительность снижается до полной сортировки.

Используя другое количество элементов TimestampShardId, вы можете выбирать между масштабируемостью записи и производительностью запросов. - большее количество сегментов обеспечивает больший параллелизм записи за счет увеличения объема данных, обрабатываемых на этапе объединения во время запроса. Мы рекомендуем протестировать производительность вашей заданной c рабочей нагрузки с различным количеством шардов, чтобы увидеть, какая точка в этом пространстве оптимальна для вас.

...