Может быть кроме пайки там еще было травление плат в кислотах. Кислотная пайка.
Лаки, клеи ... да вообще любая гаражная активность должна рассматриваться.
gitPush, можно взять все оставшиеся поля и сделать из них хеш и сохранить в какую-то табличку. Если хеш уже был - значит такой документ уже обрабатывался.
lesn1k, дружище. База скорее всего мертва. Тебе посоветовали искать место бекапов. Сосредоточся на этом.
Первый печальный опыт всегда бывает у юных начинающих ДБА и девопсов. Ты открыл кладбище убитых
баз. Это хорошо. Как хирург похоронил первого больного. Зато получил ценный опыт. И в следующий
раз ты не будешь решать проблемы убиванием дата-файлов.
Иди в крон-таблицу и ищи расписание бэкапов. Или к старшим специалистам и спрашивай у них.
Тая ваш вопрос вообще не про веб-разработку. Вот у вас в телефоне стоит таймер. И у знакомых.
Спросите у знакомых как они его используют и для каких задач. Как вы по жизни его используете.
У него вполне себе норм процессор. И кино смотреть можно. У меня такой эффект
часто бывал лет 15 назад когда я ставил еще тогда хреновые драйвера NVidia
на всякие SuseLinux, Slack e.t.c. И OpenGL не включался и рендеринг плоской
графики в VLC плеере шел с чудовищными лагами. Не лечилось это никак.
Тогда только сумашедший красноглазик мог играть в игрухи на Linux. Все понимали
что реально Windows была игровой платформой а Linux драйера для Radeon/NV
делали только энтузиасты. И как делали чорт его знает. Может реверс-инжинерингом?
И на windows такой эффект можно словить когда какая-нть Windows-2000 не осилила
найти подходящий драйвер.
Еще одна оптимизация. Если есть предположение что будем отбивать 90% негативных реквестов на contains - то можно соединить хеш таблицу с фильтром Блума.
размер биткарты будет 5 мегабайт и нужно 7 хеш-функций (на самом деле можно одну
только к аргументу единичку прибавлять) и фактор ложно-позитивного срабатывания
0.01. Вот такой фильтр будет дешевой проверкой чтоб отбивать реквесты от хешмапы.
Ну... популярность ключей это-ж краеугольный камень всего перформанс тюнинга. Это и для баз данных актуально. Для файловых систем. И для веб-приложений с Rest.
И один великий сказал дескыть всего 2 проблемы у нас. Как обозвать переменную и как инвалидировать
кеш. А все остальное - решаемо.
Если честно, у меня пока нет никаких мыслей, как это можно развить, чтобы было O(1) без жирных констант на contains
Если ты дойдешь до практики реализации кешей. То там окажется что оперативная память неодинаково
работает. Если делать тюнинг структур данных под L1/L2/L3 то может оказаться что такое зональное
деление ключей на популярные и непопулярные очень полезно для кеша.
Вот. Поэтому лучше остановись и сделай бенчмарк в сравнении с хешами STL, Google e.t.c.
O(1) - это чистая теория. А практика может показать что твой теоретический хороший O(1) может быть хуже например логарифма но адаптированного к железу. Бегаешь по красно-черному дереву но ближе к CPU. А пробирования хещ-таблиц будут всегда промахами для железа.
Вот мой десктоп дома (Ryzen-5) имеет на борту 8М кеша L3. И если я его прогрею полностью
(положу туда одну зону из хеш-таблицы) то я почти гарантирую очень короткий отклик
без вовлечения оперативной памяти.
