https://opennet.ru/openforum/vsluhforumID3/135468.html Представлена бета-версия движка хранения OrioleDB beta7 и опубликованы результаты новых тестов, демонстрирующих значительное повышение производительности по сравнению с традиционным PostgreSQL. В версии beta7 были внедрены оптимизации, направленные на улучшение работы с многопоточными нагрузками и ускорение операций чтения и записи. Первый стабильный релиз OrioleDB планируется сформировать в 2025 году. Движок написан на языке Си и распространяется под лицензией PostgreSQL, похожей на лицензии BSD и MIT...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62327<br> https://opennet.ru/openforum/vsluhforumID3/135468.html#105 Mon, 30 Dec 2024 20:10:56 GMT Есть алгоритм сериализации, приводящий к меньшему числу конфликтов, чем SSI. Называется он SSN: serializable safety network. Правда, точно так же нужно брать на всё &#171;блокировки&#187; (точнее, ставить пометки). Но конфликтов будет меньше.<br><br>Но это пока теоретический алгоритм с единственной экспериментальной реализацией от его авторов. О боевых внедрениях я пока не слышал.<br> https://opennet.ru/openforum/vsluhforumID3/135468.html#104 Fri, 27 Dec 2024 07:13:18 GMT Когда уже RC версии пойдут? Есть какой-то роадмап? А то всё альфы, да альфы, беты, да беты<br> https://opennet.ru/openforum/vsluhforumID3/135468.html#103 Mon, 23 Dec 2024 12:08:39 GMT Положительный отклик на ваш комментарий понятен -- никто не любит возиться со случаями, когда serializable действительно нужен, и никто не любит его стандартного поведения. Тем не менее, подходы вроде select for update не позволяют достаточно приблизиться к семантике "честного" SSI. Потому что именно так, как себя ведёт SSI, единственный доступный и реализуемый подход, когда важна последовательность транзакционных событий. На практике чаще всего честный S не используют не потому, что он не нужен на уровне предметной области, а потому что его поведение считают, скажем так, странным -- ведь все хотят, чтобы на этом уровне конфликты последовательности транзакций НЕ ДОПУСКАЛИСЬ в том смысле, чтобы они как-то сами собой РАЗРЕШАЛИСЬ, а не так, как это сейчас и единственно возможно, выбрасыванием исключения о невозможности соблюсти условия транзакции, которое, вот же досада, нужно как-то самому разработчику разрешать. Так вот, это я к тому, что если важна последовательность совершения транзакций, то сейчас ПРОСТО НЕ https://opennet.ru/openforum/vsluhforumID3/135468.html#102 Tue, 17 Dec 2024 08:34:31 GMT &gt; к 1с это можно прикрутить?<br><br>С 1С это вообще никак не связано. Есть еще уровень абстракции выше системы хранения с которым и работает 1С.<br> https://opennet.ru/openforum/vsluhforumID3/135468.html#101 Tue, 17 Dec 2024 08:31:11 GMT Решение БД в 99% случаев не знает о каких нибудь специфичных, супербыстрых аппаратных средствах кэширования данных. Но система с этими средствами скорее всего работает нормально. <br> https://opennet.ru/openforum/vsluhforumID3/135468.html#100 Mon, 09 Dec 2024 06:05:25 GMT Ориоль-Ди-Би<br> https://opennet.ru/openforum/vsluhforumID3/135468.html#99 Fri, 06 Dec 2024 16:04:30 GMT &gt; Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной.<br><br>Безусловно. На моей пратике большинство таких кейсов прекрасно решалось с помощью row-level locks/advisory locks. Можно сказать, что преимущество SSI &#8211; это возможность просто получить гарантии сериализуемости и не думать о тонкостях concurrency.<br><br>Но при этом у SSI есть недостатки.<br>1) Накладные расходы. Транзакция ставит predicate locks на все затрагиваемые heap tuples и индексные страницы (не только при записи, но и при чтении). Локов может оказаться очень много, в этом случае, насколько я помню, они апгрейдятся до локов на целый relation. Оценка оверхеда в 10%, полученная при разработке SSI, была получена на не очень мощном железе и не очень большой concurrency.<br>2) Необходимость учить приложение повторять любую транзакцию, которая упала из-за ошибок сериализации. Причём это https://opennet.ru/openforum/vsluhforumID3/135468.html#98 Fri, 06 Dec 2024 11:26:53 GMT SSI нужен. Полно задач, в которых бизнес-правила опираются на хронологию, выстроенную вокруг начала выполнения транзакции, а не их завершения. И если это правило не выполняется, то транзакция, как минимум, должна считаться не валидной. Хотя, конечно, кратно больше ситуаций, где SSI излишен совершенно и RC/RR достаточно.<br> https://opennet.ru/openforum/vsluhforumID3/135468.html#97 Fri, 06 Dec 2024 07:55:27 GMT Гарантии ACID такие же как и в дефолтовом движке PostgreSQL, за исключением отсутствия поддержки SSI (за всю карьеру не припомню случая где он был бы реально необходим). Но на текущем этапе зрелости проекта серьёзные баги, конечно, могут быть.<br>