Ссылки на превосходство «эталона» ничем не обоснованы, так как бенчмарки с участием Оракла без письменного разрешения Оракла законодательно запрещены. Все крупнейшие базы реализованы на различных вариантах mvcc, бенчмарки показывают, что реализация в целом неплохая и конкурентоспособная. Сейчас статьи нет под рукой, но поищу и приложу ссылки на статьи с бенчмарками версионного контроля в базах.
ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в 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 ноября, иначе они из-за "неисправного" компрессора тоже не выйдут на маршрут.
Ссылки на превосходство «эталона» ничем не обоснованы, так как бенчмарки с участием Оракла без письменного разрешения Оракла законодательно запрещены. Все крупнейшие базы реализованы на различных вариантах mvcc, бенчмарки показывают, что реализация в целом неплохая и конкурентоспособная. Сейчас статьи нет под рукой, но поищу и приложу ссылки на статьи с бенчмарками версионного контроля в базах.
ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в 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 ноября, иначе они из-за "неисправного" компрессора тоже не выйдут на маршрут.