mayton2019

Вообще не стоит задача менять разрешение текстур для 8К и выше моника. Обычно его вешают
подальше на стену из-за габаритов и сохранения угла поля зрения. И поэтому гнать
разрешение чтоб попадало точка-в-точку обычно не нужно. Все равно возможности
зрения ограничены. Разве что пользователь нажмет на паузу. И будет подходить
к экрану пока не уткнется носом чтобы что-то там разглядывать. Но это не игровой кейс.

Еще с 2000х разработчики знали хитрости. Bump-mapping, это когда на low-res текстуру
накладывся рельеф (повторяющиеся фактура дерева или камня) и это создавало иллюзию
высокого разрешения.

И процедуральные текстуры, которые можно рендерить для любого разрешения на заказ.
Они экономили память диска но не памяти текстур. Поэтому с ними есть нюансы.

Если использовать такие БД как DymanoDb, CosmosDb, Cassandra или кеш Redis, то там сразу
можно создавать записть с отметкой TTL и указывать сколько времени запись будет актуальна.
Впоследствии эту отметку можно продлить или сделать живщуей вечно.

По поводу реляционок типа Postgres.

В хранении ненужных записей я не вижу проблемы до тех пор пока вы в состоянии такие
токены идентифицировать и почистить отдельно с помощью джоба который запускается
раз в сутки например и просто удяляет их по признаку например "состояние ожидания
ввода числа из СМС". Трекайте это состояние и все будет ОК.

Когда объекты крупные в сцене то пользователь видит их скорость кадров. Можно ставить 60 fps.
Когда пользователь смотрит на объекты размером с пиксель - то и не нужно их обновлять часто.
Сделай хоть 10-15 fps и будет норм.

Ну тоесть я как-бы взял level of detalization но применительно не к пространству а ко времени.

Идея выгрузить все в Redis провалилась, так как на более 120К записей поиск начал тормозить сильнее прямого запроса к БД.

Нужно более подробно изучить этот кейс. В момент "торможения" что происходило? Шла выгрузка?
Redis упал в swap? Дело в том что структуры данных Redis спроектированы так что дают
постоянный отклик почти на любом объеме данных лишь бы хватало памяти. Этот эффект
который вы поймали говорит скорее всего о неверном использовании.

Попробуйте value хранить в разных форматах. В JSON. В бинарном (protobuf). В gzip. Оптимизируйте
бизнес данные. Я всегда находил способы не хранить длинные url. И заменить их на что-то.

В качестве промежуточного хранилища можно использовать много чего. Apache Ignite, Hazelcast,
LevelDb, RocksDb, CouchDb, Riak. Но мне кажется что проблема ваша не в том какую
dbms взять а как грамотно реплицировать бизнес-данные в слой кеширования.

Поговорите с бизнесом какое отставание кеша от данных является приемлемым и исходите из этого.
В некоторых случаях отставанее в сутки является норм. А иногда даже милисекунда - уже нельзя.

В самой нейросети. Нейросеть - это и есть память. Она конечно загадочным образом сочетает
в себе и память и процессинг но в этом вся идея.

Т.к. мы не можем сделать выборку всех заказов в статусе X, т.к. их очень много, но мы и не можем сделать выборку с лимитом т.к. не знаем точно, что данные заказы будут оплачены платёжной системой Y и наоборот, если будем строить выборку от оплат. В общем получается, что мы решаем вопросы, которые легко решены в БД, но мы их пытаемся решить в коде. Как поступать то?

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

Вы говорите что не знаете точно какие заказы оплачены. Вам нужно создать новый метод
который в правильном сервисе выдает только оплаченные заказы. А в базу ходить не надо.
Она вообще может быть недоступная по инфо-безопасности для прочих модулей.

Вот и есть правильная микросвервисная архитектура.

Не претендуя на ответ я просто перечислю здесь все советы, которые уже звучали в комментариях и
добавлю свои.

Развитие этого вопроса - плавно приводит к нарушению законов. Например,
что можем сделать с несчастным владельцем бота, зная его IP. Развивать не будем.
Пускай будет просто http-responce. Я думаю модератор одобрит сухое перечисление
с чисто академическим интересом.

- Отдавать боту безсмысленный трафик. Набор непарсящегося по html содержимого. (/dev/random)
- Отдавать мееееедленно контент. Еще медленнее....
- Отдать майнер или любой JS который создает безсмысленную нагрузку.
- Отдеть веб-ассембли создающую нагрузку.
- Отдать gzip-бомбу (сжатый трафик который переполняет память при распаковке (очень быстро))
- Отдать xml-бомбу (очень старая уязвимость XML/DTD которая не везде работает)
- Отдать png/gif картинки переполняющие память при открытии.

