mayton2019

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

С точки зрения современной инфо-безопасности docx является опасным. Макросы...
И даже если вы не будете открывать этот файл в Windows а только в pHPOffice - все
равно подстраховаться надо.

Коробочное решение удаленного доступа - это 99% SSH. Настроил и компилируй себе в командной строке.

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

Задача декомпозируется на 3 подзадачи.
1) Выбрать список строк из json
2) Перевести
3) Вставить перевод обратно.

По пункту (1), (3) есть API JSON path, Json Document или ему подобный. Почти для всех языков это уже решенная задача.

По пункту 2 лучше взять онлайн Rest API машинного перевода. Например от Google.

Здравствуйте, у меня возникла проблема с пониманием архитектуры dwh. Мне требуется сделать хранилище, но при проектировании получается, что у меня не одна единственная таблица фактов а их несколько. К примеру:
У меня есть таблица транзакций маркетплейса где указан: тип транзации, артикул, дата, склад, режим отправки и т.д.
Также у этой таблицы есть таблицы измерений (по артикулу, складу).
Но есть ещё одна таблица "Заказы" у которой указаны столбцы: статус заказа, артикул, дата, время доставки и т.д

Это нормальная ситуация. Для DWH-систем тебе нормализация не нужна. Можно денормализовывать.
Тебе нужно все таблицы поделить на 2 кучки. Первая кучка - это DWH-факты которые будут денормализованы.
Транзакции и заказы должны быть денормализованы и слиты в 1 ооооочень большую таблицу.
Она будет в центре снежинки.

Вторая кучка - это dimensions. Они будут лучами снежинки.

И не забывай сделать partitioning для главной DWH таблички.

Очень сумбурно автор описал. Многое из контекста непонятно. Вроде сам решил применить Postgres.
Ну ОК. Решил так решил.

И как по ПК можно выбрать 100 записей? Сделать 100 запросов? Или это не-ПК? Непонятно.

Вообще ни один производитель СУБД ничего не пишет про отклики. Это можно обсуждать
например в контексте приложения redis/web-server/dbms и там что-то придумывать и обосновывать.
Отклик - это сложная сумма которая состоит из множества слагаемых и не всегда БД там главная.

Вообще сама идея или само обоснование NoSQL (AWS Dynamo,. Azure Cosmos DB) идет как раз
от гарантий что вендор будет давать пропускную способность и отклик пропорционально вашей
оплате. Вы покупаете условно например какое-то количество RU (Request-Units) и все облако начинает
подстраиваться под вас таким образом чтобы соблюдать рост и независимость от размера данных.

Все что касается других (single-node, standalone) систем то они обычно быстро достигают пика
либо на диске либо на сети и после этого уже про отклик нельзя ничего говорить. Даже вкупе
с индексом все равно есть определенная деградация. И вы очень смелый человек если
сразу стали что-то стали чертить на базе реляционной системы.

Вообще если вы решили обсуждать например системную архитектуру то можно отбросить БД
и зайти со стороны философии и требований. Например лет 20 назад мы все знали что дисковая
подсистема на основе 1 магнитного диска обеспечивала скорость поиска блока в 15 мс.
Это так называемый random seek. И эта величина очень долго стоит как стена. Не
двигается особо даже для современных HDD. Механика чорт ее дери...

Для поиска любой записи в индексе вам надо сделать 4-5 seek по диску при условии что
мы диск полностью заполнили. Тоесть получается что быстрее чем 55 милисекунд мы не можем
гарантировать поиск записи по ПК для БД на магнитном носителе. Про SSD тоже можно
порассуждать. И в контексте бенчмарков в самом неблагоприятном состоянии.
Диск может быть заполнен на 99% например по размеру. Почему нет? Всяко бывает.

Вот так. Философски рассуждая мы можете вообще начать разговор. А уже какая там БД.
Tarantool, Cassandra, LevelDB это уже как-бы детали к системной архитектуре.

Ты задаешь вопросы в основном по абстрактным классам. А в них обычно нет ничего интересного.
И размер буфера это как раз особенности реализации в наследнике.

Для буферизации InputStream можно использовать такую обертку.

BufferedInputStream strm = new BufferedInputStream(new FileInputStream("file"), 128 * 1024);

Попробуй так:

create table "mytab"("COL" text, "CamelCase" text);

