А многопоточной поиск по выравненным данным не)? Бинарный, ещё тоже очень

неплохо бы если было бы выровнено

выравнивание данных это уже довольно значительные затраты по памяти (да и смысла нет если считываться будут последовательно и даже не по байтам а регистрами по 64бита или даже 128 бит если взять wasm simd). То есть там буде все будет упаковано максимально сжато под конкретный бизнес-кейс иначе для хранения 10млн товаров где у каждого товара есть еще цвета а у каждого цвета размеры а у каждого размера история изменения цены и продаж за каждый день - тут каждый лишний байт для выравнивания будет стоить гигабайт (при хранении истории за год)

Но может ли JS работать с невыровненными данными? 😉

ну я же буду работать с типизированным массивом и считывать не по одному байту а по 8 байт (Float64Array) и дальше уже распаковывать считанное число через битовые операторы. В общем это пока временные планы если будет неудобно или медленно то сразу же перейду на wasm так как уже есть с ним опыт (и еще лучше на simd с 128битными регистрами). Меня сейчас больше беспокоит не эта распаковка а необходимость жонглировать отдельными 4гб буферами и трансляцией адресов из-за невозможности аллоцировать один линейный кусок памяти в 20гб

а что там. Выровнять эти буфера так же. И тогда жонглирование будет просто на % chunkSize

На этом месте я бы просто взял колоночную БД вместо того чтобы писать её самостоятельно. 🤷‍♀️

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

Control freak, huh? 😉 Тяжело так жить, приходится всё делать самому, да...

Скорее поиск более простого решения под конкретный кейс. Выбор субд это история на месяц - по каждой бд нужно изучить огромную документацию, провести тесты, разобраться во всех нюансах конфига (и флагах при сборке) и все равно окажется что есть какие-то ограничения или что эта бд потребует на порядок больше оперативки или будет жестко виснуть из-за свопа и огромного количества рандомных чтений из диска. А тут я сразу могу взять и тут же начать писать код на js который по 5-10 типизированным массивам по 4гб по по битам-байтам-оффетам запишет нужные данные в и сервер который будет делать поиск и чтение этих данных под конкретный (достаточно простой и узкий) бизнес кейс

Т.е. для выбора БД тесты проводить нужно, а для написания своего кода — не нужно? 😉 Кроме того, БД будет "автоматически" включать в себя тот самый ни на чём не написанный скрипт для подготовки массивов в нужном формате.

тут разница между белым и черным списком - решение взять бд это подобно черному список - куча всего уже реализовано и протестировано но кто знает что эта бд эффективно решает конкретно твой бизнес-кейс? Для этого нужно потратить кучу времени чтобы изучить огромную доку, конфиг и кучу-кучу нюансов чтобы правильно настроить бд только для начально проверки занимаемой памяти и скорости (иначе можно сделать неправильные выводы) для того чтобы сравнить с другими бд. Ну и конечно же никто не отменял дилемму выбора и метания между подходящими бд. А вот свой код это типа белый список - не нужно тратить месяц чтобы найти/разобраться в бд - ты сразу пишешь максимально прямолинейный код для решения конкретного кейса. Да, могут быть баги но зато это уже будет работать и приносить какой-то профит а тесты можно будет написать позже (когда уже сформируется решение архитектура)

> Да, могут быть баги но зато это уже будет работать и приносить какой-то профит а тесты можно будет написать позже М-мм... Интересный подход к разработке. Мягко говоря. 😊