Разработчики OrioleDB проанализировали текущее состояние низкоуровневого API, применяемого для доступа расширений к таблицам и индексам в PostgreSQL (Table/Index Access Method (AM) API), и предложили пути его улучшения. С момента появления в PostgreSQL 12 подобного API разработчики получили возможность создавать альтернативные механизмы хранения данных. Однако, несмотря на наличие этого API и известные ограничения встроенного механизма хранения, до сих пор не появилось полнофункциональных транзакционных движков хранения, реализованных исключительно в виде расширений...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62991
Сколько глупостей в одном исследовании. Почему просто не сделаете свою СУБД со своими фишечками? Нет, надо внести ещё больший раздрай, 100500 вариантов, чтобы никто не разобрался и даже в теории не смог поддерживать всё это хозяйство.
Потому что потом автор "своей СУБД" окажется перед выбором - либо синкать свой патчсет с каждым релизом основной СУБД, либо остаться без всех тех улучшений, которые получит основная СУБД после создания форка.
> ещё больший раздрай, 100500 вариантовИз которых каждому достаточно разобраться в том, которые мему подходит.
А кто сказал, что это должен быть форк?
> А кто сказал, что это должен быть форк?Это очевидным образом следует из текста новости - имеется успешно работающий продукт, к которому некие люди хотят прикрутить дополнительные фичи. Если ты считаешь, что для этого надо пилить с нуля новый велосипед, то я присоединюсь к рекомендации нах.а - пили.
Oracle DB - это большой энтерпрайс и госсектор. Альтернатива должна хорошо финансироваться. Весь бэкенд Сбера на oracledb был. Если не могут тащить свой форк - пусть сворачиваются.
SQL-я на ночь начитался ? Причём тут Oracle ? Или слава Доренко спать не даёт ?
Сбер форкнул Орацле? 8-) ;-)
> Сколько глупостей в одном исследовании. Почему просто не сделаете свою СУБД со своими
> фишечками?делай, кто тебе мешает? Покажи парням, как надо!
Эти вот - разумно полагают что повторить труд проделанный сотнями человек на двух континентах за 30 лет (больше, потому что был еще ingres) - немного так себе перспективка, можно и не дожить до результатов.
> чтобы никто не разобрался и даже в теории не смог поддерживать всё это хозяйство.
да ты и так не разберешься. Для тебя ничего не поменяется. Поддерживальщик...
post потому и пост, что не ингрес. а еще вертика появилась.
Хотя бы потому, что undo log - вовсе не панацея и есть немало профилей использования, где он проигрывает родному MVCC в PostgreSQL. Поэтому поддержка и того, и другого выглядит вполне логичным решением.
Не поддержка, а access method. Так-то умников хватает, zheap тот же взять.
> Не поддержка, а access method. Так-то умников хватает, zheap тот же взять.Это разные вещи, причем в статье явно это показано. Текущая реализация API способов доступа не позволяет реализовать поддержку undo log.
С нуля повторить тридцатилетний опыт разработки? Зачем? Многие вещи в Postgresql сделаны хорошо и проверены десятилетиями реального использования в крупных проектах. А любая новая реализация будет проходить по тем же (или новым) граблям ещё как минимум 10 лет.Форк? Патчи уже существует. Синхронизировать такие низкоуровневые патчи с изменениями в апстриме без деградации после каждого мажорного обновления практически нереально, только с огромным отставанием на полгода-год. Плюс, патчи, чтобы минимизировать их размер, специфичны именно для конкретного движка. А расширением внутренних структур и API предлагается открыть путь к реализации новых движков путем написания расширений. Существующий движок эти изменения никак не затронут - он ими пользоваться не будет. Хотя, в перспективе, решение с undo log могло бы стать и дефолтным - у него ряд бесспорных преимуществ.
p.s.s. когда я ещё был студентом наш преподаватель решил нам преподать .net. Не знаю почему, насколько мне известно в других универах не учили. Он такой спрашивает - вы знаете что сотворило Майкрософт? Новейшая перспективная технология ADO.NET. Кто-то уже использовал ADO? Я поднимаю руку, а он такой скептически типа откуда я её могу знать? И как-то прервал меня. А у Borland Delphi она уже годами существовала. Потом такой про базы данных начинает рассказывать, а на тот момент тот же (ныне убогий) Paradox уделывал их же Microsoft Access. И все равно он был популярней для обучения. Но главное как саму культуру программирования испоганили - на пустом месте раздувалось ЧСВ из-за того что кто-то одни технологии знает, а кто-то другие. И вот это пустое преимущество через рекламу, пиар, сарафанное радио откровенно грязные методы продвижения своих технологий
Зря вы удалили комментарий. Я о том что все это раздувание проблемы на пустом месте, а соответственно далее пойдет реклама других технологий - либо сделают расширение под переход на другие технологии (что вряд ли), либо далее пойдет реклама других СУБД, которые решают эту проблему.
ничего не глупостей
движки нужны
и помимо того, что нужно унифицировано их поставлять в форме дополнений
нужно чтобы SQL код бесшовно работал между таблицами и индексами на разных движках
Так я что-то не понял - orioledb не в виде "годится для альфа-тестов" можно уже не ждать?
Не утрируйте:"...Status
OrioleDB now has public beta status. It is recommended for experiments, testing, benchmarking, etc., but is not recommended for production usage..."Так что на данный момент, похоже, используют то, что имеется, что, как показывает новость, неоптимально для проекта. Потому предположу, что пока "можно не ждать" каких-то мега прорывных (по сравнению с ванильным PG) результатов.
молодой человек, вы понимаете сущность слова "гипербола", "метафора" или маску эту - на стройке нашли?> It is recommended for experiments, testing, benchmarking, etc.,
вот это и был намек - что оно уже третий год рекомендед для бенчмаркинга, а судя по планов по реструктурированию громадью - мы и дальше будем только бенчмаркать, делая раз в месяц vacuum full.
> Потому предположу, что пока "можно не ждать" каких-то мега прорывных (по сравнению с
> ванильным PG) результатов.ванильный можно использовать (если осторожно). А тут похоже на признание что разработка застряла в безнадежном тупике и если авторы постгреза не захотят (а они не захотят потому что план госпопила импортозамещения сам себя не выполнит) круто поменять здоровенные куски кода - то так и останется for experiments.
Мутный какой-то этот OrioleDB
- замена данных по месту (без освобождения текущей записи и создания новой);
- прямое связывание страниц в оперативной памяти со страницами в постоянном хранилище.Вспомнили прошлый век?!
> - замена данных по месту (без освобождения текущей записи и создания новой);
> Вспомнили прошлый век?!Твое "современное" (постгресное) изменение строк путём добавления новой строки (для "простой и элегантной" реализации MVCC) наверное уместно только для таблиц без индексов. А для таблиц с индексами в системах, где данные меняются интенсивно - "какастрофа". Таблиц с индексами в БД обычно больше, чем без индексов. Да и эффект распухания БД из-за (пока) "неосвобожденных" строк и из-за вакуума (необходимого для их "освобождения") - "какастрофа плюс". А MVCC (для которого и было принято такое архитектурное решение) и другими средствами реализуется. Так что "прошлый век" (изменение строк инплэйс) _на практике_ рулит.
И чего это люди FAT-ом и dbf-ами не пользуются - там же всё напрямую пишется, даже ram-only поля в файл проецируются с мусором.
OrioleDB и OracleDB это типа как Adibas и Adidas ?
Есть такое. "Предлагаю улучшить в виндовсе формат exe до elf".
> "Необходимо улучшить в виндовсе формат exe до elf".поправил
как ADABAS.
sapdb?
Когда уже проект из бета перейдёт в гамма стадию?
@Alexander Korotkov какие планы на этот год?[сообщение отредактировано модератором]
До конца этого года планируем GA.
Спасибо, будем посмотреть.
сначала хотел написать "Александр, перелогоньтесь!" :) а потом увидел "Автор новости: Alexander Korotkov" :)желаю успехов в этом нелёгком деле :)
Спасибр!
А у вас уже есть механизм в tableam или где-то еще, который если в create table присутствует primary key, позволял бы создавать вместо стандартного btree какой-то альтернативный индекс? Мне бы такое тоже пригодилось. То есть хочется иметь возможность задавать альтернативу вот этому прибитию гвоздями:>#define DEFAULT_INDEX_TYPE "btree"
>
>index->accessMethod = constraint->access_method ? constraint->
> access_method : DEFAULT_INDEX_TYPE;
>
>access_method_clause:
> USING name { $$ = $2; }
> | /*EMPTY*/ { $$ = DEFAULT_INDEX_TYPE; }
> ;
Встроенного такого механизма нет, несколько я знаю.
а вот интересно, в плане MVCC
иные движки, например citus columnstore, повторяют стандартный MVCC? вообще должны ли они его иметь и если имеют, о чем речь в статье? что они должны повторять его с пользовательской точки зрения или подкапотной?
Там список ограничений приличный. Как я понял, по факту MVCC и нет.https://github.com/citusdata/citus/blob/main/src/backend/col...