bondle, возможно, это архитектурная проблема: высокая связность элементов системы вместо стандартных протоколов и форматов общения между ними.
Скажем, плотно посидев и сделав предварительное техническое описание API, фронт с бэком могут разойтись и начать работу - над его реализацией и его использованием. Если же ставить задачу как "вот доделаем бэк, потом можно будет и фронт к нему писать" - они, разумеется, не распараллелятся.
Разница даже в несколько байт будет ощутимой, если у вас CDN-сервер, отдающий миллиарды файлов в час. Gzip - легкий алгоритм, он не дает идеального сжатия, да и минифицированные файлы сжимаются тоже. Только из них уже выкинута неактуальная (а местами и нежелательная) информация: названия переменных, классов и функций, комментарии, отступы...
Кстати, кроме того, что минификация снижает нагрузку на сервер и каналы - она, внезапно, дает программисту свободу не экономить на спичках в рабочем коде, нормально его форматировать и богато комментировать - зная, что на его использовании эти "излишества" никак не скажутся.
Сама затея не слишком умная. БД должна иметь как можно более быстрый доступ к своим файлам. Доступ к ним по сети сделает работу БД безобразно медленной, а потом, скорее всего, приведет к повреждению базы.
Не стоит и начинать.
Задачи распаковать-то не поставлено ;)
Так что нужно написать одну функцию, которая принимает unsigned char[4] (или unsigned char*) и возвращает uint_32.
EVGENIJ NEFEDOV, это решение придется повторять 10 миллионов раз.
И перед ним логично составить полный список доменов с частотой их появления, чтобы отбросить редкие сразу.
Раз вам их пересечения в принципе неинтересны.
Задача составления такого списка и частотного словаря - вполне тривиальна и посильна для обычной персоналки, весь объем накапливаемых данных должен поместиться в памяти, и это значительно ускорит обработку по сравнению с любыми вариантами с БД.
Их список недостаточно один раз скачать, он динамический - пункты открываются, закрываются, переезжают...
У нас был случай, когда пункт умудрились закрыть между оплатой заказа и отправкой - мы узнали об этом, когда API отказалось выгружать заказ.
Вообще-то разъем в принципе ничего не гарантирует, кроме того, что в него предположительно воткнется и соединится соответствующими линиями парный разъем.
С китайцев станется подвести к этому разъему только силовые линии и оставить информационные оборванными, например. Так что зарядка через него работать будет, а какие бы то ни было подключения - нет.
gusigusiggg, ААА не разрабатываются в одиночку, так что специалистов по написанию игр такого уровня просто нет. Есть специалисты по конкретным частям проекта. Вот по этим частям вам и дают материалы.
Drno, это же не винды, чтобы гоноебиться с клонированием.
Все, что мне приходится делать, когда еще одну машинку нужно сделать киоском - загрузиться с образа Debian и указать путь до preseed-файла на локальном сервере.
Через полчаса киоск готов, причем уже с последними обновлениями.
WbICHA, в основном при том, что я к ним не привык - поэтому не могу с листа прочитать этот код.
А тратить на него время, разбираясь, кто на ком стоял - не собираюсь.
mayton2019, так решите ТС его задачу - он вам ящик выставит.
Правда, глядя на ваши описания старательного заполнения обеих ячеек заведомо симметричной петабайтной таблицы - верится в это с трудом.
Скажем, плотно посидев и сделав предварительное техническое описание API, фронт с бэком могут разойтись и начать работу - над его реализацией и его использованием. Если же ставить задачу как "вот доделаем бэк, потом можно будет и фронт к нему писать" - они, разумеется, не распараллелятся.