Область техники
[0001] Настоящая заявка относится к области компьютерных технологий и, в частности, к хранилищу данных и устройству и способу запрашивания на основе цепочки блоков.
Уровень техники
[0002] С непрерывным развитием компьютерных технологий технология цепочки блоков, которая является новой технологией распределенного хранения данных, становится все более популярной, потому что данные, хранящиеся в цепочке блоков (блокчейн), заслуживают доверия, так как устойчивость к подмене является особенностью технологии цепочки блоков (на которую также можно ссылаться как технология распределенного регистрационного журнала).
[0003] Принцип хранения данных в цепочке блоков может быть понят следующим образом: Пользователь инициирует запрос на обслуживание с помощью Ethereum-клиента (а именно клиента, который поддерживает технологию цепочки блоков (блокчейн-технологию), которого также можно назвать блокчейн-клиентом). Ethereum-клиент может отправить запрос на обслуживание в согласованную сеть. Каждый блокчейн-узел в согласованной сети выполняет процедуру согласования в отношении запроса на обслуживание. Каждый блокчейн-узел в согласованной сети сохраняет дайджест данных в запросе на обслуживание в цепочке блоков, соответствующей каждому блокчейн-узлу, после достижения согласования в отношении запроса на обслуживание. Кроме того, Ethereum-клиент может сохранять на основе предварительно определенного формата хранения данных, указанного в смарт-контракте, данные обслуживания в запросе на обслуживание на носителе данных, соответствующем Ethereum-клиенту.
[0004] Чтобы впоследствии помочь в запрашивании данных, хранящихся на носителе данных, обычно создается индекс заранее определенным образом, чтобы пользователь мог с помощью индекса выполнить операцию запрашивания в отношении данных обслуживания, хранящихся на носителе данных.
[0005] Однако на практике, если условие запрашивания, используемое для запрашивания данных обслуживания, отличается от созданного индекса (другими словами, условие запрашивания не соответствует индексу, указанному в смарт-контракте), эффективность запрашивания данных является относительно низкой или запрашивание дает сбой.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0006] Реализация настоящей заявки обеспечивает способ сохранения данных для смягчения проблем в существующей технологии, таких как низкая эффективность запрашивания или сбой запрашивания, когда запрашиваются данные, хранящиеся в цепочке блоков (блокчейн).
[0007] Реализация настоящей заявки обеспечивает способ сохранения данных, включающий в себя: прием блокчейн-узлом запроса на обслуживание; синтаксический анализ запроса на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных; и сохранение, на основе отношения отображения между типом данных и данными обслуживания, данных обслуживания, которые получены посредством синтаксического анализа в базе данных, соответствующей блокчейн-узлу.
[0008] Реализация настоящей заявки обеспечивает устройство хранения данных, чтобы облегчить проблемы в существующей технологии, такие как низкая эффективность запрашивания, или сбой запрашивания, когда запрашиваются данные, хранящиеся в цепочке блоков.
[0009] Реализация настоящей заявки предусматривает устройство хранения данных, включающее в себя: приемный модуль, сконфигурированный для приема запроса на обслуживание; модуль синтаксического анализа данных, сконфигурированный для синтаксического анализа запроса на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных; и модуль хранения, сконфигурированный для хранения на основе отношения отображения между типом данных и данными обслуживания данных обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу.
[0010] Реализация настоящей заявки обеспечивает способ запрашивания данных для устранения проблем в существующей технологии, таких как низкая эффективность запроса или сбой запроса, когда данные, хранящиеся в цепочке блоков, запрашиваются.
[0011] Реализация настоящей заявки обеспечивает способ запрашивания данных, включающий в себя: прием блокчейн-узлом запроса на запрашивание данных обслуживания; определение, на основании запроса на запрашивание данных обслуживания, типа данных, соответствующего данным обслуживания, которые должны быть запрошены; и запрашивание данных обслуживания, которые соответствуют типу данных, из базы данных, соответствующей блокчейн-узлу, причем упомянутая база данных включает в себя отношение отображения между типом данных и данными обслуживания.
[0012] Реализация настоящей заявки обеспечивает устройство запрашивания данных для смягчения проблем в существующей технологии, таких как низкая эффективность запрашивания или сбой запрашивания, когда запрашиваются данные, хранящиеся в цепочке блоков.
[0013] Реализация настоящей заявки обеспечивает устройство запрашивания данных, включающее в себя: модуль приема запроса, сконфигурированный для приема запроса на запрашивание данных обслуживания; модуль определения типа, сконфигурированный для определения, на основе запроса на запрашивание данных обслуживания, типа данных, соответствующего данным обслуживания, которые должны быть запрошены; и модуль запрашивания данных, сконфигурированный для запрашивания данных обслуживания, которые соответствуют типу данных, из базы данных, соответствующей устройству, причем упомянутая база данных включает в себя отношение отображения между типом данных и данными обслуживания.
[0014] По меньшей мере одно из ранее описанных технических решений, используемых в реализациях настоящей заявки, может достигать следующих полезных эффектов:
[0015] В реализациях настоящей заявки после приема запроса на обслуживание, отправленного пользователем, блокчейн-узел может синтаксически анализировать запрос на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных, и сохранять, на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, которые получены путем синтаксического анализа, в базе данных, соответствующей блокчейн-узлу. Данные обслуживания получают посредством синтаксического анализа, и эти данные обслуживания могут быть сохранены на основе отношения отображения между типом данных и данными обслуживания в базе данных, соответствующей блокчейн-узлу. Таким образом, пользователь может запрашивать данные обслуживания на основе таких отношений отображения в базе данных, тем самым устраняя проблему в существующей технологии выполнения запрашивания в цепочке блоков на основе индекса и эффективно улучшая гибкость и эффективность запрашивания данных в цепочке блоков.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0016] Прилагаемые чертежи, описанные здесь, предназначены для обеспечения дальнейшего понимания настоящей заявки и составляют часть настоящей заявки. Иллюстративные реализации настоящей заявки и их описания предназначены для описания настоящей заявки и не составляют ограничений для настоящей заявки. На прилагаемых чертежах:
[0017] Фиг.1 является схематической диаграммой, иллюстрирующей процесс сохранения данных в соответствии с реализацией настоящей заявки;
[0018] Фиг.2 является схематической диаграммой, иллюстрирующей таблицу данных, согласно реализации настоящей заявки;
[0019] Фиг.3 иллюстрирует подробный процесс сохранения данных в соответствии с реализацией настоящей заявки;
[0020] Фиг.4 - принципиальная схема, иллюстрирующая устройство хранения данных, согласно реализации настоящей заявки; а также
[0021] Фиг.5 является схематической диаграммой, иллюстрирующей устройство запрашивания данных, согласно реализации настоящей заявки.
ОПИСАНИЕ РЕАЛИЗАЦИЙ
[0022] Чтобы специалист в данной области техники лучше понимал технические решения в настоящей заявке, ниже четко и всесторонне описаны технические решения в реализациях настоящей заявки со ссылкой на прилагаемые чертежи в реализациях настоящей заявки. Очевидно, что описанные реализации являются лишь некоторыми, но не всеми, реализациями настоящей заявки. Все другие реализации, полученные специалистом в данной области техники на основе реализаций настоящей заявки без творческих усилий, должны попадать в объем охраны настоящей заявки.
[0023] фиг. 1 является схематической диаграммой, иллюстрирующей процесс сохранения данных, согласно реализации настоящей заявки. Процесс включает в себя следующие этапы.
[0024] S101. Блокчейн-узел получает запрос на обслуживание.
[0025] На практике в процессе обработки обслуживания пользователь может отправлять запрос на обслуживание блокчейн-узлу. Блокчейн-узел может быть устройством конечного пользователя или сервером. Например, когда блокчейн-узел является сервером, пользователь может заполнить информацию обслуживания на устройстве конечного пользователя, которое удерживается пользователем. После того, как пользователь выполняет заданную операцию на устройстве конечного пользователя, устройство конечного пользователя отправляет информацию обслуживания, заполненную пользователем, на сервер в форме запроса на обслуживание. Соответственно, сервер может принять запрос на обслуживание.
[0026] Когда блокчейн-узел является устройством конечного пользователя, пользователь может заполнить информацию обслуживания на устройстве конечного пользователя. Устройство конечного пользователя может генерировать соответствующий запрос на обслуживание при определении того, что пользователь выполняет заданную операцию (например, пользователь выполняет операцию легкого удара). Это эквивалентно получению запроса на обслуживание, отправленного пользователем.
[0027] Конечно, блокчейн-узел может альтернативно быть блокчейн-клиентом (который упоминается как клиент, который может обрабатывать связанную службу, основанную на технологии цепочки блоков, например, Ethereum-клиент). Соответственно, при выполнении обработки обслуживания с использованием согласованной блочейн-сети пользователь может запустить блочейн-клиента с помощью устройства конечного пользователя и заполнить информацию обслуживания на интерфейсе, отображаемом блокчейн-клиентом. Блочейн-клиент может генерировать соответствующий запрос на обслуживание на основе информации обслуживания, заполняемой пользователем, при обнаружении того, что пользователь выполняет заданную операцию. Это эквивалентно приему запроса на обслуживание, отправленного пользователем. В дополнение, запрос на обслуживание, принятый блокчейн-узлом, может альтернативно широковещательным образом передаваться другим блокчейн-узлом.
[0028] S102. Преобразование запроса на обслуживание на основе предварительно определенного формата данных, чтобы получить последовательность данных.
[0029] Блокчейн-узел может преобразовать запрос на обслуживание на основе предварительно определенного формата данных после приема запроса на обслуживание, чтобы получить соответствующую последовательность данных.
[0030] В настоящем варианте осуществления настоящей заявки предварительно определенный формат данных включает в себя, но не ограничивается, следующими полями: поле идентификационной информации и поле типа обслуживания.
[0031] Поле идентификационной информации используется для различения данных обслуживания на уровне пользователя, например, информации, которая может однозначно идентифицировать пользователя и включается в запрос на обслуживание, такой как открытый ключ пользователя или идентификационная информация пользователя (ID), так что данные обслуживания могут быть запрошены в пользовательском пространстве.
[0032] Поле типа обслуживания используется для различения данных обслуживания различных служб (услуг) пользователя, так что пользователь может впоследствии запросить данные обслуживания в пространстве обслуживания в процессе запрашивания данных обслуживания.
[0033] Кроме того, поле данных задается в предварительно определенном формате данных. Поле данных используется для указания отношения отображения между каждым типом данных и каждым фрагментом данных обслуживания в запросе на обслуживание. Например, предположим, что запрос на обслуживание включает следующее поле данных: имя - Xiaoming, возраст - 18 лет и вес - 65 кг. В этой информации фактическими данными обслуживания являются Xiaoming, 18 и 65 кг, а имя, возраст и вес являются типами данных для данных обслуживания. Другими словами, в настоящем варианте осуществления настоящей заявки тип данных эквивалентен ключу, данные обслуживания эквивалентны значению, а поле данных является набором отображения данных «значение- ключ».
[0034] На основе ранее описанного предварительно определенного формата данных после приема запроса на обслуживание, отправленного пользователем, блокчейн-узел может синтаксически анализировать, на основе предварительно определенного формата данных, запрос на обслуживание для получения содержимого данных, включенных в запрос на обслуживание, таких как идентификационная информация, тип обслуживания, данные обслуживания, соответствующие каждому типу данных, и каждый тип данных, которые находятся в поле данных. Затем блокчейн-узел может последовательно упорядочивать в конкретной форме данные, полученные посредством синтаксического анализа, для получения последовательности данных.
[0035] Например, предположим, что после приема запроса на обслуживание, отправленного пользователем, блокчейн-узел получает следующие поля посредством синтаксического анализа запроса на обслуживание на основе предварительно определенного формата данных: поле типа обслуживания: товар; поле идентификационной информации: PublicKey; поле данных: имя: зонтик; и стоимость: 46. Блокчейн-узел в конкретной форме последовательно упорядочивает эти поля, полученные путем синтаксического анализа, и получает следующую последовательность данных:
{"PublicKey.schema": "DEFAULT", "data": "name: umbrella, cost: 46"}.
[0036] Запрос на обслуживание преобразуется в последовательность данных на основе предварительно определенного формата данных, поскольку в настоящем варианте осуществления настоящей заявки блокчейн-узел должен записать запрос на обслуживание в цепочку блоков для последующей верификации данных обслуживания. На практике блокчейн-узел обычно должен записывать запрос на обслуживание в цепочку блоков на основе заданного формата данных. Затем после приема запроса на обслуживание, отправленного пользователем, блокчейн-узел должен преобразовать, на основе предварительно определенного формата данных, запрос на обслуживание в формат данных, а именно последовательность данных, для поддержки записи запроса на обслуживание в цепочку блоков в последующем процессе, и далее записывает запрос на обслуживание в цепочку блоков в форме последовательности данных, так что данные обслуживания могут быть эффективно верифицированы на основе запроса на обслуживание, хранящегося в цепочке блоков.
[0037] Стоит отметить, что в настоящем варианте осуществления настоящей заявки блокчейн-узел может альтернативно синтаксически анализировать запрос на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных, и затем преобразовывать, основываясь на предварительно определенном формате данных, данные обслуживания, соответствующие каждому типу данных и каждый тип данных, которые получены посредством синтаксического анализа, чтобы получить последовательность данных. В качестве альтернативы, после получения посредством синтаксического анализа каждого типа данных и данных обслуживания, соответствующих каждому типу данных, блокчейн-узел может сначала сохранить, на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, которые получены посредством синтаксического анализа, в базу данных, соответствующую блокчейн-узлу (другими словами, выполнить этап S103), а затем преобразовать, на основе предварительно определенного формата данных, каждый тип данных, включенный в запрос на обслуживание, и данные обслуживания, соответствующие каждому типу данных, для получения последовательности данных.
[0038] Другими словами, в настоящем варианте осуществления настоящей заявки этап преобразования запроса на обслуживание на основе предварительно определенного формата данных, чтобы получить последовательность данных, является необязательным.
[0039] Конкретный процесс реализации, включающий в себя этап S102 преобразования запроса на обслуживание на основе предварительно определенного формата данных, чтобы получить последовательность данных, не обязательно является процессом синтаксического анализа запроса на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных, и затем преобразования, на основе предварительно определенного формата данных, данных обслуживания, соответствующих каждому типу данных и каждого типа данных, которые получены посредством анализа, для получения последовательности данных. Альтернативно, последовательность данных может быть сгенерирована путем использования другого поля в запросе на обслуживание, отличного от данных обслуживания, соответствующих каждому типу данных и каждому типу данных, которые получены путем синтаксического анализа запроса на обслуживание. Конкретное поле, которое необходимо для генерации последовательности данных, зависит от фактически необходимого формата данных для поддержки записи запроса на обслуживание в цепочку блоков.
[0040] S103. Выполнение синтаксического анализа запроса на обслуживание, чтобы получить каждый тип данных и данные обслуживания, соответствующие каждому типу данных.
[0041] В настоящем варианте осуществления настоящей заявки после приема запроса на обслуживание блокчейн-узел может сначала отправить запрос на обслуживание другим блокчейн-узлам в согласованной сети посредством широковещательной передачи, так что каждый блокчейн-узел в согласованной сети выполняет процедуру согласования в отношении запроса на обслуживание. Каждый блокчейн-узел может сохранить запрос на обслуживание в цепочке блоков, соответствующей блокчейн-узлу, после определения того, что каждый блокчейн-узел в согласованной сети достигает консенсуса (согласования) в отношении запроса на обслуживание.
[0042] Кроме того, в настоящем варианте осуществления настоящей заявки после приема запроса на обслуживание блокчейн-узел может синтаксически анализировать запрос на обслуживание для получения каждого типа данных, включенного в запрос на обслуживание, и данных обслуживания, соответствующих каждому типу данных, и сохранять на основе отношения отображения между типом данных и данными обслуживания - данные обслуживания, которые получены путем синтаксического анализа, в базе данных, соответствующей блокчейн-узлу, в последующем процессе.
[0043] База данных, упомянутая в настоящем варианте осуществления настоящей заявки, может быть реляционной базой данных. При таком способе хранения данных данные могут быть быстро запрошены, и на запрашивание не влияет условие запрашивания. Другими словами, даже если поле индекса изменяется, данные обслуживания, хранящиеся в базе данных, все же могут адаптироваться к новому полю индекса, и на данные обслуживания, запрашиваемые пользователем, не влияет изменение поля индекса, используемого для запрашивания данных обслуживания.
[0044] В настоящем варианте осуществления настоящей заявки во время сохранения данных обслуживания блокчейн-узел может выполнять различение на основе типа обслуживания или идентификационной информации данных обслуживания, подлежащих сохранению, так что данные обслуживания, соответствующие различным типам службы или идентификационной информации, могут быть сохранены в разных базах данных. По существу, пользователь может точно запрашивать данные обслуживания в пространстве типа обслуживания или идентификационной информации в последующем процессе запрашивания данных обслуживания.
[0045] На основании этого, в дополнение к синтаксическому анализу запроса на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных, блокчейн-узел может получить, посредством синтаксического анализа, тип обслуживания и идентификационную информацию, которые соответствуют данным обслуживания, включенным в запрос на обслуживание, затем преобразовать, на основе предварительно определенного формата оператора, каждый тип данных, данные обслуживания, соответствующие каждому типу данных, тип обслуживания и идентификационную информацию, полученную посредством синтаксического анализа, для получения оператора сохранения данных и сохранять посредством выполнения этого оператора сохранения данных, данные обслуживания, полученные путем синтаксического анализа, в базе данных, соответствующей блокчейн-узлу, в последующем процессе.
[0046] Например, блокчейн-узел определяет путем синтаксического анализа запроса на обслуживание, что данные обслуживания, которые должны быть сохранены, представляют собой shoes#12xew и 158, типом обслуживания, соответствующим данным службы, которые должны быть сохранены, является товар, идентификационная информация, соответствующая данным обслуживания, которые должны быть сохранены, представляет собой PublicKey1, а типы данных, соответственно соответствующий данным обслуживания «12xew» и «158», представляют собой имя и стоимость. Блокчейн-узел может преобразовывать на основе предварительно определенного формата оператора, тип обслуживания, идентификационную информацию, данные обслуживания, соответствующие каждому типу данных, и каждый тип данных, которые получены посредством синтаксического анализа, для получения соответствующего оператора сохранения данных. Пример формы выглядит следующим образом:
[0047] insert into "PublicKey1.schema: commodity" (name, cost) value ('shoes#12xew', '158'). (Вставить в "PublicKey1.schema: commodity" (имя, стоимость) значение ('shoes#12xew', '158')).
[0048] Блокчейн-узел может сохранять, выполняя оператор сохранения данных, данные обслуживания в базе данных, соответствующей блокчейн-узлу, в последующем процессе.
[0049] Блокчейн-узел может синтаксически анализировать запрос на обслуживание с использованием предварительно определенной программы синтаксического анализа. Программа синтаксического анализа задает формат данных, который должен использоваться для синтаксического анализа, и поле, которое должно быть синтаксически проанализировано. Блокчейн-узел может синтаксически анализировать запрос на обслуживание, запустив программу синтаксического анализа. Программа синтаксического анализа может быть скомпилирована персоналом по эксплуатации и техническому обслуживанию блокчейн-узла в зависимости от фактической необходимости.
[0050] Стоит отметить, что, в отличие от сохранения данных обслуживания в базе данных в пространстве типа обслуживания и идентификационной информации, если блокчейн-узел соответствует одной базе данных, в базе данных могут быть установлены разные таблицы данных. Каждый тип обслуживания и каждый фрагмент идентификационной информации могут соответствовать одной таблице данных. Как таковой, блокчейн-узел может сохранять данные обслуживания в таблицах, данных в базе данных на основе типа обслуживания и идентификационной информации. Разумеется, данные обслуживания, соответствующие типу услуги, и идентификационная информация могут различаться в базе данных в форме, отличной от формы таблицы данных. Детали опущены здесь для простоты.
[0051] Стоит отметить, что в настоящем варианте осуществления настоящей заявки блокчейн-узел может выполнить этап S103 перед выполнением этапа S102, может выполнить этап S102 перед выполнением этапа S103 или может выполнить S102 для получения последовательности данных перед выполнением этапа S103, чтобы синтаксически анализировать полученную последовательность синтаксического анализа для получения, на основе способа, показанного на этапе S103, каждого типа данных и данных обслуживания, соответствующих каждому типу данных. Этап S102 и этап S103 могут выполняться одновременно в настоящем варианте осуществления настоящей заявки. Никаких конкретных ограничений здесь не предусмотрено.
[0052] S104. Сохранение, на основе отношения отображения между типом данных и данными обслуживания, данных обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу.
[0053] В настоящем варианте осуществления настоящей заявки после получения, посредством синтаксического анализа запроса на обслуживание, каждого типа данных и данных обслуживания, соответствующих каждому типу данных, блокчейн-узел может сохранять данные обслуживания, полученные посредством синтаксического анализа типов данных, в базе данных.
[0054] Для данных обслуживания, соответствующих различным типам услуг и идентификационной информации, блокчейн-узел может определить на основе типов услуг и идентификационной информации, которые получены посредством синтаксического анализа, базу данных, соответствующую типам услуг и идентификационной информации, а затем блокчейн-узел соответственно могут сохранять данные обслуживания, полученные путем синтаксического анализа в типах данных, в базе данных.
[0055] После получения оператора сохранения данных посредством выполнения этапа S103 блокчейн-узел может выполнить оператор сохранения данных, чтобы определить тип обслуживания и идентификационную информацию, которые соответствуют данным обслуживания, которые должны быть сохранены. Блокчейн-узел затем может дополнительно определить, соответствует ли блокчейн-узел базе данных, соответствующей типу обслуживания и идентификационной информации. Если да, блокчейн-узел может дополнительно отдельно сохранить данные обслуживания, полученные путем синтаксического анализа типов данных в базе данных. Если нет, блокчейн-узел должен создать на основе определенного типа обслуживания и определенной идентификационной информации базу данных, соответствующую типу обслуживания и идентификационной информации, чтобы блокчейн-узел сохранял данные обслуживания в этой базе данных.
[0056] Разумеется, в настоящем варианте осуществления настоящей заявки, если блокчейн-узел соответствует одной базе данных, блокчейн-узел может определить, включает ли в себя эта база данных таблицу данных, соответствующую типу обслуживания и идентификационной информации. Если да, блокчейн-узел отдельно сохранит данные обслуживания, полученные путем синтаксического анализа типов данных в этой таблице данных. Если нет, блокчейн-узел создает, используя предопределенный способ создания таблицы, таблицу данных, соответствующую типу обслуживания и идентификационной информации, а затем сохраняет данные обслуживания, полученные путем синтаксического анализа, в этой таблице данных.
[0057] Например, предположим, что блокчейн-узел определяет следующие поля, выполняя оператор сохранения данных: полем типа обслуживания, соответствующее хранимым данным обслуживания, является «товар»; и открытым ключом пользователя является «PublicKey1», который используется для указания идентификационной информации (поскольку фактический открытый ключ пользователя может быть относительно сложным, открытый ключ пользователя просто указывается с использованием здесь PublicKey1). Блокчейн-узел может дополнительно определять, включает ли в себя база данных, соответствующая блокчейн-узлу, таблицу данных, которая включает в себя идентификационную информацию PublicKey1 и тип обслуживания «товар». При определении того, что таблица данных не существует, блокчейн-узел создает таблицу данных, соответствующую типу обслуживания «товар» и идентификационной информации PublicKey1, в базе данных на основе определенного типа обслуживания «товар», определенной идентификационной информации PublicKey1 и способа создания предварительно определенной таблицы. Оператор выполнения выглядит следующим образом:
[0058] create table "PublicKey1.schema: commodity" if "PublicKey1.schema: commodity" not exist. (Создать таблицу "PublicKey1.schema: commodity" если "PublicKey1.schema: commodity" не существует.)
[0059] После определения (или создания) путем выполнения оператора сохранения данных таблицы данных, соответствующей данным обслуживания, в базе данных, соответствующей блокчейн-узлу, блокчейн-узел может определить, включает ли в себя таблица данных каждый тип данных, включенный в данные обслуживания. Если да, блокчейн-узел создает строку или столбец, соответствующие типу данных в таблице данных. Если нет, блокчейн-узел может добавить строку/столбец, соответствующие типу данных, в таблицу данных на основе типа данных и предварительно определенного способа создания строки/столбца.
[0060] Продолжая предыдущий пример, блокчейн-узел определяет поле данных: name: shoes#12xew и cost: 158 в последовательности данных. В этом поле данных «имя» и «стоимость» являются типами данных и эквивалентны ключам, а данные обслуживания, соответствующие имени и стоимости, эквивалентны значению. Блокчейн-узел может определить, включает ли в себя таблица данных, определенная на основе товара типа обслуживания и идентификационной информации PublicKey1, каждый тип данных в этом поле данных. Если да, блокчейн-узел не создает столбец, соответствующий типу данных, в базе данных. Если нет, блокчейн-узел может добавить столбец, соответствующий типу данных, в таблицу данных на основе типа данных и предварительно определенного способа создания столбца (если таблица данных создается в измерении по строке, можно использовать способ создания строки). Конкретный оператор выполнения выглядит следующим образом:
[0061] create column "name" if "PublicKey1.schema: commodity". "name" not exist; create column "cost" if "PublicKey1.schema: commodity". "cost" not exis. (создать столбец "name" если "PublicKey1.schema: commodity". "name" не существует; создать столбец "cost" если "PublicKey1.schema: commodity". "cost" не существует.)
[0062] После определения посредством выполнения оператора сохранения данных типа данных (тип данных может ранее существовать в базе данных или может быть создан блокчейн-узлом путем выполнения оператора сохранения данных), соответствующего данным обслуживания, которые должны храниться в базе данных, блокчейн-узел может сохранить данные обслуживания в типе данных в базе данных. Конечно, если блокчейн-узел определяет, что тип данных, соответствующий данным обслуживания, которые должны быть сохранены, находится в некоторой таблице данных (а именно, таблице данных, которая соответствует типу обслуживания и идентификационной информации) в базе данных, блокчейн-узел может хранить данные обслуживания, которые получают посредством синтаксического анализа в типе данных, в таблице данных, как показано на фиг. 2.
[0063] Фиг. 2 является схематической диаграммой, иллюстрирующей таблицу данных согласно реализации настоящей заявки.
[0064] На фиг. 2 имя и стоимость - это типы данных для данных обслуживания, PublicKey1 - это идентификационная информация, соответствующая данным обслуживания, товар - тип обслуживания, соответствующий данным обслуживания, и каждый тип данных записывает данные обслуживания, соответствующие типу данных. Таким образом, когда пользователь впоследствии запрашивает данные обслуживания, блокчейн-узел может принимать запрос на запрашивание данных обслуживания, отправленный пользователем, и дополнительно запрашивать данные обслуживания, которые соответствуют запросу на запрашивание данных обслуживания, из базы данных. Процесс запрашивания может быть следующим: после получения запроса на запрашивание данных обслуживания блокчейн-узел может сначала определить тип обслуживания и идентификационную информацию, которые включены в запрос на запрашивание данных обслуживания. Затем блокчейн-узел может определить таблицу данных, которая соответствует типу обслуживания и идентификационной информации, в базе данных, и выполнить дополнительное запрашивание из таблицы данных на основе отношения отображения, которое существует между типом данных и данными обслуживания и записано в таблице данных, данных обслуживания, которые должны быть запрошены на основе запроса на запрашивание данных обслуживания.
[0065] Например, предположим, что запрос на запрашивание данных обслуживания, полученный блокчейн-узлом, включает в себя следующие поля: PublicKey: PublicKey1, схема: товар, и название: blouse#4212v. Блокчейн-узел может определить в запросе на запрашивание данных обслуживания, что тип обслуживания, соответствующий запросу на запрашивание данных обслуживания, является товаром, а идентификационная информация - PublicKey1, затем идентифицировать таблицу данных, которая соответствует типу обслуживания «товар», и идентификационную информацию PublicKey1 из базы данных, соответствующей блокчейн-узлу, и идентифицируют данные обслуживания 211, соответствующие полю индекса blouse#4212v, из таблицы данных на основе поля индекса blouse#4212v.
[0066] Конечно, если данные обслуживания различаются на основе только типа данных, после приема запроса на запрашивание данных обслуживания, отправленного пользователем, блокчейн-узел может определить, на основании запроса на запрашивание данных обслуживания, тип данных, соответствующий данным обслуживания, которые должны быть запрошены, и затем запросить данные обслуживания, которые соответствуют этому типу данных, из базы данных, соответствующей блокчейн-узлу. При определении типа данных после приема запроса на запрашивание данных обслуживания, отправленного пользователем, блокчейн-узел может определить поле индекса, а именно ключ, включенный в запрос на запрашивание данных обслуживания, и определить поле индекса, а именно ключ, в качестве типа данных, соответствующего данным обслуживания, которые должны быть запрошены.
[0067] В этой таблице данных, помимо запроса данных обслуживания с использованием ключа в качестве поля индекса, данные обслуживания могут быть запрошены путем создания индекса пользователем. Например, продолжая предыдущий пример, если пользователю необходимо запросить данные обслуживания на основе диапазона цен, он может ввести диапазон цен в блокчейн-узел. Блокчейн-узел может запрашивать, основываясь на диапазоне цен, введенном пользователем, данные обслуживания, которые удовлетворяют диапазону цен, из таблицы данных в базе данных, и возвращать данные обслуживания, которые удовлетворяют условию, пользователю для просмотра.
[0068] В существующей технологии блокчейн-узел должен записывать данные обслуживания в цепочку блоков на основе формата хранения данных, указанного в смарт-контракте. Кроме того, блокчейн-узел обычно сохраняет, на основе формата хранения данных, данные обслуживания в памяти, соответствующей блокчейн-узлу по умолчанию. Следовательно, в процессе компиляции смарт-контракта обычно указывается, что блокчейн-узел сохраняет на основе указанного формата хранения данных данные обслуживания в памяти, соответствующей блокчейн-узлу. Соответственно, когда пользователь запрашивает данные обслуживания из блокчейн-узла с использованием смарт-контракта, пользователь также должен запросить фиксированным образом (например, используя поле индекса в фиксированной форме) соответствующие данные обслуживания из памяти, соответствующей блокчейн-узлу.
[0069] Однако, на практике поле индекса, используемое пользователем для запрашивания данных обслуживания, не является уникальным. Следовательно, индексное поле, используемое пользователем для запрашивания данных обслуживания, может быть не указано в смарт-контракте. Как только пользователь использует поле индекса, которое не удовлетворяет смарт-контракту, блокчейн-узел не может идентифицировать предыдущие данные обслуживания из блокчейн-узла с помощью смарт-контракта.
[0070] Например, когда блокчейн-узел сохраняет, основываясь на предварительно определенном формате хранения данных с использованием смарт-контракта, запрос на обслуживание в памяти, соответствующей блокчейн-узлу, пользователь может впоследствии запрашивать данные обслуживания из памяти только с помощью ключа в качестве поля индекса. Однако блокчейн-узел сохраняет все фрагменты данных обслуживания один за другим на основе указанного формата данных, указанного в смарт-контракте, используя этот смарт-контракт, другими словами, не сохраняет данные обслуживания в форме таблицы данных в реляционной базе данных. Поэтому, когда пользователю необходимо запрашивать данные обслуживания на основе содержимого, записанного в значении, смарт-контракт не может эффективно поддерживать поле запроса, введенное пользователем в блокчейн-узел. Следовательно, пользователь не может идентифицировать, используя смарт-контракт, предыдущие данные обслуживания из памяти, соответствующей блокчейн-узлу (поскольку предыдущие данные обслуживания могут быть запрошены только с использованием ключа в качестве поля индекса). Альтернативно, блокчейн-узел может идентифицировать соответствующие данные обслуживания из памяти, соответствующей блокчейн-узлу, только когда блокчейн-узел в течение длительного времени просматривает память на основании поля запроса, введенного пользователем.
[0071] В настоящем варианте осуществления настоящей заявки после приема запроса на обслуживание, отправленного пользователем, блокчейн-узел может синтаксически анализировать запрос на обслуживание, чтобы определить каждый тип данных, включенный в запрос на обслуживание, и данные обслуживания, соответствующие каждому типу данных, и, наконец, сохранить на основе отношения отображения между типом данных и данными обслуживания данные обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу. Таким образом, пользователь может запрашивать данные обслуживания на основе таких отношений отображения в базе данных, тем самым устраняя проблему в существующей технологии выполнения запрашивания в цепочке блоков на основе индекса и эффективно улучшая гибкость и эффективность запрашивания данных в цепочке блоков.
[0072] Стоит отметить, что в настоящем варианте осуществления настоящей заявки данные обслуживания пользователей могут различаться в базе данных на основе только идентификационной информации, и классификация типов обслуживания не выполняется для всех пользователей. Поэтому в предыдущем процессе блокчейн-узел может создать базу данных, создать таблицу данных в базе данных или определить таблицу данных в базе данных на основе идентификационной информации. Разумеется, данные обслуживания можно различать в базе данных только по типу обслуживания. Конкретный способ может использоваться для различения данных обслуживания в зависимости от потребности в обслуживании.
[0073] Чтобы дополнительно описать процесс сохранения данных, предоставленный в предыдущей реализации, в реализации настоящей заявки способ сохранения данных, представленный в настоящей заявке, дополнительно описывается с использованием конкретного процесса выполнения, как показано на фиг. 3.
[0074] Фиг. 3 иллюстрирует подробный процесс сохранения данных в соответствии с реализацией настоящей заявки. Процесс включает в себя следующие этапы.
[0075] S301. Блокчейн-узел принимает запрос на обслуживание.
[0076] Блокчейн-узел может принимать запрос на обслуживание, отправленный пользователем, используя устройство конечного пользователя. Блокчейн-узел может быть устройством конечного пользователя, может быть сервером или может быть клиентом, который может обрабатывать связанную услугу, основанную на технологии цепочки блоков.
[0077] S302. Анализируют запрос на обслуживание, чтобы определить каждый тип данных, включенный в запрос на обслуживание, и данные обслуживания, соответствующие каждому типу данных.
[0078] После приема запроса на обслуживание блокчейн-узел может синтаксически анализировать запрос на обслуживание, чтобы определить каждый тип данных, включенный в запрос на обслуживание, и данные обслуживания, соответствующие каждому типу данных. Блокчейн-узел может синтаксически анализировать запрос на обслуживание с использованием предварительно определенной программы синтаксического анализа. Программа синтаксического анализа может быть установлена персоналом по эксплуатации и обслуживанию блокчейн-узла в зависимости от фактической необходимости.
[0079] S303. Преобразовывают, на основе предварительно определенного формата данных, данные обслуживания, соответствующие каждому типу данных и каждому типу данных, которые получены посредством синтаксического анализа, для получения последовательности данных.
[0080] После получения каждого типа данных, включенных в запрос на обслуживание, и данных обслуживания, соответствующих каждому типу данных, путем синтаксического анализа запроса на обслуживание, блокчейн-узел может преобразовывать, на основе предварительно определенного формата данных, данные обслуживания, соответствующие каждому типу данных и каждому типу данных, которые получены с помощью синтаксического анализа, чтобы получить последовательность данных. Конкретный процесс получения последовательности данных может быть следующим: Блокчейн-узел может последовательно упорядочивать в конкретной форме данные, полученные путем синтаксического анализа, для получения соответствующей последовательности данных.
[0081] S304. Отправляют запрос на обслуживание в согласованную сеть для процедуры согласования и сохраняют эту последовательность данных в цепочке блоков, соответствующей блокчейн-узлу, после определения, что согласование достигнуто в отношении запроса на обслуживание.
[0082] При приеме запроса на обслуживание блокчейн-узел может отправить запрос на обслуживание в согласованную сеть, так что другой блокчейн-узел в согласованной сети выполняет процедуру согласования в отношении запроса на обслуживание. После определения того, что другой блокчейн-узел достигает согласования в отношении запроса на обслуживание, блокчейн-узел может сохранять в форме последовательности данных запрос на обслуживание в цепочке блоков, сохраненной блокчейн-узлом для последующей верификации данных обслуживания.
[0083] В настоящем варианте осуществления настоящей заявки каждый раз, когда блокчейн-узел принимает запрос на обслуживание, блокчейн-узел отправляет запрос на обслуживание в согласованную сеть для процедуры согласования. Альтернативно, блокчейн-узел может сначала принимать запросы на обслуживание, отправленные пользователями, упаковывать принятые запросы на обслуживание в блок предварительной обработки при определении, что наступает фаза согласования, и отправлять блок предварительной обработки в согласованную сеть для процедуры согласования. Соответственно, после приема запросов на обслуживание, отправленных пользователями, блокчейн-узел может синтаксически анализировать запросы на обслуживание один за другим, чтобы определить тип данных и данные обслуживания, соответствующие типу данных, которые включены в каждый запрос на обслуживание, и затем преобразовать, на основе предварительно определенного формата данных, тип данных и данные обслуживания, соответствующие типу данных, которые включены в каждый запрос обслуживания, для получения каждой последовательности данных.
[0084] После определения того, что другой блокчейн-узел в согласованной сети достигает согласования в отношении блока предварительной обработки, отправленного в согласованную сеть, блокчейн-узел может сохранять в форме каждой последовательности данных, соответствующей каждому запросу на обслуживание, каждый запрос на обслуживание, включенный в блок предварительной обработки в цепочке блоков, включенной в блокчейн-узел.
[0085] S305. Сохраняют, на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу.
[0086] При преобразовании каждого типа данных и данных обслуживания, которые получены посредством синтаксического анализа, блокчейн-узел может сохранять на основе отношения отображения между типом данных и данными обслуживания данные обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу, чтобы гарантировать, что пользователь может впоследствии идентифицировать соответствующие данные обслуживания из базы данных на основе отношения отображения между типом данных и данными обслуживания.
[0087] Блокчейн-узел может одновременно выполнять этап S303 и этап S305. Другими словами, когда блокчейн-узел преобразует данные обслуживания, соответствующие каждому типу данных и каждому типу данных, которые получены посредством синтаксического анализа, для получения последовательности данных, блокчейн-узел может сохранять, на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, полученные путем синтаксического анализа, в базе данных, соответствующей блокчейн-узлу.
[0088] Конечно, после определения того, что другой блокчейн-узел в согласованной сети достигает согласования в отношении запроса на обслуживание, блокчейн-узел может сохранять на основе отношения отображения между типом данных и данными обслуживания данные обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу.
[0089] Выше были описаны способ сохранения данных и способ запрашивания данных, предоставленные в реализациях настоящей заявки. На основе той же концепции реализации настоящей заявки дополнительно обеспечивают устройство хранения данных и устройство запрашивания данных, как показано на фиг. 4 и фиг. 5.
[0090] Фиг.4 - схематическая диаграмма, иллюстрирующая устройство хранения данных согласно реализации настоящей заявки. Устройство включает в себя: приемный модуль 401, сконфигурированный для приема запроса на обслуживание; модуль 402 синтаксического анализа данных, сконфигурированный для синтаксического анализа запроса на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных; и модуль 403 хранения, сконфигурированный для хранения, на основе отношения отображения между типом данных и данными обслуживания, данных обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу.
[0091] Устройство дополнительно включает в себя: модуль 404 согласования, сконфигурированный для преобразования на основе предварительно определенного формата данных каждого типа данных, включенного в запрос на обслуживание, и данных обслуживания, соответствующих каждому типу данных, для получения последовательности данных; выполнения процедуры согласования в отношении запроса на обслуживание с использованием согласованной сети; и сохранения последовательности данных в цепочке блоков, соответствующей устройству, после достижения согласования в отношении запроса на обслуживание.
[0092] Модуль 402 синтаксического анализа данных определяет, по меньшей мере, одно из типа обслуживания или идентификационной информации, соответствующей запросу на обслуживание.
[0093] Модуль 403 хранения преобразует, на основе предварительно определенного формата оператора, по меньшей мере, одно из каждого типа данных, данных обслуживания, соответствующих каждому типу данных, типа обслуживания или идентификационной информации, которые получены посредством синтаксического анализа, для получения оператора сохранения данных; и сохраняет данные обслуживания, полученные путем синтаксического анализа, в базе данных, выполняя этот оператор сохранения данных.
[0094] Модуль 403 хранения создает, на основе по меньшей мере одного из типа обслуживания или идентификационной информации, базу данных, соответствующую, по меньшей мере, одному из типа обслуживания или идентификационной информации, при определении посредством выполнения оператора сохранения данных, что ни одна база данных, которая соответствует по меньшей мере одному из типа обслуживания или идентификационной информации, не идентифицирована; и сохраняет данные обслуживания, полученные путем синтаксического анализа, в созданной базе данных.
[0095] Модуль 403 хранения создает каждый тип данных, который получается путем синтаксического анализа последовательности данных, в базе данных при определении того, что база данных не включает в себя тип данных; и сохраняет данные обслуживания, соответствующие типу данных, в этой базе данных.
[0096] Фиг. 5 является схематической диаграммой, иллюстрирующей устройство запрашивания данных, согласно реализации настоящей заявки. Устройство включает в себя: модуль 501 приема запроса, сконфигурированный для приема запроса на запрашивание данных обслуживания; модуль 502 определения типа, сконфигурированный для определения, на основании запроса на запрашивание данных обслуживания, типа данных, соответствующих данным обслуживания, которые должны быть запрошены; и модуль 503 запрашивания данных, сконфигурированный для запрашивания данных обслуживания, которые соответствуют типу данных, из базы данных, соответствующей устройству, причем упомянутая база данных включает в себя отношение отображения между типом данных и данными обслуживания.
[0097] В реализациях настоящей заявки после приема запроса на обслуживание, отправленного пользователем, блокчейн-узел может синтаксически анализировать запрос на обслуживание для получения каждого типа данных и данных обслуживания, соответствующих каждому типу данных, и сохранять на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, которые получены путем синтаксического анализа, в базе данных, соответствующей блокчейн-узлу. Данные обслуживания получают посредством синтаксического анализа, и данные обслуживания могут быть сохранены на основе отношения отображения между типом данных и данными обслуживания в базе данных, соответствующей блокчейн-узлу. Таким образом, пользователь может запрашивать данные обслуживания на основе таких отношений отображения в базе данных, тем самым устраняя проблему в существующей технологии выполнения запрашивания в цепочке блоков на основе индекса и эффективно улучшая гибкость и эффективность запрашивания данных в цепочке блоков.
[0098] В 1990-х годах можно было четко различить, является ли техническое усовершенствование аппаратным усовершенствованием (например, усовершенствованием структуры схемы, такой как диод, транзистор или коммутатор) или усовершенствованием программного обеспечения (усовершенствованием процедуры способа). Однако по мере развития технологий текущие усовершенствования многих процедур способов могут рассматриваться как непосредственные улучшения структур аппаратных схем. Разработчик обычно программирует улучшенную процедуру способа в аппаратную схему, чтобы получить соответствующую структуру аппаратной схемы. Поэтому, процедура способа может быть улучшена с использованием аппаратного модуля объекта. Например, программируемое логическое устройство (PLD) (например, программируемая пользователем вентильная матрица (FPGA)) является такой интегральной схемой, и логическая функция PLD определяется пользователем посредством программирования устройства. Разработчик выполняет программирование для «интеграции» цифровой системы в PLD, не обращаясь к производителю микросхем с просьбой разработать и изготовить микросхему интегральной микросхемы для конкретного приложения. Кроме того, в настоящее время вместо ручного изготовления кристалла интегральной микросхемы, этот тип программирования в основном реализуется с использованием программного обеспечения «логического компилятора». Программное обеспечение логического компилятора аналогично программному компилятору, используемому для разработки и написания программы. Оригинальный код должен быть написан на конкретном языке программирования для компиляции. Этот язык называется языком описания аппаратных средств (HDL). Существует много HDL, таких как Advanced Boolean Expression Language (ABEL), Язык описания оборудования Altera (AHDL), Confluence, Язык программирования Корнельского университета (CUPL), HDCal, Язык описания оборудования Java (JHDL), Lava, Lola, MyHDL, PALASM и Ruby Hardware Description Language (RHDL). Язык описания высокоскоростных аппаратных средств для интегральных схем (VHDL) и Verilog используются наиболее часто. Специалист в данной области также должен понимать, что аппаратная схема, которая реализует процедуру логического способа, может быть легко получена, когда процедура способа логически запрограммирована с использованием нескольких описанных языков описания аппаратных средств и запрограммирована в интегральную схему.
[0099] Контроллер может быть реализован с использованием любого подходящего способа. Например, контроллер может быть микропроцессором или процессором или машиночитаемым носителем, который хранит машиночитаемый программный код (такой как программное обеспечение или встроенное программное обеспечение), который может выполняться микропроцессором или процессором, логическим вентилем, переключателем, специализированной интегральной схемой (ASIC), программируемым логическим контроллером или встроенным микропроцессором. Примеры контроллера включают, но не ограничиваются, следующие микропроцессоры: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 и Silicon Labs C8051F320. Контроллер памяти также может быть реализован как часть логики управления памятью. Специалисту в данной области также известно, что в дополнение к реализации контроллера с использованием машиночитаемого программного кода в отношении этапов способа может быть выполнено логическое программирование, чтобы позволить контроллеру реализовать ту же функцию в виде логического элемента, коммутатора, специализированной интегральной схемы, программируемого логического контроллера и встроенного микроконтроллера. Поэтому контроллер может рассматриваться как аппаратный компонент, а устройство, сконфигурированное для реализации различных функций в контроллере, также может рассматриваться как структура в аппаратном компоненте. Или устройство, сконфигурированное для реализации различных функций, может даже рассматриваться как программный модуль, реализующий способ, и как структура в аппаратном компоненте.
[0100] Система, устройство, модуль или блок, проиллюстрированные в предыдущих реализациях, могут быть реализованы с использованием компьютерной микросхемы или объекта, или могут быть реализованы с использованием продукта, имеющего некоторую функцию. Типичным устройством реализации является компьютер. Компьютер может быть, например, персональным компьютером, ноутбуком, сотовым телефоном, телефоном с камерой, смартфоном, персональным цифровым помощником, медиаплеером, навигационным устройством, устройством электронной почты, игровой приставкой, планшетом, компьютером, носимым устройством или комбинацией любых из этих устройств.
[0101] Для простоты описания вышеприведенное устройство описывается разделением функций на различные блоки. Конечно, когда настоящая заявка реализуется, функция каждого блока может быть реализована в одном или нескольких элементах программного и/или аппаратного обеспечения.
[0102] Специалист в данной области должен понимать, что реализация настоящего раскрытия сущности может быть предоставлена как способ, система или компьютерный программный продукт. Поэтому, настоящее раскрытие может использовать форму только аппаратных реализаций, только программных реализаций или реализаций с комбинацией программного и аппаратного обеспечения. Кроме того, реализации настоящего раскрытия могут использовать форму компьютерного программного продукта, который реализован на одном или нескольких компьютерных носителях данных (включая, но не ограничиваясь этим, дисковую память, CD-ROM, оптическую память и т.д.), которые включают в себя компьютерный программный код.
[0103] Настоящее раскрытие описано со ссылкой на блок-схемы и/или блок-схемы способа, устройства (системы) и компьютерный программный продукт на основе реализаций настоящего раскрытия. Стоит отметить, что инструкции компьютерной программы могут использоваться для реализации каждого процесса и/или каждого блока в блок-схемах и/или блок-схемах и комбинации процесса и/или блока в блок-схемах и/или блок-схемах. Эти инструкции компьютерной программы могут предоставляться для универсального компьютера, специализированного компьютера, встроенного процессора или процессора другого программируемого устройства обработки данных для генерации машины, так что инструкции, выполняемые компьютером или процессором другого программируемого устройства обработки данных, генерируют устройство для реализации конкретной функции в одном или нескольких процессах на блок-схемах и/или в одном или нескольких блоках на блок-схемах.
[0104] Эти инструкции компьютерной программы могут сохраняться в машиночитаемой памяти, которая может дать команду компьютеру или другому программируемому устройству обработки данных работать определенным образом, так что инструкции, хранящиеся в машиночитаемой памяти, генерируют артефакт, который включает в себя устройство инструкций. Это устройство инструкций реализует конкретную функцию в одном или нескольких процессах на блок-схемах и/или в одном или нескольких блоках на блок-схемах.
[0105] Эти инструкции компьютерной программы могут быть загружены на компьютер или другое программируемое устройство обработки данных, так что ряд операций, операций и этапов выполняются на компьютере или другом программируемом устройстве, тем самым генерируя реализованную компьютером обработку. Следовательно, инструкции, выполняемые на компьютере или другом программируемом устройстве, предоставляют этапы для реализации конкретной функции в одном или нескольких процессах в блок-схемах и/или в одном или нескольких блоках на блок-схемах.
[0106] В типичной конфигурации вычислительное устройство включает в себя один или несколько процессоров (ЦП), один или несколько интерфейсов ввода/вывода, один или несколько сетевых интерфейсов и одно или несколько запоминающих устройств.
[0107] Память может включать в себя непостоянное запоминающее устройство, оперативное запоминающее устройство (ОЗУ), энергонезависимое запоминающее устройство и/или другую форму, которые находятся на машиночитаемом носителе, например, постоянном запоминающем устройстве (ПЗУ) или флэш-памяти (флэш-память). Память является примером машиночитаемого носителя.
[0108] Машиночитаемый носитель включает в себя постоянные, непостоянные, сменные и несменные носители, которые могут хранить информацию с использованием любого способа или технологии. Информация может быть машиночитаемой инструкцией, структурой данных, программным модулем или другими данными. Примеры компьютерного носителя данных включают в себя, но не ограничиваются этим, память с произвольным доступом к параметрам (PRAM), статическую память с произвольным доступом (SRAM), динамическую память с произвольным доступом (DRAM), другой тип оперативной памяти (RAM), постоянное запоминающее устройство (ПЗУ), электрически стираемое программируемое постоянное запоминающее устройство (ЭСППЗУ), флэш-память или другую технологию памяти, постоянное запоминающее устройство на компакт-дисках (CD-ROM), цифровой универсальный диск (DVD) или другое оптическое хранилище, кассетная магнитная лента, накопитель на магнитной ленте/магнитном диске, другое магнитное запоминающее устройство или любой другой непередающий носитель. Компьютерный носитель данных может использоваться для хранения информации, доступной для вычислительного устройства. Как описано в настоящем описании, машиночитаемый носитель не включает в себя машиночитаемый временный носитель, такой как модулированный сигнал данных и носитель.
[0109] Стоит также отметить, что термины «включать», «содержать» или любые другие их варианты предназначены для охвата неисключительного включения, так что процесс, способ, продукт или устройство, которое включает в себя список элементов, не только включают в себя эти элементы, но также включают в себя другие элементы, которые явно не перечислены, или дополнительно включают в себя элементы, присущие такому процессу, способу, продукту или устройству. Элемент, описываемый как «включает в себя...», дополнительно включает в себя, без дополнительных ограничений, другой такой же или идентичный элемент в процессе, способе, продукте или устройстве, которое включает в себя элемент.
[0110] Специалист в данной области должен понимать, что реализация настоящей заявки может быть предоставлена как способ, система или компьютерный программный продукт. Следовательно, настоящая заявка может использовать форму только аппаратных реализаций, только программных реализаций или реализаций с комбинацией программного и аппаратного обеспечения. Кроме того, настоящая заявка может использовать форму компьютерного программного продукта, которая реализована на одном или нескольких компьютерных носителях данных (включая, но не ограничиваясь этим, дисковую память, CD-ROM, оптическую память и т. д.), которая включает компьютерный код программы.
[0111] Настоящая заявка может быть описана в общем контексте исполняемых компьютером инструкций, выполняемых компьютером, например, программным модулем. Обычно программный модуль включает в себя подпрограмму, программу, объект, компонент, структуру данных и т.д., выполняющих конкретную задачу или реализующих конкретный абстрактный тип данных. Настоящая заявка также может быть применена в распределенных вычислительных средах. В распределенных вычислительных средах задачи выполняются удаленными устройствами обработки, подключенными через сеть связи. В распределенной вычислительной среде программный модуль может быть расположен как на локальных, так и на удаленных компьютерных носителях данных, включая запоминающие устройства.
[0112] Реализации в настоящем описании описаны прогрессивным способом. Для одних и тех же или аналогичных частей реализаций можно обратиться к реализациям. Каждая реализация фокусируется на отличии от других реализаций. В частности, системная реализация в основном аналогична реализации способа и поэтому описана кратко. Для связанных частей может быть сделана ссылка на связанные описания в реализации способа.
[0113] Предыдущие описания являются реализациями настоящей заявки и не предназначены для ограничения настоящей заявки. Специалист в данной области может внести различные модификации и изменения в настоящую заявку. Любая модификация, эквивалентная замена или улучшение, выполненные без отклонения от сущности и принципа настоящей заявки, должны попадать в объем притязаний настоящей заявки.
Изобретение относится к вычислительной технике. Технический результат заключается в повышении эффективности запрашивания данных в цепочке блоков. Способ хранения данных, в котором принимают блокчейн-узлом запрос на обслуживание, причем запрос на обслуживание содержит один или более типов данных и соответствующие данные обслуживания, соответствующие одному или более типу данных, которые хранятся в цепочке блоков; определяют по меньшей мере одно из типа обслуживания или идентификационной информации, соответствующей запросу на обслуживание; синтаксически анализируют запрос на обслуживание для получения каждого типа данных запроса на обслуживание и данных обслуживания, соответствующих каждому типу данных; определяют, что не было создано реляционной базы данных для соответствия типу обслуживания; в ответ на определение, что не было создано реляционной базы данных для соответствия типу обслуживания, создают реляционную базу данных для соответствия типу обслуживания; и сохраняют, на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу, путем выполнения оператора хранения данных. 2 н. и 8 з.п. ф-лы, 5 ил.
1. Способ хранения данных, содержащий этапы, на которых:
принимают блокчейн-узлом запрос на обслуживание, причем запрос на обслуживание содержит один или более типов данных и соответствующие данные обслуживания, соответствующие одному или более типу данных, которые хранятся в цепочке блоков;
определяют по меньшей мере одно из типа обслуживания или идентификационной информации, соответствующей запросу на обслуживание;
синтаксически анализируют запрос на обслуживание для получения каждого типа данных запроса на обслуживание и данных обслуживания, соответствующих каждому типу данных;
определяют, что не было создано реляционной базы данных для соответствия типу обслуживания;
в ответ на определение, что не было создано реляционной базы данных для соответствия типу обслуживания, создают реляционную базу данных для соответствия типу обслуживания;
и
сохраняют, на основе отношения отображения между типом данных и данными обслуживания, данные обслуживания, которые получены посредством синтаксического анализа, в базе данных, соответствующей блокчейн-узлу, путем выполнения оператора хранения данных.
2. Способ по п.1, в котором после синтаксического анализа запроса на обслуживание способ дополнительно содержит этапы:
преобразовывают на основе предварительно определенного формата данных каждый тип данных, который содержится в запросе на обслуживание, и данные обслуживания, соответствующие каждому типу данных, для получения последовательности данных;
выполняют процедуру согласования в отношении запроса на обслуживание с использованием согласованной сети; и
сохраняют последовательность данных в цепочке блоков, соответствующей блокчейн-узлу, после достижения согласования в отношении запроса на обслуживание.
3. Способ по п.1, в котором заранее определенный формат оператора содержит поле информации идентификации и поле типа обслуживания.
4. Способ по п.1, в котором сохранение данных обслуживания, полученных посредством синтаксического анализа, в базе данных путем выполнения оператора хранения данных содержит:
создают на основе по меньшей мере одного из типа обслуживания или идентификационной информации, базу данных, соответствующую по меньшей мере одному из типа обслуживания или идентификационной информации, в ответ на определение посредством выполнения оператора сохранения данных, что ни одна база данных, которая соответствует по меньшей мере одному из типа обслуживания или идентификационной информации, не идентифицирована; и
сохраняют данные обслуживания, полученные путем синтаксического анализа, в созданной базе данных.
5. Способ по п.1, в котором сохранение данных обслуживания, полученных посредством синтаксического анализа, в базе данных, содержит этапы:
создают каждый тип данных, который получен путем синтаксического анализа последовательности данных, в базе данных в ответ на определение того, что база данных не содержит этот тип данных; и
сохраняют данные обслуживания, соответствующие типу данных, в базе данных.
6. Способ по п.1, в котором запрос на обслуживание содержит запрос на запрашивание данных обслуживания.
7. Способ по п.6, в котором определение, на основании запроса на запрашивание данных обслуживания, типа данных, соответствующих данным обслуживания, которые должны быть запрошены, дополнительно содержит определение поля индекса, включенного в запрос на запрашивание данных обслуживания.
8. Способ по п.1, дополнительно содержащий этап, на котором:
запрашивают данные обслуживания, соответствующие типу данных, из базы данных, соответствующей блокчейн-узлу.
9. Способ по п.1, в котором идентификационная информация дополнительно содержит открытый ключ пользователя или идентификатор пользователя.
10. Устройство хранения данных, содержащее множество модулей, сконфигурированных для выполнения способа по любому из пп.1-9.
CN 106506638 A, 15.03.2017 | |||
Способ приготовления лака | 1924 |
|
SU2011A1 |
EP 3054405 A1, 10.08.2016 | |||
Токарный резец | 1924 |
|
SU2016A1 |
СПОСОБ И УСТРОЙСТВО ДЛЯ ОТПРАВКИ СООБЩЕНИЯ ПОЛЬЗОВАТЕЛЮ ИЛИ ПОЛЬЗОВАТЕЛЯМ ГРУППЫ ЧЕРЕЗ МИКРОБЛОГ | 2012 |
|
RU2589327C2 |
Авторы
Даты
2020-08-13—Публикация
2018-03-26—Подача