mayton2019

неприлично долго думаю над тем что нужно вынеси в отдельный пакет, а что достаточно вынести в отдельную структуру

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

Поэтому просто откажись от декомпозиции. Пиши сначала прототип в олимпиадном стиле. Тоесть функция
main - и погнал писать как чукча. Что вижу то и пою.

И после того как ты напишешь 1000 строк например к тебе придет понимание как следует декомпозировать.
И к этому моменту у тебя будут ДОКАЗАТЕЛЬСТВА выгодности твоего дизана. И теоретические споры можно
уже исключить.

Если ты начинающий - то лучше написать работающее приложение. А архитектура должна быть мотивированной.
Вот в книжках по шаблонам проектирования так и пишут дескыть motivation.

А если на пустом hello world делать архитектуру - то оно выглядит как-то странно. И принцип KISS/Yagni
никто не отменял. И бритву Оккама.

Когда-то давным давно использовали logrotate. Эта утилита просто дробила лог на дневные и часовые
и прочие доли. Это позволяло искать быстрее. Если ты заранее знаешь что событие произошло например
за последние сутки а не за последние 10 лет к примеру. Но logrotate может не работать под Windows.

Коробочного решения для твоего вопроса я не знаю. Кроме Elastic ничего не приходит в голову.

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

Вообще тебе нужен разработчик. Я думаю что дешевле всего трекать отдельные логи по событию event:login к примеру. Я так делал для сужения поиска. Для библиотек log4j это конфигурируется на уровне приложения.
Там как-то добавляется appender + rule.

Тут пишут https://go.dev/tour/methods/9 весьма сухо.

Interfaces
An interface type is defined as a set of method signatures.
A value of interface type can hold any value that implements those methods.

Судя по всему Google не особо заинтересован описывать детали реализации интерфейса.
Возможно на реализацию нет спеки. И Google планирует в будущем ее изменять.

А попробуй замени это
{{$projectID := .Note.ProjectID}}
на константу
{{$projectID := "00000011112222" }

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

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

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

Поскольку речь идет об .exe то скорее всего автор хочет запускать без command-shell окошка.

Вот так.
start /B программа.exe
Ну и цикл там сделать внутри.

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

id name     path  parent
-----------------------
1  Беларусь 1     null
2  Россия   2     null
3  Минск    1.3   1
4  Москва   2.4   2
5  СПБ      2.5   2
6  Невский  2.5.6 5

Ну а дальше - select... connect prior и получим ранжированый курсор по дереву. Там-же будет
доступно виртуальное поле level. И обходом этого курсора можно сделать JSON документ.
Если level растет - то увеличиваем indentation и открываем вложенный элемент соотв.

Если go-lang поддерживает stremable json writers то даже лучше.

Попробуй замени any на bytes.
map<string,bytes> property = 1;

Читай не по строкам а по символам.

Обычно там где танцует Go - там рядышком docker/kubernetes. Тоесть не проблема очень быстро поднять тестовую БД, наполнить ее данными и сразу прогнать все тесты по DAO.

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

Ты переусложняешь. Сделай просто массив строк.

{
    "data": ["string"]
}

Это покрывает все твои кейсы с 1 строкой и с null. И маппинг упрощается.

Немного бухгалтерии. Если взять по максимуму.

Размер одной записи должен быть порядка 60 + 32 +8 = 100 символов (байт для простоты)

При 50 млрд записей объем хранимых данных должен быть порядка

50 000 000 000 * 100 = 5 000 000 000 000 = 5 триллионов байт.

В дисковом хранении это будет примерно 4.5 терабайта. Задачка для in-memory неподъемная. Нужен диск + мемори.

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

Вобщем нужна дисковая БД которая встраивается в приложение. На требование менеджеров которые запретили использовать БД забейте. Они ничего не понимают. Делайте БД встраиваемую в приложение. В качестве таких (встраиваемых систем можно поробовать) LevelDb, BerkeleyDb, RocksDb. Они поддерживают индекс класса B+Tree и это даст возможность искать группы записей по одному ID. Для этого класса систем любую запись можно найти за 4-5 дисковых IOPS. Если какдый IOPS стоит 15 мс (это я так мерял свой собственный магнитный HDD) то любой поиск группы ключей для TTFB будет порядка 15 * 5 = 75 милисекунд. Ну если вы поставите SSD - то быстрее.

По поводу предложений хранить в файлах. До того как обсуждать это - надо уяснить требования по времени отклика. Сколько секунд вы согласны ждать - насколько можно и партицировать (или шардировать ваш файл).
В простейшем случае мы делим большой CSV файл на 512 partitions по хешу от ID и получаем соотв время фулл-скана всего файла поделенное на 512. Дальше - играйтесь с этим параметром партишенинга выводя его на доступный уровень отклика. Из недостатков - будет россыпь файлов. Надо почиать документацию на вашу файловую систему (ext4?) и тюнить ее так чтоб она не сдохла от такого числа inodes.

Я поддержу оба сценария. И с встраиваемой БД и с файлами. Но с БД надежнее т.к. есть транзакции а файлы у вас могут быть в крешнутом состоянии долго. И вы об этом ничего знать не будете.

По поводу Parquet. Не взлетит. Скорее всего индекс по данному типу файла - это совсем не то что вкладывают туда релационные системы. Обычно Parquet/Orc/Delta вкладывают в индекс смысл - отбрасывания тех полосок данных (stripes) которые бесполезны при чтении всего файла. Такой индес - обычно просто либо range-признак либо карта Блума. И в случае с range - дает эффект на сортированных данных. Для прочих - будет бесполезно т.к. фулл-скан все равно обеспечен. А если фулл-скан то зачем тогда вообще индекс.

Вобщем для дизайна архитектуры нам нужны цифры. Средние длины по колонкам. И я-бы еще запросил кардинальность по полю ID.

Есть строка джсона длинной 25000+ строк.

Это какая-то ерунда. JSON - это никакая не стркоа. Это JavaScript object notation. Собственно это заложено в аббревиатуру. И работать с ним надо через API который работает с JSON.

Игры со строками ни к чему хорошему не приведут. Пропустишь escaping и будет просто зря потраченное время и забаговнный код.