Интересная задачка. Предположу что решение специально написанное под эту задачу окажется более эффективным чем решения предназначены для широкого круга задач вроде sql. И в качестве варианта я бы предположил бы рассмотреть ноду и хранение данных либо полностью в оперативке либо с использованием виртуальной памяти (своп) когда ос будет вытеснять на диск память которая не влезает в оперативку. А для сохранения данных записывать на диск только append-лог операций по данным. Но для начала нужно провести расчеты сколько места будут занимать эти данные. В ноде массив из ста групп где у каждой массив из миллиона 64 битных чисел у меня на маке занял 780 мегабайт. Соотвественно потребуется где-то 78 гигабайт оперативки если хранить все данные в памяти. Да это много но сейчас вполне возможно найти сервера и с большим количеством оперативки. При хранении данных ста групп в оперативке у меня 10k чтений из случайной группы случайного элемента заняло 1.5 миллисекунды. А в случае с виртуальной памятью эти 10k рандомных чтений занимают примерно 5 секунд что в 5 тысяч раз дольше. Но даже тысячу чтений за полсекунды тоже неплохой результат. Сомневаюсь что sql и большинство no-sql баз данных покажут такую скорость. Вот скрипт которым я проводил замеры var k = 100; var n = 1000000; var arr = new Array(k); for(var j = 0; j < k; j++){ arr[j] = new Array(n); for(var i = 0; i < n; i++){ arr[j][i] = Math.random(); } } setTimeout(bench,1000); function bench(){ var value = 0; var time = Date.now(); for(var i = 0; i < 10000; i++){ var index1 = Math.random()*k|0; var index2 = Math.random()*n|0; value+=arr[index1][index2]; } console.log(value, Date.now()-time); setTimeout(bench,1000) }

Я вообще не понимаю людей которые используют лодаш и подобное

Ну тогда не было такого развития v8. Сейчас то понятно что это была одна из больших ошибок

Я вообще не понимаю людей которые используют лодаш и подобное

настоящие разработчики сами пишут свои утилы

А что если попробовать вместо V8 заюзать решения для IoT JS?

я вот только не понял bnoordhuis его идиотом назвал или нет?

Там же просто по возможностям урезанные версии

Ну я имею ввиду решения с компилированием JS. Всё таки в БД динамическую типизацию не очень хорошо впихивать, как бы там V8 её не оптимизировал.

Даже если обмазаться гидрой и оптимизировать всё-всё-всё, то это всё равно наверное из ряда фантастики

Ну я имею ввиду решения с компилированием JS. Всё таки в БД динамическую типизацию не очень хорошо впихивать, как бы там V8 её не оптимизировал.

На самом деле после того как v8 оптимизирует функцию от динамической типизации не остается и следа - все объекты имеют строгий (скрытый внутри v8) тип, благодаря которому в скомпилированный ассемблер функция может загружать свойства прямо по смещению. В общем если не делать глупостей на js которые приводят к деоптимизациям или полиморфизму то быстродействие не сильно то и будет отличаться от кода написанного на плюсах, недаром есть статьи и доклады в которых сравнивают плюсы с жс и в некоторых случаях жс даже выигрывает. В итоге сравнивать с плюсами нужно больше по удобству разработки). И кстати есть еще другой момент - даже если в какие-то вещи мы выносим в с++ расширение к ноде то может даже оказаться что интероп(пересылка данных между с++ и js) окажется медленней чем работа с данными в самом джаваскрипте

Да, он оптимизирует ваш hashmap в вектор, но он во первых хранит тип (в том числе для примитивов), а во вторых GC и heap в 1.4Gb

Камрады, вопрос такой созрел. Как наиболее эффективно хранить One-to-Many связи ооочень большого количества элементов. К примеру, 10000 групп по 1000000 объектов (строк, чисел, etc.). Варианты: 1). Тупо стандартное решение на SQL. Конечно БД пережуёт 10 млрд строк, но чёт мне подсказывает, что будут проблемс, в том числе и с маштабированием) 2). Array of * в PostgreSQL - список должен влезть в 1gb 3). Массивы в MongoDB - тут уже в 64 мб и как это будет работать при решардинге - непонятно 4). List в Cassandra (2^31 элементов) Задачи стандртные: 1). Получить список кусками 2). Добавить элемент в список (с проверкой на уникальность) 3). Удалить 4). Проверить существование в списке В качестве данных DWORD (16 бит) или строки < 30 символов. Хотелось бы услышать ваше мнение по поводу этих вариантов или рекомендации на какие-то другие БД.

Да, он оптимизирует ваш hashmap в вектор, но он во первых хранит тип (в том числе для примитивов), а во вторых GC и heap в 1.4Gb

Не return, а throw.

то есть всегда я должен вместо return использовать throw? так как везде надо обрабытывать ошибку

Нет. Но в вашей функции ошибка не возникла, вы просто создали объект класса Error.

а то приложение падает с maximum call stack size

да я понял, получается если я хочу обработать ошибку я должен не возвращять ошибку через return а через throw

А что ты подразумеваешь под сборкой?

Привет всем, во время сборки минифицируете нодовские файлы?

Если не юзаешь es6 import'ы, серверный код в сборке вообще не нуждается.

forEach ничего не возвращает

Не всякий колбек колбекается ассинхронно

почему?

почему?

forEach выполняет функцию для каждого элемента массива. Возвращает _ничего_