Представлена бета-версия движка хранения OrioleDB beta7 и опубликованы результаты новых тестов, демонстрирующих значительное повышение производительности по сравнению с традиционным PostgreSQL. В версии beta7 были внедрены оптимизации, направленные на улучшение работы с многопоточными нагрузками и ускорение операций чтения и записи. Первый стабильный релиз OrioleDB планируется сформировать в 2025 году. Движок написан на языке Си и распространяется под лицензией PostgreSQL, похожей на лицензии BSD и MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62327
Неужели не врут или опять графики подрисовали?
Может, и не врут, только вот сколько букв от ACID осталось?
Просто покажи циферки побольше и менеджмент будет доволен.
Всё там с ACID в порядке. Архитектура Постгресса действительно не оптимальна в нынешних реалиях, и сделать что-то выделяющееся на её фоне вполне возможно.
>Всё там с ACID в порядкеа ты кто? вот когда jepsen пруфнет, тогда поверим.
у субд вообще много разных проблем, не только бинарное "acid да/нет".по описанию вообще шг в сторону монго сделали ) осталось JSON нормально сделать и лет 5 повылизывать код. и получится что-то путнее
Они сделали хранилище как сделано в оракл
Гарантии ACID такие же как и в дефолтовом движке PostgreSQL, за исключением отсутствия поддержки SSI (за всю карьеру не припомню случая где он был бы реально необходим). Но на текущем этапе зрелости проекта серьёзные баги, конечно, могут быть.
SSI нужен. Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной. Хотя, конечно, кратно больше ситуаций, где SSI излишен совершенно и RC/RR достаточно.
> Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной.Безусловно. На моей пратике большинство таких кейсов прекрасно решалось с помощью 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 оправдано, это расширит моё понимание вопроса (без иронии).
Положительный отклик на ваш комментарий понятен -- никто не любит возиться со случаями, когда serializable действительно нужен, и никто не любит его стандартного поведения. Тем не менее, подходы вроде select for update не позволяют достаточно приблизиться к семантике "честного" SSI. Потому что именно так, как себя ведёт SSI, единственный доступный и реализуемый подход, когда важна последовательность транзакционных событий. На практике чаще всего честный S не используют не потому, что он не нужен на уровне предметной области, а потому что его поведение считают, скажем так, странным -- ведь все хотят, чтобы на этом уровне конфликты последовательности транзакций НЕ ДОПУСКАЛИСЬ в том смысле, чтобы они как-то сами собой РАЗРЕШАЛИСЬ, а не так, как это сейчас и единственно возможно, выбрасыванием исключения о невозможности соблюсти условия транзакции, которое, вот же досада, нужно как-то самому разработчику разрешать. Так вот, это я к тому, что если важна последовательность совершения транзакций, то сейчас ПРОСТО НЕТ НИКАКОГО ДРУГОГО СПОСОБА, кроме унылого и нелюбимого всеми S(SI). То, что его разработчики всячески избегают использовать, не значит, что он семантически избыточен и "тоже самое можно сделать иначе" (потому что иначе нельзя), а потому что... ну интеллектуально сложно честно реализовывать такие доменные поведения и даже казалось бы в тех сферах, где поведение модели должно быть предельно адекватным доменному, сплошь и рядом упрощения разной степени безответственности. Но что ещё веселей, что зачастую и доменный эксперт (заказчик) честную реализацию воспринимает как какой-то нелепый абсурд. В общем, по-моему, обычное дело: неосилянты, кароч, а не не нужно.
Есть алгоритм сериализации, приводящий к меньшему числу конфликтов, чем SSI. Называется он SSN: serializable safety network. Правда, точно так же нужно брать на всё «блокировки» (точнее, ставить пометки). Но конфликтов будет меньше.Но это пока теоретический алгоритм с единственной экспериментальной реализацией от его авторов. О боевых внедрениях я пока не слышал.
Может и не врут, но TPC-C - это всё же тест больше на модификацию, чем на выборку. И вообще без тяжелых выборок. А на аналитическом профиле нагрузки можно получить наоборот, большой провал.UnDo лог должен хранить записи до завершения всех транзакций, которые начались до попадания записи в UnDo лог. Да еще и эффективно находить эти записи для таких транзакций, так как они должны видеть эти записи такими, какими они были на момент начала транзакции. И тут вполне можно потерять больше, чем выиграл на модификациях в страницах по месту.
Если не верите – проверяйте. Некоторые уже так и сделали.
https://x.com/MinisterOfEng/status/1864793214282019065
>планируется сформировать в 2025 году
а теперь смотрим как он считается: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, понимая его как некую функцию от качества продукта, неизвестну. функции, но от характеристик продукта, а не вот это вот всё
> это явно не то что ожидаешь под словом RANKно хотя бы - интересно. И да, те у кого все работает, не будут оставлять хвалебные отзывы в "twitter events". А вот "оно опять %%!$!" - да.
Так что инфа полезная, главное уметь понять.
> т.е. достаточно, чтобы было много головняка1. То есть вот этот критерий "Number of job offers" вы в попытке построить свою логическую цепочку почему-то упустили. Почему?.
2. Кроме того, вот это "Frequency of technical discussions about the system" не обязательно обозначает "головняк", а ещё и богатство фич. Что имеется ввиду? У СУБД "А" таких фич нет, поэтому обсуждать там нечего. У СУБД "Б" такие фичи есть, поэтому их обсуждают.
3. Ещё одни фактор, который вы упустили - это "Number of profiles in professional networks". Что это означает? Это означает, что если специалистов по СУБД "Б" больше, чем специалистов по СУБД "Б", то, очевидно, СУБД "Б" более популярна. Не правда ли?
Подытожу. Вы выбрали для вашего вывода только те факты, которые удобны вам. То есть, просто подогнали их под себя, чтобы они не противоречили вашей картине мира. Имеете право, разумеется, но к объективности это не имеет никакого отношения. Я не говорю, что представленный хит-парад - идеальный. Но, думаю, он более-менее близок к реальному положению дел.
> это явно не то что ожидаешь под словом RANK, понимая его как некую функцию от качества продукта
Успехов вам создать свой собственный RANK по вашим критериям. Однако вряд ли у вас получится что-то действительно путное и лучшее, чем то, что есть. Почему? Потому что люди, которые выбирают СУБД для своих нужд в общем и целом не идиоты. То есть, смею предположить, часто (не всегда) их выбор вполне осознанный.
Опечатка:
если специалистов по СУБД "Б" больше, чем специалистов по СУБД "А" - так правильно
Я ничего не выбирал, а сказал, что этот ранк бессмысленный по своей сути и показывает НИЧЕГО.> То есть вот этот критерий "Number of job offers" вы в попытке построить...
Number of job offers, не значит ровным счетом ничего? потому что его можно по-другому интерпретировать, например, дефицит кандидатов из-за нежелания связываться с той или иной СУБД, отсюда повышенный спрос - это все гадания на манной каше.
> то, очевидно, СУБД "Б" более популярна. Не правда ли?
- нет не правда. Но и опять-таки, какое отношение это имеет к ранку? Популярность - это не функция от качества.
> Подытожу. Вы выбрали для вашего вывода только те факты, которые удобны вам. То есть, просто подогнали их под себя, чтобы они не противоречили вашей картине мира.
Какая прекрасная ошибка выжившего ))) Знаешь больше, чем тупые люди, раздражают только псевдо-интеллектулы с самомнением. Ты сам подогнал мои ответы под нужный тебе знаменатель, чтобы блеснуть (нет) эрудицией, потому что очень хотелось оппонировать.
Я привел полный список критериев на суд каждого, и один пример от меня, который показывает, что ранк вполне может быть необъективным, и корелляция там неоднозначная. И не более...
P.S.
> Потому что люди, которые выбирают СУБД для своих нужд в общем и целом не идиоты.Люди не идиоты? Пффф, вот это ты юморист...
Для всех этих подключаемых движков не поддерживается партиционирование таблиц.
а для всего постгреса шардинг, постгрес в принципе сильно переоценен
Шардинг это не про РСУБД вообще. Как слоить данные решение прикладного уровня, а не модельного.
тот случай, когда даже электромоторчик из детской машинки умнее, чем очередной Анонимпогугли список распределенных RDBMS с шардингом на уровне бд - удивишься
а некоторые из них еще и синхронные, т.е полноценный multi-master
притом некоторые из них еще и кластерные с балансировкой нагрузки между нодами
теперь что касается "слоить", прикладной уровень, модельный - я такого дерьма в голове с терминологией не видел очень давно, потому что всячекски старался избегать дешевых бложиковв БД у тебя не модели, а таблицы, будет ли отражено это на модели в предметной области (он же domain в DDD) - это еще вопрос
в любом случае даже если моя БД, будет из одной таблицы, она все равно может шардится... )))
что там под слоить понимаешь вообще никто не знает, как в принципе и "прикладной уровень", так то СУБД тоже "прикладной уровень" )))
Дружок, шардинг это когда разраб на уровне р-модели (да-да) решает, что некая сущность предметной области может быть для каких-то чисто практических целей (не модельных) представлена не одним отношением, а сразу несколькими (хотя теория этого не требует). Например, разраб решил, что Клиента можно поделить на Клиент_СПБ и Клиент_МСК, чтобы потом при реализации локализовать траффик. Может ли это решение за разраба принять инструмент? Может, и таких инструментов достаточно. Вносит ли такой инструмент корректировку в прикладную модель? Да. Имеет ли это какое-то отношение к р-теории и рсубд? Нет, никакого. Такое решение о декомпозиции не диктуется теорией, а принимается, надо полагать, осознанно разработчиком. Такое решение меняет модель? Да, безусловно, т.е. это решение прикладного модельного уровня, а не как, скажем, секционирование или смена плана исполнения, чисто уровня реализации.
> Дружок, шардинг это когда разраб на уровне р-модели (да-да) решает, что некая сущность предметной области может быть для каких-то чисто практических целей (не модельных) представлена не одним отношением, а сразу несколькими (хотя теория этого не требует). Например, разраб решил, что Клиента можно поделить на Клиент_СПБ и Клиент_МСК, чтобы потом при реализации локализовать траффик. Может ли это решение за разраба принять инструмент? Может, и таких инструментов достаточно. Вносит ли такой инструмент корректировку в прикладную модель? Да. Имеет ли это какое-то отношение к р-теории и рсубд? Нет, никакого. Такое решение о декомпозиции не диктуется теорией, а принимается, надо полагать, осознанно разработчиком. Такое решение меняет модель? Да, безусловно, т.е. это решение прикладного модельного уровня, а не как, скажем, секционирование или смена плана исполнения, чисто уровня реализации.этот бред надо заскринить ))) это даже прочитать сложно, но ладно, если ты решил что ты будешь шардить на уровне приложения, то это еще не значит:
1) что нет распределенных RDBMS которые делают это сами, собственно формируя кластер, и освобождая приложение от такой задачи
2) что тебе нужно разбивать сущность на две, даже если делать шардинги на уровне логики приложения (что само по себе уже сомнительно), то твое решение с двумя моделями - просто дно, "представлена не одним отношением, а сразу несколькими" - не является шардингом, при шардинге схема БД не меняется, и шардинг - это грубо говоря распределенное между серверами горизонтальное партиционированиенеужели так сложно "погуглить список распределенных RDBMS с шардингом на уровне бд?"
я вообще не понимаю зачем я тебе что-то объясняю, ты только больше не пиши мне "со своим роялем"
"горизонтальное партиционирование" )))) Витгентштейн (с)
При шардинге схема как может меняться, так может и не меняться. Если есть сущность с запредельным количеством реализаций, то подразумевается изменение модели -- вместо одной сущности в модели появляются n-сущностей, по которым распределяются реализации исходной.
Ещё раз. Имеет ли это какое-то отношение именно к Рсубд? Нет. Не имеет. Ещё раз, такая декомпозиция диктуется не теорией отношений, а реализацией.
Если обобщить, то критерий шардирования/секционирования простой -- если в модель вводятся новые сущности, между которыми перераспределяются реализации прежде одной сущности, то это шардирование, если новые сущности не вводятся на уровне модели, а "физически" перераспределяются только реализации всё той же сущности, то это секционирование.
Продолжим. Если взять, скажем, кусок сыру и фломастером разметить его на части, скажем, подписав на них "васе", "пете", "маше", то это разбиение куска сыра на секции -- кусок остался целым, но его снабдили мета-информацией для потребителя, провели секционирование. Если же кусок брутально нарезать ножом -- то это уже шардирование, потому что вместо одного куска сыра появилось много кусков.
В пэтэу на курсах тебе такого не объяснят.
> Продолжим. Если взять, скажем, кусок сыру и фломастером разметить его на части,
> скажем, подписав на них "васе", "пете", "маше", то это разбиение куска
> сыра на секции -- кусок остался целым, но его снабдили мета-информацией
> для потребителя, провели секционирование. Если же кусок брутально нарезать ножом --
> то это уже шардирование, потому что вместо одного куска сыра появилось
> много кусков.
> В пэтэу на курсах тебе такого не объяснят.я даже уже не читаю, что ты пишешь, и я надеюсь от твоих решений никто не зависит, особенно самолеты, медицинские приборы, критическая инфраструктура и т.д. скрестил пальцы
Когда эта вундервафля войдет в состав PostgreSQL?
это было бы логичным решением, но только если на замену родного движка, как подключаемый не вариант
PostgreSQL - очень консервативная система. Пока что в виде подключаемого движка, потом, когда-нибудь, поменяют настройки и он по умолчанию будет использоваться при создании новых таблиц. Потом, глядишь, его начнут использовать большинство инсталляций. И только потом старый движок отключат, возможно, удалят, как устаревший.Но всё это пока что вилами на воде писано. Надо хотя бы дождаться выпуска стабильной версии и доработки интерфейсов PostgreSQL для подключения этого движка без необходимости накладывать заплатки на исходный текст и пересобирать из исходников.
> Пока что в виде подключаемого движкаоно уже перестало требовать патчить основной код, или как было?
Потому что это обещали два года назад.
А, уже вижу - "with extensibility patches". Вот когда будут в мэйнлайне, тогда и приходите.
Попробовал предыдущий выпуск на реальной нагрузке. После определенного кол-ва запросов начинаются утечки памяти и все падает. Но надеюсь что допилят, очень нужная весчь.
Спасибо, что пробовали!
Утечки памяти недавно исправляли. Будем рады, если ещё раз попробуете.
>При выполнении операции UPDATE поддерживается замена данных по месту (без освобождения текущей записи и создания новой), что положительно сказывается на производительности.Но ведь запись в конец при update и была сделана для повышения производительности. А теперь вернули как было и стало еще производительней?
> Но ведь запись в конец при update и была сделана для повышения производительности.это про HOT, но не все апдейты можно сделать HOT, поэтому для ванильного посргре нагрузка на rewrite тех же строк - это беда. В то же время MySQL или OracleDB работают при такой нагрузке стабильно
Пару раз попрыгаем туда-сюда и будет еще производительнее =DНеизвестно в какой среде проводились тесты, с какими дисками, с какими рейдами если они были и т.д. и т.п.
К тому же, обновлять данные по месту записи в любом случае надо: надо записать, что физическая запись устарела и более недействительна (т.е. установить значение t_xmax). Постгрес в этом случае просто делает двойную запись: в новое место новые данные и в старое место пометку. Да и не факт, что новая запись в конце.Вот WAL да, это Append-Only log и писать там куда-то еще не требуется
В конец чего? Новая строка при update вставляется туда, где место есть, совсем не обязательно в конец чего-то.
Надо срочно пробовать. PostgreSQL жутко неповоротлив, как в работе, так и в разработке. Но альтернатив нет, к сожалению.
Сейчас 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.
А кому нужно ровно 100% от функциональности продукта "П", ни процентом больше, ни процентом меньше? Мне вот например достаточно базового CRUD без выпендрёжа. Если оно в 10 раз быстрее чем конкуренты и без каких-то особых проблем то отлично, такое мы берём.
Те просто возьмут SQLite.
OrioleDB не является самостоятельной СУБД. Это небольшой патч к ядру PostgreSQL + расширение.Не соглашусь с идеей о падении производительности по мере разработки. Всё-таки у PostgreSQL на современном железе по мере разработки производительность в целом растёт. Это можно проверить. Соберите PostgreSQL 7.4 и запустите pgbench на мощной виртуалке и вы увидите как узкие места, над расшиванием которых сообщество работало десятилетиями, приводят к крайне низкой по современным меркам производительности.
Что касается производительности OrioleDB vs дефолтовый движок PostgreSQL, то OrioleDB сейчас выигрывает за счёт своей архитектуры (https://www.orioledb.com/docs/architecture/overview). При этом остаётся огромный потенциал для оптимизаций в OrioleDB, т.к. туда пока не вложено и десятой доли труда по сравнению с дефолтовым движком PostgreSQL. Поэтому отрыв по прозиводительности в ближайшее время будет только расти.
Добавлю ещё, что в данном контексте я рассматриваю производительность именно самого табличного движка и непосредственно связанных подсистем (WAL, checkpointer, buffer manager и т.д.)
При этом в PostgreSQL есть ещё много узких мест: протокол, планировщик, экзекьютер и т.д., которые OrioleDB почти никак не затрагивает.
Они не открыли америку. Движок на основе undo logs, уже реализовали несколько лет назад zheap, сразу как только появилась возможность подключать кастомные движки. Есть где-то сравнение что из этого лучше, чтобы сравнивать похожие технологии. Ссылка полезная. Но нужно учитывать что у undo logs есть и свои минусы, что изменение записи требует вставки + перемещения старой версии в лог. В то время как у стандартного движка только вставка новой версии.
Я бы сказал, что возможность 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 есть и свои минусы, что изменение записи требует вставки + перемещения старой версии в лог. В то время как у стандартного движка только вставка новой версии.
Безусловно. Поэтому и делаем бенчмарки.
Наконец-то сделали так, как в оракле было сделано 50 лет назад.
не сделали. Всего лишь бета. Зато - седьмая. Такими темпами успеют к концу света.
Оракл нормальным стал только с версии 9. Даже 8-ка была так себе удовольствием. Т.е. с начала 00-вых. Не полвека, а только четверть.
Так а зачем городить велосипед, если можно взять взять тот же бесплатный mysql. Где тоже структура таблицы имеет первичный индекс.
Это как понять -- структура таблицы имеет первичный индекс? Табличка это упорядоченный (явно или нет) набор упорядоченных же кортежей -- фактические же структуры хранения данных в СУБД от таблички, типично, крайне далеки, ну если не брать Мю с её исамом. И причём тут индекс? Или речь о том, что в МС называется кластерной таблицей, а в оракле организованной по индексу таблицей (ни то, ни другое таблицей не является, а называется так... для простоты)? Тогда идея хранения всех данных в структуре одного из b-tree-индексов так себе идея. Это более-менее работает в МС, потому там все прочие варианты чаще всего ещё хуже (по моему опыту на больших таблицах всегда хуже и чем больше таблица, тем хуже и хуже). Если модель у вас сильно покрыта разными индексами, что типично, то хранение данных в структуре одного из них ну прям совсем не гуд. В Оракле, к слову, организованные по индексу таблички используют крайне и крайне редко. Потому что проку никакого.
Почему только myisam, innodb тоже, который по сути остался единственным вариантом для acid транзакций. Там каждая таблица кластеризована по первичному индексу. И все остальные вторичные индексы ссылаются на этот индекс.
В отличие от postgresql, где все данные лежат в неупорядоченном массиве. Там кластеризация, это лишь временная операция. А также приходится часто обновлять индексы, из-за обновления строк новыми версиями.
Ещё раз, таблица эта такая хрень, где есть первая строка, вторая, вторая ниже первой, но выше третьей, и так далее. И это порядок где-то в мета-инфе задан. Вот на листке бумажки ты табличку рисуешь карандашиком, а как ей пользоваться у тебя в социо-культурном коде в мозгах "зашито". Больше никаких таблиц нет. А "кластерная таблица" в МС или в Инно это дерево, а не таблица, в котором данные строк приделаны к листовому уровню. По факту это двунаправленных список.
И не в каких "неупорядоченных" массивах данные не лежат -- таких массивов не бывает, массив это множество, к которому приделали категорию порядка, т.е. упорядочили по определению. Типично данные "табличек"-отношений хранятся в куче.
Кластерная таблица очень-очень мутный термин. Потому что в МС кластерная таблица это про хранение данных отношения в структуре битри-индекса, а вот в Оракле кластерная таблица это вообще не про индексы, а про хранение однотипных данных разных отношений в одной куче.
Чем это лучше zheap? Оно же тоже построена на undo logs.
>прямое связывание страниц в оперативной памяти со страницами в постоянном хранилищеНу вот это они зря, нужно было всё самим ручками писать, а не ядро использовать и уж тем более не использовать mmap. Это прямой затык. Кто не верит ищите тесты гугле.
ну так это и не рс ещё даже хДДД
Мы mmap используем только для экспериментального режима хранения данных в persistent memory (проводили эксперименты с Intel Optane).
По-умолчанию у нас никакого mmap. Прямыми сслыки между страницами есть, но управляем ими сами. Можно дательнее здесь почитать.
https://www.orioledb.com/docs/architecture/overview
Просто вопросы, которые мне интересны:
- А fsync всё ещё используете (навеено этим https://habr.com/ru/articles/472684/)?
- Не считаете, что использовать fsync в БД это глупо?
- Не думали использовать, что-то типа io_uring или spdk?
Хабровая статья, как это часто бывает, перевод продуктивного бреда какого-то очередного шизофреника. Нет никакой проблемы с fsync-ом.
Ждём оттвета Короткова.
Моё личное мнение, что БД должны использовать только direct io беря на себя функции кеша и т.п., если нужна надёжность и производительность.
статья от IBM про бенефиты direct io - https://www.ibm.com/docs/en/aix/7.2?topic=io-benefits-direct
Решение БД в 99% случаев не знает о каких нибудь специфичных, супербыстрых аппаратных средствах кэширования данных. Но система с этими средствами скорее всего работает нормально.
Бредом шизофреника я был статью не назвал. Но она является вольным пересказом треда постгресовой рассылки автором статьи. И что самое главное, там отсутствует финал – коммиты которыми всё закончилось.
И ещё вопросы:
- PostgreSQL использует huge pages, если нет то пробовали ли включать?
- Если пробовали какой результат?Слышал, что или MariaDB или PerconaDB или т.п. включило huge pages и результат был хуже чем без них.
> - А 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?
Да, планируем в будущем переходить на более продвинутые решения.
>Мы mmap используем только для экспериментального режима хранения данных в persistent memory (проводили эксперименты с Intel Optane).А это в принципе не важно для чего вы используете. HFT системы, например, не используют mmap т.к. ядро Linux становится тормозом. А ядро вы используете, значит и с optane у вас на нагрузках будут те же самые грабли.
Как раз таки важно для чего использовать mmap!
Если мапить файл или блочное устройство – то ядро занимается подгрузкой и записью страниц, и происходят тормоза о которых вы говорите.
Если мапить персистентную память, подключенную к шине также как и обычная память, память просто мапится на адресное пространство процесса. И при этом уже во взаимодействии с данной памятью ядро никак не участвует.
Так что mmap mamp'у – рознь :)
Я так понял OrioleDB написан на Си. А почему на С++ или Rust не пишете?
Да, OrioleDB написан на C.Есть низкоуровневая часть кода, связанная с форматом tuples, упаковкой данных на страницы и т.д. Насколько я знаю, эта часть практически везде написана на C.
Есть часть кода, сильно завязанная на внутренние структуры и функции PostgreSQL, которые в свою очередь тоже написаны на C.
Между ними есть небольшая прослойка, которая возможно выиграла бы от Rust. Но не занимались.
Под прямыми ссылками вы имеете в виду технику известную как pointer swizzlingp [1,2] или что-то другое?1. https://ceur-ws.org/Vol-1858/paper9.pdf
2. https://bnm3k.github.io/blog/pointer-swizzling/
Да, вижу, что pointer swizzling – одной из её названий. Спасибо за ссылки.
к 1с это можно прикрутить?
> к 1с это можно прикрутить?С 1С это вообще никак не связано. Есть еще уровень абстракции выше системы хранения с которым и работает 1С.
Прям маркетинговая няшка для утомлённых ораклом. Все приписываемые улучшения улучшения только в сознании дба-неофита. Сплошные разоблачения мифов. Нет вакуума -- ура!!! Счётчик 64 бита -- ура!!! Есть отдельное ТП для undo -- ура!!! Обновления по месту, а не постоянный cow -- ура!!! WAL на уровне строк, а не на уровне кластера целиком -- ура!!! Как-то слишком про желание сделать из одного, что-то совсем другое.
>Обновления по месту, а не постоянный cow -- ура!!!Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки. Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение производительности не исключенно.
>>Обновления по месту, а не постоянный cow -- ура!!!
> Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки.
> Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение
> производительности не исключенно.Самый очевидный профит в том, что замена одной закорючки в строке из десятков или даже сотен полей не приведёт к созданию новой строки. Но модель MVCC отход от принципа всегда insert корёжит радикально.
Мусье считает, что залочить (используя atomic операции) строку для её обновления это дешевле чем вставить новую? Может тебе мат.часть подучить?
Мат. часть чего? Понятия не имею, что в конкретных условиях будет быстрее: найти место под вставку и скопировать или просто по месту, которое уже найдено, что-то поменять. По опыту лишь знаю, что даже при большом внимании к настройке вакуума файлы данных пухнут стремительно и необратимо, это в бд, в которых update-ов кратно больше insert-ов.
>Мат. часть чего?Процессора, кешей, влияния atomics на кеши, протоколы когерентности кешей и т.п. и само собой каким образом делается обновление/вставка строки по месту. Про лог не упоминаю, ты сам про него пишешь ниже. Чтобы строку заменить/обновить по месту нужно эту строку залочить (у PostgreSQL, наскольку помню, есть такая возможность), а лок делается на атомиках, а чтобы добавить новую версию строки в конец файла БД нужно всего лишь её добавить атомарно залочив в метаданные, к которым нет такого потенциально высокого конкуретного доступа.
Дешевле лочить метаданные (заголовок таблицы) чем лочить строку и это я ещё не говорил про перенос старой строки в лог, про который ты написал ниже.>Но вот Оракл как-то справляется
Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать.
>Дешевле лочить метаданные (заголовок таблицы) чем лочить строкуДополнение, при условии, что читателей больше чем писателей.
Э, Слон, как и прочие, в случае вставки вставляет не в конец (кого/чего?), а туда, где место есть. Т.е. это не тупая вставка в некий всегда известный заранее "хвост", а поиск куда вснуть в уже распределённом и только, если там нету, то выделить новую страницу, опять же, вопрос где. В общем, операция вставки далеко не факт, что дешевле, корректировки по месту. Хотя для корректировки по месту и надо лочить.
>Э, Слон, как и прочие, в случае вставки вставляет не в конец (кого/чего?), а туда, где место есть.Я описывал принципиальное отличие.
>В общем, операция вставки далеко не факт, что дешевле, корректировки по месту.
Ассмептотически оно дешевле т.к. выделяется сразу блок и оверхед размазывается по всем операциям добавления "в конец". Что касается кешей, атомиков и т.п., для этого я и сказал в самом начале - Нужны тесты.
> Правильнее сказать - 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&#...
А, понял твой скепсис. Да, такой подход требуют где-то хранить лог (или не лог, а всю строку целиком) изменений для строки. И интуиция подсказывает, что вести такой лог будет недешево. Но вот Оракл как-то справляется. Я тестил ещё 13-тый Слон против 19-го Оракл. Оракл update-ы делает быстрее. Ни на что не претендую, но разница была до 40%. Условия были такие, что в исходно созданных и заполненных табличках кол-во строк не менялось, а менялись только сами строки. За цикл все таблички переписывались полностью. Сначала Слон и Оракл были более-менее равно, но чем больше циклов, тем Слон всё сильнее отставал. Во всех табличках был только один индекс по первичному ключу.
Как произнести название на русском?
Ориоль-Ди-Би
А в чём профит маппить буферы сразу на блоки? Такое больше не надо чекпоинтить? В этом?
Когда уже RC версии пойдут? Есть какой-то роадмап? А то всё альфы, да альфы, беты, да беты