iqhater

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

Размер одной записи должен быть порядка 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.

1. Через сетевой протокол на API сторонней программы. (обычно используют JSON RPC, REST, GRPC)
2. Через вызов клиента другой программы в командной строке из вашего приложения и парсинг вывода.
3. Вызов функций SDK, предоставленного сторонней программой (обычно через cgo).

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

Можно вообще без JS, только стилями и невидимым чекбоксом, но разметка должна быть специфической:

Это нормально. Мозг развивается практикой и процесс этот мало того, что не быстрый, так ещё и бесконечный.

Про Реакт не скажу, но в Ангуляре (если мы о 2-м - 4-м) очень важной зависимостью является RxJS. Это сама по себе очень полезная вещь.
Более того, я бы посоветовал вместо Ангуляра и Реакта посмотреть на замечательный фреймворк CycleJS, который построен на идее RxJS. У него очень простая, чистая и мощная архитектура. Если её освоить - многое увидится в новом безоблачном свете. Главный минус CycleJS в отсутствии готовых комплектов вроде Material для Ангуляра. Это скорее инструмент, чем готовое решение. Но в обучении это лишь плюс - больше простора для практики.

Кроме того, полезно освоить концепцию функционального программирования, насколько это возможно в JS. Идею иммутабельных (персистентных) структур данных. Основные функции высшего порядка (вроде map, flatMap, foldLeft/reduce и др). Функциональную композицию и point-free (tacit) стиль. Очень рекомендую посмотреть на библиотеку Ramda. Всё это не является обязательным пререквизитом для Ангуляра и Реакта, но может существенно повлиять на то, как Вы пишете код.

CycleJS и Ramda - точно помогут в более углублённом изучении JS.
Angular очень хорошо учить по книге ng-book 2.

Их не нужно сравнивать. Эти подходы дополняют друг друга. Внутри методов класса ты как ни крути пишешь процедурный код.

Например так

//На N промежутков
step:=(end-start)/N
for n := 0; n < N; n++ {
    from := start + n*step
    to := from + step
    group.Go(func() error{ 
         return process(from, to)})
     })
}

Честно говоря не совсем понял в чем проблема, просто запускайте горутины в цикле, который будет иметь кол-во итераций зависящее от start-end.

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

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

Еще важный момент - правильный выбор задач.

Задача не должна быть слишком сложной - иначе неудачи отобьют желание учиться.
Задача не должна быть бессмысленной - найдите какую-нибудь простую задачу, которую вы делаете руками постоянно, файлики переименовываете, запятые в экселе лишние удаляете ручками,... вроде простые задачи руками легко, но и польза от автоматизации будет.
Выбирайте удобный и приятный для использования именно вам инструмент, а не то что советую откружающие. Одно время все говорили - бери bash крутой скриптовый язык, мегакруто, мегаудобно... ага, но мне почему то на php скрипты общего назначения писать получается гораздо удобнее, и читабельнее абракадабры.

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

Чтобы научиться писать код, надо писать код. Да, даже если не получается просто брать и решать задачу, даже если ее решения не видно.

Нет, не стоит совсем. Лучше хорошенько подтянуть нативный JS и переходить на React/Vue.