В этой статье мы рассмотрим некоторые из проблем, возникших в связи с увеличением необходимого объема ОЗУ для нод steemd, а также наши планы на будущее в контексте масштабирования. И хотя мы никогда не воспринимали проблемы масштабирования легкомысленно, мы полагаем, что основным источником беспокойства является непонимание того, как правильно/оптимально управлять нодами steemd. Ниже мы предоставим некоторые рекомендации по этому поводу, а также поговорим о кое-каких изменениях, над которыми работаем в рамках подготовки платформы к будущему прогнозируемому росту.
## Что такое масштабируемость?
Сообщество Стим быстро растет, а вместе с ним и блокчейн Стим. Рост – это хорошо, но он приносит с собой и проблемы масштабирования. Другие проекты (такие как Bitcoin и Ethereum) в течение нескольких лет никак не могут сдвинуться с мертвой точки с их проблемами масштабирования – они попросту неспособны принять какие-либо существенные изменения для удовлетворения возросших требований, связанных с активным использованием их блокчейнов. Тем временем Стим развивается и упреждает возникновение подобных проблем, что позволяет ему обрабатывать больше транзакций, чем все другие блокчейны вместе взятые. Другими словами, большинство блокчейн-транзакций, производимых в мире, выполняются на Steem.
Мы смогли это сделать, потому что наша команда состоит из постоянно растущего числа самых талантливых и продвинутых блокчейн-инженеров на планете. Но это отнюдь не делает нас высокомерными, наоборот – это заставляет нас в полной мере осознавать надвигающиеся проблемы масштабирования, и мы хотим заверить вас, что мы достаточно подготовлены к их решению. И хотя мы уверены в своей стратегии, мы также хотим услышать ваши мысли, возражения и идеи в комментариях.
## Краткая история масштабирования
Самое важное решение в плане масштабирования – это то, с чего вы начинаете. Чем более масштабируема платформа изначально, тем более масштабируемым является стек. Способность стека к масштабированию соотносится с начальной точкой, в лучшем случае, экспоненциально. Редко когда архитектура способна за один день переключиться с обслуживания 3000 человек на 3 000 000 человек. Чаще это происходит последовательно: с 3 до 6, затем до 12 и т.д. Запуск платформы на основе архитектуры, которая изначально намного опережала конкурентов с точки зрения масштабируемости ([Graphene](http://docs.bitshares.org/)), была ключевым компонентом нашей стратегии масштабирования. Те, кто не принял подобного решения, теперь оказались в сложном положении, испытывая необходимость перестроить свой фундамент, при этом не повредив всю построенную на нем экосистему.
## ChainBase и AppBase
Первым крупным обновлением для повышения масштабируемости стала замена Graphene на [ChainBase](https://steemit.com/ru/@rusteemitblog/anons-steem-0-14-4-prevyu-reliz-raspredelennoi-bazy-dannykh-perevod-stati-steemitblog). Благодаря более быстрому времени загрузки и выхода, а также повышенной устойчивости к сбоям, ChainBase стал ключевым элементом, позволяющим сети Стим обрабатывать текущий объем транзакций.
Следующее важное усовершенствование, работа над которым близится к завершению (благодаря усилиям @vandeberg и команды), является [AppBase](https://steemit.com/steem/@rusteemitblog/appbase-eshe-odin-shag-vpered-dlya-blokcheina-steem-da-nachnetsya-test-steemitblog), который дополнительно повысит общую масштабируемость Стима путем модуляризации. AppBase позволит множеству компонентов блокчейна Стим работать независимо, что даст steemd возможность эффективнее использовать многопоточность компьютеров, а также обеспечит возможность запуска различных компонентов блокчейна на разных серверах – что уменьшит необходимость запуска блокчейна Стим на отдельных высокомощных дорогостоящих серверах.
## Оптимизация нод Steemd: журнал блоков + файл состояния
Что касается работы steemd-нод в настоящее время, важно понимать, что Стиму требуется два хранилища данных: журнал блоков и файл состояния. Журнал блоков – это сам блокчейн, записанный на диск. К нему обращаются нечасто, но он имеет решающее значение для проверки целостности новых блоков и переиндексации файла состояния в случае необходимости.
Файл состояния содержит текущее состояние объектов Steem, таких как балансы аккаунтов, посты и голоса. Он поддерживается диском, но доступен через метод, называемый отображение файлов в память (memory-mapped files). Этот метод был введен в декабре 2016 года, одновременно с релизом ChainBase.
## Всё связано с ОЗУ?
Многие операторы нод полагают, что у серверов должно быть достаточно ОЗУ для хранения файла состояния всего Стима, исходя из того факта, что производительность Стима падает, когда операционная система начинает подкачку памяти Стима, что является типичной методикой работы с памятью. Здесь мы хотим быть предельно ясными: нет никакой необходимости в организации работы steemd-нод именно таким образом. Это, безусловно, действенный метод повышения производительности переиндексации ноды и обслуживания вызовов API, однако он полезен только в ограниченном числе случаев. В большинстве же случаев (включая ноды бирж, заверителей и сид-ноды) достаточно хранить файл разделяемой памяти на быстром накопителе SSD или NVMe, а не в ОЗУ.
## Требования к ОЗУ нод заверителя и сид-нод
Для запуска ноды steemd с одним только плагином `witness` (типичная конфигурация для нод заверителей и сид-нод) Steemit рекомендует использовать 16 ГБ ОЗУ, хотя может оказаться достаточно и 8 ГБ, если вашей ноде не требуется частая переиндексация. Если файл разделяемой памяти хранится в `/dev/shm/`, то для хранения всего файла состояния потребуется дополнительная ОЗУ, но такая конфигурация не рекомендуется. Чтобы избежать необходимости в дополнительной ОЗУ, файл разделяемой памяти можно хранить непосредственно на быстром накопителе SSD или NVMe.
Сервер с 8-16 ГБ оперативной памяти будет медленным в плане переиндексации, однако он будет функционировать должным образом в качестве сид-ноды/ноды заверителя, как только он синхронизируется с последним блоком. Эксплуатация на 32Гб-сервере идеальна для оптимального времени воспроизведения, но отнюдь не обязательна для корректного функционирования ноды заверителя/сид-ноды.
## Размер файла разделяемой памяти
Конфигурация по умолчанию для ноды steemd хранит файл разделяемой памяти в директории `data/blockchain`. До тех пор пока он находится на достаточно быстром (SSD или NVMe) диске с достаточным объёмом свободной памяти, настройка по умолчанию должна работать.
Актуальная рекомендация состоит в том, чтобы иметь как минимум 150 ГБ SSD хранилища, включая `block_log` (в настоящее время около 90 ГБ) и `shared_memory.bin` (в настоящее время около 33 ГБ). Эти цифры будут увеличиваться с течением времени.
Всякий раз, когда размер файла разделяемой памяти превышал размер, заданный в файле `config.ini`, необходимо было обновить конфигурацию до большего размера и перезапустить ноду. В версию Steem 19.4 внесены изменения, которые будут автоматически увеличивать этот предел по мере необходимости, без нужды перезапускать ноду. Это можно будет настроить и полностью отключить, если вы хотите хранить файл состояния в `/dev/shm`.
## Требования к полной ноде
Ноды, на которых запущены дополнительные плагины API (особенно история аккаунта), потребуют больше ОЗУ для поддержки более крупного файла состояния. «Полная нода» (та, на которой работают все плагины) технически может быть запущена на сервере с 64 ГБ, однако она будет очень медленно переиндексироваться и обслуживать вызовы API, поскольку алгоритм подкачки операционной системы не очень хорошо подходит для обработки отображаемых в память файлов. Ноды с ОЗУ 64-256 ГБ и быстрым накопителем SSD/NVMe может быть достаточно для множества случаев использования, в зависимости от нагрузки.
## Повышение производительности нод с высокой нагрузкой
Для более активно используемых нод лучший на данный момент способ увеличить производительность – иметь объём ОЗУ, достаточный для хранения всей базы данных. Это избавляет от необходимости в подкачке как таковой, что технически упраздняет смысл наличия отображаемых в память файлов. Для ноды, на которой запущены все плагины, за исключением истории аккаунтов, на данный момент требуется 256 ГБ оперативной памяти, если она pre-AppBase
Метод, который мы использовали для снижения требований к памяти полной ноды (поддерживающей всё, включая историю аккаунтов), состоит в том, чтобы разделить узел API на два сервера. На одном сервере работает только история аккаунтов, а на другом – всё остальное. Это позволяет обоим серверам использовать менее 256 ГБ оперативной памяти вместо того, чтобы запускать всё на сервере с 512 ГБ оперативной памяти. Мы настоятельно рекомендуем запускать историю аккаунтов на выделенном сервере, если вам нужна полная история всех аккаунтов, поскольку это устраняет необходимость иметь один сервер с 512 ГБ оперативной памяти.
Оптимизация работы полной ноды – одна из наших приоритетных задач, и мы поговорим об этом в следующем разделе. Если вам нужна только история определенных аккаунтов или поддержка лишь некоторых операций, требования к оборудованию могут быть значительно снижены.
## Планы на будущее масштабирование
В настоящее время мы работаем над несколькими проектами, которые сократят требования к памяти для полных нод, переместив большую часть логики API на неконсенсусные плагины, такие как HiveMind и SBDS. Это позволит выполнять многие функции, используя SSD, а не ОЗУ, что снизит эксплуатационные расходы. Выгружая данные в hivemind/sbds и/или RocksDB (ниже), мы должны получить возможность снизить требования для полной ноды до уровня консенсусной/сид-ноды, что очень важно для нас.
## RocksDB
В дополнение к неконсенсусным плагинам мы начали исследование по использованию альтернативных хранилищ данных и постепенному отказу от Chainbase. Одним из таких многообещающих хранилищ данных является [RocksDB](http://rocksdb.org/).
RocksDB – это быстрое хранилище данных для SDD с продвинутым уровнем кеширования, способное дополнительно минимизировать задержку при чтении с диска/записи на диск, поскольку оно оптимизировано для быстрого хранилища с низкой задержкой. Используемый в производственных системах в нескольких крупномасштабных сетях (Facebook, Yahoo, LinkedIn), RocksDB основан на LevelDB, но обладает повышенной производительностью за счет своей способности использовать несколько ядер процессора и SSD-хранилище для I/O bound рабочих нагрузок. Например, его использование в MyRocks приводит к использованию меньшего объема SSD-памяти, повышению срока службы SSD и доступной емкости IO для обработки запросов.
## Дальнейшая модуляризация
Мы также работаем над тем, чтобы и дальше модуляризировать блокчейн сверх того, что первоначально планировалось для исходного внедрения AppBase, например, путем организации отдельных сервисов, которые могут работать на разных серверах. Это позволит обеспечить дальнейшее распределение процессов на множество небольших серверов, тем самым повышая гибкость и снижая издержки.
# Заключение
Поскольку блокчейн-проекты продолжают набирать популярность, вопрос масштабируемости будет вставать всё более остро.
Быть масштабируемым блокчейном – это не только делать одноразовые исправления для разрешения текущих проблем ресурса. Это также и готовность эффективно решать будущие задачи.
Стим уже зарекомендовал себя как самый быстрый блокчейн с наибольшим количеством транзакций, и его масштабируемость по-прежнему остаётся в центре нашего внимания. Мы знаем, что эта проблема никогда не исчезнет полностью, поэтому планируем продолжить внедрять инновации, дабы гарантировать, что какой бы рост нас не ожидал – мы будем к нему готовы.
*- Команда Steemit*
---
***<div class="pull-right">Переведено @blockchained</div>***
**Оригинал поста: [ЗДЕСЬ](https://steemit.com/steem/@steemitblog/exploring-steem-scalability)**
---
## Если вам нравится то, что мы делаем - поддержите witness blockchained в сети Steem
---
## Телеграм чат: https://t.me/steemit
---
# [Вы можете торговать токенами STEEM/SBD на RuDEX](https://market.rudex.org/#/market/RUDEX.STEEM_USD)
<center>[](https://market.rudex.org)</center>