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

"Седьмая бета версия OrioleDB, высокопроизводительного движка хранения для PostgreSQL"	+/–
Сообщение от opennews (??), 02-Дек-24, 08:19
Представлена бета-версия движка хранения OrioleDB beta7 и опубликованы результаты новых тестов, демонстрирующих значительное повышение производительности по сравнению с традиционным PostgreSQL. В версии beta7 были внедрены оптимизации, направленные на улучшение работы с многопоточными нагрузками и ускорение операций чтения и записи. Первый стабильный релиз OrioleDB планируется сформировать в 2025 году.  Движок написан на языке Си и распространяется под лицензией PostgreSQL, похожей на лицензии BSD и MIT... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62327
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
Сообщение от Аноним (1), 02-Дек-24, 08:19
Неужели не врут или опять графики подрисовали?
Ответить | Правка | Наверх | Cообщить модератору

	2. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+7 +/–
	Сообщение от Аноним (2), 02-Дек-24, 08:21
	Может, и не врут, только вот сколько букв от ACID осталось?
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
	Сообщение от Аноним (7), 02-Дек-24, 09:13
	Просто покажи циферки побольше и менеджмент будет доволен.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+5 +/–
	Сообщение от funny.falcon (?), 02-Дек-24, 10:50
	Всё там с ACID в порядке. Архитектура Постгресса действительно не оптимальна в нынешних реалиях, и сделать что-то выделяющееся на её фоне вполне возможно.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	33. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–2 +/–
	Сообщение от freebzzZZZzzd (ok), 02-Дек-24, 17:57
	>Всё там с ACID в порядке а ты кто? вот когда jepsen пруфнет, тогда поверим. у субд вообще много разных проблем, не только бинарное "acid да/нет". по описанию вообще шг в сторону монго сделали ) осталось JSON нормально сделать и лет 5 повылизывать код. и получится что-то путнее
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (51), 03-Дек-24, 12:31
	Они сделали хранилище как сделано в оракл
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 06-Дек-24, 10:55
	Гарантии ACID такие же как и в дефолтовом движке PostgreSQL, за исключением отсутствия поддержки SSI (за всю карьеру не припомню случая где он был бы реально необходим). Но на текущем этапе зрелости проекта серьёзные баги, конечно, могут быть.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	98. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 06-Дек-24, 14:26
	SSI нужен. Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной. Хотя, конечно, кратно больше ситуаций, где SSI излишен совершенно и RC/RR достаточно.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+2 +/–
	Сообщение от Alexander Korotkov (?), 06-Дек-24, 19:04
	> Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной. Безусловно. На моей пратике большинство таких кейсов прекрасно решалось с помощью row-level locks/advisory locks. Можно сказать, что преимущество SSI – это возможность просто получить гарантии сериализуемости и не думать о тонкостях concurrency. Но при этом у SSI есть недостатки. 1) Накладные расходы. Транзакция ставит predicate locks на все затрагиваемые heap tuples и индексные страницы (не только при записи, но и при чтении). Локов может оказаться очень много, в этом случае, насколько я помню, они апгрейдятся до локов на целый relation. Оценка оверхеда в 10%, полученная при разработке SSI, была получена на не очень мощном железе и не очень большой concurrency. 2) Необходимость учить приложение повторять любую транзакцию, которая упала из-за ошибок сериализации. Причём это относится даже к read-only траназкциям. Или же нужно ждать гарантированно сериализуемого снапшота, как это делает pg_dump. Ну и конечно, повторения транзакций тоже добавлют оверхед. В итоге за свою карьеру я не видел ни одного кейса, где плюсы использования SSI были бы больше чем минусы. Хрестоматийным примером SSI так и остаётся суд штата Wisconsin, которому "очень нужна была консистентность данных в правосудии", и который проспонсировал работу над SSI. Больше никаких деталей не известно. Поймите меня правильно, я с большим уважением отношусь к SSI и всем кто приложил руку к её разработке. SSI в PostgreSQL – это хорошая реализация прекрасной области computer science, по ней можно учить студентов. Но если вы поделитесь годным use case'ом, где применение SSI оправдано, это расширит моё понимание вопроса (без иронии).
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от ptr (ok), 04-Дек-24, 17:20
	Может и не врут, но TPC-C - это всё же тест больше на модификацию, чем на выборку. И вообще без тяжелых выборок. А на аналитическом профиле нагрузки можно получить наоборот, большой провал. UnDo лог должен хранить записи до завершения всех транзакций, которые начались до попадания записи в UnDo лог. Да еще и эффективно находить эти записи для таких транзакций, так как они должны видеть  эти записи такими, какими они были на момент начала транзакции. И тут вполне можно потерять больше, чем выиграл на модификациях в страницах по месту.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	96. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 06-Дек-24, 10:53
	Если не верите – проверяйте. Некоторые уже так и сделали. https://x.com/MinisterOfEng/status/1864793214282019065
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–2 +/–
Сообщение от Аноним (3), 02-Дек-24, 08:30
>планируется сформировать в 2025 году А пока: https://db-engines.com/en/ranking
Ответить | Правка | Наверх | Cообщить модератору

	10. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+8 +/–
	Сообщение от chdlb (?), 02-Дек-24, 10:16
	а теперь смотрим как он считается:     Number of mentions of the system on websites, measured as number of results in search engines queries. At the moment, we use Google and Bing for this measurement. In order to count only relevant results, we are searching for <system name> together with the term database, e.g. "Oracle" and "database".     General interest in the system. For this measurement, we use the frequency of searches in Google Trends.     Frequency of technical discussions about the system. We use the number of related questions and the number of interested users on the well-known IT-related Q&A sites Stack Overflow and DBA Stack Exchange.     Number of job offers, in which the system is mentioned. We use the number of offers on the leading job search engines Indeed and Simply Hired.     Number of profiles in professional networks, in which the system is mentioned. We use the internationally most popular professional network LinkedIn.     Relevance in social networks. We count the number of Twitter (X) tweets, in which the system is mentioned. т.е. достаточно, чтобы  было много головняка - и упс, ты лидер на форумах или в поисковых запросах это явно не то что ожидаешь под словом RANK, понимая его как некую функцию от качества продукта, неизвестну. функции, но от характеристик продукта, а не вот это вот всё
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от нах. (?), 02-Дек-24, 15:44
	> это явно не то что ожидаешь под словом RANK но хотя бы - интересно. И да, те у кого все работает, не будут оставлять хвалебные отзывы в "twitter events". А вот "оно опять %%!$!" - да. Так что инфа полезная, главное уметь понять.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Прохожий (??), 03-Дек-24, 01:36
	> т.е. достаточно, чтобы  было много головняка 1. То есть вот этот критерий "Number of job offers" вы в попытке построить свою логическую цепочку почему-то упустили. Почему?. 2. Кроме того, вот это "Frequency of technical discussions about the system" не обязательно обозначает "головняк", а ещё и богатство фич. Что имеется ввиду? У СУБД "А" таких фич нет, поэтому обсуждать там нечего. У СУБД "Б" такие фичи есть, поэтому их обсуждают. 3. Ещё одни фактор, который вы упустили -  это "Number of profiles in professional networks". Что это означает? Это означает, что если специалистов по СУБД "Б" больше, чем специалистов по СУБД "Б", то, очевидно, СУБД "Б" более популярна. Не правда ли? Подытожу. Вы выбрали для вашего вывода только те факты, которые удобны вам. То есть, просто подогнали их под себя, чтобы они не противоречили вашей картине мира. Имеете право, разумеется, но к объективности это не имеет никакого отношения. Я не говорю, что представленный хит-парад - идеальный. Но, думаю, он более-менее близок к реальному положению дел. > это явно не то что ожидаешь под словом RANK, понимая его как некую функцию от качества продукта Успехов вам создать свой собственный RANK по вашим критериям. Однако вряд ли у вас получится что-то действительно путное и лучшее, чем то, что есть. Почему? Потому что люди, которые выбирают СУБД для своих нужд в общем и целом не идиоты. То есть, смею предположить, часто (не всегда) их выбор вполне осознанный.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	41. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Прохожий (??), 03-Дек-24, 01:37
	Опечатка: если специалистов по СУБД "Б" больше, чем специалистов по СУБД "А" - так правильно
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от chdlb (?), 03-Дек-24, 09:18
	Я ничего не выбирал, а сказал, что этот ранк бессмысленный по своей сути и показывает НИЧЕГО. > То есть вот этот критерий "Number of job offers" вы в попытке построить... Number of job offers, не значит ровным счетом ничего? потому что его можно по-другому интерпретировать, например, дефицит кандидатов из-за нежелания связываться с той или иной СУБД, отсюда повышенный спрос - это все гадания на манной каше. > то, очевидно, СУБД "Б" более популярна. Не правда ли? - нет не правда. Но и опять-таки, какое отношение это имеет к ранку? Популярность - это не функция от качества. > Подытожу. Вы выбрали для вашего вывода только те факты, которые удобны вам. То есть, просто подогнали их под себя, чтобы они не противоречили вашей картине мира. Какая прекрасная ошибка выжившего ))) Знаешь больше, чем тупые люди, раздражают только псевдо-интеллектулы с самомнением. Ты сам подогнал мои ответы под нужный тебе знаменатель, чтобы блеснуть (нет) эрудицией, потому что очень хотелось оппонировать. Я привел полный список критериев на суд каждого, и один пример от меня, который показывает, что ранк вполне может быть необъективным, и корелляция там неоднозначная. И не более... P.S. > Потому что люди, которые выбирают СУБД для своих нужд в общем и целом не идиоты. Люди не идиоты? Пффф, вот это ты юморист...
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

4. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+3 +/–
Сообщение от Catwoolfii (ok), 02-Дек-24, 08:48
Для всех этих подключаемых движков не поддерживается партиционирование таблиц.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+2 +/–
	Сообщение от chdlb (?), 02-Дек-24, 10:17
	а для всего постгреса шардинг, постгрес в принципе сильно переоценен
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
	Сообщение от Аноним (98), 03-Дек-24, 12:13
	Шардинг это не про РСУБД вообще. Как слоить данные решение прикладного уровня, а не модельного.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от chdlb (?), 03-Дек-24, 18:07
	тот случай, когда даже электромоторчик из детской машинки умнее, чем очередной Аноним погугли список распределенных RDBMS с шардингом на уровне бд - удивишься а некоторые из них еще и синхронные, т.е полноценный multi-master притом некоторые из них еще и кластерные с балансировкой нагрузки между нодами
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от chdlb (?), 03-Дек-24, 18:15
	теперь что касается "слоить", прикладной уровень, модельный - я такого дерьма в голове с терминологией не видел очень давно, потому что всячекски старался избегать дешевых бложиков в БД у тебя не модели, а таблицы, будет ли отражено это на модели в предметной области (он же domain в DDD) - это еще вопрос в любом случае даже если моя БД, будет из одной таблицы, она все равно может шардится...  ))) что там под слоить понимаешь вообще никто не знает, как в принципе и "прикладной уровень", так то СУБД тоже "прикладной уровень" )))
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	85. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–2 +/–
	Сообщение от Аноним (98), 04-Дек-24, 12:10
	Дружок, шардинг это когда разраб на уровне р-модели (да-да) решает, что некая сущность предметной области может быть для каких-то чисто практических целей (не модельных) представлена не одним отношением, а сразу несколькими (хотя теория этого не требует). Например, разраб решил, что Клиента можно поделить на Клиент_СПБ и Клиент_МСК, чтобы потом при реализации локализовать траффик. Может ли это решение за разраба принять инструмент? Может, и таких инструментов достаточно. Вносит ли такой инструмент корректировку в прикладную модель? Да. Имеет ли это какое-то отношение к р-теории и рсубд? Нет, никакого. Такое решение о декомпозиции не диктуется теорией, а принимается, надо полагать, осознанно разработчиком. Такое решение меняет модель? Да, безусловно, т.е. это решение прикладного модельного уровня, а не как, скажем, секционирование или смена плана исполнения, чисто уровня реализации.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от chdlb (?), 04-Дек-24, 15:04
	> Дружок, шардинг это когда разраб на уровне р-модели (да-да) решает, что некая сущность предметной области может быть для каких-то чисто практических целей (не модельных) представлена не одним отношением, а сразу несколькими (хотя теория этого не требует). Например, разраб решил, что Клиента можно поделить на Клиент_СПБ и Клиент_МСК, чтобы потом при реализации локализовать траффик. Может ли это решение за разраба принять инструмент? Может, и таких инструментов достаточно. Вносит ли такой инструмент корректировку в прикладную модель? Да. Имеет ли это какое-то отношение к р-теории и рсубд? Нет, никакого. Такое решение о декомпозиции не диктуется теорией, а принимается, надо полагать, осознанно разработчиком. Такое решение меняет модель? Да, безусловно, т.е. это решение прикладного модельного уровня, а не как, скажем, секционирование или смена плана исполнения, чисто уровня реализации. этот бред надо заскринить ))) это даже прочитать сложно, но ладно, если ты решил что ты будешь шардить на уровне приложения, то это еще не значит: 1) что нет распределенных RDBMS которые делают это сами, собственно формируя кластер, и освобождая приложение от такой задачи 2) что тебе нужно разбивать сущность на две, даже если делать шардинги на уровне логики приложения (что само по себе уже сомнительно), то твое решение с двумя моделями - просто дно, "представлена не одним отношением, а сразу несколькими" - не является шардингом, при шардинге схема БД не меняется, и шардинг - это грубо говоря распределенное между серверами горизонтальное партиционирование неужели так сложно "погуглить список распределенных RDBMS с шардингом на уровне бд?" я вообще не понимаю зачем я тебе что-то объясняю, ты только больше не пиши мне "со своим роялем"
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
	Сообщение от Аноним (98), 04-Дек-24, 15:40
	"горизонтальное партиционирование" )))) Витгентштейн (с)
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
	Сообщение от Аноним (98), 04-Дек-24, 15:53
	При шардинге схема как может меняться, так может и не меняться. Если есть сущность с запредельным количеством реализаций, то подразумевается изменение модели -- вместо одной сущности в модели появляются n-сущностей, по которым распределяются реализации исходной. Ещё раз. Имеет ли это какое-то отношение именно к Рсубд? Нет. Не имеет. Ещё раз, такая декомпозиция диктуется не теорией отношений, а реализацией.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	90. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
	Сообщение от Аноним (98), 04-Дек-24, 16:06
	Если обобщить, то критерий шардирования/секционирования простой -- если в модель вводятся новые сущности, между которыми перераспределяются реализации прежде одной сущности, то это шардирование, если новые сущности не вводятся на уровне модели, а "физически" перераспределяются только реализации всё той же сущности, то это секционирование.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	91. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
	Сообщение от Аноним (98), 04-Дек-24, 16:24
	Продолжим. Если взять, скажем, кусок сыру и фломастером разметить его на части, скажем, подписав на них "васе", "пете", "маше", то это разбиение куска сыра на секции -- кусок остался целым, но его снабдили мета-информацией для потребителя, провели секционирование. Если же кусок брутально нарезать ножом -- то это уже шардирование, потому что вместо одного куска сыра появилось много кусков. В пэтэу на курсах тебе такого не объяснят.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	92. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
	Сообщение от chdlb (?), 04-Дек-24, 16:55
	> Продолжим. Если взять, скажем, кусок сыру и фломастером разметить его на части, > скажем, подписав на них "васе", "пете", "маше", то это разбиение куска > сыра на секции -- кусок остался целым, но его снабдили мета-информацией > для потребителя, провели секционирование. Если же кусок брутально нарезать ножом -- > то это уже шардирование, потому что вместо одного куска сыра появилось > много кусков. > В пэтэу на курсах тебе такого не объяснят. я даже уже не читаю, что ты пишешь, и я надеюсь от твоих решений никто не зависит, особенно самолеты, медицинские приборы, критическая инфраструктура и т.д. скрестил пальцы
	Ответить | Правка | Наверх | Cообщить модератору

5. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+3 +/–
Сообщение от DEF (?), 02-Дек-24, 09:02
Когда эта вундервафля войдет в состав PostgreSQL?
Ответить | Правка | Наверх | Cообщить модератору

	12. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от chdlb (?), 02-Дек-24, 10:19
	это было бы логичным решением, но только если на замену родного движка, как подключаемый не вариант
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от www2 (??), 02-Дек-24, 10:53
	PostgreSQL - очень консервативная система. Пока что в виде подключаемого движка, потом, когда-нибудь, поменяют настройки и он по умолчанию будет использоваться при создании новых таблиц. Потом, глядишь, его начнут использовать большинство инсталляций. И только потом старый движок отключат, возможно, удалят, как устаревший. Но всё это пока что вилами на воде писано. Надо хотя бы дождаться выпуска стабильной версии и доработки интерфейсов PostgreSQL для подключения этого движка без необходимости накладывать заплатки на исходный текст и пересобирать из исходников.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от нах. (?), 02-Дек-24, 11:45
	> Пока что в виде подключаемого движка оно уже перестало требовать патчить основной код, или как было? Потому что это обещали два года назад.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
	Сообщение от нах. (?), 02-Дек-24, 11:54
	А, уже вижу - "with extensibility patches". Вот когда будут в мэйнлайне, тогда и приходите.
	Ответить | Правка | Наверх | Cообщить модератору

6. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+8 +/–
Сообщение от anguest (?), 02-Дек-24, 09:11
Попробовал предыдущий выпуск на реальной нагрузке. После определенного кол-ва запросов начинаются утечки памяти и все падает. Но надеюсь что допилят, очень нужная весчь.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+9 +/–
	Сообщение от Alexander Korotkov (?), 02-Дек-24, 11:51
	Спасибо, что пробовали! Утечки памяти недавно исправляли. Будем рады, если ещё раз попробуете.
	Ответить | Правка | Наверх | Cообщить модератору

17. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
Сообщение от ОООноним (?), 02-Дек-24, 11:19
>При выполнении операции UPDATE поддерживается замена данных по месту (без освобождения текущей записи и создания новой), что положительно сказывается на производительности. Но ведь запись в конец при update и была сделана для повышения производительности. А теперь вернули как было и стало еще производительней?
Ответить | Правка | Наверх | Cообщить модератору

	21. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
	Сообщение от anonimus (?), 02-Дек-24, 12:07
	> Но ведь запись в конец при update и была сделана для повышения производительности. это про HOT, но не все апдейты можно сделать HOT, поэтому для ванильного посргре нагрузка на rewrite тех же строк - это беда. В то же время MySQL или OracleDB работают при такой нагрузке стабильно
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от inklesspen (ok), 02-Дек-24, 12:17
	Пару раз попрыгаем туда-сюда и будет еще производительнее =D Неизвестно в какой среде проводились тесты, с какими дисками, с какими рейдами если они были и т.д. и т.п. К тому же, обновлять данные по месту записи в любом случае надо: надо записать, что физическая запись устарела и более недействительна (т.е. установить значение t_xmax). Постгрес в этом случае просто делает двойную запись: в новое место новые данные и в старое место пометку. Да и не факт, что новая запись в конце. Вот WAL да, это Append-Only log и писать там куда-то еще не требуется
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	63. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 15:29
	В конец чего? Новая строка при update вставляется туда, где место есть, совсем не обязательно в конец чего-то.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

23. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
Сообщение от Аноним (23), 02-Дек-24, 14:54
Надо срочно пробовать. PostgreSQL жутко неповоротлив, как в работе, так и в разработке. Но альтернатив нет, к сожалению.
Ответить | Правка | Наверх | Cообщить модератору

24. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
Сообщение от Аноним (24), 02-Дек-24, 15:13
Сейчас 1733140900 PostgreSQL: 1996-07-08, 836784000, 896356900 ago, 100% ago OrioleDB: 2024-03-02,  1709337600, 23803300 ago, 2.7% ago Знаменитое эмпирическое правило 20/80 утверждает, что 20% работы покрывает 80% функциональности, а вот оставшийся дьявол в деталях занимает 80% работы... Да, сейчас есть искусственный интеллект и инструменты, и гитхаб, и стековерфлоу. Если мы дадим новой базе 10кратную фору в скорости, и оценим её готовность в смысле работы как 27% от PostgreSQL, то можно предположить, что она достигла около 80% функциональности оной. Но кому она нужна, без оставшихся 20%? Кому нужна бочка мёда с ложкой дёгтя? И, раз будучи мегапопулярным проектом, на котором построены несколько коммерческих бизнесов, PostgreSQL так и не смог лучшить производительность до уровня OrioleDB ... можно ожидать, что по мере добирания OrioleDB недостающих функций PostgreSQL её производительность будет падать до оной PostgreSQL.
Ответить | Правка | Наверх | Cообщить модератору

	31. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
	Сообщение от Аноним (31), 02-Дек-24, 15:58
	А кому нужно ровно 100% от функциональности продукта "П", ни процентом больше, ни процентом меньше? Мне вот например достаточно базового CRUD без выпендрёжа. Если оно в 10 раз быстрее чем конкуренты и без каких-то особых проблем то отлично, такое мы берём.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (34), 02-Дек-24, 18:35
	Те просто возьмут SQLite.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 03-Дек-24, 10:48
	OrioleDB не является самостоятельной СУБД. Это небольшой патч к ядру PostgreSQL + расширение. Не соглашусь с идеей о падении производительности по мере разработки. Всё-таки у PostgreSQL на современном железе по мере разработки производительность в целом растёт. Это можно проверить. Соберите PostgreSQL 7.4 и запустите pgbench на мощной виртуалке и вы увидите как узкие места, над расшиванием которых сообщество работало десятилетиями, приводят к крайне низкой по современным меркам производительности. Что касается производительности OrioleDB vs дефолтовый движок PostgreSQL, то OrioleDB сейчас выигрывает за счёт своей архитектуры (https://www.orioledb.com/docs/architecture/overview). При этом остаётся огромный потенциал для оптимизаций в OrioleDB, т.к. туда пока не вложено и десятой доли труда по сравнению с дефолтовым движком PostgreSQL. Поэтому отрыв по прозиводительности в ближайшее время будет только расти.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	46. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 03-Дек-24, 10:53
	Добавлю ещё, что в данном контексте я рассматриваю производительность именно самого табличного движка и непосредственно связанных подсистем (WAL, checkpointer, buffer manager и т.д.) При этом в PostgreSQL есть ещё много узких мест: протокол, планировщик, экзекьютер и т.д., которые OrioleDB почти никак не затрагивает.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от fuggy (ok), 03-Дек-24, 12:31
	Они не открыли америку. Движок на основе undo logs, уже реализовали несколько лет назад zheap, сразу как только появилась возможность подключать кастомные движки. Есть где-то сравнение что из этого лучше, чтобы сравнивать похожие технологии. Ссылка полезная. Но нужно учитывать что у undo logs есть и свои минусы, что изменение записи требует вставки + перемещения старой версии в лог. В то время как у стандартного движка только вставка новой версии.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	94. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 05-Дек-24, 06:06
	Я бы сказал, что возможность table access methods коммитилась с прицелом на zheap, который тогда уже был в разработке. При этом zheap всё равно не вписывался в разработанный API и всегда шёл с патчем к ядру. zheap никогда не был доделан до сколь-нибудь существенной степени годности хотя бы для бенчмарков. В частности, там были запланированы, но не реализованы delete-marking indexes (по аналогии с InnoDB). В итоге весь zheap просто даёт нам такой как бы перевёрнутый HOT: если не меняются индексные поля, то версии уезжают в UNDO, а не складываются рядом. Но как-только ты трогаешь индексные поля, всё фактически работает по-старому. https://www.pgcon.org/2018/schedule/attachments/501_zheap-a-... При этом использование UNDO - практически единственное отличие zheap от heap, к тому же не доведённое до ума. Если учесть ещё что zheap мёртв, просто не хочется тратить ресурсы на него. Но если кто-то сделает бенчмарки с ним, будет хорошо. > Но нужно учитывать что у undo logs есть и свои минусы, что изменение записи требует вставки + перемещения старой версии в лог. В то время как у стандартного движка только вставка новой версии. Безусловно. Поэтому и делаем бенчмарки.
	Ответить | Правка | Наверх | Cообщить модератору

28. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
Сообщение от slew (ok), 02-Дек-24, 15:38
Наконец-то сделали так, как в оракле было сделано 50 лет назад.
Ответить | Правка | Наверх | Cообщить модератору

	29. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
	Сообщение от нах. (?), 02-Дек-24, 15:42
	не сделали. Всего лишь бета. Зато - седьмая. Такими темпами успеют к концу света.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 12:29
	Оракл нормальным стал только с версии 9. Даже 8-ка была так себе удовольствием. Т.е. с начала 00-вых. Не полвека, а только четверть.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	52. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от fuggy (ok), 03-Дек-24, 12:33
	Так а зачем городить велосипед, если можно взять взять тот же бесплатный mysql. Где тоже структура таблицы имеет первичный индекс.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	59. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 14:46
	Это как понять -- структура таблицы имеет первичный индекс? Табличка это упорядоченный (явно или нет) набор упорядоченных же кортежей -- фактические же структуры хранения данных в СУБД от таблички, типично, крайне далеки, ну если не брать Мю с её исамом. И причём тут индекс? Или речь о том, что в МС называется кластерной таблицей, а в оракле организованной по индексу таблицей (ни то, ни другое таблицей не является, а называется так... для простоты)? Тогда идея хранения всех данных в структуре одного из b-tree-индексов так себе идея. Это более-менее работает в МС, потому там все прочие варианты чаще всего ещё хуже (по моему опыту на больших таблицах всегда хуже и чем больше таблица, тем хуже и хуже). Если модель у вас сильно покрыта разными индексами, что типично, то хранение данных в структуре одного из них ну прям совсем не гуд. В Оракле, к слову, организованные по индексу таблички используют крайне и крайне редко. Потому что проку никакого.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от fuggy (ok), 03-Дек-24, 15:53
	Почему только myisam, innodb тоже, который по сути остался единственным вариантом для acid транзакций. Там каждая таблица кластеризована по первичному индексу. И все остальные вторичные индексы ссылаются на этот индекс. В отличие от postgresql, где все данные лежат в неупорядоченном массиве. Там кластеризация, это лишь временная операция. А также приходится часто обновлять индексы, из-за обновления строк новыми версиями.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 18:04
	Ещё раз, таблица эта такая хрень, где есть первая строка, вторая, вторая ниже первой, но выше третьей, и так далее. И это порядок где-то в мета-инфе задан. Вот на листке бумажки ты табличку рисуешь карандашиком, а как ей пользоваться у тебя в социо-культурном коде в мозгах "зашито". Больше никаких таблиц нет. А "кластерная таблица" в МС или в Инно это дерево, а не таблица, в котором данные строк приделаны к листовому уровню. По факту это двунаправленных список. И не в каких "неупорядоченных" массивах данные не лежат -- таких массивов не бывает, массив это множество, к которому приделали категорию порядка, т.е. упорядочили по определению. Типично данные "табличек"-отношений хранятся в куче.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 18:11
	Кластерная таблица очень-очень мутный термин. Потому что в МС кластерная таблица это про хранение данных отношения в структуре битри-индекса, а вот в Оракле кластерная таблица это вообще не про индексы, а про хранение однотипных данных разных отношений в одной куче.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

32. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
Сообщение от fuggy (ok), 02-Дек-24, 16:26
Чем это лучше zheap? Оно же тоже построена на undo logs.
Ответить | Правка | Наверх | Cообщить модератору

35. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
Сообщение от Olololololololo (-), 02-Дек-24, 20:43
>прямое связывание страниц в оперативной памяти со страницами в постоянном хранилище Ну вот это они зря, нужно было всё самим ручками писать, а не ядро использовать и уж тем более не использовать mmap. Это прямой затык. Кто не верит ищите тесты гугле.
Ответить | Правка | Наверх | Cообщить модератору

	37. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 02-Дек-24, 21:09
	ну так это и не рс ещё даже хДДД
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 03-Дек-24, 10:14
	Мы mmap используем только для экспериментального режима хранения данных в persistent memory (проводили эксперименты с Intel Optane). По-умолчанию у нас никакого mmap. Прямыми сслыки между страницами есть, но управляем ими сами. Можно дательнее здесь почитать. https://www.orioledb.com/docs/architecture/overview
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	53. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 13:18
	Просто вопросы, которые мне интересны: - А fsync всё ещё используете (навеено этим https://habr.com/ru/articles/472684/)? - Не считаете, что использовать fsync в БД это глупо? - Не думали использовать, что-то типа io_uring или spdk?
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 14:31
	Хабровая статья, как это часто бывает, перевод продуктивного бреда какого-то очередного шизофреника. Нет никакой проблемы с fsync-ом.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 15:34
	Ждём оттвета Короткова. Моё личное мнение, что БД должны использовать только direct io беря на себя функции кеша и т.п., если нужна надёжность и производительность.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 15:40
	статья от IBM про бенефиты direct io - https://www.ibm.com/docs/en/aix/7.2?topic=io-benefits-direct
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от bOOster (ok), 17-Дек-24, 11:31
	Решение БД в 99% случаев не знает о каких нибудь специфичных, супербыстрых аппаратных средствах кэширования данных. Но система с этими средствами скорее всего работает нормально.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	95. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 05-Дек-24, 08:18
	Бредом шизофреника я был статью не назвал. Но она является вольным пересказом треда постгресовой рассылки автором статьи. И что самое главное, там отсутствует финал – коммиты которыми всё закончилось.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	73. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 16:21
	И ещё вопросы: - PostgreSQL использует huge pages, если нет то пробовали ли включать? - Если пробовали какой результат? Слышал, что или MariaDB или PerconaDB или т.п. включило huge pages и результат был хуже чем без них.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	81. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 04-Дек-24, 08:11
	> - А fsync всё ещё используете (навеено этим https://habr.com/ru/articles/472684/)? > - Не считаете, что использовать fsync в БД это глупо? Да, fsync используем. Не считаю, что это глупо, но считаю то не оптимально. К статье на хабре стоит добавить то, чем всё закончилось https://git.postgresql.org/gitweb/?p=postgresql.git;h=1556cb... https://git.postgresql.org/gitweb/?p=postgresql.git;h=9ccdd7... > - Не думали использовать, что-то типа io_uring или spdk? Да, планируем в будущем переходить на более продвинутые решения.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	54. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 13:21
	>Мы mmap используем только для экспериментального режима хранения данных в persistent memory (проводили эксперименты с Intel Optane). А это в принципе не важно для чего вы используете. HFT системы, например, не используют mmap т.к. ядро Linux становится тормозом. А ядро вы используете, значит и с optane у вас на нагрузках будут те же самые грабли.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	80. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 04-Дек-24, 08:01
	Как раз таки важно для чего использовать mmap! Если мапить файл или блочное устройство – то ядро занимается подгрузкой и записью страниц, и происходят тормоза о которых вы говорите. Если мапить персистентную память, подключенную к шине также как и обычная память, память просто мапится на адресное пространство процесса. И при этом уже во взаимодействии с данной памятью ядро никак не участвует. Так что mmap mamp'у – рознь :)
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 13:26
	Я так понял OrioleDB написан на Си. А почему на С++ или Rust не пишете?
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	83. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 04-Дек-24, 09:00
	Да, OrioleDB написан на C. Есть низкоуровневая часть кода, связанная с форматом tuples, упаковкой данных на страницы и т.д. Насколько я знаю, эта часть практически везде написана на C. Есть часть кода, сильно завязанная на внутренние структуры и функции PostgreSQL, которые в свою очередь тоже написаны на C. Между ними есть небольшая прослойка, которая возможно выиграла бы от Rust. Но не занимались.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Алексей Демаков (?), 03-Дек-24, 15:24
	Под прямыми ссылками вы имеете в виду технику известную как pointer swizzlingp [1,2] или что-то другое? 1. https://ceur-ws.org/Vol-1858/paper9.pdf 2. https://bnm3k.github.io/blog/pointer-swizzling/
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	82. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 04-Дек-24, 08:12
	Да, вижу, что pointer swizzling – одной из её названий. Спасибо за ссылки.
	Ответить | Правка | Наверх | Cообщить модератору

39. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
Сообщение от Аноним (39), 02-Дек-24, 22:03
к 1с это можно прикрутить?
Ответить | Правка | Наверх | Cообщить модератору

	102. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от bOOster (ok), 17-Дек-24, 11:34
	> к 1с это можно прикрутить? С 1С это вообще никак не связано. Есть еще уровень абстракции выше системы хранения с которым и работает 1С.
	Ответить | Правка | Наверх | Cообщить модератору

48. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
Сообщение от Аноним (98), 03-Дек-24, 12:26
Прям маркетинговая няшка для утомлённых ораклом. Все приписываемые улучшения улучшения только в сознании дба-неофита. Сплошные разоблачения мифов. Нет вакуума -- ура!!! Счётчик 64 бита -- ура!!! Есть отдельное ТП для undo -- ура!!! Обновления по месту, а не постоянный cow -- ура!!! WAL на уровне строк, а не на уровне кластера целиком -- ура!!! Как-то слишком про желание сделать из одного, что-то совсем другое.
Ответить | Правка | Наверх | Cообщить модератору

	55. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 13:25
	>Обновления по месту, а не постоянный cow -- ура!!! Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки. Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение производительности не исключенно.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 14:50
	>>Обновления по месту, а не постоянный cow -- ура!!! > Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки. > Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение > производительности не исключенно. Самый очевидный профит в том, что замена одной закорючки в строке из десятков или даже сотен полей не приведёт к созданию новой строки. Но модель MVCC отход от принципа всегда insert корёжит радикально.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 15:30
	Мусье считает, что залочить (используя atomic операции) строку для её обновления это дешевле чем вставить новую? Может тебе мат.часть подучить?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 15:44
	Мат. часть чего? Понятия не имею, что в конкретных условиях будет быстрее: найти место под вставку и скопировать или просто по месту, которое уже найдено, что-то поменять. По опыту лишь знаю, что даже при большом внимании к настройке вакуума файлы данных пухнут стремительно и необратимо, это в бд, в которых update-ов кратно больше insert-ов.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 16:04
	>Мат. часть чего? Процессора, кешей, влияния atomics на кеши, протоколы когерентности кешей и т.п. и само собой каким образом делается обновление/вставка строки по месту. Про лог не упоминаю, ты сам про него пишешь ниже. Чтобы строку заменить/обновить по месту нужно эту строку залочить (у PostgreSQL, наскольку помню, есть такая возможность), а лок делается на атомиках, а чтобы добавить новую версию строки в конец файла БД нужно всего лишь её добавить атомарно залочив в метаданные, к которым нет такого потенциально высокого конкуретного доступа. Дешевле лочить метаданные (заголовок таблицы) чем лочить строку и это я ещё не говорил про перенос старой строки в лог, про который ты написал ниже. >Но вот Оракл как-то справляется Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 16:10
	>Дешевле лочить метаданные (заголовок таблицы) чем лочить строку Дополнение, при условии, что читателей больше чем писателей.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Аноним (98), 03-Дек-24, 16:49
	Э, Слон, как и прочие, в случае вставки вставляет не в конец (кого/чего?), а туда, где место есть. Т.е. это не тупая вставка в некий всегда известный заранее "хвост", а поиск куда вснуть в уже распределённом и только, если там нету, то выделить новую страницу, опять же, вопрос где. В общем, операция вставки далеко не факт, что дешевле, корректировки по месту. Хотя для корректировки по месту и надо лочить.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	75. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Olololololololo (-), 03-Дек-24, 16:56
	>Э, Слон, как и прочие, в случае вставки вставляет не в конец (кого/чего?), а туда, где место есть. Я описывал принципиальное отличие. >В общем, операция вставки далеко не факт, что дешевле, корректировки по месту. Ассмептотически оно дешевле т.к. выделяется сразу блок и оверхед размазывается по всем операциям добавления "в конец". Что касается кешей, атомиков и т.п., для этого я и сказал в самом начале - Нужны тесты.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 04-Дек-24, 09:07
	> Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать. Я скорее склонен считать, что дело скорее в подходе PostgreSQL, чем в оптимизациях. Например, вот интересная критика подхода [1] из академических кругов. О том, что PostgreSQL достаточно отполирован косвенно свидетельствует провал таких оптимизаций как WARM [2]. WARM должен был решить часть проблем MVCC, но породил такое количество архитектурных проблем, что доделать его не получилось 1. https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg... 2. https://www.postgresql.org/message-id/flat/CABOikdMNy6yowA&#...
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	69. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	–1 +/–
	Сообщение от Аноним (98), 03-Дек-24, 15:51
	А, понял твой скепсис. Да, такой подход требуют где-то хранить лог (или не лог, а всю строку целиком) изменений для строки. И интуиция подсказывает, что вести такой лог будет недешево. Но вот Оракл как-то справляется. Я тестил ещё 13-тый Слон против 19-го Оракл. Оракл update-ы делает быстрее. Ни на что не претендую, но разница была до 40%. Условия были такие, что в исходно созданных и заполненных табличках кол-во строк не менялось, а менялись только сами строки. За цикл все таблички переписывались полностью. Сначала Слон и Оракл были более-менее равно, но чем больше циклов, тем Слон всё сильнее отставал. Во всех табличках был только один индекс по первичному ключу.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

58. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+1 +/–
Сообщение от Аноним (58), 03-Дек-24, 14:38
Как произнести название на русском?
Ответить | Правка | Наверх | Cообщить модератору

	100. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
	Сообщение от Alexander Korotkov (?), 09-Дек-24, 09:05
	Ориоль-Ди-Би
	Ответить | Правка | Наверх | Cообщить модератору

66. "Седьмая бета версия OrioleDB, высокопроизводительного движка..."	+/–
Сообщение от Аноним (98), 03-Дек-24, 15:39
А в чём профит маппить буферы сразу на блоки? Такое больше не надо чекпоинтить? В этом?
Ответить | Правка | Наверх | Cообщить модератору

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

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