mayton2019

В феврале всегда 28 дней. Использую datetime.

Ну все стандартные библиотеки используют астрономические формулы. Там число дней
в году расчитывается по формуле високосного года. И вряд-ли эту формулу можно изменять.
Ну я такого не встречал нигде. Так что выход у тебя один - искать любую реализацию
этой формулы в python и вносить туда ручные корректировки.

Не пойму зачем тебе накое надо.

Технически - можно. Но MongoDb оптимизирована для хранения документов. И если вместо документов
туда складывать фильмы то может оказаться так что вы платите очень много за такие блобы которые
выгоднее держать на файловой системе или на сторедже. Привету пример. Если вы храните
документ в котором десяток текстовых полей и 11 поле - это блоб с фильмом длиной 1.5Гб то
получается что реально полезная для поиска и индексирования информация составляет
менее 1% (!) от общего размера БД. А все остальное - это балласт. Я как бывший базовик
привык что в таблицах БД лежит только полезная и нужная для SELECT ... WHERE информация.
Если эта информация не полезна для поиска - то ей не место в БД.

Хуже того что эти блобы будут вовлечены в процесс планового бэкапа. Даже если они не изменялись.
Может возникнуть кейс когда скопировать БД все таки надо. А копировать тяжело. БД уже превысила
пета-байт просто потому что кто-то захотел фильмы хранить рядом с данными.

Я не специалист конкретно по Монге но вот тут пишут о реализациях хранения блобов https://www.mongodb.com/developer/products/mongodb...

Почитайте.

У меня был комп Электроника БК1001 и ZXSpectrum которые работали на частотах 3 и 3.5 Мгц и никаких
проблем я не испытывал.

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

Прикладной код, при работе на низких частотах может видеть некоторые аномалии при работе с датой-временем
но это вообще не проблема процессора - а это проблема вашего прикладного кода. Тоесть вы должны были
писать код таким образом что даже припаркованный VMWare не должен крашить вашу бизне логику только
потому что часы резко прыгнули вперед на несколько суток например.

Других проблем вобщем-то не предвидится.

Вот посмотри может это поможет https://www.postgresql.org/docs/current/dblink.html

Докину 5 коп.

Я думаю что никто такую задачу вобщем-то не ставит. И никогда не поставит. Тут не то что Java
а я прошу прощения Cobol не могут никак заменить. Языку - уде более 50 лет возраста.
И хотя проблема касается в основном США, но это просто пример того что код живет очень долго.
У джунов уже седые бороды отрасли :)

Язык Rust вобщем-то создавалася как язых обще-системного программирования с правильным
механизмом управления памятью. И уже если ему и где-то конкурировать - так это там где нужен
отклик (игры или реал-тайм приложения).

Сильные стороны Java сегодня - это большой репозитарий библиотек на все случаи жизни.
Статистика по maven https://mvnrepository.com/ заявляет что 35 миллионов артифактов
имеется в наличии. Можно наверное найти любой драйвер или парсер или любую
либу поддержки сетевых протоколов. Большая часть из них проверена временем.
Production ready. Можно ли говорить о production-ready для Rust - библиотек я не знаю.
Пускай знающие отпишут.

Java - машина с развитым рантаймом. Рефлексия позволяет делать позднее инстанциирование
компонентов через конфиги. И этим очень сильно пользуются во фреймворках. Фактически
если проводить сравнительные анализы Rust и Java - мы встанем перед дилеммой - чем заменить
механику рефлексии в Rust? Создавать рантайм? Но это противоречит идеям системного программирования
или все таки принять как факт что Spring и ему подобные фреймворки принципиально нельзя
воспроизвести в языке статической компилляции таком как Rust.

Если-бы я сравнивал этот язык (Rust) - то ставил бы ему в одну весовую категорию Nim, Zig и прочие
языки "пост-плюсового" периода. И в качестве задач я-бы ставил - разработку игр и драйверов
для операционок. Вот там и тестируйте.

Самому финтеху не всегда нужен рилтайм. Иногда - даже вообще не нужен. В батч-джобах биг-даты
и python нормально работает. Специфика своя там. А критичные части бигдаты (Apache Arrow, Databricks Photon)
- и так переписаны на сях чтобы быстринько search + join работал. В стриминге биг-даты - тоже вобщем-то
CPU не сильно критичен. Там и Node и C# тоже годится в качестве языков. Вобщем задачи - I/O bounded.

Postgres очень быстро паркуется, если надо. Кажется pg_ctl там с аргументами или services stop postgresql.
Вот сделай скриптик.

