Как хранить и иметь быстрый доступ к данным?

[webgraph]

Все от величин зависит.
Если скажем взять обычные целые. Максимальное целое число, которое может быть точно представлено в js -
Number.MAX_SAFE_INTEGER = 2**53 - 1 = 9,007,199,254,740,991
16 разрядов однако.
Может этого будет достаточно?

Если бы было достаточно, тогда не приходилось бы прибегать к BigInt.

[webgraph]

В конец дописать - массив однозначно быстрее.

Чаще всего Array действительно быстрее)

class ItemList {
        next = null;
        prev = null;
        operation;
        constructor(operation) {
            this.operation = operation;
        }
    }

    class List {
        first = null;
        last = null;
        constructor(){}
        add(item) {
            this.first ??= item;
            item.prev = this.last;
            if(this.last)
                this.last.next = item;
            this.last = item;
            return this;
        }
    }

    const list = new List();
    const arr = [];
    const NA = 1_000_000;
    let na;


    na = NA;
    console.time('list');
    while(na--) list.add(new ItemList(na));
    console.timeEnd('list');


    na = NA;
    console.time('arr');
    while(na--) arr.push(na);
    console.timeEnd('arr');

Насколько корректно проведено тестирование?)

[webgraph]

memberOperations = new Map ()

Ключом является UUID участника
Значение - такой объект
{
operations: [<n.op>, <n.op>, <n.op...] // номера операций м массиве operations_objects с этим участником
values: new Map();
}

ключ у values - values из операции
значение - [<n.op>, <n.op>...] - номера операций м массиве operations_objects с этим участником и с этим values

voraa, а на сколько большой может быть такой массив данных?

[voraa]

voraa, а на сколько большой может быть такой массив данных?

Какой именно?
Если массив operations, то это зависит от ваших условий. Сколько там операций у вас идет?
Про Map точно не знаю ограничений, но пару миллионов точно влезает.
Где то читал про объекты, вроде нельзя больше 8 миллионов полей. Думаю для Map примерно такое же ограничение.
Ну и разумеется, должно хватить памяти у компа.

[webgraph]

Какой именно?
Если массив operations, то это зависит от ваших условий. Сколько там операций у вас идет?
Про Map точно не знаю ограничений, но пару миллионов точно влезает.
Где то читал про объекты, вроде нельзя больше 8 миллионов полей. Думаю для Map примерно такое же ограничение.
Ну и разумеется, должно хватить памяти у компа.

Суть в том, что изучили все возможные БД и SQL, и NoSQL, и NewSQL... И реляционные, и документоориентированные, и колоночные...

Вот колоночные как-то больше всего подходят (именно архитектура). Но по итогу ни одна из них не подходит.

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

Либо, допустим, построчно хранить операции в файле — типа как лог. А отдельно ещё сделать в виде колонок — чтобы иметь мгновенный доступ к требуемым данным. Например, в одной колоночной БД — реализован механизм, который создаёт виртуальные колонки, отсортированные по конкретной колонке:

Н-р, в нашем случае есть 3 основных столбца — from, to, amount. Если представить их в хронологическом порядке, то в столбце amount всё идет как попало и сложно что-либо найти быстро. Для этого создаётся отдельная колонка (или "представление") в котором все данные отсортированы по порядку — как результат мы можем использовать либо бинарный поиск, либо ваще интерполирующий (вот бы ещё понять как его на строки перевести).

По итогу ограничение данных просто отсутствует.

[voraa]

Тогда только думать про БД. С индексами и все как положено.
Рассмотрите Mongo, как вариант.
Но с любой БД вы не получите таких скоростей, как с хранением в оперативной памяти
Все таки хранение на диске, считывание индексов, самих данных....
О временах в пределах нескольких мс на операцию можно не мечтать.

[webgraph]

Тогда только думать про БД. С индексами и все как положено.
Рассмотрите Mongo, как вариант.
Но с любой БД вы не получите таких скоростей, как с хранением в оперативной памяти
Все таки хранение на диске, считывание индексов, самих данных....
О временах в пределах нескольких мс на операцию можно не мечтать.

Mongo была вдоль и поперек рассмотрена. Это вообще не то.

Хм, а если тогда использовать несколько серверов? Типа в тех же колоночных БД данные хранятся в файлах размером до 256 МБ.

Получается вместо файла просто будет отдельный веб-сервер.

[webgraph]

считывание индексов

Кстати, в колоночной БД — колонки сами по себе являются индексами.

[webgraph]

использовать несколько серверов?

voraa,
или как-то может виртуальных серверов?

[voraa]

Не знаю. Совсем не спец по архитектуре серверов. В любом случае надо будет смотреть, что там с временами запросов будет.