Давайте тут уж по честному, если вы уперлись в производительность индексов (если мы подразумеваем что они используются корректно), то мне кажется тут пора писать своё хранилище, а весь проект уже давно на расте или си переписан =))
s Ещё надо убедиться, что все демоны переведены с tcp- на unix- сокеты /s
Размер строк для хранения ключа не имеет никакого значения. Он влияет только на скорость выполнения хеш-функции.Сами хеши строк всегда одного размера (иначе не удастся обращаться к ним по указателю). Размер этих хешей обычно больше числового, то есть в одной ноде можно поместить больше ключей.Кроме того сравнение чисел более дешёвая операция чем сравнение строк.
По большому счёту это все преимущества числовых индексов.
То есть выиграли на работе хеш функции (1) , размере массива в ноде (2) , сравнении/сортировке(3). Много или мало? 99,(9)% пользователей этого форума разницы ни на одном проекте не заметят.
А разве индексы в БД это не массив хэшей?
Если мы говорим о b-tree, то скорее двусвязный список, нодами которого являются массивы.
Тут избыточность мне кажется не причем...
Для хеша в b-tree нужны 2 момента - уникальность и постоянный размер. Целое число удовлятворяет обоим критериям:- оно так уникально - его не надо ещё раз уникализировать- размер (например INT) всегда 4 байта
Ключи в БД не выглядят как их значения, то что вы видите цифру 1 ключ это не цифра 1 =))
В b-tree? С чего бы вдруг? Для целочисленных значений используется метод идентичности функции, то есть числовой индекс остаётся исходным числом. Для распределения/поиска по листам b-tree, соответственно, используется либо модульность, либо мультипликация. Хешировать целое число неиденитичной функцией - явная изобыточность.
Но в целом придерживаюсь мнения что рандомно как-то они отказывают/принимают. Чисто человеческий фактор.
Отправлял 3 раза подряд одну и ту же справку по форме 18.9 (Беларусь). На третий раз приняли.
Прокси только у браузера.
Я запускал файл .jnlp из консоли системы своей.
Деталей за давностью не помню, но у ovh ip в браузере при скачивании и ip host'а с которого он запускается должны совпадать, так что или качайте его без прокси в браузере или запускайте jav'у через тот же прокси.
Я на png пока тестировал
По png не подскажу, а по jpg MozJPEG должен дать выигрыш относительно стандартной libjpeg на процентов 13-20, но проиграет по времени (где-то двухкратно)
На серваке Дебиан есть папка с подпапками. Есть ли решение, которое сожмет без потери качества png и jpg не меняя названия файлов? Чтобы уровень сжатия был сопоставим с сайтом https://www.iloveimg.com
Пока я попробовал эти команды
Сжимает, но далеко не так хорошо как указанный выше сайт. Есть ли еще решения?
jpegoptim собран с MozJPEG?
всё-таки Гленливет победил меня вчера :)
NoMoreContent #:Если смотреть не по конкретной задаче, а с академическим интересом, у вас много исследовательских мыслей. Однако многие из них напоминают задачи, уже решенные создателями файловых систем.
Так я и не претендую на оригинальность. Например, эта идея отлично отражена в реализации модуля nginx proxy_cache_path. Там вложенность, вроде, ограничена 3-мя уровнями.
