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

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

Сообщения

[Сортировка по ответам | RSS]

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

2. Сообщение от нах. (?), 31-Мрт-25, 20:55	–1 +/–
Так я что-то не понял - orioledb не в виде "годится для альфа-тестов" можно уже не ждать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

4. Сообщение от Аноним (4), 31-Мрт-25, 21:08	–2 +/–
Мутный какой-то этот OrioleDB - замена данных по месту (без освобождения текущей записи и создания новой); - прямое связывание страниц в оперативной памяти со страницами в постоянном хранилище. Вспомнили прошлый век?!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

5. Сообщение от Аноним (5), 31-Мрт-25, 21:20	+3 +/–
OrioleDB и OracleDB это типа как Adibas и Adidas ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #30

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

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

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

12. Сообщение от нах. (?), 31-Мрт-25, 22:10	–2 +/–
> Сколько глупостей в одном исследовании. Почему просто не сделаете свою СУБД со своими > фишечками? делай, кто тебе мешает? Покажи парням, как надо! Эти вот - разумно полагают что повторить труд проделанный сотнями человек на двух континентах за 30 лет (больше, потому что был еще ingres) - немного так себе перспективка, можно и не дожить до результатов. > чтобы никто не разобрался и даже в теории не смог поддерживать всё это хозяйство. да ты и так не разберешься. Для тебя ничего не поменяется. Поддерживальщик...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #33

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

14. Сообщение от Аноним (1), 31-Мрт-25, 22:36	+1 +/–
> "Необходимо улучшить в виндовсе формат exe до elf". поправил
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

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

23. Сообщение от zo0M (ok), 01-Апр-25, 01:55	+2 +/–
Когда уже проект из бета перейдёт в гамма стадию? @Alexander Korotkov какие планы на этот год? [сообщение отредактировано модератором]
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

27. Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 08:44	–1 +/–
> А кто сказал, что это должен быть форк? Это очевидным образом следует из текста новости - имеется успешно работающий продукт, к которому некие люди хотят прикрутить дополнительные фичи. Если ты считаешь, что для этого надо пилить с нуля новый велосипед, то я присоединюсь к рекомендации нах.а - пили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

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

29. Сообщение от Аноним (29), 01-Апр-25, 09:04	+/–
С нуля повторить тридцатилетний опыт разработки? Зачем? Многие вещи в Postgresql сделаны хорошо и проверены десятилетиями реального использования в крупных проектах. А любая новая реализация будет проходить по тем же (или новым) граблям ещё как минимум 10 лет. Форк? Патчи уже существует. Синхронизировать такие низкоуровневые патчи с изменениями в апстриме без деградации после каждого мажорного обновления практически нереально, только с огромным отставанием на полгода-год. Плюс, патчи, чтобы минимизировать их размер, специфичны именно для конкретного движка. А расширением внутренних структур и API предлагается открыть путь к реализации новых движков путем написания расширений. Существующий движок эти изменения никак не затронут - он ими пользоваться не будет. Хотя, в перспективе, решение с undo log могло бы стать и дефолтным - у него ряд бесспорных преимуществ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

30. Сообщение от 1 (??), 01-Апр-25, 09:06	+/–
как ADABAS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #32

32. Сообщение от Аноним (32), 01-Апр-25, 09:22	+/–
sapdb?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

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

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

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

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

39. Сообщение от Аноним (39), 01-Апр-25, 10:42	+3 +/–
сначала хотел написать "Александр, перелогоньтесь!" :) а потом увидел "Автор новости: Alexander Korotkov" :) желаю успехов в этом нелёгком деле :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

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

41. Сообщение от Аноним (42), 01-Апр-25, 15:05	+1 +/–
> - замена данных по месту (без освобождения текущей записи и создания новой); > Вспомнили прошлый век?! Твое "современное" (постгресное) изменение строк путём добавления новой строки (для "простой и элегантной" реализации MVCC) наверное уместно только для таблиц без индексов. А для таблиц с индексами в системах, где данные меняются интенсивно - "какастрофа". Таблиц с индексами в БД обычно больше, чем без индексов. Да и эффект распухания БД из-за (пока) "неосвобожденных" строк и из-за вакуума (необходимого для их "освобождения") - "какастрофа плюс". А MVCC (для которого и было принято такое архитектурное решение) и другими средствами реализуется. Так что "прошлый век" (изменение строк инплэйс) _на практике_ рулит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #44

42. Сообщение от Аноним (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ообщить модератору
Родитель: #2 Ответы: #43

43. Сообщение от нах. (?), 01-Апр-25, 15:43	+/–
молодой человек, вы понимаете сущность слова "гипербола", "метафора" или маску эту - на стройке нашли? > It is recommended for experiments, testing, benchmarking, etc., вот это и был намек - что оно уже третий год рекомендед для бенчмаркинга, а судя по планов по реструктурированию громадью - мы и дальше будем только бенчмаркать, делая раз в месяц vacuum full. > Потому предположу, что пока "можно не ждать" каких-то мега прорывных (по сравнению с > ванильным PG) результатов. ванильный можно использовать (если осторожно). А тут похоже на признание что разработка застряла в безнадежном тупике и если авторы постгреза не захотят (а они не захотят потому что план госпопила импортозамещения сам себя не выполнит) круто поменять здоровенные куски кода - то так и останется for experiments.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

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

46. Сообщение от Алексей Демаков (?), 02-Апр-25, 10:43	+/–
А у вас уже есть механизм в 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; } > ;
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53

47. Сообщение от nrv (ok), 02-Апр-25, 10:58	+/–
ничего не глупостей движки нужны и помимо того, что нужно унифицировано их поставлять в форме дополнений нужно чтобы SQL код бесшовно работал между таблицами и индексами на разных движках
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

48. Сообщение от nrv (ok), 02-Апр-25, 11:03	+1 +/–
а вот интересно, в плане MVCC иные движки, например citus columnstore, повторяют стандартный MVCC? вообще должны ли они его иметь и если имеют, о чем речь в статье? что они должны повторять его с пользовательской точки зрения или подкапотной?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

49. Сообщение от ptr (ok), 02-Апр-25, 19:16	+/–
> Не поддержка, а access method. Так-то умников хватает, zheap тот же взять. Это разные вещи, причем в статье явно это показано. Текущая реализация API способов доступа не позволяет реализовать поддержку undo log.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

50. Сообщение от Alexander Korotkov (?), 04-Апр-25, 10:59	+/–
До конца этого года планируем GA.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #54

51. Сообщение от Alexander Korotkov (?), 04-Апр-25, 10:59	+/–
Спасибр!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

52. Сообщение от Alexander Korotkov (?), 04-Апр-25, 11:04	+/–
Там список ограничений приличный.  Как я понял, по факту MVCC и нет. https://github.com/citusdata/citus/blob/main/src/backend/col...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

53. Сообщение от Alexander Korotkov (?), 04-Апр-25, 11:08	+/–
Встроенного такого механизма нет, несколько я знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

54. Сообщение от zo0M (ok), 05-Апр-25, 11:12	+/–
Спасибо, будем посмотреть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

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

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