В предыдущем посте я получил довольно интересные комментарии. Основная тема текущего поста - как обновлять информацию с Голоса в своей базе данных. Архитектура там будет своя, строиться будет на базовых принципах. @primus правильно отметил:
Зачем обновлять всех пользователей по крону? Может лучше парсить блокчейн Голоса по мере появления новых блоков и исходя из того, что в блоках записано - накатывать обновления в базе пользователей / статей / балансов / апвоутов и т.п. Тогда у вас не будет пустой работы о "обновлению" неактивных аккаунтов и будет только производительная деятельность по учёту реальных изменений.
В целом - идея здравая. И ее можно попытаться частично реализовать - начать рыть методом get_block и пробираться по блокчейну восстанавливая все данные в своей структуре. Возможно, я попытаюсь сделать что-то подобное. Это самый "правильный" способ, в теории. А вот на практике - не знаю. В одном блоке часто записано много операций. В них записано всё: и новые посты, и комментарии, и лайки, и переводы голоса, и создание аккаунтов. И изменение постов. И комментариев.
Более того - изменение постов и комментариев написаны в виде unidiff (читаем Универсальный формат Diff). Получается огромная линейка событий. И тут развилка в желаниях и возможностях. Получить конечный/актуальный контент можно по прямому запросу. А можно пройдя все исторические слепки воссоздать актуальный контент. Что же выбрать и почему?
По-правде говоря - толстому клиенту не зачем хранить всю историю изменений - это и так записано в Голосе, зачем дублировать эту информацию? Требуется последняя версия контента. И тут мы попадаем в следующую ловушку. Необходимость проходить рекурсивно все комментарии.
Рассмотрим пример - предыдущий пост и комментарии к нему. Как видно - API выдает лишь комментарии первой вложенности. Хотите загрузить дальше? Делайте еще один запрос. Рекурсия меня не пугает, но вот обработку данных она может запросто превратить в ад.
Для того, чтобы определиться - нужно в первую очередь разобраться, что проще и быстрее внедрить. Стоит ли держать у себя ВСЕ данные Голоса. Или стоит "собирать" их по-требованию от клиента. Зашел человек к пользователю, который давно не обновлялся, быстро подгрузилась/дополнилась история его постов и комментарии по API выборке с этого конкретного пользователя. Получится реализация кругами по воде. Запросили - дали + подгрузили связанные части.
Очень двоякая ситуация, не понятно как ее решить. Дорогу осилит идущий. Целостность контента тоже очень важна. Вопрос лишь в том, как получать новые данные через API. Думаю, если у меня удастся правильно отработать unidiff на контенте/комментариях в PHP, то стоит рассмотреть полный обход линейки блоков Голоса. А вы как считаете?
Обновления контента это довольно редкая вещь. И в API всегда есть возможность получать из блокчейна текущий слепок актуального контента поста или комментария без необходимости самостоятельно применять diff каждый раз при обновлении контента.
Т.е. если в блоке идёт обновление уже существующего контента - по ещё одному запросу к ноде вы можете получить сразу обновленный контент,
Таких запросов не много, существенной нагрузки они не создадут.
То же касается и комментариев - зачем их каждый раз вытягивать рекурсивно из блокчейна, если вы пишете толстый клиент и всё храните в MySQL? Заносите их туда по мере поступления свежих блоков, а дерево стройте уже сами средствами PHP или что там у вас с качестве обработчика на сервере.
если своя нода - то нет, а если общественная - то тормоза в пики еще какие! я иногда таймаут на 7 секундах хватаеют. это не дико ли?
Своя нода, конечно, лучше.
Для полного хардкора можно на бинарном уровне (не через API) общаться с блокчейном и P2P нодами (параллельно сразу со всеми активными). Но проще, конечно, локальную ноду поднять.
хоть куда копать и у кого спросить? поскольку я как-раз то что ты сказал понимаю, но где начать не представляю)
Готового стороннего решения я не видел, Так что копать только в исходники Голоса на Гитхабе.
И их на этот предмет не изучал, так что даже имена файлов пока не подскажу.
своя нода дорого!
а вот тут можно подробнее? как законектиться, как общаться? меня этот вопрос давно интересует все заняться не могу)
Я о технических деталях рассказать не могу, т.к. сам на практике это не реализовал.
Но ведь все ноды друг с другом в P2P сети синхаются как-то без API. Вот и можно подключиться к этому протоколу своим клиентом.
Я давным-давно писал свой клиент под P2P код биткоина, без API. Для Голоса/Стима при желании можно тоже сделать, тем более что исходники открыты.
блин, лично мое мнение
вывод - меньше запросов к ноде и меньше данных на серваке. а то порвет.
я понимаю что можно бесконечнов ертикально масштабировать железку, но мне такой вариант не нравится
Первые два комментария и оба совершенно разные. @tristamoff и @primus наоборот считают, что целостность важнее. Я пока не могу оценить вот этот момент:
Не могу по той причине, что сложно оценить "объем" всех данных. Так может лучше пройти всю линейку блоков, чтобы потом забирать ТОЛЬКО новые данные, а не дублировать запросы с обновлением данных по таймеру? Надо сейчас пойти проверить в базе @arcange общий объем Голоса.
ок, сделаю тебе завтро маленькую добро-подлость.
буду завтра раздавать всем по два голоса чб в кита вложились)
космотришь при больших объемах как твой код работает и сам сделаешь вывод)
А если у тебя 300 человек смотрят одновременно разных пользователей? Это 300 запросов к API голоса и потом от каждого update запрос к своей БД?
смотреть нужно и думать. сканирвоать каждый блок - есть смысл когда ты много инфы используешь. опять же, иногда от ноды проще напрямую нужно получить.
Важно понимать насколько тебе важна актуальность данных. чб в реалтайме или от зачержки никто не умрет?
И когда у тебя в голове есть ответы на эти вопросы, то можно смело выбрать что тебе важнее)
Можно же лимитировать, очереди + время прошлого обновления принимать во внимание.
Это да, но опять же - смотреть надо.
А если само содержимое постов не хранить у себя - то все эти сортировки и выборки можно делать и места много не займёт.
Я всё-же соглашусь с @primus
Смотреть блок и вытаскивать из него нужные данные думаю не проблема.
Если в блоке много разных действий - кидай их все в очередь и потом спокойно обрабатывай отдельным потоком, скажем так.
Я бы так поступил.
Согласен, это правильнее. Плюс надо изучить этот пост от @dark.sun, возможно там будет что-то интересное. Позже напишу, что получилось.
Ваш пост поддержали следующие Инвесторы Сообщества "Добрый кит":
losos, t3ran13, antino, tristamoff, ropox, gryph0n, asuleymanov, vika-teplo, anomalywolf, myhardmoney, generationg
Поэтому я тоже проголосовал за него!
Узнать подробности о сообществе можно тут:
Разрешите представиться - Кит Добрый
Правила
Инструкция по внесению Инвестиционного взноса
Вы тоже можете стать Инвестором и поддержать проект!!!
Если Вы хотите отказаться от поддержки Доброго Кита, то ответьте на этот комментарий командой "!нехочу"
Зачем вам список всех пользователей? Там много дохлых. Активных пользователей за месяц всего пару тысяч, самых активных наверное 10 процентов от этих пары тысяч. Лучше получать данные по мере надобности.
Во вторых, если нода локальная к серверу, то работа по вебсокету на порядок быстрее.
В третьих считаю, что блоки читать, что бы получить содержание не нужно. Это и так делает сама нода и раскладывает все по полочкам. Клиентам лучше пользоваться методами API и брать готовое с полочек. Блоки читать нужно только если обработчики простые. Там апвоты в рилтайме обработать и подобное. Или как триггер, что бы обновить ленту (хотя толстый даже так не делает). Можно и посты обрабатывать, но проще увидев в блоге коммент, вызвать get_content и получить все готовое к употреблению, чем самому собирать и хранить у себя. Пост может в течении месяца редактироваться, а после ХФ вообще без ограничений. Вы хотите сами прочитать все начиная с певого блока и собрать базу? Зачем, все это есть уже у ноды.
да, это тоже важный фактор - своя нода)
но она толстожопая. для нее отдельный сервак нужен)
В этом и смысл толстого клиента. "Все это есть у ноды" конфликтует с богатыми возможностями глубокой фильтрации, управлением и кастомизацией собственного профиля. Если делать инструмент для всех, он должен иметь все данные для самостоятельной работы. И обновлять их как можно скорее.
Это не беда. Таблица юзеров не такая раздутая, чтобы вообще беспокоиться про дохлые аккаунты. Можно ввести правило - нет активности = более редкое обновление. Сейчас база ВСЕХ пользователей голоса весит около 5-6 Мегабайт.