New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Фича для ХФ - key-value storage #924

Closed
t3ran13 opened this Issue Aug 10, 2018 · 26 comments

Comments

Projects
None yet
7 participants
@t3ran13
Copy link

t3ran13 commented Aug 10, 2018

Создать плагин для key-value хранилища, реализация в 2 строчки кода.
можно взять за основу гет пост и выкинуть все лишнее

@gropox

This comment has been minimized.

Copy link

gropox commented Aug 10, 2018

Храни все в metadata аккаунта

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Aug 10, 2018

мы за правильные "стильные" решения)
приватные сообщения ведь запилили, хотя для низ можно было и левый сервис заюзать) дешевле и быстре)

@gropox

This comment has been minimized.

Copy link

gropox commented Aug 10, 2018

Ну да, красивее было бы что то вроде

set_value account key value
get_value account key

Но надо ограничивать, по СГ аккаунта. Причем сильно. Что бы не надували ноды всяким хламом.

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Aug 10, 2018

Ну да, это как раз простимулирует покупку голосов)
если перевод на бэндвиз влияет х10, то тут можно смело делать Х30-50
в идеале параметр вынести для делегатов.

@asuleymanov

This comment has been minimized.

Copy link

asuleymanov commented Aug 10, 2018

Идея конечно здравая. Думаю только сделать ограничение по количеству таких записей в зависимости от СГ. А уж что там хранить каждый может решать сам. Вот только надо тогда делать так чтобы это смог запостить и получить только один и тот же человек.
Также можно добавить шарить остальным такие записи.

@On1x

This comment has been minimized.

Copy link

On1x commented Aug 10, 2018

Поддерживаю, ОЧЕНЬ НУЖНАЯ ВОЗМОЖНОСТЬ! Только в виде отдельного плагина, отдельные операции под это не надо делать, обойдемся форматом в custom_json.

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Aug 10, 2018

@asuleymanov
ограничение по СГ будет через бэндвиз
а для старта хватит простого публичного кей валуе, потом можно будет и проапдейтить)

@On1x
да, я тоже думал что хранить можно и в кастом джейсон, тут просто нужно обертку для апи сделать чб запись и чтение сама нода под капотом контролировала)

@afalaleev

This comment has been minimized.

Copy link
Member

afalaleev commented Aug 10, 2018

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

можно захардкодить определенный тип custom_json_operation на бендвич, но в чем тогда разница с обычной операцией? можно просто добавить set_value и считать по нему бендвич нормально. а чтобы иметь возможность не хранить на ноде key-value хранилище, то сделать настройку в конфиге.

лично мне больше нравится - блокировать часть СГ на хранение данных, чем бендвич. бендвич он только на траффик через ноду работает, и не работает на объем.
как вариант - можно сделать уменьшение объема бендвича на объем хранимых данных.

чтение под копотом ноды можно не контролировать - берешь собираешь ноду без контроля и получаешь данные без ограничений.

поскольку данные нода никак не валидирует, для нее value просто blob, то туда можно класть хоть зашифрованные данные.

@afalaleev afalaleev added the hardfork label Aug 10, 2018

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Aug 10, 2018

Ваш менеджер жалуется что у вас времени нет, так что хватит простенького варианта как предложил оникс

@marijadia marijadia added the low label Aug 16, 2018

@marijadia marijadia added this to the 0.19.0 milestone Aug 16, 2018

@maslenitsa93 maslenitsa93 self-assigned this Sep 17, 2018

@maslenitsa93

This comment has been minimized.

Copy link

maslenitsa93 commented Sep 18, 2018

@gropox @t3ran13 @On1x I'm gonna implement it.
Какая в итоге реализация нужна?

@gropox

This comment has been minimized.

Copy link

gropox commented Sep 18, 2018

Есть два варианта,

Вариант 1

один дешевый, неконсенсусный. Написать плагин, который бы сохранял последние последние custom_json-ы с отправленные пользователем. С ID в качестве ключа.

И метод, что бы их извлечь. К примеру get_custom_json("ropox", "state") возвратит "json" аттрибут последней custom_json операции, с ID "state".

Минусы такого варианта: Неконсенсусно, Непонятно как ограничивать объем хранения по пользователю. Хотя можно наверное ограничить максимально 10 записей (10 x 63kb = 640кб макс. на пользователя), старые удалять.

Вариант 2

Второй вариант - консенсусный

добавить операцию для сохранения значения с ключем. Таже custom_json, только

set_value( "ropox", "balance$t3ran13", "{'USD': '1000.00'}")
set_value( "ropox", "ropox11", "['t3ran13', 'on1x']")
И геттер
get_value("ropox", "balance$t3ran13")

Которое вернет {"USD": "1000.00"}

Тут тоже надо думать, как ограничивать. Думаю дать делегатам определять цену памяти в голосах, так как у них на серверахз все будет храниться. Сколько стоит один байт или килобайт в Голосах. Допустим 1024 Байт RAM стоит 100 Голосов, при 100к Голосах в СГ, можно сохранить данных на 1 мегабайт. Так проще наверно, чем делать вариант EOS с покупкой RAM. На голосе можно нарегать адресов почти бесплатно и делегировать им сколько угодно CГ тем самым зарезервировав "адресное пространство" ))

Альтернативно "стоимости", можно задать максимальный размер пула памяти и распределять его сообразно СГ. Допустим определить как 2Gb (определяется делегатами). При наличии 100кСГ получается ~0.11% (согласно steemul) от всего стэка голосов, то есть от 2GB выходит примерно 2 мегабайта? Что в принципе неплохо.

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