В конечном счете эффект от этих сюрпризов будет сильно зависеть от самого бота. Я подозреваю
что никакого эффекта в целом не будет. От игнора содержимого до незначительных ошибок и
резкого закрытия соединения.

Хорошие статьи на хабре были:

https://habr.com/ru/articles/667576/
https://habr.com/ru/articles/445378/
https://habr.com/ru/articles/318530/

Еще была такая штука как коллапс волновой функции.

https://www.youtube.com/watch?v=2SuvO4Gi7uY

Я честно скажу что до конца не понимаю как это работает - но генерирует хорошие реалистичные картины
мира.

Этот сценарий возможен. Но я-бы советовал сделать его через backup на внешнее устройство.
Объем - маленький. Можно сделать за несколько часов всю работу.

Как растягивать Windows я не знаю. Давно это было. Но были утилиты типа Acronis, которые
кажется это делали с загрузочного диска.

JavaScript на Java уже писали много раз. Поищи по ключевым словам Rhino, MVEL.

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

Почему Ардуинка? Почему SD?

Если это одноразовая задача - то ее лучше решить на десктопе на Python.
Да. Странное форматирование. Пропущена запятая между элементами massiv.
Или это автор так удачно копи-пастил. Вобщем разбирайся с запятой, или это
будет еще одной проблемой к списку проблем.

Коробочные решения для парсеров

Python : https://www.w3schools.com/python/python_json.asp
Java : https://www.baeldung.com/jackson-streaming-api

В реляционных БД нельзя сделать серебрянную пулю которая всегда будет успешно стрелять.
Чаще всего в БД делают так. Анализируют какие группы запросов наиболее тяжелые
и пытаются материализовать по 1 mat view на каждую группу.

Можно сделать более детальный партишенинг (у вас шардинг) тами образом чтобы искомые данные
всегда лежали в маленькой части таблицы.

Поиск идет в одной из шард, определяемой по дате.

Попробуйте более детальную дату. От суток - к часам. От часов к минутам.

Для поиска используется 2-3 поля, которые являются какими-либо идентификаторами, сильно сужающими выборку (до нескольких записей в пределах нужной даты).

Если у вас есть тренд на использование 1-2 дней (оперативная информация)
то отгрузите этот опер-период в отдельную свехр-быструю БД (Redis)
и сгенерируйте все возможные комбинации запросов и ответов.

Звучит странно но такая материализация может быть выгоднее чем точечные
запросы (которые у вас не являеются OLTP т.к. возвращают в общем случае
более чем 1 строку).

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

Здесь я не очень понял, является ли указание отдела взаимоисключающим. Но попробуйте
подумать направлении фасетов (facets). Это почти тот-же партишенинг-шардинг но ключ
партишенинга будет сочетанием нескольких атрибутов.

Получение по настоящему случайных чисел - это криптографическая задача и ее делают через всякие
библиотеки типа OpenSSL и прочие. Там есть API для криптостойких ГПСЧ. Вы можете вызывать их
без сидирования между вызовами поскольку там эта проблема уже решена.

Если вы уже добрались до работы с системными часами
system_clock::now()
то означает что у вас есть какие-то мысли по поводу ГПСЧ или вы видите недостатки просто
вызова rand() - то расскажите какие именно. Или где вы внутри rand увидели дефект.
Обычно 99% пользователей довольны rand и име ничего другого не надо.

В вашем коде srand(..) нужно вызвать 1 единственный раз и потом просто брать значения из rand(..)

Apache Lucene вообще не знает что такое файлы. Он оперирует понятием документ
(org.apache.lucene.document.Document) и поля документа (Field, StringField e.t.c).
Поля могут быть Stored (просто храниться) или Indexed (участовать в генерации текстового
индекса).

Поэтому посмотри учебные примереы с Lucene и попробуй перезадать вопрос по другому.

Пользователь этож тебе не корова, которая молоко и мясо дает. Это сложная система.
Что за задачи у пользователя. Может он в 1С раз в день что-то поищет и потом будет
целый день сидеть в другой системе.

Бери аналогичную систему и просто накинь коэффициентик.

Тебе надо обязательно прочитать что такое манифест
https://docs.oracle.com/javase/tutorial/deployment...

Большинство ответов на твои вопросы лежит там. Существуют разные методики упаковки
приложения в jar-артифакт. Можно делать зависимости внешними. А можно создавать
так называемый fat-jar (толстый jar) куда будут перепакованы все внешние зависимости.
Shade plugin, jar plugin и еще много плагинов этим занимаются для maven сборщиков.

Почитай еще что такое Java9 modules. Это тоже полезно.

В школе мы делали такой эксперимент. Клали на магнит толстый лист бумаги. И потом
сверху сыпали металлические опилки. И трясли.

После этого опилки выстраивались как-бы в линии магнитной напряженности.
Вот твоя задача - рассечь катушку плоскостью
и насыпать виртуальных опилок.