Здравствуйте, kulentsov, Вы писали:
M>>В оракле, например, аналогичная фича называется IOT (Index Ordered Table), и она тоже далеко не сама собой рождается... K> О более быстрой выборке по Primary key. Вообще-то, если отлистать назад, я нигде не говорил, что "во всех случаях". :-| Ясен пень, что не всегда.
Ну как бы да, теоретически если таблицу отсортировать по PK, то выборка по нему будет быстрее. Но если мне вообще не нужно делать выборку по PK? Тоже будем по нему индекс создавать? И таблицу по нему сортировать тоже будем?
M>>А мне и не надо их иметь. Вот когда пользователю они потребуются я нужную статистику и заведу. Но опять-таки K> ... а в процессе заведения её и потребуются ad-hoc запросы.
Тоесть? Это будут уже не ad-hoc запросы, а вполне себе регулярные и укладывающиеся в спроектированную и перепроектированную архитектуру. Когда я буду их пускать база уже будет под них перенастроена.
K> ... и распиханные индексы как раз тут и помогут. Тем более что накопительная статистика требует дополнительной логики, и пока ты будешь её реализовывать, может потребоваться пока вывесить страничку, считающую все это "в лоб".
Вот за подсчеты в лоб и надо бить по рукам, один такой запрос может любую систему колом поставить, за исключением версионной. Но это отдельная песня, спроблемы с ad-hoc запросами, пожалуй самый серьезный недостаток блокировочников.
Возвращаясь к нашей проблеме, опять-таки построить индекс — пятиминутное шевеление пальцами, вто время как развешивание их где попало — черевато боком...
Как ты думаешь, почему сервер при создании таблицы сам не распихивает индексы везде где можно?
M>>Enjoy. Две/три сотни более-менее активно пишущих пользователя возвратят тебя в реальный мир. M>>В качестве дополнительного приза каждому активному расставлятелю индексов дедлок в подарок. K> Не думаю. Против дедлока у нас есть такие не вчера придуманные вещи, как журнальные таблицы, в которых (сюрприз!) операция добавления ничего не блокирует. В приложении к моей конкретике борьба будет выглядеть как ALTER TABLE Type=InnoDB один раз.
Ага, сюрприз будет у DBA, когда транзакция прочитает не согласованные данные, а потом куда-нибудь запишет. Концов не найдешь.
Вот тогда тебе, как разработчику, спасибо и скажут.
K>
K> Этого достаточно для иллюстрации моей мысли?
Какой? Где здесь создание индекса?
K>>>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа. M>>Смело. K> Уж такой я. Возможно, я чего-то не знаю и существуют базы, которые обеспечивают уникальность поля _без_ заведения индекса по нему. Тогда просветите — пополню свою коллекцию софта, которым нельзя пользоваться.
Записывай: MSSQL, Oracle, DB2, Informix, Sybase... достаточно?
K>Я по-прежнему считаю, что дал начинающему совершенно правильный совет. Так как нормальная ситуация — когда добавление/модификация данных занимают проценты либо даже какие-то доли процента от общей загрузки сервера. Приведенный пример с сотнями пишущих пользователей меня не убеждает. Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична. То есть если при таком разкладе добавление (пусть 1/40 = 2.5 процента операций) начинает занимать десятки процентов, то тут не в индексах вопрос, тут какое-то глубокое "не то" с архитектурой вообще, надо либо что-то кардинально переписывать, либо SQL сервер на нормальный менять.
Совет ты дал совершенно не верный.
Вопервых речь шла именно об MSSQL.
Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался
а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу.
б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде"
В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач.
K> Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству.
А вот это очень серьезное заблуждение.
Таблицы с сотней полей вполне нормальное явление, и если по большинству построить индексы, то мало не покажется.
K> То есть вот сделал он базу, внедрил её, наделал статистики, расставил индексов где надо, и есть таблица с двенадцатью полями, из которых девять индексированных. И другой вариант: сделал базу, сразу всё оптом проиндексировал, потом всё остальное, и получилась там таблица с двенадцатью индектированными полями вместо девяти. Ну, и кто это заметит? Ответ "Merle с профайлером" не принимается. И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?
Ага, а когда таблиц больше сотни и в некоторых полей штук по пятьдесят? Тоже все индексировать?
Похоже мы просто о задачах разного уровня говорим...
У вас такой горячий спор, что влазить в ваш разговор сначало не хотелось.
Ключ по Primary Key можно создать максимум по 16 полям, но на счет даже 8 или 10 надо серьезно подумать есть ли в этом большая необходимость. У меня был всего один случай когда я делал Primary Key по 9 полям, но там просто мне это было необходимо. Если же можно обойтись, то лучше такого не делать. И вообще ключи я создаю только для уникальности и целостности данных, если же в таблице нет уникальности, то я создаю спец.поле и делаю на него ключ.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, kulentsov, Вы писали:
M>>>В оракле, например, аналогичная фича называется IOT (Index Ordered Table), и она тоже далеко не сама собой рождается... K>> О более быстрой выборке по Primary key. Вообще-то, если отлистать назад, я нигде не говорил, что "во всех случаях". :-| Ясен пень, что не всегда. M>Ну как бы да, теоретически если таблицу отсортировать по PK, то выборка по нему будет быстрее. Но если мне вообще не нужно делать выборку по PK? Тоже будем по нему индекс создавать? И таблицу по нему сортировать тоже будем?
Это.. Ты прежде чем отвечать, порядок в голове наводи, а то ерунду писать начинаешь. Перечитай начало. Скорость выборки по PK — это один вопрос, который тут обсуждали, а расстановка индексов — совсем другой вопрос, никаким боком не относящийся к первому.
M>>>А мне и не надо их иметь. Вот когда пользователю они потребуются я нужную статистику и заведу. Но опять-таки K>> ... а в процессе заведения её и потребуются ad-hoc запросы. M>Тоесть? Это будут уже не ad-hoc запросы, а вполне себе регулярные и укладывающиеся в спроектированную и перепроектированную архитектуру. Когда я буду их пускать база уже будет под них перенастроена.
Ты упорно не понимаешь, о чем я пишу. Понимаешь, есть такая информация, для получения которой нам либо надо _с самого_ начала предусмотреть статистику для неё (что для всех случаев невозможно, как я писал), либо пускать запрос по всей базе. Можешь называть это "перенастройкой базы", если хочешь, суть не изменится.
M>Как ты думаешь, почему сервер при создании таблицы сам не распихивает индексы везде где можно?
Я думаю, потому что правильный путь для сервера заключается в другом. При каждом запросе он составляет список индексов, которые ему нужны, и смотрит, какие из них есть, чтобы их использовать. Если каких-то не хватает, то создаются временные данные, которые помогают ему выполнить запрос — индекс в памяти, что-то еще, неважно. Важно то, что после запроса они чикаются, что и есть ошибка. Надо недостающие индексы просто автоматически создавать в базе. Тогда человеку вообще не надо будет думать об индексах (чего мы и добиваемся), а заниматься собственно данными.
M>>>Enjoy. Две/три сотни более-менее активно пишущих пользователя возвратят тебя в реальный мир. M>>>В качестве дополнительного приза каждому активному расставлятелю индексов дедлок в подарок. K>> Не думаю. Против дедлока у нас есть такие не вчера придуманные вещи, как журнальные таблицы, в которых (сюрприз!) операция добавления ничего не блокирует. В приложении к моей конкретике борьба будет выглядеть как ALTER TABLE Type=InnoDB один раз. M>Ага, сюрприз будет у DBA, когда транзакция прочитает не согласованные данные, а потом куда-нибудь запишет. Концов не найдешь.
Это где так — в MS SQL, что ли? В нормальных серверах добавления не только ничего не блокируют, но и видны становятся остальным тредам все сразу когда надо — в конце транзакции.
M>Вот тогда тебе, как разработчику, спасибо и скажут.
Предпочитаю наличность.
K>>
K>> Этого достаточно для иллюстрации моей мысли? M>Какой? Где здесь создание индекса? На диске, мой друг, на диске!
K>>>>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа. M>>>Смело. K>> Уж такой я. Возможно, я чего-то не знаю и существуют базы, которые обеспечивают уникальность поля _без_ заведения индекса по нему. Тогда просветите — пополню свою коллекцию софта, которым нельзя пользоваться. M>Записывай: MSSQL, Oracle, DB2, Informix, Sybase... достаточно?
"Век живи — век учись" — сказал порутчик Ржевский. Сказав "А", скажи и "Б":
1. Какой командой мы обеспечиваем уникальность столбца без заведения индекса по нему?
2. Как база данных реализует проверку на уникальность без индекса?
3. раз уж мы тут — зачем это нужно? Какие преимущества по сравнению со случаем уникального индекса?
M>Совет ты дал совершенно не верный. M>Вопервых речь шла именно об MSSQL.
Да, вернее было бы сказать "Переползай на Оракл".
M>Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался M>а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу.
SQL — да, транзакции — нет. Читайте новости, которые уже давно не новости (про альтернативные типы таблиц).
M>б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде"
Ерунда полная. Неразвитость SQL легко замещается, а надежность и масштабируемость MySQL выше всяких похвал. А заодно и переносимость. После появления InnoDB у Оракла появилась проблема. Этого еще не видно, но думаю, когда MySQL AB поработает над языком в достаточной степени, это проявится.
M>В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач.
Ничего такого специфичного именно для веба я не утверждал.
K>> Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству. M>А вот это очень серьезное заблуждение. M>Таблицы с сотней полей вполне нормальное явление, и если по большинству построить индексы, то мало не покажется.
... M>Ага, а когда таблиц больше сотни и в некоторых полей штук по пятьдесят? Тоже все индексировать? M>Похоже мы просто о задачах разного уровня говорим...
Ну крут, крут. Но аргумент мимо тазика. Потому что спрашивающий еще не достиг такого уровня, чтобы писать приложения с сотнями таблиц. А когда достигнет — у него просто не будет возникать подобных вопросов. А тормозные запросы в результате отсутствия индексов появятся у него гоораздо раньше.
Теперь о самой ситуации. Не, ребята... Сотни таблиц? С сотнями полей? ТЫСЯЧИ ИЛИ ДЕСЯТКИ ТЫСЯЧ ПОЛЕЙ, НАБИТЫЕ ВРУЧНУЮ АВТОРОМ ПРИЛОЖЕНИЯ? Это — нормально? Это — АБнормально. Это просто абзац какой-то. Это полное неумение проектировать и как следствие — решение задач негодными средствами. Это всё равно что иметь пару сотен параметров в приложении и вместо того, чтобы сделать из них массив или коллекцию, заводить для каждой свою переменную.. Это нормально для 10-20 переменных, но не для 100. Когда у меня задачи начали грозить количеством полей за 20-30, я их стал унифицировать в отдельных таблицах, а когда с количеством классов объектов началась подобная беда, я перешёл на объектную базу. Чего и другим желаю.
Здравствуйте, kulentsov, Вы писали:
K> Скорость выборки по PK — это один вопрос, который тут обсуждали, а расстановка индексов — совсем другой вопрос, никаким боком не относящийся к первому.
Вот именно об этом я и говорю...
K> Ты упорно не понимаешь, о чем я пишу. Понимаешь, есть такая информация, для получения которой нам либо надо _с самого_ начала предусмотреть статистику для неё (что для всех случаев невозможно, как я писал), либо пускать запрос по всей базе. Можешь называть это "перенастройкой базы", если хочешь, суть не изменится.
Нет, это ты не понимаешь..
Индекс — вовсе не есть та самая статистика, точнее он только часть необходимой статистики, причем далеко не самая важная.
M>>Как ты думаешь, почему сервер при создании таблицы сам не распихивает индексы везде где можно? K> Я думаю, потому что правильный путь для сервера заключается в другом. При каждом запросе он составляет список индексов, которые ему нужны, и смотрит, какие из них есть, чтобы их использовать. Если каких-то не хватает, то создаются временные данные, которые помогают ему выполнить запрос — индекс в памяти, что-то еще, неважно. Важно то, что после запроса они чикаются, что и есть ошибка.
А вот теперь ты расскажи мне какие сервара так делают, чтобы я знал, чем пользоваться не стоит. MySql?
K>Надо недостающие индексы просто автоматически создавать в базе.
Индексы надо создавать только необходимые. Ни больше не меньше.
Собственно это и есть основной и принципиальный вопрос наших разногласий. Может быть для MySql'я твой подход и годится, но ни для MSSQL'я, ни для Oracle'а, ни для DB2, ни для любого другого полноценного реляционного сервера БД так делать нельзя.
Во первых вариантов индекса может быть гораздо больше, чем возможных полей. Иногда нужны составные индексы, покрывающие, для ряда запросов и т.д. Ты предлагаешь создавать все возможные варианты просто на всякий случай?
Во вторых создавая индексы сверх необходимого ты полностью теряешь возможность управлять ходом выполнения запроса, что может привести к весьма печальным последствиям.
M>>Ага, сюрприз будет у DBA, когда транзакция прочитает не согласованные данные, а потом куда-нибудь запишет. Концов не найдешь. K> Это где так — в MS SQL, что ли? В нормальных серверах добавления не только ничего не блокируют, но и видны становятся остальным тредам все сразу когда надо — в конце транзакции.
Угу. Расскажи мне пожалуйста про такой феномен, как Phantom Read, про известные способы борьбы с ним и про преимущества и недостатки этих способов.
Вот тогда и поговорим, предметно...
А так же, что это за "нормальные сервера" и что ты понимаешь под термином "нормальный сервер"?
Да и в конце какой транзакции они становятся видны? Тоже очень любопытно.
K>1. Какой командой мы обеспечиваем уникальность столбца без заведения индекса по нему?
UNIQUE.
K>2. Как база данных реализует проверку на уникальность без индекса?
Зависит от внутреннего механизма.
Но индекс и уникальность — не муж и жена, а четыре разных человека.
K>3. раз уж мы тут — зачем это нужно? Какие преимущества по сравнению со случаем уникального индекса?
Целостность гарантируется, но нет накладных расходов на поддержание индекса.
M>>Вопервых речь шла именно об MSSQL. K> Да, вернее было бы сказать "Переползай на Оракл".
Вернее было бы промолчать. Или по крайней мере не ссылаться на "общий случай". Сказал бы, что "В MySql'е надо создавать все индексы, какие только можно..." И ни кто и слова бы против не сказал. Если это действительно так.
M>>Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался M>>а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу. K> SQL — да, транзакции — нет. Читайте новости, которые уже давно не новости (про альтернативные типы таблиц).
Про поддержку транзакций я слышал, а так же и про то, что она весьма далека от совершенства. Насколько я помню там содрали механизм concurrency c BerklyDB, которая далеко не образец для подражания в этом плане.
M>>б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде" K> Ерунда полная. Неразвитость SQL легко замещается, а надежность и масштабируемость MySQL выше всяких похвал.
Ага. Масштабируемость еще пожалуй потянет, а вот по поводу надежности лучше не надо, и по поводу поддержки транзакций тоже.
Вообще MySql весьма вольно обходится со стандартами и теорией которой ты здесь оперировал, поэтому ссылаться на него по меньшей мере не корректно.
И опять-таки не надо мешать в одну кучу теорию и конкретные реализации.
K>А заодно и переносимость. После появления InnoDB у Оракла появилась проблема. Этого еще не видно, но думаю, когда MySQL AB поработает над языком в достаточной степени, это проявится.
Ну, я думаю еще лет пять-семь упорной работы и из MySql получится достойный сервер.... Только оно надо? Он на своем месте и так не плох.
M>>В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач. K> Ничего такого специфичного именно для веба я не утверждал.
Тебя процитировать? "....Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична......"
Так вот форумы, вовсе не являются типичной OLTP задачей.
K> Ну крут, крут. Но аргумент мимо тазика. Потому что спрашивающий еще не достиг такого уровня, чтобы писать приложения с сотнями таблиц. А когда достигнет — у него просто не будет возникать подобных вопросов.
Надо сразу учить, как делать правильно.
K> А тормозные запросы в результате отсутствия индексов появятся у него гоораздо раньше.
Не появятся. Чтобы индексами пользоваться надо для начала чего-нибудь про них прочитать, а не распихивать везде где можно. А если появятся, спросит — объясним.
И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?
Мы уже победили, просто это еще не так заметно...
