Вот я снова у клавиатуры. И если вам хоть немного понравилась предыдущая заметка, давайте снова углубимся в вопросы связи архитектуры и геймдизайна.
Я обещал рассказать подробнее о том, какой подход выбрала наша команда, почему мы это сделали, какие это открывает перед нами перспективы, ну и, конечно, почему мы все же считаем программную архитектуру одним из важнейших факторов в вопросе внедрения разнообразных сложных механик и масштабности ММО.
В чем же его особенность? Как я уже писал в прошлой заметке, тут важна история развития самих ЭВМ. Если быть точнее, в основном речь идет о росте производительности процессоров и памяти, которые не очень соотносятся.
Как видите, на графике прослеживается сильное отставание скорости доступа процессоров к оперативной памяти, а это значит, что каким бы классным и быстрым не был процессор (CPU), ваша оперативная память (RAM) будет ограничивать его.
Но не расстраивайтесь! Для того, чтобы снизить влияние этого разрыва, производители добавляют немного магии… Ой, нет, немного очень дорогой и быстрой памяти прямо на кристалл CPU. Эта память называется кешем и на сегодняшней день часто имеет аж целых 3 уровня. В характеристиках процессоров обычно пишут что-то вроде: «Объем кеша L1 64 КБ». Да, кеш измеряется в килобайтах, чем выше уровень кеша, тем он более медленный, но имеет немного больший объем.
Казалось бы, этой памяти довольно мало, но основная идея такой архитектуры в том, что небольшие блоки данных и программной логики в течение довольно короткого промежутка времени (миллионные доли секунды) могут снова понадобиться. А значит, разумнее держать их как можно «ближе», чтобы не приходилось долго (в сравнении с кешем) ждать их из оперативной памяти.
Таким образом, задача DoD состоит в том, чтобы структурировать данные программы в соответствии с тем, в каком порядке они будут обрабатываться. Это называется «принципом локальности». И в наиболее распространенной на сегодняшний день парадигме программирования, о которой я говорил в прошлой заметке, этот принцип повсеместно нарушается.
В чем же проблема? Дело в том, что при создании разнообразных объектов программисты в ООП исходят из принципов нашей человеческой логики, объединяя данные и логику в абстракции, аналогичные объектам реального мира. При этом однородные данные перестают храниться поблизости друг от друга в оперативной памяти, а значит, и в кеше процессора. Кроме того, они начинают занимать там намного больше места, чем могли бы, что приводит к значительным задержкам в обработке этих данных.
Проще говоря, процессоры плохо переваривают любые сложноустроенные объекты и иерархии, вне зависимости от того, насколько структурированными и понятными они выглядят для человека. И это свойство заложено глубоко в архитектуре современных CPU, а значит буквально диктует нам как должен быть написан наш код
Entity-Component-System (ECS)
Итак, наши данные из DoD мы теперь просто называем компонентами. Они представляют из себя просто свойства сущностей игрового мира: существ, игроков, предметов, явлений и так далее.
Сущности, в отличии от объектов в ООП, не содержат в себе буквально ничего. В каком-то смысле это просто ID (идентификатор), при помощи которого мы можем отличить одну сущность от другой и понять какие она имеет свойства.
Ну и наконец системы. Системы — это сама логика нашего мира. Системы занимаются тем, что последовательно обрабатывают данные, что буквально вдыхает жизнь в наш мир.
Это может показаться не менее сложным, чем та же ООП. Но вот более простое описание того, что делает ECS.
Данные теперь можно представить как огромную таблицу Excel, где сущности — это номера строк, а компоненты — столбцы. В итоге системы занимаются тем, что последовательно обрабатывают изменения данных в столбцах. Согласитесь — звучит очень просто.
Еще проще дело обстоит с тем, чтобы ускорить работу этой обработки. Все, что вам нужно сделать, это обрабатывать не все данные в столбце по очереди, а разделить их на группы, соответствующие числу потоков\ядер вашего процессора, и обрабатывать все параллельно. Обработка будет во столько раз быстрее, сколько у вас будет доступных потоков\ядер процессора. И это имеет свои плоды: вы можете полноценно утилизировать производительность даже таких монстров как 64-ядерные процессоры. Я говорю не о каких-то странных синтетических тестах, а о полноценной полезной нагрузке. Это большая редкость для софта вообще, чего уж говорить про игры.
Ну а что же насчет механик? Самым значимым плюсом для ММО, которая написана на базе ECS, является простота сопровождения, что включает и добавление новых механик.
Сопровождение — это процесс улучшения, оптимизации и устранения дефектов программного обеспечения.
Любая оптимизация, поиск багов и исправления в уже существующих системах очень сильно упрощается за счет полной изоляции. Можно сказать, что в некотором смысле системы в ECS работают практически как отдельные программы.
Создание новых систем и свойств никак не ограничено, за исключением ограничений производительности машины, на которой это все запущено. На самом деле это огромные цифры: миллионы сущностей с десятками разнообразных свойств\компонентов.
И для гемдизайнера это означает абсолютную свободу действий: любые масштабы, любые безумные идеи, любые взаимодействия могут быть созданы буквально простым добавлением данных в таблицу.
Конечно, какие-то кардинально новые механики требуют написания новой логики. Однако, из-за изолированности систем, опять же, новые механики очень просто внедрять, отлаживать и настраивать.
Кончено, существует во многом похожий простой компонентный принцип на базе ООП, который стал популярным в играх. Он используется и в UE4, и до 2018 версии активно использовался в Unity. Скорее всего, и многие самописные движки тоже используют его. Но у него все еще есть минусы, ограничивающие пластичность, если можно так выразиться. Объекты, которые вы захотите создать в игре, все еще будут шаблонными, они не смогут иметь любые свойства, какие вам захочется, так как компоненты добавляются в процессе написания самого кода. Справедливости ради можно добавить, что существуют способы обойти эти ограничения и в ООП, но подобная архитектура требует еще больших затрат времени и имеет еще большую сложность, не говоря о том, что она нарушает все тот же принцип локальности данных.
В ECS же вы вольны создавать просто немыслимые гибриды сущностей, абсолютно не заботясь об изменениях в архитектуре проекта. Так мы можем создать книгу-NPC, которая может ходить или летать, выдавать квесты, а затем, изменив несколько параметров, превратить ее в предмет, который будет контейнером, содержать в себе какую-то информацию и даст игрокам возможность положить эту сущность в инвентарь. И, конечно, «книга», выполнив все возложенные на нее обязательства, может стать просто книгой, которая имеет только 2-3 свойства в виде простых численных значений. И все это в процессе выполнения программы. Возможность создавать сущности, которые имеют любые свойства прямо в игре абсолютно без ограничений и без необходимости что-то дописывать — это очень удобно, поверьте.
На мой взгляд, не менее воодушевляющим примером может служить компонентный AI. Часто в играх используются так называемые древа поведения, которые, если упрощать, определяют: что делает NPC в данный момент времени, что он может сделать после этого, что будет, если произойдут такие-то события. Тут мы столкнемся с тем, что необходимо заранее определить все возможные варианты развития событий, чтобы наш NPC не тупил на ровном месте. Да, с простым компонентным подходом мы можем написать планировщик, который будет оценивать свойства этого NPC (или его состояния, как вам больше нравится), свойства мира вокруг и планировать свои действия для достижения какой-то цели. Однако, эта система и все ее состояния для конкретного NPC все еще будут жестко определены программным кодом, и после компиляции вы уже ничего не сможете изменить.
Что предлагает нам ECS? Нам дается сущность, которую в процессе самой игры мы можем наделить свойствами: сделать NPC торговцем, бандитом, бродягой, а после смерти оставить лишь компонент модели тела и пару других свойств. Но представьте, что тело NPC никуда не денется, на это место придет некромант, который «заменит» компонент одной модели на другую и сделает из нашего трупа NPC-нежить. Так каждое новое добавленное свойство меняет поведение этого NPC, делая его умнее или глупее, изменяя его цели и методы их достижения.
По итогу я все же смею утверждать, что, как минимум в контексте ММО, описанная архитектура не имеет аналога с таким же уровнем производительности и одновременной простотой реализации, и причина не в том, что это какой-то универсальный способ вылечить все проблемы вашего кода и выпрямить вам руки. Нет, причина просто в том, что железо диктует нам, как его использовать максимально эффективно.
В качестве вывода, пожалуй, немного перефразирую то, что написал в комментариях к прошлой заметке: чем проще внедрить механику и заниматься ее отладкой и видоизменением, тем выше вероятность того, что кто-то эту механику внедрит, а значит, мы будем иметь больше ММО с большим количеством разнообразных сложных и интересных механик.
P.S. Для тех, кто хочет и имеет возможность погрузиться глубже и разобраться в деталях, я могу посоветовать вот эту статью. И для расширения тематики огромный список разнообразных полезных материалов по DoD.
Я обещал рассказать подробнее о том, какой подход выбрала наша команда, почему мы это сделали, какие это открывает перед нами перспективы, ну и, конечно, почему мы все же считаем программную архитектуру одним из важнейших факторов в вопросе внедрения разнообразных сложных механик и масштабности ММО.
DOD — сделай процессору приятно
Где-то после года разработки на UE4 мы поняли, что предоставляемый Epic Games функционал нас во многом не устраивает. И тогда, в поисках ускорения работы сервера, мы наткнулись на такую штуку как Data-oriented Design.(дизайн ориентированный на данные или просто DoD)В чем же его особенность? Как я уже писал в прошлой заметке, тут важна история развития самих ЭВМ. Если быть точнее, в основном речь идет о росте производительности процессоров и памяти, которые не очень соотносятся.
Как видите, на графике прослеживается сильное отставание скорости доступа процессоров к оперативной памяти, а это значит, что каким бы классным и быстрым не был процессор (CPU), ваша оперативная память (RAM) будет ограничивать его.
Но не расстраивайтесь! Для того, чтобы снизить влияние этого разрыва, производители добавляют немного магии… Ой, нет, немного очень дорогой и быстрой памяти прямо на кристалл CPU. Эта память называется кешем и на сегодняшней день часто имеет аж целых 3 уровня. В характеристиках процессоров обычно пишут что-то вроде: «Объем кеша L1 64 КБ». Да, кеш измеряется в килобайтах, чем выше уровень кеша, тем он более медленный, но имеет немного больший объем.
Казалось бы, этой памяти довольно мало, но основная идея такой архитектуры в том, что небольшие блоки данных и программной логики в течение довольно короткого промежутка времени (миллионные доли секунды) могут снова понадобиться. А значит, разумнее держать их как можно «ближе», чтобы не приходилось долго (в сравнении с кешем) ждать их из оперативной памяти.
Таким образом, задача DoD состоит в том, чтобы структурировать данные программы в соответствии с тем, в каком порядке они будут обрабатываться. Это называется «принципом локальности». И в наиболее распространенной на сегодняшний день парадигме программирования, о которой я говорил в прошлой заметке, этот принцип повсеместно нарушается.
В чем же проблема? Дело в том, что при создании разнообразных объектов программисты в ООП исходят из принципов нашей человеческой логики, объединяя данные и логику в абстракции, аналогичные объектам реального мира. При этом однородные данные перестают храниться поблизости друг от друга в оперативной памяти, а значит, и в кеше процессора. Кроме того, они начинают занимать там намного больше места, чем могли бы, что приводит к значительным задержкам в обработке этих данных.
Проще говоря, процессоры плохо переваривают любые сложноустроенные объекты и иерархии, вне зависимости от того, насколько структурированными и понятными они выглядят для человека. И это свойство заложено глубоко в архитектуре современных CPU, а значит буквально диктует нам как должен быть написан наш код
ECS — данные + воображение
Ну, хорошо — у нас есть DoD, мы имеем четко структурированные данные. А что, собственно, с ними делать? Конечно обрабатывать. И тут нам понадобятся какие-то абстракции, которые будут объединять наши данные для создания всего многообразия игрового мира. Такими абстракциями в нашем случае выступают сущности, компоненты и системы:Entity-Component-System (ECS)
Итак, наши данные из DoD мы теперь просто называем компонентами. Они представляют из себя просто свойства сущностей игрового мира: существ, игроков, предметов, явлений и так далее.
Сущности, в отличии от объектов в ООП, не содержат в себе буквально ничего. В каком-то смысле это просто ID (идентификатор), при помощи которого мы можем отличить одну сущность от другой и понять какие она имеет свойства.
Ну и наконец системы. Системы — это сама логика нашего мира. Системы занимаются тем, что последовательно обрабатывают данные, что буквально вдыхает жизнь в наш мир.
Это может показаться не менее сложным, чем та же ООП. Но вот более простое описание того, что делает ECS.
Данные теперь можно представить как огромную таблицу Excel, где сущности — это номера строк, а компоненты — столбцы. В итоге системы занимаются тем, что последовательно обрабатывают изменения данных в столбцах. Согласитесь — звучит очень просто.
Еще проще дело обстоит с тем, чтобы ускорить работу этой обработки. Все, что вам нужно сделать, это обрабатывать не все данные в столбце по очереди, а разделить их на группы, соответствующие числу потоков\ядер вашего процессора, и обрабатывать все параллельно. Обработка будет во столько раз быстрее, сколько у вас будет доступных потоков\ядер процессора. И это имеет свои плоды: вы можете полноценно утилизировать производительность даже таких монстров как 64-ядерные процессоры. Я говорю не о каких-то странных синтетических тестах, а о полноценной полезной нагрузке. Это большая редкость для софта вообще, чего уж говорить про игры.
Ну а что же насчет механик? Самым значимым плюсом для ММО, которая написана на базе ECS, является простота сопровождения, что включает и добавление новых механик.
Сопровождение — это процесс улучшения, оптимизации и устранения дефектов программного обеспечения.
Любая оптимизация, поиск багов и исправления в уже существующих системах очень сильно упрощается за счет полной изоляции. Можно сказать, что в некотором смысле системы в ECS работают практически как отдельные программы.
Создание новых систем и свойств никак не ограничено, за исключением ограничений производительности машины, на которой это все запущено. На самом деле это огромные цифры: миллионы сущностей с десятками разнообразных свойств\компонентов.
И для гемдизайнера это означает абсолютную свободу действий: любые масштабы, любые безумные идеи, любые взаимодействия могут быть созданы буквально простым добавлением данных в таблицу.
Конечно, какие-то кардинально новые механики требуют написания новой логики. Однако, из-за изолированности систем, опять же, новые механики очень просто внедрять, отлаживать и настраивать.
Кончено, существует во многом похожий простой компонентный принцип на базе ООП, который стал популярным в играх. Он используется и в UE4, и до 2018 версии активно использовался в Unity. Скорее всего, и многие самописные движки тоже используют его. Но у него все еще есть минусы, ограничивающие пластичность, если можно так выразиться. Объекты, которые вы захотите создать в игре, все еще будут шаблонными, они не смогут иметь любые свойства, какие вам захочется, так как компоненты добавляются в процессе написания самого кода. Справедливости ради можно добавить, что существуют способы обойти эти ограничения и в ООП, но подобная архитектура требует еще больших затрат времени и имеет еще большую сложность, не говоря о том, что она нарушает все тот же принцип локальности данных.
В ECS же вы вольны создавать просто немыслимые гибриды сущностей, абсолютно не заботясь об изменениях в архитектуре проекта. Так мы можем создать книгу-NPC, которая может ходить или летать, выдавать квесты, а затем, изменив несколько параметров, превратить ее в предмет, который будет контейнером, содержать в себе какую-то информацию и даст игрокам возможность положить эту сущность в инвентарь. И, конечно, «книга», выполнив все возложенные на нее обязательства, может стать просто книгой, которая имеет только 2-3 свойства в виде простых численных значений. И все это в процессе выполнения программы. Возможность создавать сущности, которые имеют любые свойства прямо в игре абсолютно без ограничений и без необходимости что-то дописывать — это очень удобно, поверьте.
На мой взгляд, не менее воодушевляющим примером может служить компонентный AI. Часто в играх используются так называемые древа поведения, которые, если упрощать, определяют: что делает NPC в данный момент времени, что он может сделать после этого, что будет, если произойдут такие-то события. Тут мы столкнемся с тем, что необходимо заранее определить все возможные варианты развития событий, чтобы наш NPC не тупил на ровном месте. Да, с простым компонентным подходом мы можем написать планировщик, который будет оценивать свойства этого NPC (или его состояния, как вам больше нравится), свойства мира вокруг и планировать свои действия для достижения какой-то цели. Однако, эта система и все ее состояния для конкретного NPC все еще будут жестко определены программным кодом, и после компиляции вы уже ничего не сможете изменить.
Что предлагает нам ECS? Нам дается сущность, которую в процессе самой игры мы можем наделить свойствами: сделать NPC торговцем, бандитом, бродягой, а после смерти оставить лишь компонент модели тела и пару других свойств. Но представьте, что тело NPC никуда не денется, на это место придет некромант, который «заменит» компонент одной модели на другую и сделает из нашего трупа NPC-нежить. Так каждое новое добавленное свойство меняет поведение этого NPC, делая его умнее или глупее, изменяя его цели и методы их достижения.
По итогу я все же смею утверждать, что, как минимум в контексте ММО, описанная архитектура не имеет аналога с таким же уровнем производительности и одновременной простотой реализации, и причина не в том, что это какой-то универсальный способ вылечить все проблемы вашего кода и выпрямить вам руки. Нет, причина просто в том, что железо диктует нам, как его использовать максимально эффективно.
В качестве вывода, пожалуй, немного перефразирую то, что написал в комментариях к прошлой заметке: чем проще внедрить механику и заниматься ее отладкой и видоизменением, тем выше вероятность того, что кто-то эту механику внедрит, а значит, мы будем иметь больше ММО с большим количеством разнообразных сложных и интересных механик.
P.S. Для тех, кто хочет и имеет возможность погрузиться глубже и разобраться в деталях, я могу посоветовать вот эту статью. И для расширения тематики огромный список разнообразных полезных материалов по DoD.
36 комментариев
Любому инженеру, решившему понять семейство ES парадигм, в первую очередь стоит обратиться к статьям и wiki этого человека. Адам занимается развитием этого семейства еще с начала нулевых. Тема CO/ES/ECS является очень старой. Без это всего реализация таких игр как, например, Prototype, стала бы крайне затруднительной.
William_Godwin , мне вот что стало интересно. Какую реализацию компонентного подхода вы решили выбрать для своего проекта?
Если сущности изолированы, как они будут взаимодействовать между собой?
Я так и не понял разницу между добавлением поля в сущности и добавлением поля в обычном объекте. Что там, что там одна строчка кода для поля плюс логика обработки.
Чем это отличается от объектов в JavaScript и других динамических языках? Там тоже можно добавлять любые свойства в процессе выполнения программы. Или обычным HashMap, где ключ — название поля, а значение — любой объект в качестве значения поля? Только производительностью?
В конце статьи ссылка на статью, написанную 11 лет назад, что ECS — это будущее. Теперь это будущее уже наступает?
Сущности не изолированы, скорее даже наоборот, в отличии от ООП у вас вообще нет никакого сокрытия данных. Изолированы и независимы друг от друга системы, а если вам нужно какое-то взаимодействие, то оно осуществляется через изменения компонентов и только так.
у сущности нет полей, это просто ID. Вы же, я думаю, видите разницу между созданием объекта с переменной и записью данных в конкретную ячейку таблицы в базе данных.
Нарушением принципов локальности данных. С мапой вопрос в том, что она куда проще устроена чем таблицы в стиле RMD.
Ну, все сразу не делается ведь. А вообще, можно такой вопрос задать создателям SpatialOS. Что-то мне подсказывает, что они просто умеют в рекламу.))
Можно начать с малого. Сперва можно понять, что функциональность может существовать отдельно от данных. Такой подход позволяет нелинейно наращивать функциональность вокруг набора данных, не меняя при этом уже созданную функциональность или сами данные.
На следующем шаге можно свыкнуться с тем, что довольно часто монолитность данных искусственна, что в прошлом она была подчинена требованиям функционального интерфейса. А когда функциональный интерфейс отделен от данных, его требования перестают довлеть над данными. Появляется возможность декомпозиции данных.
Когда данные декомпозированы, формальная классификация объектов теряет свое качество. Теперь объект может быть классифицирован через композицию данных. В это же самое время, над композицией данных становится возможным выполнение некоторого внешнего функционального интерфейса. Но самое интересное в том, что композиция данных может свободно меняться во время жизни объекта — что меняет как его классификацию, так и набор доступных функциональных интерфейсов.
Теперь все разнообразие объектов определяются только композицией своих данных, связанных вместе через абстрактный идентификатор сущности, и набором универсальных функциональных интерфейсов, каждый из которых понимает только часть общей композиции данных сущности, думая что предоставленная часть композиции — это и есть вся сущность.
Слово «просто» встречается в заметке 13 раз. Корень «прощ» — 5 раз. Однако, из прошлой заметки, и вашего комментария в этой заметке, складывается впечатление, что все совсем уж ни разу не «просто»
Вызывает диссонанс.
Есть ли какие-то, эгхм, простые примеры, side-by-side сравнение OOP vs DoD в виде кода?
эгхм
Мне интересно посмотреть на прямое сравнение. Функция, написанная в рамках ООП, и рядом, такая же, но в DOD. Чтоб можно было наглядно увидеть разницу. 10-20 строчек, что угодно. Может, у вас есть что-то из кода вашего проекта, что вы уже переписывали? Мне интересно именно в сравнении глянуть.
Вот, даже юнити
Единственное, где они отошли от ООП — это на последних слайдах, где вместо списка объектов сделали несколько списков, по одному списку для каждого поля. И это ускорило программу аж 28% в их случае (43ms→31ms update). Улучшение небольшое, и я думаю, что более сложный код не стоит того. Но в некоторых особо сложных ситуациях может помочь.
Выводы, что я сделал: ООП живее всех живых и отлично работает. А если писать лишние циклы, то это будет тормозить при любой парадигме программирования.
1)Перечисляются конкретные признаки ООП (объекты это еще не ООП)
2)Объясняется, что использование объектов именно такими методами замедляет работу процессора с данными в 400-700 раз (сами инструкции выполняются со скоростью меньше наносекунды, основным узким местом всегда были и остаются данные)
Если вы утверждаете, что код становится сложнее, то вы точно не поняли как это работает. Ну а впихивать или пытаться подружить DoD с OOD, как это делали в презентации разработчики из Unity, как я писал еще в комментариях к прошлой заметке — плохая идея.
А ООП для хайлоад давно умер, если конечно вы не хотите поспорить с эффективностью реляционной модели данных))
А для хайлоада и реляционная модель неактуальна, на её место приходит NoSQL, как я понял. И хайлоад для ММО, в принципе, не нужен особо, если у нас 5к человек на сервер. По-моему, тут больше проблема в геймдизайне, чтобы сделать интересную игру, а не в технической реализации. Так что, лучше писать, как проще, и уже когда игровая схема взлетит, тогда и заниматься оптимизацией производительности.
NoSQL тут не причем, речь про реляционную модель как таковую, то есть логические связи, а не физические. К слову, 5к человек онлайн означает, что у вас в DB записей гигантское количество, т.к. игру купило раз в 100 больше людей.
Насчет NoSQL я бы не торопился, особенно когда у вас есть многопоточный слон, а вам нужна больше даже не скорость записи а скорость чтения селекта и т.п в условиях очень больших таблиц. у сервера ММО свой запросы.
Если вы сайт пилите, может это и прокатит, но писать как попало ММО, а потом все переделывать это какой-то мазохизм, простите.
Еще напомню, что сейчас не «10 лет назад» и объем данных у игр изменился. А про сервера линейки на яве с майкулькой я вообще лучше промолчу))
Для этого есть DBa и архитекторы. Которые создадут нормальную структуру, напишут для запросов хинты, создадут вьюшки и партиции. Оперативка и SSD дают огромное преимущество в скорости отклика.
«Хотя, может вам виднее, чем специалистам, или вы из разряда «и так сойдет»\«все так делают»?))»
Извините, я читая вас просто не заметил, что вы специалист.
«Еще напомню, что сейчас не «10 лет назад» и объем данных у игр изменился.»
Насколько принципиально изменился объём данных на уровне БД при том же количестве игроков и примерно тех же параметрах персонажей? Всё те же таблицы, с теми же полями — аккаунты, персонажи, таблицы вещей, справочники. Если мы говорим про сервер с 5к игроками на одном шарде, а не про MOBA игру.
«А про сервера линейки на яве с майкулькой я вообще лучше промолчу))»
Ну, во первых были украденные хроники совершенно на другой БД. Во вторых, MySQL сама по себе довольно шустрая БД которая используется не только для маленьких сайтиков. Там весьма ограниченный язык, но её используют и в том числе и в корпоративных решениях. Можно погуглить если интересно что такое Percona (и что она может) и MariaDB.
Точно внимательно читали, может стоит прочесть ЕЩЕ раз?
Вы застряли в 2005 году
Слон щас тихо в сторонке смеется)
И про поля таблиц расскажите, которые кардинально и в разы отличаются от тех, что были в 2005ом. И про скорость MySql на простых селектах, например.
<
«Если мы говорим про сервер с 5к игроками на одном шарде»
5к онлайн, разумеется.
«Еще разок, 700ns и 2ns, ок?»
Ещё раз, в 2005ом хватало простых рейдов для работы БД, не очень большого количества оперативки и довольно слабых по нынешним временам процессоров. Что так кардинально изменилось в данных, что стало не хватать при новом железе, которое даёт гораздо более быстрый отклик? Не говоря уже о том, что значительно продвинулись сами движки БД.
Что касается скорости отклика, если уж нужен рилтайм — Oracle TimesTen. Да и куча других.
яговорил не про себя. Я не зря ссылки даю, а чтоб по ним ходили.
Мне этот некропостинг, если честно, не сильно интересен, если вы не понимаете где у вас ботлнек и упорно тыкаете в память, хотя обе заметки были именно о ней, ну я не знаю что еще сказать.
Еще вы, видимо, не знаете, но я вам расскажу, что количество людей онлайн не так сильно влияет на скорость того самого селекта, как само количество записей в вашей БД и таблиц, особенно если вам еще и джоины иногда нужны. А в 2005 вы застряли еще и потому, что сейчас вообще ни один адекватный сервер на HDD не стоит, тот же яндекс вообще предлагает NVMe, что тоже не спасет вас, если вы считаете, что все «и так сойдет».
Далее, если внимательно почитать все три мои заметки на этом ресурсе, то станет понятно, что:
1 — реляционная модель и на клиенте и на сервере, где при этом ботлнек я тут в комментах и даже в самой заметке объяснил.
2 — в 2019 всем как-то уже недостаточно того объема информации, которого требовала лина
3 — мне сказали что не реляционные базы данные в тренде и они якобы быстрые, но у них очень много проблем, в том числе с кешмис-ами и для ММО они не подходят.
Ага, а по сети с клиентом оно тоже за 10ms дойдет? Увас там конь щароообразный в вакууме убегает — ловите.)
На каких операциях с БД нужна скорость отклика в 2мс?
Ты упорно не отвечаешь на мои вопросы, где тут диалог? Что принципиально нового добавилось на стороне БД ммо с 2005го года? О каких объёмах данных речь? Почему вдруг перестало хватать на более быстрых винтах? Откуда такое жёсткое требование по латенси и для каких операций оно нужно (примеры)?
При вашем уровне профессионализма (а он, поверьте, виден в каждом комменте) писать про коней не стоит. Я уже писал, что если нужен низкий латенси ставят Infiniband. Большинство игровых серверов работают без него (например на той же LA2). Infiniband уже давно стоит в инфраструктуре EvE, хотя я не помню чтобы они гнались именно за латенси. Им просто нужна была широкая шина.
NVMe это и есть SSD, просто через PCIe. С того, что появились SSD я и начал беседу.
Ну так и что же произошло? Откуда берется такое жесткое требование к задержкам чтения из ПЗУ в современных проектах?
А откуда у тебя 2мс взялось? В каком тексте эта величина фигурировала?
Раз вы такой профессионал ( я себя таковым не называл), то почему вы до сих пор не прочитали внимательно все треды и не поняли о чем вообще изначально была речь? Увидели пару строчек про БД? Эффект Даннинга-Крюгера?
Да, я признаюсь, что у меня там есть ошибка в букве и это могло сбить с толку, но вас не смущает, что изначально речь вообще шла о сравнении noSQL и SQL, а все две заметки как бы про огромный потенциал реляционной модели данных как таковой?
А вы ведь и правда так и не поняли про работу с данными и про ботлнек, да?
И с логикой беда. Да, они и так везде стоят, но от кривой реализации они не спасут, а вы утверждаете, что «ну поставил SSD и все зишибись».
В ваших любимых ганкбоксах — ничего.
Вообще ощущение, что мне пытаюсь продать дельфина, хотя я давно купил слона и доволен, по многим причинам, не только из-за скорости при большом объеме данных и вообще перспективах при расширении. Так зачем вы это делаете?
Как вы? Просто говоря, что «выниченепанимаите нада так»? Или я должен был поведать про архитектуру своего проекта? (вообще странно, что я что-то должен, но ок.) Нет, я так делать не буду, я как-то больше люблю статичстику, а она, что интересно, из гугла, ага.
По ссылкам на HL++ я уже предлагал ходить...
Вообщем, у меня нет никакого желания что-то доказывать врывающимся в тред «профессионалам», мне хватает такого в спорах с разработчиками н адругих площадках. Ок, вы профессионал — я дурак-любитель, который ничего не понимает в БД и не хочет делать стандартные MMORPG с механиками уровня 2003 года, CMS или социальную сеть с магазиньчиком.
Спасибо за внимание.
К слову, 5к человек онлайн означает, что у вас в DB записей гигантское количество, т.к. игру купило раз в 100 больше людей.
Насчет NoSQL я бы не торопился, особенно когда у вас есть многопоточный слон, а вам нужна больше даже не скорость записи а скорость чтения селекта и т.п в условиях очень больших таблиц. у сервера ММО свой запросы.
в ответ на сообщение Элая«И хайлоад для ММО, в принципе, не нужен особо, если у нас 5к человек на сервер. „
Гонора вполне себе как у профессионала, у которого за плечами как минимум 10 лет DBA.
Простой вопрос — простой ответ. Написали про латенси в 10мс — обоснуйте, в каких случаях в играх требуется меньше. Написали про разницу в 700 и 2мс — напишите, в каких случаях требуется 2мс. Я на ваши вопросы отвечаю. Вы уже в который раз от ответа уходите.
Уход от ответа. Не убедили, попробуйте ещё раз. Или снова будете вертеться, как уж на сковородке?
Такого я не говорил.
Слэнговые “слон», «дельфин» должны как-то усилить ваш образ продвинутого программиста? Так никто не говорит. Я вообще не заводил речь о том, лучше PostgreSQL чем MySQL или хуже. Это вы насмехались над mysql в качестве БД и у меня закономерно возник вопрос. Ведь я полагаю, что если человек о чём-то уверенно пишет — значит он это знает и я всегда надеюсь, что он этим знанием со мной поделиться.
Я ответил на все ваши вопросы. Вы на мои — нет. После этого на голубом глазу писать «Как вы?», браво. Мне вот интересно, когда до реальной работы дело дойдёт — неужели вы думаете, что такие дискуссии вам помогут?
Ну, это можно было и не писать — так вы уже до этого показали свою несостоятельность не ответив практически ни на один мой вопрос.
Чтобы понимать формат нашей дискуссии важно понимать политическую ситуацию не ммозге. Не будь я его «злейшим врагом», вы бы уже купались в щедрых минусах за свою демагогию, манипуляции, уходы от ответа и напыщенность при минимуме знаний. А так, видимо принцип «враг моего врага мой друг» важнее истины.
И неважно, 5к онлайн на таком сервере, или 200 персонажей — сервер все рано будет искать игрока в базе из этих 60к персонажей.
Линейка то, линейка се…
Посмотрим, скажем на FF14 — персонаж, имеющий сейчас первое место в рейтинге The Feast eu.finalfantasyxiv.com/lodestone/character/486374/. Из 14 слотов экипировки на внешность не влияют только два — пояс и кристалл души класса. Как думаешь, какую нагрузку создаст на сервер этот игрок, просто пройдя пару кругов по городской локации в час пик?
Какая скорость потокового чтения с блина? Какая скорость блочного чтения с SSD? Какая скорость доступа к блоку на кристалле 3D NAND? Какая скорость доступа к блоку на кристалле 3D XPoint? О какой скорости чтения говорить не надо и почему не надо?
Расскажи о технике асинхронного блочного чтения с блинов, с NAND SSD, с 3D XPoint. Поточный доступ быстрее или блочный? В каких случаях?
Расскажи топологию данных в БД для одного аккаунта из L2, из PW, из Aion, Cabal Online. Какие зависимости и связи созданы для данных аккаунта? Сколько будет весить бинарный дамп одного аккаунта со всеми связями для среднестатистического персонажа с максимальной прокачкой?
Плюс в том документа про фронтэнд, для бэкэнда свои заморочки будут, но в целом, дизайн ориентированный на данные — может вполне пригодится и там, так как эти проверки нужно повторять. Но это еще нужно подумать.
Но в целом я согласен, это больше просто технология построения связей в программе, чем новая парадигма и замена ООП.
Но исходя из этого документа, я начинаю понимать почему игры типа Battletech жрут по 9ГБ ОЗУ и тормозят даже в интерфейсах меню сохранения…
Разработчики пошли ленивые и не желающие оптимизировать свои творения.
Для работы с этой парадигмой нужно просто подругому мыслить, но очень многие люди, которые переходили с OOD на DoD говорят, что проекирование, написание и отладка стала где-то двже в разы проще. Блольшое количесто вещей етсть, за которые теперь вообще не нужно беспохоиться, как например настройка доступа к данным при добавлении многопоточности. Теперь просто разделяешь все данные на кучки и параллельно обрабатываешь: скорость есть, а головной боли нет.)))
Это логично, если учесть, что веся логика представляет из себя отдельные изолированные блоки, которые занимаются исключительно своим делом, добавляй себе и добавляй.