Высокопроизводительные счетчики в Cloud Spanner

Я хочу вести подсчет некоторых элементов, таких как лайки и комментарии к публикации. Скорость записи может быть высокой, например. 1К лайков / сек.

Использование SELECT COUNT не представляется возможным, даже если набор результатов проиндексирован, поскольку для подсчета может потребоваться несколько миллионов строк.

Я думаю об использовании подхода с использованием сегментированных счетчиков, когда конкретный счетчик (лайков для данного сообщения) состоит из N сегментов / строк. Увеличение счетчика приведет к увеличению значения столбца в строке одного осколка, в то время как чтение счетчика приведет к чтению всех строк осколка и суммированию значений счетчика. Возникнут ли проблемы при таком подходе со Spanner?

Я понимаю, что в Bigtable несколько обновлений одной и той же строки будут создавать новые версии ячеек в строке, и в результате вы можете привести к превышению допустимого размера строки. Поэтому использование строк в качестве сегментированных счетчиков в Bigtable кажется плохой идеей. Есть ли у Spanner похожие проблемы?


google-cloud-spanner google-cloud-bigtable
person MHS    schedule 19.03.2019    source источник
comment
Что касается Bigtable, у вас, вероятно, не будет проблем с размером строки, если у вас есть разумная Политики GC, и вы можете обеспечить атомарную запись с помощью ReadModifyWrite Increment операций.   -  person Dan    schedule 20.03.2019

Ответы (2)


arrow_upward
3
arrow_downward

Я понимаю, что в Bigtable несколько обновлений одной и той же строки будут создавать новые версии ячеек в строке, и в результате вы можете привести к превышению допустимого размера строки. Поэтому использование строк в качестве сегментированных счетчиков в Bigtable кажется плохой идеей. Есть ли у Spanner похожие проблемы?

Как отмечалось в комментариях, вы можете использовать API-интерфейс ReadModifyWrite Increment с оговоркой, что транзакционные операции со строками, такие как ReadModifyWrite в Bigtable, выполняются медленнее.

Однако использование нескольких строк для представления одного счетчика и последующее чтение строк вместе с использованием сканирования по префиксу должно быть нормальным.

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

person Ramesh Dharan    schedule 21.03.2019

arrow_upward
2
arrow_downward

Разделение счетчиков для улучшения параллелизма кажется хорошей идеей. Cloud Spanner управляет старыми версиями данных иначе, чем BigTable, поэтому вы не можете достичь тех же ограничений. Spanner хранит старые версии в течение 1 часа. Однако при разработке схемы вы можете позаботиться о том, чтобы избегать горячих точек. .

Я бы порекомендовал вам попробовать реализовать слой кэширования памяти поверх Spanner. Это можно использовать для:

  1. Сгруппируйте несколько обновлений вместе.
  2. Быстро считывает / считает.

Возможны некоторые компромиссы в возможной потере некоторых обновлений, если кеш исчезнет, ​​но это может быть приемлемо, если это просто кеширование лайков / подсчетов.

person Biswa Nag    schedule 19.03.2019
comment
Спасибо! Да, мы планируем создать уровень кэширования Redis, чтобы обеспечить быстрое считывание / подсчет. Мы также рассматривали возможность пакетной записи, хотя для нас это больше вопрос продукта. - person MHS; 19.03.2019