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

Ответ - да, если будет ровный шейп.
Те выравнивание все равно нужно.
Хотя бы на уровне карточки товара.
Нужно, чтобы сделать ровно срез и потом уже парсить  на кривых.

Иначе приведет к тому, что чтение будет везде выглядеть через вот так:

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

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

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

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

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

MySQL BitValue =)

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

(а написать свою - на 3)

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

Миграция тоже весело =)
Миграция 50 гигов

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

> Да, могут быть баги но зато это уже будет работать и приносить какой-то профит а тесты можно будет написать позже

М-мм... Интересный подход к разработке. Мягко говоря. 😊

Мы в Озоне используем PostgreSQL. Не очень понимаю, зачем писать свою СУБД

(когда уже сформируется решение и архитектура)

Тогда будет поздно, так как сколько придется миграций делать =)? А кто их валидировать будет, что цвет не стал ценой?

И что кто-то не купил миллион черных скалок по 0 рублей=)

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

Если это поисковой движек, то как правило пишут свой на базе Lucene. Само по себе хранение в in memory не особо и нужно

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