The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Разработчики OrioleDB предложили улучшить API для альтернативных движков PostgreSQL"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Разработчики OrioleDB предложили улучшить API для альтернативных движков PostgreSQL"  +/
Сообщение от opennews (??), 31-Мрт-25, 20:48 
Разработчики OrioleDB проанализировали текущее состояние низкоуровневого API, применяемого для доступа расширений к таблицам и индексам в PostgreSQL (Table/Index Access Method (AM) API), и предложили пути его улучшения. С момента появления в PostgreSQL 12 подобного API разработчики получили возможность создавать альтернативные механизмы хранения данных. Однако, несмотря на наличие этого API и известные ограничения встроенного механизма хранения, до сих пор не появилось полнофункциональных транзакционных движков хранения, реализованных исключительно в виде расширений...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62991

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –7 +/
Сообщение от Аноним (1), 31-Мрт-25, 20:48 
Сколько глупостей в одном исследовании. Почему просто не сделаете свою СУБД со своими фишечками? Нет, надо внести ещё больший раздрай, 100500 вариантов, чтобы никто не разобрался и даже в теории не смог поддерживать всё это хозяйство.
Ответить | Правка | Наверх | Cообщить модератору

9. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от YetAnotherOnanym (ok), 31-Мрт-25, 21:43 
Потому что потом автор "своей СУБД" окажется перед выбором - либо синкать свой патчсет с каждым релизом основной СУБД, либо остаться без всех тех улучшений, которые получит основная СУБД после создания форка.
> ещё больший раздрай, 100500 вариантов

Из которых каждому достаточно разобраться в том, которые мему подходит.

Ответить | Правка | Наверх | Cообщить модератору

10. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –1 +/
Сообщение от Аноним (1), 31-Мрт-25, 21:53 
А кто сказал, что это должен быть форк?
Ответить | Правка | Наверх | Cообщить модератору

27. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 08:44 
> А кто сказал, что это должен быть форк?

Это очевидным образом следует из текста новости - имеется успешно работающий продукт, к которому некие люди хотят прикрутить дополнительные фичи. Если ты считаешь, что для этого надо пилить с нуля новый велосипед, то я присоединюсь к рекомендации нах.а - пили.

Ответить | Правка | Наверх | Cообщить модератору

22. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –3 +/
Сообщение от Аноним (22), 01-Апр-25, 01:22 
Oracle DB - это большой энтерпрайс и госсектор. Альтернатива должна хорошо финансироваться. Весь бэкенд Сбера на oracledb был. Если не могут тащить свой форк - пусть сворачиваются.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

28. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +1 +/
Сообщение от 1 (??), 01-Апр-25, 09:04 
SQL-я на ночь начитался ? Причём тут Oracle ? Или слава Доренко спать не даёт ?
Ответить | Правка | Наверх | Cообщить модератору

40. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (40), 01-Апр-25, 12:40 
Сбер форкнул Орацле? 8-) ;-)
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

12. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –2 +/
Сообщение от нах. (?), 31-Мрт-25, 22:10 
> Сколько глупостей в одном исследовании. Почему просто не сделаете свою СУБД со своими
> фишечками?

делай, кто тебе мешает? Покажи парням, как надо!

Эти вот - разумно полагают что повторить труд проделанный сотнями человек на двух континентах за 30 лет (больше, потому что был еще ingres) - немного так себе перспективка, можно и не дожить до результатов.

> чтобы никто не разобрался и даже в теории не смог поддерживать всё это хозяйство.

да ты и так не разберешься. Для тебя ничего не поменяется. Поддерживальщик...

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

33. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от фывапролджэ (?), 01-Апр-25, 10:02 
post потому и пост, что не ингрес. а еще вертика появилась.
Ответить | Правка | Наверх | Cообщить модератору

13. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +3 +/
Сообщение от ptr (ok), 31-Мрт-25, 22:15 
Хотя бы потому, что undo log - вовсе не панацея и есть немало профилей использования, где он проигрывает родному MVCC в PostgreSQL. Поэтому поддержка и того, и другого выглядит вполне логичным решением.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

37. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от фывапролджэ (?), 01-Апр-25, 10:26 
Не поддержка, а access method. Так-то умников хватает, zheap тот же взять.
Ответить | Правка | Наверх | Cообщить модератору

29. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (29), 01-Апр-25, 09:04 
С нуля повторить тридцатилетний опыт разработки? Зачем? Многие вещи в Postgresql сделаны хорошо и проверены десятилетиями реального использования в крупных проектах. А любая новая реализация будет проходить по тем же (или новым) граблям ещё как минимум 10 лет.

Форк? Патчи уже существует. Синхронизировать такие низкоуровневые патчи с изменениями в апстриме без деградации после каждого мажорного обновления практически нереально, только с огромным отставанием на полгода-год. Плюс, патчи, чтобы минимизировать их размер, специфичны именно для конкретного движка. А расширением внутренних структур и API предлагается открыть путь к реализации новых движков путем написания расширений. Существующий движок эти изменения никак не затронут - он ими пользоваться не будет. Хотя, в перспективе, решение с undo log могло бы стать и дефолтным - у него ряд бесспорных преимуществ.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

36. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +1 +/
Сообщение от Аноним (-), 01-Апр-25, 10:24 
p.s.s. когда я ещё был студентом наш преподаватель решил нам преподать .net. Не знаю почему, насколько мне известно в других универах не учили. Он такой спрашивает - вы знаете что сотворило Майкрософт? Новейшая перспективная технология ADO.NET. Кто-то уже использовал ADO? Я поднимаю руку, а он такой скептически типа откуда я её могу знать? И как-то прервал меня. А у Borland Delphi она уже годами существовала. Потом такой про базы данных начинает рассказывать, а на тот момент тот же (ныне убогий) Paradox уделывал их же Microsoft Access. И все равно он был популярней для обучения. Но главное как саму культуру программирования испоганили - на пустом месте раздувалось ЧСВ из-за того что кто-то одни технологии знает, а кто-то другие. И вот это пустое преимущество через рекламу, пиар, сарафанное радио откровенно грязные методы продвижения своих технологий
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

38. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –1 +/
Сообщение от Аноним (-), 01-Апр-25, 10:32 
Зря вы удалили комментарий. Я о том что все это раздувание проблемы на пустом месте, а соответственно далее пойдет реклама других технологий - либо сделают расширение под переход на другие технологии (что вряд ли), либо далее пойдет реклама других СУБД, которые решают эту проблему.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –1 +/
Сообщение от нах. (?), 31-Мрт-25, 20:55 
Так я что-то не понял - orioledb не в виде "годится для альфа-тестов" можно уже не ждать?

Ответить | Правка | Наверх | Cообщить модератору

42. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (42), 01-Апр-25, 15:22 
Не утрируйте:

"...Status
OrioleDB now has public beta status. It is recommended for experiments, testing, benchmarking, etc., but is not recommended for production usage..."

Так что на данный момент, похоже, используют то, что имеется, что, как показывает новость, неоптимально для проекта. Потому предположу, что пока "можно не ждать" каких-то мега прорывных (по сравнению с ванильным PG) результатов.

Ответить | Правка | Наверх | Cообщить модератору

43. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от нах. (?), 01-Апр-25, 15:43 
молодой человек, вы понимаете сущность слова "гипербола", "метафора" или маску эту - на стройке нашли?

> It is recommended for experiments, testing, benchmarking, etc.,

вот это и был намек - что оно уже третий год рекомендед для бенчмаркинга, а судя по планов по реструктурированию громадью - мы и дальше будем только бенчмаркать, делая раз в месяц vacuum full.

> Потому предположу, что пока "можно не ждать" каких-то мега прорывных (по сравнению с
> ванильным PG) результатов.

ванильный можно использовать (если осторожно). А тут похоже на признание что разработка застряла в безнадежном тупике и если авторы постгреза не захотят (а они не захотят потому что план госпопила импортозамещения сам себя не выполнит) круто поменять здоровенные куски кода - то так и останется for experiments.

  

Ответить | Правка | Наверх | Cообщить модератору

4. "Разработчики OrioleDB предложили улучшить API для альтернати..."  –2 +/
Сообщение от Аноним (4), 31-Мрт-25, 21:08 
Мутный какой-то этот OrioleDB
- замена данных по месту (без освобождения текущей записи и создания новой);
- прямое связывание страниц в оперативной памяти со страницами в постоянном хранилище.

Вспомнили прошлый век?!

Ответить | Правка | Наверх | Cообщить модератору

41. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (42), 01-Апр-25, 15:05 
> - замена данных по месту (без освобождения текущей записи и создания новой);
> Вспомнили прошлый век?!

Твое "современное" (постгресное) изменение строк путём добавления новой строки (для "простой и элегантной" реализации MVCC) наверное уместно только для таблиц без индексов. А для таблиц с индексами в системах, где данные меняются интенсивно - "какастрофа". Таблиц с индексами в БД обычно больше, чем без индексов. Да и эффект распухания БД из-за (пока) "неосвобожденных" строк и из-за вакуума (необходимого для их "освобождения") - "какастрофа плюс". А MVCC (для которого и было принято такое архитектурное решение) и другими средствами реализуется. Так что "прошлый век" (изменение строк инплэйс) _на практике_ рулит.

Ответить | Правка | Наверх | Cообщить модератору

44. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (4), 01-Апр-25, 17:03 
И чего это люди FAT-ом и dbf-ами не пользуются - там же всё напрямую пишется, даже ram-only поля в файл проецируются с мусором.
Ответить | Правка | Наверх | Cообщить модератору

5. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +2 +/
Сообщение от Аноним (5), 31-Мрт-25, 21:20 
OrioleDB и OracleDB это типа как Adibas и Adidas ?
Ответить | Правка | Наверх | Cообщить модератору

11. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (4), 31-Мрт-25, 21:59 
Есть такое. "Предлагаю улучшить в виндовсе формат exe до elf".
Ответить | Правка | Наверх | Cообщить модератору

14. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +1 +/
Сообщение от Аноним (1), 31-Мрт-25, 22:36 
> "Необходимо улучшить в виндовсе формат exe до elf".

поправил

Ответить | Правка | Наверх | Cообщить модератору

30. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от 1 (??), 01-Апр-25, 09:06 
как ADABAS.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

32. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (32), 01-Апр-25, 09:22 
sapdb?
Ответить | Правка | Наверх | Cообщить модератору

23. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +2 +/
Сообщение от zo0Memail (ok), 01-Апр-25, 01:55 
Когда уже проект без бета перейдёт в гамма стадию?
@Alexander Korotkov какие планы на этот год?
Ответить | Правка | Наверх | Cообщить модератору

45. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +/
Сообщение от Аноним (4), 01-Апр-25, 17:04 
> планы

срубить бабла с кого-нибудь на очередную бету альфы.

Ответить | Правка | Наверх | Cообщить модератору

39. "Разработчики OrioleDB предложили улучшить API для альтернати..."  +2 +/
Сообщение от Аноним (39), 01-Апр-25, 10:42 
сначала хотел написать "Александр, перелогоньтесь!" :) а потом увидел "Автор новости: Alexander Korotkov" :)

желаю успехов в этом нелёгком деле :)

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру