Зависит ли производительность базы данных от количества записей?

Vitsliputsli, есть старый фокус селективности. Он больше относится к мангитным дискам. Считается что если вы делаете выборку по индексу и выбираете более 3-5% строк - то использование indexscan уже не эффективно. Проще сделать Fulltablescan.

Как сейчас - не знаю. В эпоху SSD такой параметр как seek time перестал играть роль для индексного поиска.

И чтоб определить эту границу переключения - нужен был CBO. Для SSD я думаю что были подкручены коэффициенты. Всегда проще сделать так чем менять rules. Потому что CBO это как-бы персептрон и менять его поведение лучше коэффициентами чем логикой алгоритма.

Зависит ли производительность базы данных от количества записей?

Vitsliputsli, я раньше хорошо помнил как работает оптимизатор Oracle. Сейчас после Databricks/catalyst у меня каша в голове. Тем более что этих CBO.... каждая овоще-база делает свой. Вобщем точно не помню. Но в идеале оптимизатор должен работать не на RBO это точно.

Будет ли оптимизатор рисковать полагаясь на статистику

это вопрос сложный. Старые рекомендации от оракла образца 2010 года писали что надо
просто пересобрать статистику. Там процедура была gather_table_stats. Она и так по скедулеру
работала ежесуточно. И предполагалось что количество строк в крупных БД - стационарно
или меняется не сильно. Ну если их - миллионы - то загрузка там сто тыщ строк в день
особо не делает погоды. Были краевае кейсы когда CBO ошибался. Но философия такова
что для крупных систем если оптимизатор угадывал эффективность плана хотябы в 9 запросах
из 10 то это уже был успех. Потому что тюнить запросы на ходу DBA не успевали. Особенно
там где кодо-генерация. Всякие ORM/Hibernate и динамический SQL и билдеры отчетов. Там даже доступа к исходнику не всегда можно получить.

4k монитор GeForce GTX 1050 mobile и i5-8300H скорость работы?

Да. Это правда для всех игровых технологий. Хочешь поднять fts - уменьшай screen-resolution.
Мы это знали еще во времена 3dfx, NVidia карт и ускорителей.

И за 25 лет ничего вобщем не изменилось. Пикселы "имеют значение".

Насчет Literoom я не знаю. Надо понять какие технологии он использует. И тут проще действовать
по аналогии. Запускать игру. Смотреть все сенсоры видеокарты. Фиксировать. И потом лайтрум
и тоже смотреть какие части техно-стека или какие элементы конвейера грузятся или перегреваются.

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

На чем дешево и долго хранить десятки Тб информации сейчас?

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

Есть еще стратегия. Я правда не знаю как она называется. Я ее называю тик-так.
У вас есть 2 хранилища. И вы бэкапите по четным неделям на первое. И по нечетным неделям
на второе. При таком подходе если одно хранилище умирает или недоступно - у вас есть второе максиммум
давности 2 недели.

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

Есть еще идея чтоб форматировать бєкапные диски в BtrFS/ZFS и просто делать снапшоты. Но я
этот вопрос не исследовал так глубоко чтоб рекомендовать это. Да и в адрес Btrfs пока еще идут
жалобы. Тут - цена рисков - насколько мы доверяем Oracle/FreeBDS и есть ли шанс восстановить
если диск поврежден или какая-то неведомая ошибка возникает в использовании. Тут - нет теоретически
верного ответа. Тут просто время и практика должны быть главным аргументом.

Как сконвертировать .mht -> .pdf?

Кто-же еще perl использует в наше время :)

На чем дешево и долго хранить десятки Тб информации сейчас?

Dmitry Bay, учитывая риски я-бы хранил 50Тб не в одном а в двух местах. Ситуация в мире показала что облакам тоже не стоит сильно доверять.

И тут уже к автору вопрос, готов ли он раз в 2-3 года обновлять диски в raid массиве. Если данные критичны, то по 2-3 диска минимум необходимо в raid запустить.

Я-бы не использовал RAID. Это режим доступа реального времени. Слишком шикарно. Для информации которая редко поднимается - можно и просто добавлять контрольные коды восстановления как я предложил выше. А уровень восстановления подобрать экспериментально.

Не запускается Kafka в docker-compose, как починить?

Вот статья которую я читал https://developer.confluent.io/learn/kraft/ но я еще не успел попробовать.

Вот список proposals где сама идея описывалась https://cwiki.apache.org/confluence/display/kafka/...

я думаю по ключевому слову KRaft там можно найти главный proposal который является основой для всех других.

На чем дешево и долго хранить десятки Тб информации сейчас?

Есть у меня облачко с хранилищем типа S3. Пользуясь случаем я щас гляну цены на самое жлобское хранение файлов.

Вобщем там на каждый файл атрибут ставится. Есть такой тип хранения:

Glacier Deep Archive - Long-lived archive data accessed less than once a year with retrieval of hours - min storage duration 180 days - Per-GB fees apply.

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

Цены за гигабайт пока не вижу. Чуть позже поищу прейскурант.

Как сделать очередность промисов?

Автор хочет уничтожить саму идею асинхронности?

P.S. -Все. Пропал дом! - воскликнул Филипп Филиппович и всплеснул руками.

Зависит ли производительность базы данных от количества записей?

Да. Это справедливо для RBO-оптимизатора. Тоесть если движок следует правилам то он всегда пойдет по индексу если таковой есть. Если работает CBO - то возможен кейс когда проще сделать FTS по маленькой таблице в 1 блок чем сделать 2-3 чтения (1й уровень и второй индекса + чтение табличного блока по ROWID).

Зависит ли производительность базы данных от количества записей?

Vitsliputsli, пожалуй да. Но здесь автор ничего не указывает про таблицу и индексы. Индекс вобщем-то вещь опциональная. Например Oracle не требует создавать индексов. И классическая таблица-лог тоже их не требует в силу отсутсвия НФ выше чем 1. Таблицы staging. Таблицы дата-аналитики. Все это не индексируется обычно.

На чем дешево и долго хранить десятки Тб информации сейчас?

alexalexes, это понятно что через 15 лет можно и не найти привод. Но я просто развиваю идею что писали выше про магнитные блины. Вероятность их восстановления выше чем у SDD - что черт знает что внутри и пинцетом не потрогать и в другой корпус - не переставить.

Были фирмы лет 10 назад которые восстанавливали информацию с магнитных дисков которые утонули или побывали в пожаре.

На чем дешево и долго хранить десятки Тб информации сейчас?

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

NAME
       par2 - PAR 2.0 compatible file verification and repair tool.

SYNOPSIS
       par2 c|v|r [options] <PAR2 file> [files]

       par2 c(reate) [options] <PAR2 file> [files]
       par2 v(erify) [options] <PAR2 file> [files]
       par2 r(epair) [options] <PAR2 file> [files]

       Also:
       par2create [options] <PAR2 file> [files]
       par2verify [options] <PAR2 file> [files]
       par2repair [options] <PAR2 file> [files]

DESCRIPTION
       par2cmdline is a program for creating and using PAR2 files to detect damage in data files and repair them if necessary. It can be used with any kind of file.

Почему не работает Майнкрафт мод?

Автор прекращай играться в майнкрафт. Иди учить Java и сетевое программирование. У тебя ошибка
InvalidCredentialsException: Status: 401
И видеокарта здесь твоя совсем не причем.

Как отсортировать многоуровневый словарь с помощью sorted()?

Вот попробуй так. Тогда сортировка будет иметь смысл.

{
  "10.10.100.100": [
    {
      "name": "list1",
      "count": 5205,
      "protocols": {
        "tcp": 432,
        "udp": 8796
      }
    },
    {
      "name": "list1",
      "count": 23458,
      "protocols": {
        "tcp": 189,
        "udp": 8
      }
    }
  ]
}

Как отсортировать многоуровневый словарь с помощью sorted()?

Aragorn, кто придумал схему этого документа? У меня есть совет по улучшению.

Зависит ли производительность базы данных от количества записей?

Отвечая на этот вопрос можно целую книгу написать. Разница будет. Мелкая база будет читать 1 блок или page из кеша страниц. Индекс при этом не нужен. Толстая база будет ходить в индекс и примерно за 3-4 чтения блока из кеша будет находить тебе эту одну и ту-же запись. Обычно индекс для миллионов записей состоит из 3-4 уровней. Я не знаю точно как устроен индекс в MySQL но если он похож на оракловый - то примерно так.

В этой задаче больше времени будет занимать сетевой roundtrip пакета туда-сюда поэтому время будет не сильно отличаться. Грубо говоря медленная сетка может результаты этого эксперимента свести почти к полному равенству.

Как сделать ежесекундную обработку действий?

Есть ли способ как-то уменьшить время выполнения? Или может какие-нибудь другие технологии

Ну если ты разработчик игры - то ты должен уметь находить узкое место в коде. Только указать его не так как ты указал на словах. А привести фрагмент кода. Готов спорить что у тебя там стоит
$conn->query("UPDATE ....")
Вот. Технологий много. От регулировки MySQL engine до полного отказа от MySQL и перехода на NoSQL.
А потом - отказ от PHP и переход на что-то другое.

Копирование одного диска на несколько, как ускорить?

Melkij, хорошо. Но вы согласны с тезисом что здесь мы достигли софтварного предела и дальше мы можем обсуждать только топологию подключения дисков?

Копирование одного диска на несколько, как ускорить?

Melkij, нельзя использовать для бенчмарка?