ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в ClickBench, о котором статья) - если вы опубликуете такой бенчмарк про Оракл или MSSQL, готовьтесь быть арестованным в ближайшем аэропорту свободного мира - https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-database . Но у этого есть плюс - если видите в бенчмарках любое упоминание этих неприкасаемых, сразу ясно, кто за него платит за этот бенчмарк, и почему все остальные такие плохие.
не надо так строго критиковать этот бенчмарк, это как ребенка обижать 😀, рука не поднимается. В нем некоторые базы сами по умолчанию строят индексы в больших количествах, поскольку такой формат таблицы. Зато на вопрос - что со скоростью записи ? - ответ будет - какой записи? Это аппенд-онли таблица, причем на один раз. Метаданные, индексы - все в конце таблицы, дописать - это создать новую такую же плюс новые данные. Зато мы ее из S3 можем считать, по сети. Такое видение OLAP сегодня у некоторых.
тут победить мог кто угодно, так как одним сказали скакать вон той короткой дорогой (используя индексы), а другим вон той длинной песчаной (без единого индекса) и с грузом (fillfactor у таблицы 70% для ускорения записи, а тестировалось только чтение). Этот бенчмарк изначально делался, чтобы оценить скорость нескольких систем, чтобы сделать выбор для конкретной ситуации.
Про парсер - я имею в виду, что парсер создал для VALUES двумерный массив выражений (строка-столбец). Эти выражения могут давать константный результат, то это не известно - для этого надо вычислить значения этих элементов. На этапе парсера и на этапе начала планирования нельзя сказать, из константных элементов состоит VALUES или там есть переменные. А когда уже можно сказать, то уже поздно что-то менять. Интересно, а mssql как делает планирование таких VALUES. У меня под рукой его нет.
А куда ему родному деваться-то? Так реляционная алгебра постулирует.
Тут даже более приземленно - для планировщика это одно из отношений (с типом VALUES) и он ничего не знает о его содержимом, так как его окончательное содержимое выдаст экзекьютор, выполнив этот узел.
Пока parser отдельно не выделяет константные VALUES (без условий, сортировок и LIMIT), планировщик ничего не сможет сделать
А не может быть причиной то, что VALUES были в SQL всегда, а массивы появились в PostgreSQL значительно позднее? Традиционно PostgreSQL считает, что VALUES - это один из видов отношений, и обрабатывает его сразу, как отношение. IN ( rowset) на раннем этапе планирования преобразовывается в JOIN, и после этого момента константный VALUES поздно оптимизировать (функции и константные выражения обрабатываются позднее). Думаю, разумнее, чтобы такие вещи делал все-таки сервер, а не программисту DB разбираться в особенностях планировщика - у программиста DB своих проблем на своем уровне хватает.
При создании модели планировщика можно учитывать текущую нагрузку сервера, как параметр? Например, при высокой нагрузке будут строится планы с учетом этой нагрузки (например, без parallel workers, так как они сейчас все заняты, или меньше памяти под какой-то вариант плана - это уже модель сама решит, что поменять). Чтобы модель не только умно планы создавала, но умно реагировала на нагрузку сервера
Может быть об этом надо дополнительно сказать в документации к IN. Тем более, что оба оператора IN описываются в двух разных разделах. Пока на грабли не наступят, не обратят на это внимание. Как из вопросов про английский:"Иногда вижу has, иногда had - никак не пойму разницу, почему буква на конце разная"
Интересно, что пользователи используют такую конструкцию IN (VALUES(1),(2)...) и видят замедление запроса, и пытаются это понять, но это им не очевидно. Это из реальных вопросов программистов. То, что IN - это два разных оператора в случае массива справа и набора данных из одного поля справа - это не очевидно. Соответственно, не очевидно, что надо запрос переделать на более оптимальный.
Вы написали "Хотя она (PostgreSQL) и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа." Не могли бы Вы сослаться хотя бы на один источник информации, откуда следует, что Postgres работает медленнее (по контексту - Oracle). Oracle юридически запрещает все бенчмарки. Вы видели какие-то сравнения по скорости? Хотел тоже посмотреть.
Векторными называют базы, в которых есть функция поиска (быстрого поиска) векторов (вектор - длинный массив чисел, хранить могут почти все базы, но быстро искать - почти никто). Чтобы точно найти ближайший вектор, надо полностью перебрать всю базу (это математическая теорема), поэтому используют приблизительный поиск. Обычно - чем меньше точность поиска, тем больше скорость и наоборот. Точность можно измерить на тестовых наборах данных или в своем приложении - при разных параметрах Вы просто видите, что поиск начал выдавать какую-то ерунду и увеличиваете точность поиска параметрами.
Скажите, а почему Вы задаетесь таким вопросом? Вы же не видели лицензионного соглашения на тот ключ, и не можете рассуждать без него о правомерности использования ключа. Вы не собственник лицензии, но Вас почему-то беспокоит, что кто-то кому-то переслал ключ от чужой программы. Не первый раз вижу подобные заявления, и не понимаю их смысла.
Если не секрет, что за работа, на которой приходилось заниматься векторами? Просто интересно, кто уже реально этой технологией пользовался для работы, а не для тестирования.
Не отрицая разумности изложенных правил рынка труда, хочу обратить внимание на факты, обсуждение которых сейчас избегают, так как это тема хуже Холокоста евреев с 6 миллионами погибших, а виновники живы до сих пор: в России в 90-е годы вместо 20-25 миллионов родилось около 10 миллионов детей. 10 миллионов просто не родилось, а они сейчас должны были пойти на работу, менять тех, кто уходит на пенсию. Плюс к этому увеличение смертности в полтора раза. Теперь каждые 30 лет будет волна спада рождаемости. Это и есть причина дефицита, просто нет людей. И это никак не компенсировалось мигрантами.
Только надо привязать в одном из тех шести прямоугольников, так как наружи неисправные поезда не поедут, и до 21 ноября, иначе они из-за "неисправного" компрессора тоже не выйдут на маршрут.
Я не вполне понял, почему Вы себя называете мы. Вы нигде не представлялись, как коллектив авторов.
Вы уже видите, что Ваша статья не привлекла никакого внимания пользователей. Здесь начинается дискуссия по любому мало мальски стоящему поводу. Уже можете написать своим кураторам, чтобы переводили серебренники за проделанную работу.
На тот редкий и невероятный случай, что Вы действительно решили для себя проделать эту работу, то только в этом случае хотел Вам сказать, что Вы не туда полезли, и прямо нарушаете законодательство страны. Не удивляйтесь, это стандартная практика всех стран, запрещающих вмешиваться в выборы. Можете удивиться и написать статью про результаты выборов в штате Мичиган в 2020 году. И тогда мы с Вам увидимся лет через 18, если Вы попытаетесь это опубликовать где-то в района штата Мичиган.
ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в ClickBench, о котором статья) - если вы опубликуете такой бенчмарк про Оракл или MSSQL, готовьтесь быть арестованным в ближайшем аэропорту свободного мира - https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-database . Но у этого есть плюс - если видите в бенчмарках любое упоминание этих неприкасаемых, сразу ясно, кто за него платит за этот бенчмарк, и почему все остальные такие плохие.
Кстати, да, почему-то с этим колоночными типами бенчмарка нет. тут хотя бы сопоставимая среда сравнивалась - Postgres с колонками и без
не надо так строго критиковать этот бенчмарк, это как ребенка обижать 😀, рука не поднимается. В нем некоторые базы сами по умолчанию строят индексы в больших количествах, поскольку такой формат таблицы. Зато на вопрос - что со скоростью записи ? - ответ будет - какой записи? Это аппенд-онли таблица, причем на один раз. Метаданные, индексы - все в конце таблицы, дописать - это создать новую такую же плюс новые данные. Зато мы ее из S3 можем считать, по сети. Такое видение OLAP сегодня у некоторых.
тут победить мог кто угодно, так как одним сказали скакать вон той короткой дорогой (используя индексы), а другим вон той длинной песчаной (без единого индекса) и с грузом (fillfactor у таблицы 70% для ускорения записи, а тестировалось только чтение). Этот бенчмарк изначально делался, чтобы оценить скорость нескольких систем, чтобы сделать выбор для конкретной ситуации.
А вот, кстати, и вариант для тестирования https://sqlize.online/sql/mssql2017/2fed3c7e1c23a573e04630837f8f82a8/
Про парсер - я имею в виду, что парсер создал для VALUES двумерный массив выражений (строка-столбец). Эти выражения могут давать константный результат, то это не известно - для этого надо вычислить значения этих элементов. На этапе парсера и на этапе начала планирования нельзя сказать, из константных элементов состоит VALUES или там есть переменные. А когда уже можно сказать, то уже поздно что-то менять. Интересно, а mssql как делает планирование таких VALUES. У меня под рукой его нет.
Тут даже более приземленно - для планировщика это одно из отношений (с типом VALUES) и он ничего не знает о его содержимом, так как его окончательное содержимое выдаст экзекьютор, выполнив этот узел.
Пока parser отдельно не выделяет константные VALUES (без условий, сортировок и LIMIT), планировщик ничего не сможет сделать
А не может быть причиной то, что VALUES были в SQL всегда, а массивы появились в PostgreSQL значительно позднее? Традиционно PostgreSQL считает, что VALUES - это один из видов отношений, и обрабатывает его сразу, как отношение. IN ( rowset) на раннем этапе планирования преобразовывается в JOIN, и после этого момента константный VALUES поздно оптимизировать (функции и константные выражения обрабатываются позднее). Думаю, разумнее, чтобы такие вещи делал все-таки сервер, а не программисту DB разбираться в особенностях планировщика - у программиста DB своих проблем на своем уровне хватает.
При создании модели планировщика можно учитывать текущую нагрузку сервера, как параметр? Например, при высокой нагрузке будут строится планы с учетом этой нагрузки (например, без parallel workers, так как они сейчас все заняты, или меньше памяти под какой-то вариант плана - это уже модель сама решит, что поменять). Чтобы модель не только умно планы создавала, но умно реагировала на нагрузку сервера
Может быть об этом надо дополнительно сказать в документации к IN. Тем более, что оба оператора IN описываются в двух разных разделах. Пока на грабли не наступят, не обратят на это внимание. Как из вопросов про английский:"Иногда вижу has, иногда had - никак не пойму разницу, почему буква на конце разная"
Интересно, что пользователи используют такую конструкцию IN (VALUES(1),(2)...) и видят замедление запроса, и пытаются это понять, но это им не очевидно. Это из реальных вопросов программистов. То, что IN - это два разных оператора в случае массива справа и набора данных из одного поля справа - это не очевидно. Соответственно, не очевидно, что надо запрос переделать на более оптимальный.
Спасибо! Прочитал и вдохновился.
Добрый день!
Вы написали "Хотя она (PostgreSQL) и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа." Не могли бы Вы сослаться хотя бы на один источник информации, откуда следует, что Postgres работает медленнее (по контексту - Oracle). Oracle юридически запрещает все бенчмарки. Вы видели какие-то сравнения по скорости? Хотел тоже посмотреть.
Векторными называют базы, в которых есть функция поиска (быстрого поиска) векторов (вектор - длинный массив чисел, хранить могут почти все базы, но быстро искать - почти никто). Чтобы точно найти ближайший вектор, надо полностью перебрать всю базу (это математическая теорема), поэтому используют приблизительный поиск. Обычно - чем меньше точность поиска, тем больше скорость и наоборот. Точность можно измерить на тестовых наборах данных или в своем приложении - при разных параметрах Вы просто видите, что поиск начал выдавать какую-то ерунду и увеличиваете точность поиска параметрами.
>Но будет ли такая инсталляция лицензионной?
Скажите, а почему Вы задаетесь таким вопросом? Вы же не видели лицензионного соглашения на тот ключ, и не можете рассуждать без него о правомерности использования ключа. Вы не собственник лицензии, но Вас почему-то беспокоит, что кто-то кому-то переслал ключ от чужой программы. Не первый раз вижу подобные заявления, и не понимаю их смысла.
Если не секрет, что за работа, на которой приходилось заниматься векторами? Просто интересно, кто уже реально этой технологией пользовался для работы, а не для тестирования.
У меня сейчас повился Макбук про с функциональными кнопками вместо тачбара, и я счастлив после 5 лет мучения. Вот уж о вкусах не спорят.
Не отрицая разумности изложенных правил рынка труда, хочу обратить внимание на факты, обсуждение которых сейчас избегают, так как это тема хуже Холокоста евреев с 6 миллионами погибших, а виновники живы до сих пор: в России в 90-е годы вместо 20-25 миллионов родилось около 10 миллионов детей. 10 миллионов просто не родилось, а они сейчас должны были пойти на работу, менять тех, кто уходит на пенсию. Плюс к этому увеличение смертности в полтора раза. Теперь каждые 30 лет будет волна спада рождаемости. Это и есть причина дефицита, просто нет людей. И это никак не компенсировалось мигрантами.
Только надо привязать в одном из тех шести прямоугольников, так как наружи неисправные поезда не поедут, и до 21 ноября, иначе они из-за "неисправного" компрессора тоже не выйдут на маршрут.
Я не вполне понял, почему Вы себя называете мы. Вы нигде не представлялись, как коллектив авторов.
Вы уже видите, что Ваша статья не привлекла никакого внимания пользователей. Здесь начинается дискуссия по любому мало мальски стоящему поводу. Уже можете написать своим кураторам, чтобы переводили серебренники за проделанную работу.
На тот редкий и невероятный случай, что Вы действительно решили для себя проделать эту работу, то только в этом случае хотел Вам сказать, что Вы не туда полезли, и прямо нарушаете законодательство страны. Не удивляйтесь, это стандартная практика всех стран, запрещающих вмешиваться в выборы. Можете удивиться и написать статью про результаты выборов в штате Мичиган в 2020 году. И тогда мы с Вам увидимся лет через 18, если Вы попытаетесь это опубликовать где-то в района штата Мичиган.