Четвертый скрин, там есть СТРОКА в выборке =))
Вы можете дальше жить в своем неведении и считать что ID в строке даст вам какой то значительный буст =))
Там если и будет разница, то фактически нивелироваться железом, вот табличка на 1.5kk записей
И в ней 3 индекса, 1 праймари и 2 составных (один чисто числовой, второй имеет строку) и собственно вот запросы
По праймари кею
По первому составному из 2х чисел
И из 2х чисел со строкой
В общем тут на уровне погрешности разница между ними и это вполне логично
у вас каша в голове, несмотря на то, что вы знаете, что такое b-tree, вы не знаете что такое целые числа, они не хранятся в виде строк!
Я вам задам другой вопрос, кто вам сказал что строки в индексе хранятся в виде строк? =))
Вы можете думать что угодно, я же вам предлагаю проверить.
Чем логичнее? =) То что знаков больше? Так по вашему ID 10000000 будет искаться дольше чем строка address
Ключи в БД не выглядят как их значения, то что вы видите цифру 1 ключ это не цифра 1 =))
Ну вы же наверняка в валдбериез и яндекс маркете архитектором работаете, ведь так? =)))
Я конечно не работаю там, но предполагаю, что используют это для такой штуки как шардинг. Так как базу данных сложно масштабировать горизонтально, то принимают решение, что например ID товаров с 1 до 1кк мы храним на сервере А, а с 1кк до 2кк на сервере Б, без ID в урле это действительно сложно делать. Вы если мне не верите, можете сделать табличку на 2 поля, число по праймари и varchar на пусть 100 символов с индексом желательно уникальным и запустить тест выборки по полям. Я это все к чему, я работаю на проектах подобных что вы озвучили, и мы, например, используем как ключи uuid, а не числа.
Вот вам пример такой таблицы, есть ключ праймари и ключ по url (строке), для БД это один и тот же тип индекса, поэтому я не очень понимаю что вы мне тут пытаетесь доказать, я даже не уверен что у вас есть понимание работы всего этого, сделать эксперимент же делов то полу часа, зато сформируете свое мнение основанное на опыте и практике, а не кто то где то сказал.
Я вот чисто примеряя на себя, то открывал бы какой то специализированный хостинг. Например в России нет не одного (по крайней мере я не нашел) аналога https://www.netlify.com/
Зачем сейчас все эти хостинги классические, когда хочется указать URL на репозиторий и в случае изменений в нем приложение (сайт) само раскатывалось, само масштабировалось, само нагрузку распределяло и так далее. Можно еще что нибудь подсмотреть конечно, но компании с деньгами, как правило, готовы взять готовую услугу за бесперебойную работу и снятия с них геморроя по сопровождению за достаточно приличный прайс.
Я думаю можно начать от сюда https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started.html
Что там сложного? Уже напилили полную коробочку инструментов. Разделять фронт и бэк сейчас сильно проще.
Вопрос мне кажется не совсем правильный.
Нагрузка на статичный контент? Это шутка?
Почему ларавел? Почему вообще php или в чем разница php laravel или php wordpress? Laravel заставит написать вас просто все ручками дав набор инструментов, но никто не запрещает так же ручками написать и в wordpress, просто то что это laravel это не значит что ручками напишут нормально =)))
В чем будет ускорение на примерах от PerconaDB (fork mysql) или даже mysql8?
С сотней запросов в секунду в целом я думаю справится любая CMS на выделенном сервере, у нас битрикс тянет больше 2500 запросов в секунду и это интернет магазин, а не статический контент =))
От куда вы эту ерунду берете? Для того чтобы быстро работал нормальный ЧПУ надо на него повесить индекс, разница от числа будет только в размерах этого индекса на жестком диске так как число занимает меньше байт.
По своему опыту работы в хайлоад проектах могу сказать что профиль нагрузки разный на разных проектах и не бывает чтобы CMS или работала или не работала, есть какие то участки где алгоритм не оптимален или делается больше запросов или запрос тяжелый и так далее, то есть оптимизация как правило происходит по факту появления проблем, изначально заниматься такой ерундой нет смысла, в вертикальном масштабировании расти можно очень долго, а потом просто БД вынести на отдельный сервер и снова расти долго =)) Ну а если упретесь в ресурсы всегда можно переписать проект на го или расте =))
