Я использовал C++ API rockdb и создал несколько семейств column_families. Теперь я хочу создать автоинкрементный столбец, поэтому я хочу получить общее количество ключей в столбце, а затем +1. Есть ли способ получить размер столбца напрямую?
RocksDB получить номер ключа семейства столбцов
Ответы (1)
Я не думаю, что это существует из коробки, потому что есть несколько решений, которые имеют разные компромиссы, а rockdb — это скорее библиотека для создания баз данных, а не полноценная база данных в традиционном смысле SQL, поэтому они позволяют вам сделать выбор. Предоставление этого из коробки также потребовало бы принятия решения для одновременной поддержки этого, и многим людям это не требуется.
Два простых варианта:
- транзакционно вести специальную запись размера для каждого семейства столбцов
- сохраните размер в памяти и просканируйте таблицы при запуске, чтобы вычислить его (или, альтернативно, запомнить последний ключ), затем защитите его с помощью блокировки и обновления при изменениях.
Я не буду вдаваться в более сложные варианты, потому что я думаю, используя, например. CRDT позволяет нетривиально гарантировать, что вы не создаете повторяющиеся ключи. Для всего, что не подразумевает общий порядок операций, поддержание автоинкремента будет довольно сложным.
person
midor
schedule
25.08.2019
Эй, мидор, спасибо. Я воспользуюсь вашим советом, чтобы сделать поле для записи размера каждого столбца. и, возможно, добавят автоматический сканер для обновления статистической информации.
- person Jason ZHANG; 26.08.2019
Это два разных подхода к сохранению размера. Если вы не поддерживаете транзакционную запись в базе данных, у вас, скорее всего, будет ошибка согласованности позже, если вы выберете 1.). Сканирование данных - это совершенно другой подход, который увеличивает время запуска, но позволяет вам вычислить размер столбцов в памяти, которые вам затем все равно нужно поддерживать транзакционно, но вы можете сделать это с блокировкой, и вы сохраните обновление в записи, что в противном случае, безусловно, было бы чрезвычайно спорным, что ограничило бы общую пропускную способность вашей базы данных.
- person midor; 27.08.2019