Автор мне кажется ты решаешь две разных задачи.
Первое - кольцевой буфер. Его не надо сортировать и его API
обычно очень простой. Это блокирующие push/pop или там атомарный
peek или проверка на пустоту. Они работают быстро и в этом их преимущество.

Если ты задумал очереди с приоритетами то посмотри например пирамиду (heap).

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

Разумеется можно формировать любые таблицы и документы. Только к ним нужно
относится с большим подозрением и проверять все в том числе и цифры.
При таком double-check я думаю что ИИ автоматизация теряет смысл.

Уж лучше формировать отчетность теми средствами как вы делали раньше.

А AI можете использовать для генерации писем.

Например x1y1z1=c1, а x2y2z2=c2

Вы не можете проверить саму формулу. Ее смысл не вытекает ниоткуда. По краейней мере для вас.
Об этом писал Курт Гёдель. Формула корректна потому что она нам дана таковой.

Но вы можете как тестировщик проверить ее реализацию. Обычными тестами или тестами свойств.
Property-Based-Testing (PBT)

Для PBT обычно вы подаете на вход рандомные значения и проверяете что выполняется какой-то
инвариант. Например если формула дает площать фигуры - то площать всегда не отрицательная.
Или Например если это площать круга - то она всегда будет меньше например площади
описанного квадрата. Это грубая проверка но она позволяет по крайней мере очень быстро
доказать что нет грубой ошибки.

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

Если типы данных у вас - вещественные то все формулы в тестировании проверяются не на точное
совпадение а с допуском (эпсилон) который вы описываете в asserts:

assert ( x * y * z == c, ε = 0.000001 )

для всей области определения x,y,z

В качестве фреймворков для Java/Scala есть соотвественно jqwik, scalacheck

Я-бы свел обе фигуры к объединению трапеций. Это легко сделать обходя все точки.
После чего булевы операции можно делать над трапециями.
Результат - снова объединить в фигуру.

Я думаю можно. Но действительно ли вам нужна нейросеть? Может Elastic Search или Sphinx
закроют все потребности?

А нейросети обычно выдают не точные а вероятностные ответы. И если с текстом еще хорошо
то с цифрами там могут быть сильные неточности. Поэтому как бухгалтерия это точно не пройдет.

Эту задачу можно начать просто с описи всего инвентаря в Excel файл.
Возможно на этом этапе будет достаточно учета.

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

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

Хочу напомнить что такие системы как ClickHouse ориентированы не на одиночные события
а на стриминг. Тоесть вы должны не просто логгировать а желательно просто потоком лить
много событий. Батч-режим вставки в кликхаус - это и есть ее оптимальный режим.

Вставка по 1 строке например раз в несколько секунд с фиксацией - будет не благоприятным
режимом работы для кликхауса. И наверное с плохим КПД. Подумайте о том что может
стоит все таки писать логи классическим способом и по истечении времени например
сбрасывать пачку к аналитические хранилища.

Приложение JD-Gui поможет тебе анализировать (декодировать) байткод class files.

https://java-decompiler.github.io/

Если речь идет о криптографии (дешифрование) то это отдельная тема. Но мне кажется
что тут пока не доказано применение шифрования. И это во много раз сложнее
чем декодирование.

Я вижу следующие пути оптимизации.
1) Мемоизировать (запомнить в массив) хотя-б первую сотню чисел. Тогда например для 120 чиссла
все считать не надо и можно делать перемотку вперед. Или мемоизировать с шагом. Тоже экономия.

2) Можно попробовать считать через золотое сечение (приближенно) если этого достаточно для
ответа.

3) Можно отказаться от java в пользу С++/GMP библиотек. Возможно расчет суммы будет быстрее.

Но вообще фибоначчи действительно не параллелится. В этом главная проблема.

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

Они и будут максимально непохожие поскольку принадлежат к разным кластерам.

Возможно есть лучшее решение. Но это вполне мне кажется приемлемое.

Не существует общих методик проверки БД на валидность. Только пользователь (бухгалтер)
может сказать рабочая БД или нет.

Попробуйте написать SQL скрипт который моделирует действия бухгалтера по валидации.
Например он смотрит какие-то последние операции за период и их балансы.

Применяйте этот скрипт автоматически. Сделайте штук 10 таких скриптов и метрика будет
например 80% от всех скриптов дали зеленый свет.