Цитата Iska:
Вот про это я и говорил. В этой таблице ни первое, ни второе поле, ни их совокупность не могут выступать в качестве ключевого. Т.е., как минимум нужно будет ещё одно уникальное поле. »
|
если просто наличие ключевого поля (которое так-то предполагалось) помогает субд ускорить выполнение этого запроса, то я об этом не знал
Цитата Iska:
Ошибки в проектировании структуры обходятся весьма дорого, и псу под хвост идут сотни и тысячи человеко-часов работы. »
|
согласен, для меня это высший пилотаж, поэтому интересны решения применительно к рассматриваемому случаю, записей будут сотни миллионов, это точно, как их дробить или делать что-то ещё, это я и пытаюсь выяснить
Цитата Iska:
По сути: на мой взгляд, на объёме 100,000,000*((20+20)*2)/2^30 ≈ 7.45 Gb — за «не более 2-3 минут» справится любой сервер. Даже скрипт на весьма старом железе справляется на текстовом файле (т.е., ни разу не файл прямого доступа) при доступе к нему по OLE DB за немногим большее время:
« скрыть
Цитата:
Файл лога имел размер 630 915 078 байт, все записи (строки) без условий выбираются примерно за 80 сек. (5 223 755 строк). С условиями (WHERE): 164 117 строк примерно за 70 сек., 2 228 строк примерно за 44 сек., ноль строк примерно за те же 44 сек.
WinXP SP2, 512Мб памяти, Celeron D 3.0GHz.
Что уж говорить про SQL сервер на серверном железе. »
|
у меня ( i3 (2x3.5ГГц) 4Гб ОЗУ ) 2Гб на одном и том же разделе копируются почти 2 минуты
и байт в моём случае на порядок больше получается
понятно, что процедуры в субд специально оптимизированы и не совсем корректно делать такие сравнения, но если на простейшем запросе будут эти 2 минуты, то на более сложных запросах время выполнения увеличится в несколько раз (хотя бы 5-минутная задержка с учётом добавки времени на дальнейшую обработку полученных результатов (например, при использовании в веб-приложении) это в данном случае критично)
на следующей неделе начну тесты на боевом сервере (дома такого нет), поэтому цифры станут точнее
Цитата Iska:
По вопросам сравнительной производительности конкретных серверов попробуйте задать Ваш вопрос на специализированном форуме, типа SQL.RU и т.п. Правда, боюсь, и там можно будет вместо ответа нарваться на эпичный срач, наподобие этого. »
|
срача не надо, но если есть какие-либо соображения по этом поводу, буду только рад