Здравствуйте, voxel3d, Вы писали:
V>быстрее в документации найти.
В общем-то да. Но часто лениво, понимаю.
V>Вы попробуйте ради интереса найти в документации к мусклу максимальные длины всех доступных типов индексов. Я вот нифига не нашёл быстро.
Ради интереса нашел, быстро, первая ссылка, ведущая на мануал.
prefix can be up to 1000 bytes long for MyISAM tables, and 767 bytes for InnoDB tables. The NDBCLUSTER storage engine does not support prefixes
V>Чтобы узнать оптимальное направление рытья, мне надо либо узнать на форуме, куда двигаться, либо тупо пробовать и сравнивать. На пробовать и сравнивать всё существующее у меня нет времени, гораздо лучше, если, кто-то сразу отметёт мне часть тестов.
По первому вопросу я бы спросил, а зачем индексировать непременно весь URL, почему недостаточно префикса? И зачем для URL UTF-8, готовитесь к запуску домена .рф ?
По второму вопросу видимо нужно профилировать, искать узкое место. Каждый индекс разумеется замедляет вставку, но вот насколько — зависит от многих факторов. По MySQL ничего определенного не подскажу, опыта нет. Кстати от длины ключа наверняка зависит.
Очень вероятно поможет буферизация в приложении и вставка пачками по 100 и более строк.
Здравствуйте, voxel3d, Вы писали: V>Надо поле содержащее URL проиндексировать, его длина составляет 2000 символов.
Для поиска по точному совпадению можно хеш взять — например sha1.
1. Какой длины индексы можно сделать для текстового поля в указанных в сабже серверах, в котором содержатся UTF-8 записи? Надо поле содержащее URL проиндексировать, его длина составляет 2000 символов.
В MySQL, к сожалению, длина B-TREE индекса составляет 333 символа.
2. Производительность вставки записей. На заданном железе, на вебсервере удалось достичь производительности сохранения информации представляющей из себя несколько числовых полей и два текстовых поля по 2кб — 1400-1900 запросов в секунду. К сожалению, с добавленем B-TREE индексов на два текстовых поля производительность упала до 300-400 запросов в секунду.
Насколько быстро в сравнении с MySQL будут вести себя сервера из сабжа?
Здравствуйте, voxel3d, Вы писали:
V>1. Какой длины индексы
Что есть длина индекса? Может длина ключа?
V>Надо поле содержащее URL проиндексировать, его длина составляет 2000 символов.
Такие вещи нужно смотреть в документации. В Oracle можно.
V>Насколько быстро в сравнении с MySQL будут вести себя сервера из сабжа?
В неумелых руках (на что есть подозрение) могут и медленнее.
Здравствуйте, wildwind, Вы писали:
V>>1. Какой длины индексы W>Что есть длина индекса? Может длина ключа?
В документации к MySQL используется термин "index length", видимо, под длиной ключа вы понимаете то, что я понимаю под длиной индекса.
"With col_name(N) syntax in an index specification, you can create an index that uses only the first N characters of a string column. Indexing only a prefix of column values in this way can make the index file much smaller."
V>>Надо поле содержащее URL проиндексировать, его длина составляет 2000 символов. W>Такие вещи нужно смотреть в документации. В Oracle можно.
Ага, а на форуме не спрашивайте, это же намного дольше, спросить, быстрее в документации найти. Вы попробуйте ради интереса найти в документации к мусклу максимальные длины всех доступных типов индексов. Я вот нифига не нашёл быстро.
V>>Насколько быстро в сравнении с MySQL будут вести себя сервера из сабжа? W>В неумелых руках (на что есть подозрение) могут и медленнее.
Знаете, мне абстрактное умничание не поможет. Чтобы узнать оптимальное направление рытья, мне надо либо узнать на форуме, куда двигаться, либо тупо пробовать и сравнивать. На пробовать и сравнивать всё существующее у меня нет времени, гораздо лучше, если, кто-то сразу отметёт мне часть тестов.
Здравствуйте, wildwind, Вы писали:
W>По первому вопросу я бы спросил, а зачем индексировать непременно весь URL, почему недостаточно префикса? И зачем для URL UTF-8, готовитесь к запуску домена .рф ?
полностью было бы хорошо проиндексировать урл, чтобы поиск вида
...WHERE url LIKE '%var%'
использовал индекс. С частичным индексом индекс используется только при таком поиске:
...WHERE url LIKE 'var%'
UTF-8 в сязи с тем, что во втором текстовом поле упакована detail информация, которая в UTF-8. Использование же master — details вставки сильно медленнее самой худшей вставки одной строки. Худшей — в том смысле, что максимальной длины индексы и utf-8 в "master" части.
W>По второму вопросу видимо нужно профилировать, искать узкое место. Каждый индекс разумеется замедляет вставку, но вот насколько — зависит от многих факторов. По MySQL ничего определенного не подскажу, опыта нет. Кстати от длины ключа наверняка зависит.
Нет, меня больше интересует подсказка, типа "oracle делает данные инсерты быстрее чем...".
W>Очень вероятно поможет буферизация в приложении и вставка пачками по 100 и более строк.
А это всегда общая тенденция? Или просто связанная с затратами на открытие соединения? (у меня оно постоянно открыто).
> полностью было бы хорошо проиндексировать урл, чтобы поиск вида > > ...WHERE url LIKE '%var%' > > использовал индекс.
Такой запрос никогда не будет использовать любой из изндексов типа b-tree(на
самом деле любой, построенный на упрорядочивании данных).
С частичным индексом индекс используется только при > таком поиске: > > > ...WHERE url LIKE 'var%'
Это твои домыслы. Будет такой запрос использовать индекс, если сервер
сочтёт его полезным для запроса, и это не будет зависеть от того, "частичный"
индекс или "полный". Поэтому кстати и делают префиксные индексы (по началу
ключа), потому что они ВСЁ РАВНО МОГУТ ИСПОЛЬЗОВАТЬСЯ, а эффективность
индекса с увеличением длины ключа снижается.
Главное, чтобы отрезанный префикс ключа был бы РАЗНЫЙ для разных ключей.
> UTF-8 в сязи с тем, что во втором текстовом поле упакована detail > информация, которая в UTF-8.
Вообще-то разные поля таблицы могут быть в разных кодировках.
Особенно это верно для MySQL (т.е. для MySQL это ТОЧНО ВЕРНО, он
это умеет. MSSQL -- если только современный, ORACLE, PG -- не знаю)
Использование же master — details вставки > сильно медленнее самой худшей вставки одной строки. Худшей — в том > смысле, что максимальной длины индексы и utf-8 в "master" части.
Если тебе так нужны быстрые вставки, это ты значит что-то не так
делаешь. Быстрые вставки вообще не для СУБД, особенно транзакционных.
Единственная СУБД из обсуждаемых, имеющая опциональную ACID-транзакционность
-- это MySQL с движком MYISAM. Так что если тебе нужна скорость вставок,
то очень странно что ты с MySQL хочешь так расстаться: его все WEB-телепузики
именно за это и любят, за скорость (в ущерб транзакционности и надёжности)
> Каждый индекс разумеется замедляет вставку, но вот насколько — зависит > от многих факторов.
На O( log(N) ) где N -- текущий размер таблицы. Особенно не от чего это
и не зависит.
По MySQL ничего определенного не подскажу, опыта > нет. Кстати от длины ключа наверняка зависит.
Ну, зависит, но в тех случаях, когда индекс неэффективен и не нужен.
В случае нормальных индексов можно этим пренебречь.
> Нет, меня больше интересует подсказка, типа "oracle делает данные > инсерты быстрее чем...".
Жёстко транзакционный Oracle делает вставки медленнее, чем MySQL + MyISAM.
> W>Очень вероятно поможет буферизация в приложении и вставка пачками по > 100 и более строк.
Не поможет особо. Потому что это разница в несколько раз, а разницы между
транзакционной/нетранзакционной СУБД -- несколько порядков.
Здравствуйте, voxel3d, Вы писали:
V>1. Какой длины индексы можно сделать для текстового поля в указанных в сабже серверах, в котором содержатся UTF-8 записи? Надо поле содержащее URL проиндексировать, его длина составляет 2000 символов.
V>В MySQL, к сожалению, длина B-TREE индекса составляет 333 символа.
деревья не предназначены для текстовго поиска, c увеличением длинны ключа растет глубина дерева и оно быстро становится неэффективным, поэтому длинну ключа ограничивают. Пользуйтесь полнотекстовым поиском
V>2. Производительность вставки записей. На заданном железе, на вебсервере удалось достичь производительности сохранения информации представляющей из себя несколько числовых полей и два текстовых поля по 2кб — 1400-1900 запросов в секунду. К сожалению, с добавленем B-TREE индексов на два текстовых поля производительность упала до 300-400 запросов в секунду.
V>Насколько быстро в сравнении с MySQL будут вести себя сервера из сабжа?
зависит от того как делать, для MSsql тысячи з\сек вполне нормально
MZ>На O( log(N) ) где N -- текущий размер таблицы. Особенно не от чего это MZ>и не зависит.
неправда, там дерево не двоичное и степень логарифма нааамного больше. при таких высоких степенях затраты растут дискретно
MZ>А где ты там видишь двоичный логарифм ? я что -то про его двоичность писал ?
Ну тогда считай что я уточнил твой ответ, согласись нетривиально догадаться что показатель логарифма для индекса по инту ~ 1000
Здравствуйте, voxel3d, Вы писали:
V>Здравствуйте, wildwind, Вы писали:
W>>По первому вопросу я бы спросил, а зачем индексировать непременно весь URL, почему недостаточно префикса? И зачем для URL UTF-8, готовитесь к запуску домена .рф ?
V>полностью было бы хорошо проиндексировать урл, чтобы поиск вида
V>...WHERE url LIKE '%var%'
V>использовал индекс. С частичным индексом индекс используется только при таком поиске:
V>...WHERE url LIKE 'var%'
Если тебе нужен произвольный поиск, то стандартные индексы БД тебе не помогут. Тебе может помочь полнотекстовый индекс, но еще лучше воспользоваться тем что url имеет регулярную структуру, разбить его на токены. А токены уже можно индексировать стандартными средствами. Учитывая что большинство токенов — английские слова, то можно их вынести в справочник и держать его в памяти приложения, тогда будет и быстрый поиск (с настройкой релевантности), и быстрая вставка (не будет обновления текстовых индексов).
