Николай Савельев

Давайте прикинем объем который понадобится. Что такое триллион?
Это 12 нулей. Или 1 000 000 000 000 элементов. Какая у нас data-row?
8 + 64 символов типа ASCII (байт подходит чтоб покрыть все символы).
Итого 72 байта на строку. Там можно еще поужимать биты в байтах но только
сложность повышает а большой пользы для дела не дает. Пускай будет ASCII == 1 байт.

Вобщем такой расчет

72000000000000 байтов на весь сегмент данных когда таблица загружена.
Или 65 терабайт. А сколько магнитных блинов надо прикупить? Возьмем популярный магнитный
Western Digital Purple 10TB 7200rpm 256MB WD102PURZ 3.5" SATA III при цене 290$
Порядка 7 штук надо. Вобщем готовте котлету денег 290$ * 7 = 2030$

По поводу DBMS. Да key-value здесь подходит. Можно начинать с LevelDb или RocksDb но у них
расход дисковой памяти на 1 строчку может быть больше чем я посчитал. Я ведь считал эконом-эконом
вариант в виде бинарного типизированного файла где все записи строго по 72 байта. Сколько именно
захватит РоксДб или ЛевлДб - чорт его знает. Вряд-ли документация об этом что-то говорит.
Но берите 1% датасета. Загружайте
и аппроксимируйте сколько выйдет после полной прогрузкуи. Это - надежный способ оценки.

1 - самая простая нейросеть - камень-ножницы-бума... Тьфу ты. Принтер-ножницы-.клей. 2. Для "перелицовки лица" нейросеть нахр не нать - любой растровый грф. редактор, поддерживающий слои (я юзаю связку КорольДров и Фотомагаз., ибо в векторах работаю постоянно, а растер - для души- ну, там, теньку справа\слева кинуть или титьку увеличить\УВЕЛИЧИТЬ). ИМХО, для нейросети тупо завянешь раскладывать, ШОЯХОЧУВИДЕТЬ... :) Просто видел примеры "творчества" нейросетей на основе запроса. Лучче прощще: нашел дезигнера-в течение течения пенного скинул ему на мозг свои хотелки - ну и ждай. К тому ж с нейросеткой не оспоришь результат . Как-то так.

ioncube
А вообще, за такие провинности требовать 100% предоплату. Конечно, предварительно предоставить нужную информацию, что задача выполнена в полном объеме.
Да и без провинностей минимум на 50% соглашаться, чтобы уровнять риски

Бывают. Мне один из бывших работодателей написал и позвал на проект. Даже собеседования не было.

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

Люди всё правильно говорят. Это не тот вопрос, которым следует заниматься способному в лучшем случае к NoCode управленцу. Так-то найти куски кода, который делает что-то, не так сложно. По ключевым словам легко найти практически что угодно на гихабе, хабре, stackoverflow, куче форумов, в документации к конкретным языкам и библиотекам. Сейчас ещё и расплодились агрегаторы кода, которые по ключевым словам выдёргивают фрагменты кода из кучи опенсурсных проектов, иногда бывают полезны, но чаще раздражают....

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

Программист намного более эффективно проведёт отбор вариантов (сразу выкинув лишь кажущиеся перспективными, но совершенно бестолковые варианты, делающие не то, что надо, или не так, как это разумно), а затем более квалицифированно разберёт всё, что осталось. Конечно, можно ему сказать "я тут видел XXX и YYY, которые кажутся интересными" (и это не запрещено - почему бы и не сказать?), но программист всё равно сделает этот же поиск с нуля ещё раз и выберет ZZZ, который управленец выкинул при отборе, потому что ошибочно посчитал, что он тут не годится.

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

В чем проблема?

В отсутствии базовых знаний языка и непонимании написанного вами кода. Пройдите глазами по коду, построчно, вслух проговаривая что происходит на каждой строке. Если не поможет - отпишитесь)) Подскажу в чём именно проблема.

Обычная проблема, пытаетесь писать сокращенный код до того как поняли что происходит.

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

// метод forEach на каждый найденный элемент вызывает функцию, куда первым аргументом передает ссылку на этот элемент
peresortDel.forEach(foreachCallbak);

function foreachCallbak(el) {
  el.onClick = onClickCallback;
}

function onClickCallback() {
  peresortcontent.style.display = 'none';
}

Никак и слава тому, кто это сделал.

В Java некрасиво получается если объявлять Function прямо в теле метода. Тебе проще инлайнить эту колбасу
(a * x * x * x) + (b * x * x) + (c * x) + d

Довольно много.
При регистрации в сети остается триангуляция до симки. То есть тебя сразу вычисляют с точностью 100 - 1500 метров.
Дальше ты платишь за симку, 2 раза и у них уже есть набор видео где можно сличать персонажей.
Хоть один раз попадал в милицию и твоя морда в системе.
Барыги на рынке кстати стучат операм.
Дальше сугубо технические детали. все твои адреса куда ты там ходил.
Если это российский ресурс, то все данные предоставят по запросу.

Но ты кстати спрашивай, уточняй

никак. либо ТОР

Нигде. Незачем middle+ разрабу работать над чужими идеями, он скорее всего завален высокооплачиваемой работой, очень ценит личное время и полон собственных идей.

Данный вопрос безсмысенно обсуждать только в разделе АЛГОРИТМЫ.

Дело в том что в каждом языке программирования есть своя реализация хеш-таблиц со своими преференциями.
Например в Java создается по умолчанию пустая табличка с 16 buckets и с фактором загрузки 0.75.

Типы данных для ключей и значений - могут быть любые. От них лишь требуется один контракт. Ключи должны позволять на себе посчитать хеш. И ключи нужно сравнивать на равенство и они должны быть иммутабельны. Тоесть ключом не может быть объект представляющий системный таймер например или генератор случайных чисел.

Для случая автора число 42. Мы считаем остаток от деления на 16 это будет 10. Тоесть мы запишем в 10 бакет. А после того как в табличку зайдет большое число ключей и и соотношение ключей и емкости станет больше чем 0.75 - будет создана новая таблица с 32 бакетами и старые данные будут скопированы туда с реогранизацией ключей. Это тяжеловатая процедура поэтому изначально хеш-таблицу рекомендуется создавать уже с заранее известным capacity. Если хотите хранить 6 млрд социальных номеров людей планеты земля - то создавайте соотв такую таблицу. Тогда реорганизации не будет. И load factor можно сделать близким к 1.0.

(Старая таблица с 16 бакетами после этой процедуры будет уничтожена)

Вот это было сделано в 2000 году, по моему на целеронах
https://www.youtube.com/watch?v=G58gFchy-QM&t=47s
И меня останавливала только девушка которая была в конторе.

Черных списков нет.
И вообще у нас нужно очень страшно накосячить, чтобы твой прежний начальник, - ежели ему вдруг позвонят, - сказал бы о тебе плохо.
На Западе - закладывают проще.

Возможно, позвнили старому начальнику, если его лично знают.
Но что все работодатели будут это делать - нереально.

Пробуйтесь еще.