Snakecharmer

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

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

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

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

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

А сложность начинается, как только задачи, стоящие перед ботом, перерастают уровень примера в документации видеотуториале пятилетней давности.

Нужно сделать несколько под-команд у команды. Напишу цепочку if-elif-else, делов то. Ой, а теперь простыня кода на пять экранов, в которой фиг чего найдёшь. Потому что нет привычки структурировать код.

Нужно, чтобы несколько команд/событий формировали цепочку (сценарий). Например, пользователь отправил тре сообщения, первое с именем, второе с возрастом, третье с адресом. Ой, а как это сделать вообще? Не зная понятия "конечный автомат" (finite state machine, FSM), очень трудно догадаться, как тут поступить.

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

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

Нужно добавить боту графический интерфейс - админку. Ой, а работает или интерфейс, или сам бот! Потому что нужно представлять, как устроено большинство GUI-фреймворков, и как устроена асинхронное приложение. А заодно понимать многопоточность, вопросы синхронизации действий между двумя потоками, и особенности работы с asyncio в многопоточных приложениях. Потому что одним потоком тут обойтись будет очень непросто.

Нужно хранить данные в БД. Ой, а почему у меня проблемы при записи в БД имени пользователя? А потому что погромист собирает SQL-запрос через форматирование строк. Надо было почитать доки, чтобы наткнуться на prepared statements, они же parameterized queries.

Нужно хранить данные в БД. Вот только данные имеют связи многие-ко-многим. Я знаю! Я буду просто добавлять или удалять столбцы в таблицу! Потому что не освоены даже азы проектирования БД. Тут уже nuff said. И да, я такое видел на этом сайте.

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

1. Про взаимодействие:
программирование прикладная дисциплина, и осуществлять работу с так называемым AI может совершенно любой человек. Среди людей работающих с така называемым AI есть физики, химики, биологи, экономисты, финансисты, разработчики игр, веб разработчики, люди не имеющие четкой специализации и т.д.

2. Про разработку:
современный AI требует взаимодействия множества разных специалистов.

3. Итог:
да есть ученые работающие над созданием AI примеров много, из известных ну например, Yoshua Bengio. Это один из явных примеров именно ученого. Но есть и не ученые работающие именно над созданием новых систем AI, и работают эти люди, как в маленьких компаниях, так и в корпорациях.

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