| |
| 2.11, Семен (??), 15:19, 10/02/2025 [^] [^^] [^^^] [ответить]
| +4 +/– |
да, только Сitus это не СУБД, в новости ошибка, это расширение для PostgreSQL, которое на себя берет функции шардинга. "Citus is a PostgreSQL extension that transforms Postgres into a distributed database—so you can achieve high performance at any scale." Т.е. вы можете иметь любую версию PostgreSQL, накатить расширение и развернуть кластер. Для 1c для лучшей производительности и работы с юникодом вам желательно накатить патчи для PostgreSQL и пересобрать PostgreSQL. Плюс Сitus не берет на себя функции менеджера соединений, в PostgreSQL дорогое создание соединений, поэтому для нормального кластера вам понадобится еще что-то типа PgBouncer, да и без кластера PgBouncer может быть не лишним. Суть в том, что если вам нужна быстрая аналитика и построение отчетов, то к примеру вам выгоднее иметь 10 серверов с шардами по 100гб, чем один сервер с базой 1TB. Т.е. вы можете получить плюсы OLTP и OLAP одновременно. С OLTP на больших базах у вас будет очень дорогое и медленное создание индексов, индексы могут весить намного больше полезных данных, в итоге вы будете вынуждены минимизировать количество индексов в бд, и практиковать частичные индексы, чтобы это работало более менее нормально, но не везде это применимо.
| | |
| |
| 3.22, Аноним (22), 16:45, 10/02/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
1C - позорище, до сих пор не могут сделать поддержку Postgre без патчей.
| | |
| |
| 4.38, Семен (??), 23:12, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Скажу в защиту 1C, поддержка postgresql в 1С появилась более 15 лет назад, и за эти 15 лет они очень сильно оптимизировали работу со всеми СУБД, изначально у них был опыт только с mssql, отсюда они работали с ораклом и с postgresql как с mssql, не беря во внимание архитектурные особенности. Так же все современные конфигурации были переписаны, чтобы эффективнее работать с бд и блокировками. На самопале и на старых версиях платформы 1с предприятия есть проблемы, и где-то их не спешат обновлять, на новых все работает довольно хорошо. Так же эти 1с патчи не сильно изменились, и их не сложно портировать на новые версии postgresql. Есть другой вопрос, и он юридический, если вы обрабатываете персональные данные вам нужна СУБД с сертификатом ФСТЭК. В остальных случаях вы можете хоть самопальную СУБД использовать.
| | |
| |
| 5.39, AnonNoX (?), 00:32, 11/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
1C-ники плевались от ПГ 15 лет назад. Сейчас с удовольствием читаю, что там подгорает. Проблем с использованием MS SQL c 1C, теоретически, быть не должно ))
| | |
|
|
| 3.27, Аноним (27), 19:14, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Плюс Сitus не берет на себя функции менеджера соединений, в PostgreSQL дорогое создание соединений
Хех... А если софтину, которую я юзаю, писали умные люди и она держит пул соедиений к БД, через которые идут все запросы, так сабж для меня ващще тортик?
| | |
| |
| 4.30, Семен (??), 21:29, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Citus это кластер и это несколько серверов. Если у вас несколько серверов вам в любом случае нужно что-то типа HAProxy для нормальной балансировки нагрузки. Насчет PgBouncer сказать сложно, нужен он вам или нет, надо смотреть во что упирается БД, это может быть IOPS, оперативная память под кэш, или процессор. Вполне вероятно у вас просто нет нагрузок к бд, и можно обойтись без прочего инструментария. Если упирается в IOPS вряд ли проблема у вас с соединениями, тут скорее сигнал, что надо расширять хранилище - добавлять диски в рейд или добавлять сервера в кластер, и самое главное вероятно надо пересмотреть структуру БД и более грамотно спроектировать индексы. Новое соединение, требует к примеру память и процессор, так как надо к примеру скопировать часть кэшей, и данные не сразу записываются на диск. "писали умные люди" для всех "умные люди" это совсем разный люди и критерии. По опыту, что связанно с данными и обработкой данных, даже умные люди не могут решить все проблемы, и есть много подводных моментов, с которыми вы можете столкнуться или вовсе никогда не столкнуться, у всех разные данные и структуры данных. Поэтому пока не проверишь, сказать сложно.
| | |
| 4.31, Семен (??), 21:51, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Кстати, если вы считаете, что софтину писали умные люди. Просто откройте багрепорты PgBouncer, Pgpool, Odyssey, да и просто почитайте статьи по ним, вы поймете, что не все так просто, и там просто овер дофига проблем, которые возникают на ровном месте и которые очень сложно решить.
Есть несколько веток развития:
1. Ограничение фунционала, чтобы снизить количество багов.
2. Приложение молодое, широкий функционал, и много багов.
3. Средний функционал, мало багов, приложение старое и работает надежно как автомат калашникова.
И есть представители из всех 3 категорий в достаточно "простом" приложении, как пулер соединений.
| | |
|
|
|
| |
| 2.15, Семен (??), 15:39, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Это так же как сравнить куй с пальцем. Есть условно ваниальный PostgreSQL которому почти 30 лет, он надежен как автомат калашникова, а есть хипстерские новомодные СУБД с блекджеком и шардингом, там больше функций, но и больше багов, что может быть критично в продакшене. Citus в РФ более популярен, и большая часть багов адекватно решаемые.
| | |
| |
| 3.35, Аноня (?), 22:45, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Он "настолько надёжен" что втихушку теряет данные без возможности восстановления. Потом они пофиксили этот баг (которому овердофига лет), но бэкпортить в 14 не стали (он там тоже есть).
А в Release Notes написали так, как будто это какое-то мелкое исправление, про потерю данных там ничего написано не было (но они это знали - понятно по описанию коммита исправляющего)
| | |
| |
| 4.37, Семен (??), 23:02, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Вас расстрою, но на больших данных все бд могут терять данные, и дело даже не в бд, банально диски могут отказывать, поэтому бэкапы никто не отменял. В том же оракле был очень веселый баг, когда оракл начинал отжирать всю память на серваке, и его прибивал OOM, и базу корежило. Не знаю решили ораклы этот баг или нет, но оракл не умел ограничивать использование памяти. В каких-то БД все эти баги возникают чаще, где-то реже, вопрос к зрелости и возрасту проекта. И для таких как вы есть параметр -k для initdb, чтобы быстрее отлавливать ошибки повреждения данных. В любом нормальном руководстве по postgresql вы увидите, что в продакшене надо обязательно включать --data-checksums. По умолчанию они были отключены в ванильном postgresql, в postgresql pro они включены по умолчанию. Если лыжи не едут по асфальту, то дело далеко не в лыжах, а в ездаке...
| | |
|
|
|
| 1.7, chdlb (?), 15:01, 10/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а всё, вопрос снимается, эта шляпа single-master, а multi-master только через DTC и вообще не является режимом по умолчанию, или с кастомным механизмом резолва конфликтов
| | |
| |
| 2.8, Аноним (8), 15:08, 10/02/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
У Майкрософта и documentdb на базе постгри. Этим они открыто показывают полную несостоятельность ms sql server.
| | |
| |
| 3.10, Ося Бендер (?), 15:16, 10/02/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
В таком случае и Оракул несостоятелен. У них тоже МайЭсКюЗль есть.
Думаю МикроСофт все делает, чтобы поднасрать. Ну или, когда не можешь победить, нужно возглавить.
| | |
|
|
| 1.9, Аноним (9), 15:15, 10/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
А сами PG не смогли это реализовать? Все нужные фичи приходится корпорациям добавлять.
| | |
| |
| 2.12, Семен (??), 15:30, 10/02/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Они реализованы сторонними компаниями и за не малые бабки. Потому что сделать надежный шардинг на уровне бд довольно сложно, много подводных моментов, ошибок, которые надо отловить. По этой причине не мало компаний практикуют шардинг на уровне приложения, вместо шардинга средствами СУБД. Про это даже есть не мало научных статей, это только со стороны обывателей кажется легкой задачей. Даже если взять просто PgBouncer, который является менеджером соединений, вроде все просто, ничего сложного обрабатывать соединения и проксировать запросы к СУБД, но даже там есть кучу серьезных багов, которое отлавливали и фиксили годами, просто так даже такое "простое" приложение не написать. Плюс у PostgreSql есть определенные архитектурные проблемы, которые мешают реализовать все это, поэтому проще создать новую СУБД заточенную именно под шардинг, и так появились некоторые модные субд.
| | |
| 2.14, Аноним (14), 15:38, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
А корпорации не могли реализовать свои БД, почему они делют это для постгреса?
| | |
| |
| 3.36, Аноня (?), 22:50, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Совместимость и экосистема. Диалекты SQL у всех разные.
Своё - переписывать прикладное ПО. Все ORM сразу отваливаются и т.д. и т.п.
У потенциальных клиентов уже что-то "стоит" - и скорее всего это будет Postgres.
| | |
|
| 2.17, Аноним (8), 15:46, 10/02/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты наверно поправильному хотел спросить зачем вообще шардирование нужно рсубд. Ведь всем кому это действительно нужно используют nosql где шардирование работает из коробки с нулём лишних телодвижений.
| | |
| |
| 3.21, Аноним (9), 16:36, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Раз мс это сделал, значит им это было нужно и готовые варианты их не устроили.
| | |
|
|
| 1.13, Аноним (13), 15:30, 10/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Хорошо, я это все забыл. Голова реально взрывалась от этих идиотских прослоек! Почему этого нет в функционале СУБД, когда это реально нужно?!
| | |
| |
| 2.16, Семен (??), 15:45, 10/02/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что вы не закоммитили этот функционал. Опенсорс же, критикуешь - предлагай свое решение и коммить его. Кому реально нужно, они нанимают разработчиков и реализуют функционал сами, а даренному коню в зубы не смотрят. Как выше писал, с виду простые проблемы в СУБД, требуют огромных, дорогих исследований и научной работы, не всегда есть такие ресурсы у опенсорс.
| | |
| |
| 3.18, Аноним (8), 15:46, 10/02/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это не простая проблема. Это вообще ненужная функция в рамках рсубд.
| | |
|
|
| 1.42, Аноним (42), 09:06, 11/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>Компания Citus Data, принадлежащая Microsoft, опубликовала распределённую СУБД Citus 13.0, реализованную в форме расширения к PostgreSQL 17.
Неужели MSSQL хотят закопать?
>Код написан на языке Си и распространяется под лицензией AGPLv3.
Да ладно, GPL и M$ ! Что в лесу M$ определённо померло.
| | |
| 1.43, Аноним (-), 10:26, 11/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
M$ не помер, речь всё-таки о PostgreSQL. Я лично предполагаю что хотят на свои продукты перетянуть с Postgres. И желательно на облака, где все секреты будут храниться у американцев на компьютерах со свободным доступом к ним западного товарища майора. Мне кажется дураков нет - по политическим причинам использовать не будут. Они же свою политику показали.
Какое им дело вообще до конфликта между славянскими странами? Вы меня извините, но я вас врагами вообще не воспринимаю до сих пор. И в целом считаю неплохой идеей проиграть (т.е. чтоб вы выиграли) и стать одной страной снова. Но да, нам теперь нигде не рады, а жить как-то нужно будет. Жаль что от меня ничего не зависит.
| | |
| |
| 2.44, Аноним (44), 12:03, 11/02/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Какое им дело вообще до конфликта между славянскими странами?
Мистер Trump хочет стать голубем мира, получить Нобелевскую премию мира. Не, он, конечно, не бедствует, но престижно же.
| | |
|
|
