Долгосрочная история транзакций RPC

Необходимо, чтобы RPC обслуживал как минимум 6 месяцев истории транзакций. Текущая история порядка нескольких дней недостаточна для нижестоящих пользователей.

Данные транзакций за 6 месяцев практически не могут храниться в реестре RocksDB валидатора, поэтому необходимо внешнее хранилище данных. Бухгалтерская книга rockdb валидатора будет продолжать служить основным источником данных, а затем вернется к внешнему хранилищу данных.

Затронутые конечные точки RPC:

Некоторые ограничения дизайна системы:

Объем данных для хранения и поиска может быстро достигать терабайтов и является неизменным.
Система должна быть максимально легкой для SRE. Например, кластер базы данных SQL, для которого требуется SRE для постоянного мониторинга и перебалансировки узлов, нежелателен.
Данные должны быть доступны для поиска в режиме реального времени - пакетные запросы, выполнение которых занимает минуты или часы, неприемлемы.
Легко реплицировать данные по всему миру, чтобы разместить их вместе с конечными точками RPC, которые будут их использовать.
Взаимодействие с внешним хранилищем данных должно быть простым и не зависеть от рискованных малоиспользуемых библиотек кода, поддерживаемых сообществом.

Исходя из этих ограничений, в качестве хранилища данных выбран продукт Google BigTable.

Схема таблицы

Экземпляр BigTable используется для хранения всех данных транзакций, разбитых на разные таблицы для быстрого поиска.

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

Очистка старых данных выполняется автоматически путем соответствующей настройки политики хранения данных таблиц экземпляров, они просто исчезают. Поэтому порядок добавления данных становится важным. Например, если данные из эпохи N-1 добавляются после данных из эпохи N, более старые данные эпохи переживут более новые данные. Однако, помимо создания дырок в результатах запроса, такое неупорядоченное удаление не будет иметь негативных последствий. Обратите внимание, что этот метод очистки эффективно позволяет хранить неограниченное количество данных транзакций, ограниченное только денежными затратами на это.

Макет таблицы поддерживает только существующие конечные точки RPC. Для новых конечных точек RPC в будущем могут потребоваться дополнения к схеме и, возможно, повторение всех транзакций для создания необходимых метаданных.

Доступ к большой таблице

BigTable имеет конечную точку gRPC, доступ к которой можно получить с помощью tonic] и необработанного API protobuf, поскольку в настоящее время не существует крейта Rust более высокого уровня для BigTable. На практике это усложняет анализ результатов запросов BigTable, но не является серьезной проблемой.

Заполнение данными

Текущее заполнение данных экземпляра будет происходить с периодичностью эпохи за счет использования новой команды solana-ledger-tool, которая преобразует данные rockdb для заданного диапазона слотов в схему экземпляра.

Тот же процесс будет запущен один раз вручную для заполнения существующих данных реестра.

Таблица блоков: `блок`

Эта таблица содержит данные сжатого блока для данного слота.

Ключ строки генерируется путем использования 16-значного шестнадцатеричного представления слота в нижнем регистре, чтобы гарантировать, что самый старый слот с подтвержденным блоком всегда будет первым при перечислении строк. например, ключ строки для слота 42 будет 000000000000002a.

Данные строки представляют собой сжатую структуру StoredConfirmedBlock.

Таблица поиска подписи транзакции адреса учетной записи: `tx-by-addr`

Эта таблица содержит транзакции, которые влияют на данный адрес.

Ключ строки: <base58 address>/<slot-id-one's-compliment-hex-slot-0-prefixed-to-16-digits>. Данные строки представляют собой сжатую структуру TransactionByAddrInfo.

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

Адреса Sysvar не индексируются. Как бы часто ни использовались такие программы, как Vote или System, они, скорее всего, будут иметь строку для каждого подтвержденного слота.

Таблица поиска подписи транзакции: `tx`

Эта таблица сопоставляет подпись транзакции с ее подтвержденным блоком и индексом в этом блоке.

Ключ строки — это подпись транзакции в кодировке base58. Данные строки представляют собой сжатую структуру TransactionInfo.