Для миллионов объектов лучше хранить в массиве или базе данных, например, redis, если объекты нужны в реальном времени?

Question

Я разрабатываю симуляцию, в которой могут быть миллионы сущностей, которые могут взаимодействовать друг с другом.На данный момент все объекты хранятся в списке.Было бы лучше хранить объекты в базе данных, например, Redis вместо списка?

Answer 1

Примечание: Я предположил, что это было реализовано на Java (сила привычки). Мой ответ не очень полезен, если это не Java.

Делая множество предположений о ваших требованиях, я бы рассмотрел Redis, если:

• Вы сталкиваетесь с недопустимыми паузами GC из-за миллионов ваших объектов ИЛИ
• Созданные вами объекты могут быть повторно использованы в нескольких прогонах моделирования

Java-приложения с гигантскими кучами и множеством долгоживущих объектов могут работать в очень длительных паузах GC, в зависимости от рабочей нагрузки. то есть старый ген наполняется всеми этими миллионами предметов, и они никогда не могут быть собраны. Независимо от этого, периодически будет происходить полный сбор (если вы не мастер настройки GC), и вам придется сканировать эти миллионы объектов старого поколения. Каждый раз, когда это происходит, это может занять много секунд, и вы замерзаете в течение этого времени. Если это происходит, и вам это не нравится, вы можете разгрузить все эти долгоживущие объекты в Redis и оплатить стоимость сериализации / десериализации доступа к ним, а не паузы GC.

Что касается повторного использования сущностей: если вы загружаете большую базу данных Redis, а затем отбрасываете все ее данные, когда симуляция заканчивается, это кажется немного расточительным. Если вы можете повторно использовать сущности во время прогонов симуляции, вы можете сэкономить кучу времени, сохранив их в Redis.

Answer 2

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

Если ваши данные помещаются в память, доступ осуществляется таким образом, что означает, что вы можете эффективно использовать базовые структуры данных, такие как списки / массивы и хеш-таблицы, и ко всем элементам обращаются примерно одинаково часто, поэтому хранение ваших данных в памяти, вероятно, является лучшим вариантом .

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

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

Answer 3

Список не обязательно является лучшей структурой данных, если только «взаимодействие» не ограничено соответствующим следующим или предыдущим элементом. Произвольный доступ (по индексу) очень медленный в списке.
Перечисляет ракету при вставке спереди и в конце и при поиске следующего (или предыдущего) элемента или вставке одного между ними. Они полностью взорвали для доступа к элементу 164553, а затем к элементу 10657, будучи O (N) при произвольном доступе. Таким образом, «взаимодействовать друг с другом » говорит о том, что список является плохим выбором.

Это очень сильно зависит от шаблонов доступа и распределения, но vector или deque, вероятно, будет гораздо лучше, чем список для вашей симуляции.

Redis основан на хеш-таблице, которая имеет (намного!) Лучшую характеристику для произвольного доступа, но, скорее всего, все же будет медленнее, поскольку он имеет значительные накладные расходы для сериализации данных он проходит через сокет, повторно анализирует и анализирует его, отправляя ответ, и вы анализируете его.