Приветствую, уважаемые читатели Habr! Сегодня я хотел бы рассказать об интересном подвиде одного алгоритма, о котором Вы могли возможно забыть! У меня довольно интересный опыт в разработке модификаций для мультиплееров (далее - МП) трехмерных игр на серверной и клиентской части для разных игровых проектов, как на языках JS, так и Lua, которые использовались на сервере и клиенте.В один прекрасный день, я все же решил углубиться в настоящий Highload и изучать для себя язык Go. Пока я ходил по собеседованиям, я понял, что у меня действительно малозначительный опыт именно в разработке высоконагруженных систем. И, пока всё это происходило, я понял, что знания все же необходимо подтягивать, а сами собеседования помогут направить меня в нужное русло. И, после одного из собеседований с вопросами об индексах, я решил углубиться в них (помимо бездумного расставления btree и hash через EXPLAIN ANALYZE).Так я наткнулся на интересный для себя индекс в PostgreSQL - GiST. Что из себя представляет индекс GiST? Вспомним, что GiST - это подвид структуры R-tree, которая позволяет быстро обращаться к данным в пространстве. Когда я это прочитал, мне стало невероятно интересно, как в игровых модификациях, с которыми я работал, обстоят дела с пространственным поиском? Там, где я работаю, существует один из старейших МП, разработанный ещё в 2004 году. Исходников у меня не было, поэтому мне стало интересно, как решали эту проблему тогда и, возможно, сейчас. Объяснение для тех, кто совсем не связан с играми.В каждом МП, где большое количество игроков (а я работал с МП, где средний онлайн на одном сервере более 300-500, а порой и 1000 человек). Представляем себе большую карту и понимаем, что игрокам не обязательно видеть друг друга на большом расстоянии. Поэтому у каждого игрока есть своя зона видимости - то есть, зона стрима.Эта зона стрима обновляется не в реальном времени каждую возможную единицу времени, а раз в секунду, для того чтобы не создавать большой нагрузки на сервер МП. В итоге, я решил узнать, как конкретно игрок 1 должен узнавать, что игрок 2 должен находиться в зоне стрима. Обратившись к своему хорошего другу, с кем я продолжаю работать в этой сфере, и скинув ему интересную статью, он подсказал мне, как действительно устроен стриминг в этом МП. Он смог покопаться в закрытом исходном коде и найти конкретно то место, которое меня интересовало. Ответ меня поразил и смутил. Разработчик МП буквально перебирал каждого игрока для каждого игрока. Я был в шоке, но в то же время понимал, почему разработчик этого старого МП ограничился всего 1000 игроков в пределах одного сервера. Если бы он поставил хотя бы ограничение в 1500 игроков, то сложность поиска игроков в зоне стрима увеличилась бы уже буквально в 2.25 раз. И, судя по метрикам, даже текущее решение съедало не мало так ресурсов.   Вооружившись современным инструментов в виде языка Go я решил провести искусственное нагрузочное тестирование с алгоритмами R-tree и квадратичным (каждый игрок для каждого игрока) линейным поиском.  Что я сделал в логике приложения на Go?  На сервере есть сущности с данными: Координаты X и Y Массив указателей на игроков, которые находятся в зоне видимости этой сущности Данные области видимости и "поля" для поиска: Размер поля в X и Y (2000x2000 у. е.) Размер стороны области видимости Область видимости, в данном случае - это квадрат с равными сторонами, которые указаны в данных выше. Сущность, к которой применяется поиск, находится в центре этого квадрата.Синхронизация в логике Go обновляется раз в секунду. У следующих сущностей будут случайно сгенерированная позиция в пределах поля. Теперь к самим показателям, начнем с квадратичного линейного поиска: Количество сущностей, единиц Область видимости, у. е. Время обновления стриминга для всех игроков, мсек 1000 200 72.5 2000 200 295 4000 100 1150 С учетом того, что синхронизация обновляется раз в секунду, мы можем понять, что при показателях в 4000 сущностей сервер просто перестанет нам отвечать, если все данные обрабатываются в одном потоке или если есть обращение к этой структуре...Как это выглядит в коде:  Сложность квадратичного линейного поиска здесь буквально O(n^2), и мы можем её сократить. Например, если один игрок уже видит второго, то и второй игрок видит первого. Следовательно, нам не нужно перебирать весь список игроков внутри второго цикла. В итоге, можем представить новый код уже вот так: Довольно банальное решение, и я был крайне удивлен, что разработчик мультиплеера к этому не пришел. Показатели O(n^2)/2: Количество сущностей, единиц Область видимости, у. е. Время обновления стриминга для всех игроков, мсек 1000 200 35 2000 200 150 4000 100 580 Уже лучше, но даже с учетом затрат в виде 580 из 1000 мсек чисто на синхронизацию - это невероятно много, потому что в том же потоке работает ещё и основная логика сервера. В общем, это решение так же не подходит... И, наконец, гвоздь программы - R-tree! К моему счастью (огромное спасибо dhconnelly) я буквально сразу нашел библиотеку rtreego, которая реализовывала структуру R-tree в языке Go. Количество сущностей, единиц Область видимости, у. е. Время обновления стриминга для всех игроков, мсек 1000 200 16 2000 200 55 4000 100 110 Я был невероятно удивлен, ведь показатели времени обновления зоны стрима оказались от 4 до 10 раз меньше, чем то, что используется сейчас!Что удивительно, в моей сфере есть более современный мультиплеер, у которого есть примерно аналогичная проблема, но утверждать я, к сожалению, ничего не могу, так как нет доступа к исходному коду от слова СОВСЕМ.Однако есть только метрики со стороны логического ядра работы, на которые я могу полагаться. Показатели отображали, что сеть не была перегружена от слова совсем, как и логическое ядро, однако наблюдались невероятно большие проблемы с синхронизацией при более 1300 игроков на одном сервере. Я уже радовался победе, что сделал что-то полезное, как друг, которому я скидывал эту же статью обратил внимание, что там написано R*-tree, а не R-tree в некоторых местах. Как мы поняли, R*-tree и R-tree - это две разных структуры данных, первая является подвидом второй. Параллельно я решил покопаться у себя в показателях, заведя свой код с отладкой, и понял, что 70-80% времени занимает вставка и удаление.Я решил сравнить R-tree и R*-tree хоть в каких-нибудь бенчмарках, чтобы убедиться, что, возможно, есть алгоритм ещё эффективнее. Поискав бенчмарки R*-tree в сравнении R-tree и наткнувшись на: Delphi в статье; R*-tree в Boost (туда я пока не хочу); Статью про нейробиологию от 2020 года научного деятеля в Швеции; Имплементация на Java вместе с бенчмарками и показателями эффективности структуры.  Имплементация на Java с показателями оказалась ровно тем, что мне нужно, но...Оказалось, что показатели вставки в R*-tree гораздо медленнее, но поиск гораздо эффективнее. Мне стало резко интересно, а есть ли R*-tree такое в Go? И такого не оказалось. И тут мне невероятно сильно захотелось это воссоздать и сравнить на практике... После таких историй пора приступить к делу и понять, в чём разница между R*-tree и R-tree простыми словамиR-tree - это древовидная структура, которая разбивает пространство на области.R*-tree - это подвид структуры дерева R-tree, которое балансирует эти данные, чтобы поиск по этому дереву был эффективнее.Заранее спешу сообщить, что указанная статья ответит на большую часть Ваших вопросов, но если Вам трудно перейти, то постараюсь объяснить своими словами, чтобы не углубляться, буквально на картинках.Возьмем пример обычного R-tree: Синими квадратами обозначаются поддеревья или ветки.Красными квадратами обозначаются "листья" этих поддеревьев, в которых хранятся элементы.Черные точки - те самые элементы в этом дереве.Теперь же возьмем пример R*-tree: Все данные остаются теми же самыми, но мы буквально можем заметить визуальные отличия: Поддеревья и ветки располагаются так, чтобы не накладываться друг на друга. Уменьшается перекрытие веток. Все ветки или поддеревья стараются быть минимальных размеров. Уменьшается площадь листьев и веток. Как раз, в этом и есть главная задумка R*-tree!При абсолютно каждой вставке элемента происходит цикл, который перебирая все возможные элементы, старается уменьшить площадь веток и перекрытие веток, таким образом, упрощая в будущем поиск по этой структуре данных!Как мы понимаем, за счет таких манипуляций, растёт и цена (то есть, время) вставки элемента. Причем, если дерево становится больше, то и элементов нужно перебирать больше. Буквально, на примере разработки игровых модификаций, я пришел к таким выводам:Где можно использовать R-tree? Игровые мультиплееры с большим количеством элементов; Любая реал-тайм карта с множеством элементов, которые перемещаются (например, карта автомобилей с такси) Где можно использовать R*-tree? Статические карты хоть с миллионом миллионов элементов (например, это можно использовать в игровом стриминге статических объектов); Любые гео-данные, которые читаются в несколько раз чаще, чем заполняются (например, карта целого города или области) Я решил не использовать стандартное решение в виде бенчмарков Go и буквально на своих примерах показать время обработки запросов. Я решил взять приблизительные размеры карты той игры, в которой я работал, и актуальный размер зоны стрима. Область в условных единицах: 8000x8000 Область видимости: 500x500, элемент находится в центре зоны видимости Позиции элементов: генерируются случайно Показатели: средние из 3-5 прогонов Тип поиска R-tree R*-tree Вставка 1000 элементов 18.5 мсек 330 мсек Вставка 100 тысяч элементов 2.91 сек 37 сек Вставка 1 млн элементов 37.8 сек 6 мин 30 сек Поиск среди 1000 элементов (1 тыс. итераций) 1.5 мсек 0.2 мсек Поиск среди 100 тысяч элементов (1 тыс. итераций) 140.1 мсек 8 мсек Поиск среди 1 млн элементов (1 тыс. итераций) 1.4 сек 40 мсек Интересная идея: невероятно эффективным (и простым в реализации, особенно в случае языка Go) решением является создание нескольких деревьев для поиска, чтобы искать элементы в разных горутинах в нескольких деревьях. Простыми словами - чтобы достичь максимальной эффективности - нужно найти для себя максимальное количество элементов в среднем на дерево и делить деревья на равные части. Буквально, как партицирование в БД :) Невероятно огромное спасибо за внимание!  Если Вы знаете более эффективные решения для игр или гео-данных на вставку или чтение, я буду очень рад почитать в комментариях! Ссылка на реализацию rtreego (обычного R-tree), которую я взял за основу и переделал её под R*-tree.  Backend-разработчик