mayton2019

Варианты. Можно преобразовать JSON в JSON-Lines (где каждая строчка - это независимый JSON документ представляющий строку таблицы).

Потом загрузить это в spark dataframe

Using Scala version 2.12.15 (OpenJDK 64-Bit Server VM, Java 11.0.17)
Type in expressions to have them evaluated.
Type :help for more information.

scala> val df1 = spark.read.json("/tmp/emp.json")
df1: org.apache.spark.sql.DataFrame = [_corrupt_record: string]

И имея фрейм либо сохранить в CSV либо подключить драйвер JDBC записать прямо в базу.

Еще во фреймворке Pandas есть опции загрузки из JSON. Но я сам не спец в пандасе поэтому
точно как сделать не скажу.

Вот. Еще я помню где-то писал утилиту чтоб произвольные JSON конвертить в JSON-lines.

Короче способов - масса. Беда как обычно в вопрошающем. Что он готов для этого установить
и что выучить.

Те которые на 100Гб можно подарить детям на игрушки. А для больших (несколько терабайт) - моешь посмотреть SMART информацию (как советуют выше).

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

Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.

Ты напомнил анекдот когда женщина приша к урологу и жалуется что у мужа дескыть "одно яичко ниже другого. Непорядочек.."

Вобщем перфекционизм хорош в меру. Если ты читал об организации индексов на основе B+Tree (практически везде) во всех DBMS, то ты должен был читать о том что среднее заполнение листовых блоков обычно равно 75% от размера блока. Это связано с возможностью оперативно делать insert новых ключей и значений. Если ты, используя какие-то утилиты специально выровнял заполнение блоков - то индес становится медленным для будущих вставок. Каждая вставка продуцирует операцию split (тяжелая операция) и пока не посплитятся все листы - перформанс будет плохой.

Если исходники хранит - то наверное git подходит.

Если фильмы и музыку - то наверное надо другой подход обсудить. Вобщем ты мало информации сказал.

Тяжелую задачку ты зацепил. Я не знаю есть ли в классическом Win32GDI такие функции чтоб вдоль curve печатать текст.

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

https://learn.microsoft.com/en-us/windows/win32/gd...

Для exe-шников еще в 90-е создавались не архиваторы а всякие "упаковщики". Из таковых я помню UPX https://upx.github.io/

Чтобы понять async нужно в принципе понимать мультизадачность.

Есть два вида мультизадачки. Первая базируется на preemptive multitasking. Это классика на потоках (Threads). Подходит для приложений где есть нагрузка на CPU и мало I/O. Пример таких приложений - рендеринг 3Д графики. Майнинг.

И есть второй вид когда есть много I/O а нагрузка на процессор - малая и ее можно считать неизменяющейся. Как обработчик событий. Ее делают на async/await. Или еще на мультиплексированном I/O. Она подходит для веб-серверов. Яркий пример - nginx. Или системы обрабоки MQ. Сокет-серверы. Файловые серверы и прочее.

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

UPD: Fixed

Весят чет многовато даже после компрессии.

Все очень просто. Зависимость размера от ширины - квадратичная.
Это означает что размер картинки растет не линейно а в квадрате от
одного из измерений. И JPEG/WebP здесть не помогает т.к его алгоритмы
не меняютс своих свойств от размера. Обычно ты задаешь коэфф сжатия
или он берется по дефолту. Ставить более сильное сжатие нет смысла
т.к. портится качество мелких деталей. А если портить - то нахрена
увеличивать размер?

Пример такого расчета в сыром размере RBG байтов:

Разрешение FullHD 1920 x 1080 = 2073600 pix = 2073600 * 3 = 6 220 800 bytes
Тоже самое в два раза больше в поперечнике 3840х2160 = 8294400 pix = 24 883 200 bytes
Итого размер стал в 3 раза больше. Для 8К разрешения ситуация станет хуже во много раз.

Поэтому увеличивать разрешение нужно очень осторожно.

В связи с повышенной влажностью моя клавиатура стала делать повторные нажатия клавиш. К примеру нажав какую либо букву она нажимается дважды, изредка трижды. Денег на покупку такой же клавиатуры нет, а к другой я буду долго привыкать.

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

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

Вобщем верно говорят. Купи клавиатуру. Потому что трата времени и мозго-топлива на фиксацию этого аппаратного дефекта займет у тебя слишком много времени.

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

Это +16% к частоте. Даже не заметишь. А риски что будет нестабильно есть. Я-бы ничего не делал. Оставил как есть. Тем более что перформанс в играх зависит не только от памяти а еще от CPU/GPU диска.

В современном мире, если вы используете bind-variables или нормальные ORM-фреймворки - то вам ничего нигде не надо экранировать. Пользуйтесь коробочным продуктом и не изобретайте своих SQL билдеров.

Не знаю как в Го-шке. Но в сях есть два базовых подхода к работе с текстовой графикой.
Первое - это печатать управляющией символы (backspace) чтоб стирать предыдущие.
Так например работает текстовый архиватор Rar пока печатает прогресс. Все это на уровне STDOUT.

Второе - это использовать библиотеки наподобие ncurses. Это такая Rich-графика в тексте.
Можно делать красивые цветные текстовые таблицы наподобие TurboVision. И даже интерактивность.
Диалоговые окна. Edit boxes e.t.c.

Тяжелая задачка тебе прилетела. Я-бы вообще не советовал ее делать. Много ручной работы.
И эффективность решения сильно зависит от того как выглядит документ. Что там внутри?
Текст? Таблицы? Или сканированные фото.

По поводу парсинга pdf на python - вот был вопрос в стековер https://stackoverflow.com/questions/18755412/parse... можно начать с этого.

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

Какая тут схема?