Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
>Не сравнить с монументальными творениями гигантских комитетов,
Если вы PL/1 упомянули как творение комитета, то мне кажется это мимо, потому что это было а) произведение исключительно IBM б) на то время это был весьма приличный язык, уж всяко лучше Алгола, где авторы полностью позабыли про ввод-вывод. С десятками реализаций, диалектами, и всем таким.
Если вы PL/1 упомянули как творение комитета, то мне кажется это мимо, потому что это было а) произведение исключительно IBM б) на то время это был весьма приличный язык, уж всяко лучше Алгола, где авторы полностью позабыли про ввод-вывод. С десятками реализаций, диалектами, и всем таким.
Да, детище IBM, настолько монструозное, что всех его возможностей наверняка не знали даже его создатели :)
Да ладно, ничего особо монструозного там не было. Намного проще чем C++, к примеру. Язык конечно сложный, одно управление памятью чего стоит (в трех вариантах, насколько я помню). Структуры данных не особо удобные. В тоже время, вполне можно было пользоваться либо подмножеством, либо писать достаточно сложные вещи типа компиляторов, лазать по структурам ОС почти без ассемблера, и т.п.
Вполне практичный язык был, иными словами. На то время (а это 1964 год, между прочим). Уж что было творение комитета — так это Алгол-60. Забыть ввод-вывод — это надо было суметь.
Вполне практичный язык был, иными словами. На то время (а это 1964 год, между прочим). Уж что было творение комитета — так это Алгол-60. Забыть ввод-вывод — это надо было суметь.
Либо хэш, либо сортировка, я так и написал.
Если у вас нет оперативной памяти на хранение всех идентификаторов строк,
что происходит при организации хэша,
без сортировки не обойтись.
Если у вас нет оперативной памяти на хранение всех идентификаторов строк,
что происходит при организации хэша,
без сортировки не обойтись.
А без шпаргалки, вот у вас миллиард записей, нужно сделать
сделать GROUP BY по двум вычисляемым значениям.
Предложите алгоритм.
сделать GROUP BY по двум вычисляемым значениям.
Предложите алгоритм.
Но ведь ваше решение на awk тоже использует хеш.
Чем оно принципиально лучше, чем group by через хеш на сервере?
Чем оно принципиально лучше, чем group by через хеш на сервере?
Тем что этот хэш строится на моём компе и никому не мешает :)
На самом деле, хэш — это отличный вариант, к сожалению SQL процессор не всегда может сообразить что можно построить именно хэш, а не временный индекс.
А в варианте с lambda функциями даже и хэш не нужен, можно обойтись двумерным массивом.
На самом деле, хэш — это отличный вариант, к сожалению SQL процессор не всегда может сообразить что можно построить именно хэш, а не временный индекс.
А в варианте с lambda функциями даже и хэш не нужен, можно обойтись двумерным массивом.
Вы разменяли один ресурс (память на сервере) на другой (ширину канала к серверу). Т.е. частное решение для очень конкретной ситуации. С другой стороны, если такие запросы типичные, то постоянный fullscan большой таблицы даст большие нагрузки. Возможно, стоит хранить агрегаты в отдельной таблице (и поддерживать триггерами), либо смотреть в сторону OLAP-решений, если заранее неизвестно, какие будут агрегаты.
А в варианте с lambda функциями даже и хэш не нужен, можно обойтись двумерным массивом.И что? Снова кушаем память на сервере, от чего вы хотели избавиться. Но асимптотическая оценка на хранение промежуточных данных остаётся одинаковой, что для хеша, что для массива.
Не совсем так, с lambda функциями мне нужна только память под счетчики попаданий (я ведь гистограмму строю).
В случае groupby через хэш — под идентификаторы строк.
В случае groupby через хэш — под идентификаторы строк.
В случае groupby через хэш — под идентификаторы строк.Зачем?! Всё точно так же — нужна память под строки-группы, и не более.
Делаем groupby по двум вычисляемым значениям, соответствующего индекса нет, максимум можем рассчитывать на статистику.
Что вы называете строками-группы?
Что вы называете строками-группы?
Делаем groupby по двум вычисляемым значениям, соответствующего индекса нет, максимум можем рассчитывать на статистику.И зачем серверу делать хеш с количеством узлов, равное количеству строк в исходнике? Как это ему поможет посчитать суммы по группам?
Сервер делает ровно то же самое, что вы предложили делать вручную — определяет состав ключа (это выражения, по которым группируем) и составляет хеш именно по ключам группировки.
За исключением случаев, когда есть готовый индекс, полностью покрывающий ключ группировки (например, нашёлся индекс по полям X,Y,Z, когда GROUP BY указан по X,Y). В этом случае можно идти по индексу, но часто это оказывается медленнее, чем новое построение хеша. В этом случае можно добавить хинт «не испольуй индекс».
Что вы называете строками-группы?Строки-группы, это строки, которые выходят как результат запроса.
хэш не нужен, можно обойтись двумерным массивом.Если данные разрежены, хеш сохранит их компактнее, чем двумерный массив всех возможных пар координат.
Если возможных пар координат мало (например, поле 1000x1000 при источнике в 1e12 строк), то с практической точки зрения, затраты на хранение промежуточного результата что в хеше, что в массиве пренебрежимо малы по сравнению с необходимостью считать все строки источника. Тут group by на сервере памяти мало съест
Конечно. Но в этом и прелесть lambda функций что я пишу код, который актуален только здесь и сейчас. Мне не нужен общий случай.
Если исходя из структуры данных я ЗНАЮ, что двумерный массив подойдёт, использую его, иначе хэш.
Если исходя из структуры данных я ЗНАЮ, что двумерный массив подойдёт, использую его, иначе хэш.
Но вы пишете код с той же асимптотикой по времени и памяти.
Если условный GROUP BY не подходит под ваши задачи, а кастомное решение, которое жрёт всего лишь в 4 раза меньше памяти — подходит, то проект в большой опасности. У меня так получается, что с каждым годом растёт скорость роста баз. И значит, если нет запаса по таким запросам хотя бы 10-кратного (а SQL-сервер страхует тем, что сам может понять, хватает ему места в памяти, или надо выгружать во внешние файлы), в неожиданный момент и кастомное оптимизированное решение рухнет (там нет такой подстраховки).
Если условный GROUP BY не подходит под ваши задачи, а кастомное решение, которое жрёт всего лишь в 4 раза меньше памяти — подходит, то проект в большой опасности. У меня так получается, что с каждым годом растёт скорость роста баз. И значит, если нет запаса по таким запросам хотя бы 10-кратного (а SQL-сервер страхует тем, что сам может понять, хватает ему места в памяти, или надо выгружать во внешние файлы), в неожиданный момент и кастомное оптимизированное решение рухнет (там нет такой подстраховки).
Вы правы, я ошибался, изменил текст статьи.
.
Таблиц с миллиардами строк в наших базах нет, но сотни миллионов запросто.
Пока все выборки (а они весьма извращенные) удается решать стандартными способами ms sql.
При разработке и анализе никто не мешает насоздавать каких угодно индексов и определится что в итоге нам нужно. А затем все грохнуть и создать вычисляемые поля, поля для группировки (хоть триггером заполнять) и тому подобное.
При выборке там где планировщик запросов идет не по тому пути всегда можно хинтом намекнуть.
В общем я пока остаюсь при мнении что велосипед уже изобретен.
Пока все выборки (а они весьма извращенные) удается решать стандартными способами ms sql.
При разработке и анализе никто не мешает насоздавать каких угодно индексов и определится что в итоге нам нужно. А затем все грохнуть и создать вычисляемые поля, поля для группировки (хоть триггером заполнять) и тому подобное.
При выборке там где планировщик запросов идет не по тому пути всегда можно хинтом намекнуть.
В общем я пока остаюсь при мнении что велосипед уже изобретен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lambda-функции в SQL… дайте подумать