В парадигме современной BigData, вы должны писать все что приходит на вход.
Как это там обзывают.... ELT (Extract, Load, Transform)
Никто не знает наперед какие данные понядоабятся - поэтому фиксируйте весь raw
трафик. Потом - отфильтруете. Построете материализованные views. Но главное что данные
будут.

Учитывая что clickhouse - column oriented - безразлично 2 поля из 2 выбирать или
2 поля из 2000.

Если хранилище у вас все таки переполнится - (со скоростью 2.5 Гб в день) то тогда уже почистите те
колонки которые стали объективно не нужны после например пары месяцев эксплуатации.

Почитай про conda https://docs.conda.io/en/latest/
Там есть коробочные решения для управления версиями окружения Python/GCC e.t.c.
Поможет или нет - я не знаю. Я использовал это только для Python.

Скачивать какие-то частные версии проектов и компилировать их локально и устанавливать - это
риски. Можно поменять окружение так что потом хрен вернешся назад.

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

Все настоящиее DLL-файлы имеют сигнатуру. Это магическое число (обычно 2 или 4 или 8 байт) которые прописываются в заголовке данного типа и никогда не меняются.

Для DLL я точно не помню но кажется совпадает с Windows-executable. Два символа 'M', 'Z' будут сигнатурой.

Теперь задача - найти все DLL-файлы на дисковой системе и найти один файл-уродец который этой сигнатуры
не имеет. Это и будет твой файл.

Для любого программиста - это задача на 10-20 минут.

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

Поищи по ключевому слову Stable Diffusion.

Ну для floating point чисел ничего интересного не происходит. Результат будет - бесконечность (Inf).
И эта бесконечность - это вполне себе реальная константа для таких чисел.

Очереди могут обеспечить exactly once. По крайней мере в настройках у многих есть такой параметр.

Дедубликация - это слишком жесткое требование. Оно требует хранения ключей в неких индексах
которые должны быть консистентны. Это - ближе к базам данных. А очереди обычно используют
достаточно простые и плоские структуры (файлы) для хранения месседжей.

Декларация класса и реализация его методов могут лежать в разных файлах исходного кода (*.h, *.cpp)

До postgresql версии 13, если я не ошибаюсь, индексы были в полтора, а то и два раза больше. У нас на проекте версия 9, если не ошибаюсь, там индексы добавляют к памяти иногда по 5 гигов. Нормально ли это? Я слышал что индексы должны быть в пределах мегабайт, а не гигабайт.

Работаю с базами данных давно. Начинал с Oracle9i.
Большая часть индексов базируются на B+Tree. Хотя в последнее время в эпоху RocksDb/Cassandra/Tarantool
появились более интересные стурктуры такие как LSM-tree. Они по скорости записи более эффективны.

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

В Оракле есть положительный эффект от периодической перестройки индекса (alter index rebuild).
Этот эффект временный и обычно связан с фактором кластеризации. Его очень любят новички и
часто сам вопрос является троллингом Oracle-профессионалов. Но это было лет 20 назад. Щас
в эпоху облак всем стало пофиг.

Всегда ли не кластиризованные индексы хранятся в оперативной памяти или это как-то можно регулировать?

Не знаю откуда ты такие вот факты черпаешь. Конечно лучше всю базу данных положить в память.
Но база обычно многократно превышает память и мы довольствуемся страничным кешем (page cache)
или buffer pool в других системах. И все они работают по принципу LRU (хранения наиболее горячих
блоков диска). А будет ли это таблица или индекс или еще какойто подвид объекта - это как повезет.
Во всех DBMS есть мониторинг этого страничного кеша. Вот посмотри что у тебя там лежит в час
наибольшей нагрузки. Это и будет самый правильный ответ на твой вопрос. И главное - практически
подтвержденный.

Читал, что бывает так, что индекс в таблице индекса хранит сразу данные определенных столбцов, а не ссылки на эти строки в основной таблице. В каких случаях и почему так бывает?

Приводи ссылки где ты читал потому-что в твоем пересказе получается мистика. Индекс обязан хранить
копии индексируемых столбцов. Иначе-бы поиск вообще не работал.
Если ты строишь композитный индекс по 3 полям то он и будет физически хранить 3 копии этих полей
и ROWID (физический указатель на позицию в таблице для строки). И при определенных условиях
оптимизатор может выдавать данные не из таблицы а прямо из индекса если в SELECT запросе
достаточно данных в индексе. Этим часто пользуются для оптимизации.

Есть альтернативные DBMS наподобие Amazon DynamoDB где индексов нет но есть полная реплика
таблицы которая по другому кластеризована. Динамо считает это индексом хотя с точки зрения
классической DBMS это просто маркетинговый обман.

UPD: R+Tree

Это - тяжелая книга для новичка. Начните с Вирта или Седжвика.