mayton2019

Декларация класса и реализация его методов могут лежать в разных файлах исходного кода (*.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

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

Мне не удавалось добиться от GPT генерации корректного кода под ассмблеры fasm/nasm.
Видимо все таки языковые модели обобщают языки настолько что не могут придерживаться
строгих правил при генерации. Может отсутсвие строгих правил - это как раз сильная сторона
этих моделей. В противном случае мы вернулись бы в эпоху Prolog-программирования и формальной
логики где программы бы всегда компилировались и работали но никакой фантазии или обобщения
из двух программ мы не получили-бы.

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

Я никогда не расчитывал на чяты в части чистого написания кода. Но например в сборе информации
эти чяты вполне себе полезны.

Как Jit Компиляторы обнаружат недостижимой код и лишние проверки?

Если мне не изменяет память, JIT компиллятор компилирует java-метод целиком. Переводя byte-code в машинный код для x86 например.

А то что спрашивает автор - это задача основного компиллятора который язык Java переводит в байткод.

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

ли Космические Лучи, в Ram попали, что тогда будет?

Программисты 20-го века работали в условиях глючной памяти (когда были ЭВМ на лампах и на тразнисторах)
и обрабатывали специальное прерывание типа "глюк в ячейке памяти".

С точки зрения современной парадигмы разработки - это невозможно. Никакой прикладной
программист не ставит себе задачу отслеживания целостности памяти. Это как-бы не его
уровень. Мы предполагаем что память надежна и всегда корректна. А иначе ОС выпадает
в синий экран и никаких принятий решения мы все равно не сделаем а облачные балансировщики
примут свои решения когда хост выпадет из сети.

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

Рассматривать такие случаи в топике Java - бесполезно и контр-продуктивно. Давайте
их рассматривать в топиках инфо-беза и операционок.

По идее minikube и kubectl достаточно. Но если речь идет допустим о пользовании на Windows - то там надо внимательно читать microsoft инструкции. У них всегда много нюансов.

Ну вот первое значение будет 0x62 и второе будет 0x22.

Поскольку Android - это тоже разновидность Linux то тебе надо изучать следующие темы.
- программирование под Linux. Безопасность памяти и процессов.
- язык Си.
- обратный инжинеринг кода.
- архитектура процессоров семейства ARM
- архитектура виртуальный машин ART и Dalvik байткод. Языки Java и Kotlin. Android NDK.
- структура типичного Android приложения. Стек.
- структура упаковки Apk. Процесс деплоя.
- безопасность Android-приложений. Контейнеризация.

Изучай все. И не вздумай углы срезать! А то будешь - маленький свинтус и лентяй.

Большинство преподавателей скорее всего проигнорируют такие требования.
Обучение в первую очередь ставит целью - научить понимать алгоритмы и применять
их на практике. Искать ошибки. Это такая себе пирамида приоритетов.

Стандарты С99 и С11 это какая-то вторичная чепуха. Если вы умеете писать с С99 то
для вас не будет проблемой писать что-то в следующей версии стандарта. Это как у водителя.
Если на 5-скоростной коробке передач ездил то и на 6 скоростной тоже поедет без проблем.
Акцентировать на этом внимание никакой преподаватель не будет. Это не наука. Это - факультатив.

Сам почитаешь короче. Если у вас такая душная вакансия и такие душнилы-работодатели что им
прямо нужен какой-то стандарт - то это не задача 1 дня. Это длительный процесс. Я видел различные
попытки переписывать ентерпразы с одной версии языка на другую. Это все выглядит очень плохо
для организации и скорее всего хеш-тег С11 появился просто по ошибке рекрутера. И его можно
в данном случае просто не брать во внимание.

А почему ты решил что парсинг это узкое место? Ты пишешь информацию в базу. Тоесть у тебя конвейер операций.
И я думаю что до того как начинать оптимизацию, надо собрать логи по таймингам. Сколько милисекунд занимет
чистый парсинг и сколько запись в БД.

Попробуй еще простой параллелизм. Разбей эти 8000 файлов на 2 фолдера по 4000.
И запусти 2 python-процесса. Будет допустим не 5 часов а 3 часа. Уже лучше.
Продолжнай дробить пока удельная скорость обработки не деградирует.

У тебя должна быть shared memory для всех потоков-участников этого процесса.
И один из потоков (главный) должен заранее планировать что какие-то части
файлов должны находится в shared memory в нужное время. Технически
для C/C++ это решенная задача. Тут единственное что интересно - это
обсуждать логику главного потока. Тоесть когда и в какой момент времени
главный должен решать что подгружать. А может он передумает и решит
что надо срочно выгружать потому что сюжет игры меняется. Или игрок
будет бегать между 2 левлами через портал и постоянно перегружать
уровни туда-сюда.

Ну для дисков у меня обычно есть такая формула. Я считаю соотношение объем/цена.

К примеру Kingston SSDNow A400 480GB 2.5" SATAIII 3D V-NAND стоит 25$ тоесть считаем
25$ / 480Gb = 0.05 $/Gb = 5 центов за гигабайт.

Если взять самый топовый SSD по объему то он может оказаться очень дорогим. Непропорционально.

Поэтому. Беру 2-3 разных диска и 2-3 разных производителя. Получается табличка. Сортирую по цене за гиг и
в топе обычно висят парочка кандидатов на покупку. Очень часто бывает что самые большие
образцы оперативной памяти и дисков стоят дороже чем середнячки. Тоесть может быть
выгодно купить 2xHDD на 4 терабайта чем 1 на 8 терабайта.

Здесь еще можно учитывать занятость слотов и энергопотребление но главная формула уже
есть и от нее можно отталкиваться.

Самая интересная идея для ИИ - как разбогатеть очень быстро и без рисков.

Идея - нужная. Я гарантирую это (С)

Такой функции скорее всего не существует. Тут как в парадоксе про пудинг. Чтобы узнать хороший он или
нет - его надо сьесть. Вот чтобы узнать длину машинного кода нужно провести этот код по всем стадиям
компилляции. А судя по внешнему виду это не С++. Это DotNet поэтому здесь будет минимум 2 стадии.
DotNet => MSIL. И потом уже в машинный код. Подозреваю что длина машинного кода будет
зависеть от версии DotNet, от разрядности платформы 32/64 и от целевой железной архитектуры
Intel/ARM e.t.c.

Вот такое получается уравнение со многими неизвестными. И его решить можно только практически.
Компиллируем. Смотрим. Считаем. Если нудно считать - автоматизируем подсчет функции.

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

Тебе можно вообще все три таблицы объединить в одну. И сделать partitioning by range по полю created.
При такой архитектуре все запросы у вас пойдут в одну таблицу. А поле push_type станет просто ненужным.
Или можете сохранить его чтобы различать бывшие типы строк push/push_actual.

По partitioning - посмотрите примеры как тут пишут https://dev.mysql.com/doc/mysql-partitioning-excer...

Лет 10 назад можно было на барахолках купить стриммеры HP. А кассет было много на предприятиях. Некоторые впоследствии на радиорынках продавались еще в нераспечатанном виде. Производитель лент гарантировал что-то вроде 15 лет хранения информации (при условиях правильной температуры и влажности). Это - самые длительные сроки что я видел. Размер касеты у них кажется был 20-40Гб.

Еще Verbatim продвигал какие-то особо прочные DVD+R диски с алмазным покрытием. А по объему кажется это были 4.7G Надо посмотреть я не помню точно. Вобщем надо искать + еще покупать пищущее устройство.
А сейчас даже ноуты продают уже без DVD привода.

Я у себя дома храню на двух HDD дисках серии WD-Green. Конечно непонятно что делать если от времени сгорает
контроллер но вроде как 2 сразу в один день не должны сгореть.