mayton2019

В телефонных станциях мне попадался экзотический вариант такого переключателя. Тип - "молоток".
В нем красный был безобравно соединен с одним из других контактов. Разумеется это был не микрик.
Это было реле. Даже в момент переключения был безобрывно соединен.

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

Испортить это время может сетевой лаг который в данной задаче мы просто не учитываем. Считаем что сеть идеальна.

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

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

Вообще учеба чем хороша. Нормальной жизнью студента. Где можно бухнуть. Где можно погулять со студентками.

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

UPD: Тема окороков удалена. :) Мало-ли. Вдруг кто-то обидется. Щас время такое. Все обидчивые стали.

Нужно собрать это всё в один бинарник и скинуть человеку который по умолчанию не умеет использовать компьютер(точнее умеет только сёрфить в интернете), на компе винда.

Может я чего-то упускаю. Но я не понимаю каким образом это поможет человеку? Он как не умел запускать так и не умеет. Как он будет пользоваться консольной прогой в данном кейсе?

Есть базы данных, весит примерно 40 гб. Нужно его восстановить на свой сервер

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

(я достигал резкого увеличения скорости загрузки когда переключал engine с InnoDb на MyISAM.
Это было давно. И как щас я не знаю. Может щас появились новые engines которые лучше чем
MyISAM. Надо читать. Но на тот момент мне транзакции были безразличны. Нужно было просто
хоть как-то загрузить данные и MyISAM помог).

Очень хорошо грузится CSV в пустую свеже-созданную таблицу без ничего. Даже не надо объявлять PK.. Лучше потом его активировать и также добавить констрейнты в режиме no check.

UPD:

Зачем транзисторы? Нужна сверх-задача.
Например.

Загрузил туда все данные по котировкам - и завтра разбогател.
Или загрузил всю историю литературы - и завтра стал литературным гением.
Или загрузил всю науку за последние 20 веков - и стал новым Ноббелевским лауреатом.

Зачем унижаете возможности GPT?

Вот эта колбаса
[2023-03-14 16:08:42] local.INFO:
имеет длину 36 символов кажется. И если ее просто отрезать слева от строк лога то будет то что надо.
subsr или subsrring.

У автора же не сразу 50Тб а как-то постепенно накапливается?

Можно купить Blue-Ray диски на 50Гб. И писать потихоньку.
Помню еще Verbatim производила надежные диски DVD с алмазным покрытием.
Можно поискать есть ли такие для формата Blue-Ray.

SSD - точно не подойдут. Ни один производитель не гарантирует столько лет хранения информации.
С другой стороны эти же SSD стоят в облачных хранилищах где их просто спасает уровень redundancy
в 2 и 3 и более раз.

Успех мероприятия зависит от пропускной способности канала. Например если все 4 участника этой гонки - магнитные диски и включены в SATA3 порты - то копирование будет в первую очередь ограничиаться шлейфом SATA3 (до 6Gbit) и даже если 3 других в сумме дают более быстрый трафик то мы будем исходить их скорости самого медленного верблюда в караване.

Иногда помогает легкое поджатие информации. В BigData например используют кодеки snappy/LZ0.
Хотя я никогда не видел snappy реализованного в виде консольной утилиты.

Не надо ничего форматировать. Софт который делает процедуру импорта должен это сделать автоматически. Если не умеет - софт надо доработать. Но никаких дополнительных ручных действий над Excel делать не надо. Тем более что форматирование - это не контент.

Мне кажется что для обобщения надо все таки новую статью добавить в MySQL. Чтоб API проводящий сравнение хотя-бы был единообразным.

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

Насчет Sphinx - ничего не скажу. Не использовал. Но в классическом текстовом поиске все слова хешируются в 18-20 битные числа. Потом гистограмма. И дальше эти векторы можно быстро сравнивать. (там еще слова чистятся. удяляются предлоги. приводятся к единой форме). Это теория. Как это реализовано в MySQL - я ХЗ. В Postgres это точно есть. Один чел выше уже написал.

Вот ответ https://stackoverflow.com/questions/32582244/how-t...

Тебе не стоит искать физический или геометрический смысл прям везде.

Математика тем и характерна что вводит абстракции такого уровня, которым нельзя привязать ничего
физического. Например дисперсия имеет размерность квадрата измеряемой величины. Тоесть если ты меряешь
вес слонов в килограмах, и дисперсия получается - килограмм в квадрате. Вот что это за физический смысл?
Безсмыслица. Переводишь координаты точки в кватернион. И у трехмерной точки появляется четвертое измерение.
Какой у него физический смысл? А никакого. Просто линейная комбинация других измерений.

А если ты полезешь в мир физики элементарных частиц - то там вообще есть такие забавные эффекты
что ты не можешь одновременно измерять координаты частицы и ее скорость точно. Или одно или другое.

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

Вот исходя из этих принципов и проектируются надежные и безопасные системы. А если автор надеется на то что непопулярный алгоритм шифрования его спасёт - то он сильно ошибается. На этом погорели многие самоуверенные архитекторы. Они тоже надеялись что на незнании можно делать секрет. В принципе вся военная секретная переписка до 20 го века базировалась на предположении что противник не знает. А современная - уже считает что это не главное. А главное - как быстро мы сможем заменить скомпрометированный ключ на новый. И эта замена как раз и есть замена алгоритма. Потому что ключ в крипторгафии и это и есть секретность. А сами алгоритмы вообще ни разу ни секретных. Это кстати - требование. Под сертификацию идут обычно публично известные алгоритмы и их обсуждают. Их анализируют. Их брутфорсят. И только благодаря этому процессу они и являются надежными.

Не знаю как щас. А лет 10 назад базы обслуживал DBA. Это был инженер и хозяйственник. Кроме того что он знал бизнес. Он также знал примерный объем таблиц в гигабайтах и в миллионах строк. Не обязательно все а хотя-бы топ 10. И даже если какая-то из них внезапно опухла - то это было-бы лакмусом того что в системе что-то пошло не так. (Я в бытность DBA-администраторства знал примерно сколько в день растут таблицы бизнес-фактов и сколько архивных логов накатывает Oracle). Обычно схема даже очень сложных систем состоит из справочников которые не растут. И из таблиц бизнес-операций которые и нужно держать под наблюдением. И их не очень много.

Вот тут пишут как посмотреть размер таблиц https://stackoverflow.com/questions/21738408/postg...

Количество строк - сами напишете. Ну и мониторинг и еще раз мониторинг. Возможно причины - банальны. Переход на новую версию комплекса в процессе которого были добавлены новые колонки например.

И внезапный рост бизнес-данных - это не вопрос к qna. Это вопрос ко всем отвественным которые платят за железо и софт и сам программный продукт 1С.

Тебя-же никто не заставляет открывать все под Хром. В конце концов мы живем в эпоху браузерного либерализма.

Установи себе Mozilla, Edge. Может на них утечка памяти не будет так фатальна.

Дело в том что Google использует свою jvm бинарно не совместимую с Sun/Oracle jvm.
Поэтому я могу спорить на виски что не взлетит никак.