При понижении СГ, удалять старые данные сначала.

Я лично за второй вариант.

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Sep 18, 2018

Второй зачетный, но он на порядок сложнее и дает нагрузку на ноду, не говоря о том, что если сделать слишком дорогим, то им никто не станет пользоваться

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

Хоть второй и красивее, первый все равно выйграет, т.к. можно хранить инфу в комментах или в постах

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

@maslenitsa93

This comment has been minimized.

Copy link

maslenitsa93 commented Sep 18, 2018

@t3ran13 Будет первый.
А зачем черный и белый лист юзеров?

@gropox

This comment has been minimized.

Copy link

gropox commented Sep 18, 2018

Что бы в приватной ноде не хранить все подряд

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Sep 18, 2018

Горох прально ответил

@maslenitsa93

This comment has been minimized.

Copy link

maslenitsa93 commented Sep 18, 2018

@t3ran13 А одного списка не хватит - либо черный, либо белый?
Цель вообще какая? Если сделать для всех кроме некоторых, то черный. Если сделать только для некоторых - то белый. Как лучше?

@gropox

This comment has been minimized.

Copy link

gropox commented Sep 18, 2018

Сделать как в opration_history

@gropox

This comment has been minimized.

Copy link

gropox commented Sep 18, 2018

Если делать плагином, то надо в любом случае ограничивать, что бы не грузить ноду лишними данными. Сделать максимальное число сохранённых данных или как в opration_history удалять по прошествии заданного в конфиге колличество блоков. Наверное последнее лучше. Плюс в приватной ноде не хочется хранить чужие данные, хватило бы и белого списка. А вот в публичной, образцово-показательной ноде golos-js.io лучше хранить все и на всякий случай дать возможность исключать злоупотребляющих доверием - то бишь черный список. Вообще оба списка пригодятся

@gropox

This comment has been minimized.

Copy link

gropox commented Sep 18, 2018

Сорри, как в account_history плагине

@afalaleev

This comment has been minimized.

Copy link
Member

afalaleev commented Sep 18, 2018

Я тоже за плагин.
Вопрос в том, чтобы не злоупотребляли, потому что делегатские ноды custom_json не обрабатывают.
Но на делегатских нодах можно считать бендвич на все (без разбора на какой плагин) custom_json операции. А делегатам вынести параметры xN (как для трансферов x10) насколько увеличивать потребление бендвича по custom_json операциям.

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Sep 18, 2018

По спискам горох прав, слижите из истории акка

И логику по выносу в параметр бэндвиза поддерживаю) по дефолту сделать как трансферы х10

@afalaleev

This comment has been minimized.

Copy link
Member

afalaleev commented Sep 19, 2018

@maslenitsa93, Looks good!
Small improvements:

  • tracked_account and untracked_account are not needed. tracked_accounts and untracked_accounts are enough
  • Add configuration for limit on size of stored key/value
  • Add calculation of bandwidth for custom_json like for transfers
  • Add param to chain_properties for xN (default x10) of bandwidth for custom_json
@maslenitsa93

This comment has been minimized.

Copy link

maslenitsa93 commented Sep 19, 2018

  • Create new plugin account_notes. Do next steps inside the plugin.
  • Implement config like in account_history-plugin, but also with blacklist:
  • tracked_accounts
  • untracked_accounts
  • Add config keys for limits on size of stored key, stored value, count of notes per account
  • Add account_note_object. For value use shared_string. Add index of these objects.
  • Add operation set_value_operation (to be sending with custom_json)
  • Define API method get_value (parameters are account and key) to return the value.
  • Add calculation of bandwidth for custom_json like for transfers
  • Add param to chain_properties for xN (default x10) of bandwidth for custom_json
  • Write checklists for pull request
  • Write unit-tests for plugin_tests

maslenitsa93 added a commit that referenced this issue Sep 24, 2018

maslenitsa93 added a commit that referenced this issue Sep 24, 2018

maslenitsa93 added a commit that referenced this issue Sep 25, 2018

maslenitsa93 added a commit that referenced this issue Sep 25, 2018

maslenitsa93 added a commit that referenced this issue Sep 25, 2018

maslenitsa93 added a commit that referenced this issue Sep 25, 2018

@maslenitsa93

This comment has been minimized.

Copy link

maslenitsa93 commented Oct 16, 2018

@t3ran13 @gropox @On1x Продолжаем работу над #924 !
На данный момент у нас есть такая реализация плагина:
#958
Там единственный коммит, весь код в нём.
Возникла пара вопросов. Например, не нужно ли нам хеш вместо key (хотя это уже скорее будет внутренняя кухня)?

@gropox

This comment has been minimized.

Copy link

gropox commented Oct 16, 2018

Шифрование и хэши не нужны. Шифровать можно и в приложении при необходимости. С хэшами тоже самое

@t3ran13

This comment has been minimized.

Copy link

t3ran13 commented Oct 16, 2018

+1 к гороху

maslenitsa93 added a commit that referenced this issue Oct 18, 2018

maslenitsa93 added a commit that referenced this issue Oct 19, 2018

maslenitsa93 added a commit that referenced this issue Oct 22, 2018

maslenitsa93 added a commit that referenced this issue Oct 23, 2018

maslenitsa93 added a commit that referenced this issue Oct 23, 2018

maslenitsa93 added a commit that referenced this issue Oct 23, 2018

afalaleev added a commit that referenced this issue Oct 24, 2018

Merge pull request #958 from GolosChain/924-account-notes-plugin
Account_notes plugin, bandwidth for custom_json #924

@afalaleev afalaleev closed this Nov 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment