Блог

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

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

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

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

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

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

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

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

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

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

1. Пакетируйте несколько обновлений вместе.
2. Выполняйте быстрые чтения / подсчеты.

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