ок, спасибо за совет, кстати а биндинги v8 позволяют вообще пробросить массив длиной больше 4гб или это ограничение касается не только внутренних жс-массивов но и внешних? Тогда получается что этому бинарному модулю нужно будет пробрасывать не массив а функцию чтения и записи по индексу и соотвественно возникает следующий вопрос - насколько это будет медленно если это по сути получается интероп с с++ кодом, не получится так что цикл где на каждой итерации вызываться с++ функция будет на порядок медленнее?

... то ОС освободит все выделенные ему ресурсы. 🤷‍♀️

Ну так там же что-то было важное в этих 50ГБ, возможно, в этом и прикол, что освободит, и кто-то в них начнет писать.

А, в этом смысле "улетело в трубу"! Тогда нужно брать язык без NRE/NPE, но это уже далеко за пределами изначального вопроса.

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

Я не думаю что лимит 4GB просто так

Тогда тебе ram диск + BD которая умеет, это явно не ручное занятие

Думаю, этот вопрос дальше обсуждать лучше в @webnya_chat

Скорее всего, тщательно настроенная SQLite. 😂

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

:) Возможно.
Но ты все равно сделаешь половину того, что делает DB.
Только поддерживать это невозможно будет.

А что значит "вручную размеченные под конкретный кейс данные"? Какие "способы работы с ними" требуются?

А то я знаю "вручную размеченные данные" только в контексте Supervised Learning... 😃

Я думаю там строгая моделька с прибитыми оффсетами+размерам (как большинстве реляционках).
Где ты можешь просто по id * size + columnOffset узнать данные

По этому он не хотел 333 буфера, чтобы оффсеты не пересчитывать

Давайте не будем гадать и просто дождёмся ответа @xbgnx ? 😊

ну это значит что я сам определяю структуру того куска памяти (пара десятков гигабайт) - как и в каком виде там будут хранится таблица соответствия id и адреса, в каком промежутке будет сжат этот адрес (типичного указателя на 8 или даже 4 байта много), как будут организованы сами товары для быстрого поиска, в каком числовом промежутке будут сжаты числовые значения цены и количества продаж (типичного числа в 8 или даже 4 байта много и например достаточно 20 бит чтобы сохранить цену от 0 до 1млн и точно также можно сжать количество проданных товаров), будет ли это фикс значение или переменное (например LEB) ну и главное какая будет организация полей (сразу все поля товара подряд в памяти или разбиты на отдельные участки) чтобы нужные фильтры фильтровали только полезную инфу и процессорные кеши не забивались ненужными для этого фильтра полями и т.д

Тогда советую взять какой-нибудь rust, написать на нем эту BD полностью, пробросить api которое просто будет выполнять как раз эти транзакции по поиску, сортировке и тд, без вообще захода в JS  :)

> как будут организованы сами товары для быстрого поиска

Ну и как же? 😊

зависит от того как по ним будет происходить поиск и чтение - в общем типичная дилемма array-of-objects vs object-of-arrays и в целом тема всяких там сжатий значений и флагов (битмап-фильтры) под нужный поиск