Меня терзают смутные сомнения

Сейчас приходится жить с Posgres/Greenplum, Hadoop, Clickhose. Теперь Oracle вспоминается с позитивом. У теперешних инструментов часто проблемы там, где бы никогда их не ждал. А объясняют так: «Ну вы же понимаете… ну это же только развивается..». Помнится, у моего экземпляра аптайм годами измерялся и терпел любые эксперименты. А теперь: ACID роскошь, курсоры роскошь, пакетов нема, job`ов вообще нигде нет! «Коннекты не держит? - так нужно было брать Clickhouse. Ой, упало по памяти с правой стороны join? - так аккуратнее, частями грузи». А оракл жевал OLTP рядом с вертикальными инмемори-столбцами. А секрет прост - С-монолит в десятки миллионов строк за много денег.

А секрет прост

Топовые проприетарные СУБД пилят намного более талантливые люди? А ведь такие СУБД подразумевают не только отличное владение сишечкой, но ещё и знание «матана»?

Да, без матана там нельзя.

да ну прям. ну где там «матан»? конечно, если вы понимаете, что такое матан, а не используете это слово как некую абстракцию для «чего-то сложного». я слабо представляю себе, как натянуть матан на программирование. там же чистая теория, даже не численные методы.

по таким вещам, конечно, было бы интересно более детальное сравнение. но понимаю, что ЛОР слишком мелок для такой аналитики.

я гоняла некоторые базы типа постгреса в больших нагрузках, вроде ничего не падало. но у меня были не такие большие объёмы базы. и я не использовала прямо все-все фичи. но хотелось бы понять, что там может пойти не так и чего не хватает для жирного прода. кстати, он тоже «монолит на сишке», в принципе. ну, то есть, код там вполне приличный. я его смотрела немного.

Если корпорации и госы увязнут еще сильнее в импортозамещении, то с чего бы им обратно на буржуйскую проприетарщину откатываться?

Я больше думаю, что если санкции отменят, и частные корпы полезут опять на винду/оракл/чтотамеще, то появятся какие-то программы поблажек за использование отечественного софта. И частники сто раз подумают, платить буржуинам или своим. И если у частников появятся деятели которые будут опять тянуть на Microsoft/Oracle/SAP и т. д. то этим деятелям быстро объяснят их место в пищевой цепочке.

А госы будут пользовать то что разрешит государство.

Я очень надеюсь, что санкции продлятся настолько долго, что откат на буржуинское будет невозможен.

Для меня матан - это Тер-Крикоров:) В СУБД это будут комбинаторика , теорвер и графы. В частности, в оптимизаторе запросов и использовании статистики распределения данных (например гистограммы). + вроде там свой аллокатор памяти. Ну и концепция autonomous database (самооптимизация экземпляра) тоже к математике подталкивает.

ну, это матстатистика, а не матан. но в целом понятно. так-то там никакой сложной математики нет. но очень важна грамотная реализация, с хорошей оптимизацией. фиговая реализация сведёт на нет все попытки использования распределений для оптимизации работы с данными. насколько я понимаю, с теорией проблем нет. а вот с реализациями как-то не очень.

хотя мой личный опыт с постгресом весьма успешен. я его гоняла на нагрузку и прочее. вроде пашет и у меня к нему нареканий нет, но я не использую распределённые базы, шардинг, репликация у меня только для бэкапов. в целом, это очень малый набор фич современных монстрозных СУБД. с другой стороны, там есть деление таблиц на сегменты (по датам, например), что очень удобно во многих задачах. они даже втащили туда json, емнип, но это уже сомнительная штука и будет тормозить.

а так, я когда-то сравнивала все шустрые базы, которые работают в памяти или на больших скоростях и больше всего мне понравился MemSQL: эти перцы сделали не просто сишную реализацию. у них запросы - это компилируемый код! и оно работает просто потрясающе быстро. идея прекрасна. раньше они даже давали код своей базы, сейчас не знаю.

Параллельные сортировки по мульти индексам - не?

Там такой json, что до сих пор быстрее re поиск. Я пробовал вешать индексы на ветки, всё равно бред и проще на этапе ETL выкусывать и заполнять нужные поля.

так я его и не рекламирую. json вообще не нужен, по идее. и тем более глупо пихать его в базу, да ещё и пытаться делать по нему селекты. это уже какая-то таблица в таблице, а это нездорово по определению.

это никакого отношения к матану не имеет, я полагаю.

Бэкап данных из субд в облака?

А что в этом странного?

DB там-же

База в облаке распределеная.

Востанавливается не с одного диска а паралленьно.

Соответственно это быстрее.

И если у частников появятся деятели которые будут опять тянуть на Microsoft/Oracle/SAP и т. д. то этим деятелям быстро объяснят их место в пищевой цепочке.

И кто же будет проводить такие разъяснительные беседы?

Вы думаете у государства, тем более такого, как Россия, не найдется рычагов давления на частный бизнес? :) Ну вот тебе пример: используешь неправильный софт – не участвуешь в госзакупках.

не участвуешь в госзакупках.

Гыгы. Вот «с улицы», и даже не «с улицы» заход в госзакупки - это последние 10 лет гарантированная ж.... В Петербурге так несколько мостостроителей обанкротилось (не «генеральных подрядчиков», а нормальных).

База в облаке распределеная.

Вы про Azure Hyperscale ?

И кто же будет проводить такие разъяснительные беседы?

Менеджеры российских брендов, которые не хотят потерять свой кусок пирога. Как это так: кушали-кушали, и тут от них отказываются. У крупных интеграторов такое просто так не проходит.

Санкции никогда не снимут. СССР распался, а поправка Джексона-Вэника ещё много лет действовала.

Менеджеры российских брендов, которые не хотят потерять свой кусок пирога.

Цитаты:

синхронная репликация в пг - миф. соответственно нужен догон вала. вал физический и очень медленный. а ещё есть смешные моменты по типу
у тебя есть 1 мастер и 2 реплики. и есть кодеры, чтобы отдать в личный кабинет данные нужно сделать джойны по 5+ таблицам, потом сделать агригейт. ну в общем строк 40 запрос.
в итоге мастер предположим здох\переезжать начал. на реплике джойны. а нга второй реплике паника.... и нифига твой автофейловер не будет работать

https://t.me/kubernetes_ru/1047386

одни вон великие русские продажники постгреса. вообще рекомендуют шардировать пг каждые 500 гб

https://t.me/kubernetes_ru/1047394

9к баксов за ядро(760к рублей)

https://t.me/kubernetes_ru/1047424

И что? Ты сейчас привел какие-то проблемы хайлоада на опенсорсе, которые волнуют исключительно бигтеховые компании.

Куча внутренних информационных систем на 2-3 тыщщи пользователей эти проблемы вообще не касаются. А таких систем в бизнесе большинство.

которые волнуют исключительно бигтеховые компании.

Он госами вроде занимается.

Он госами вроде занимается.

Ну госы тоже разные бывают. Госуслуги или налоговая - это одно, а учет и выдача иностранных паспортов - это другое.

Поэтому госсистему миграционного и регистрационного учета «Мир» смогли в еще в 2017 году перевести на древние Эльбрус-4С, и она походу до сих пор работает на том же Постгресе. Я на ней паспорт в СПб оформлял - все сделали мгновенно, без всяких проволочек. Никаких там рассказов что «мы не можем быстро, у нас система глючит и тормозит» - не было.

Все зависит от структуры, объемов и задачи. Бигтеховых хайлоадных задачь в мире то немного. И организаций, соответственно, тоже.

Все зависит от структуры, объемов и задачи.

С течением времени объёмы растут, задачи усложняются.

Поэтому появилось горизонтальное масштабирование записи даже в IBM Db2 (DPF) и MSSQL (как минимум Hyperscale).

А что с горизонтальным масштабированием записывающей OLTP нагрузки у PG?

Цитата:

я тебюе больший смех скажу. для большинства компаний переезд с терадаты и оракла с дб2 на пг обходится x5 дороже чем сидеть на тех "дорогих" бд

https://t.me/kubernetes_ru/1047428

С течением времени объёмы растут, задачи усложняются.

Задачи надо уметь разбивать, а не делать монолит. Тогда и объемы у задачи могут даже уменьшиться. Не просто так появились микросервисы, докеры и кубернетисы - это ментально из той же серии.

А что с горизонтальным масштабированием записывающей OLTP нагрузки у PG?

OLTP (Online Transaction Processing, Оперативная Обработка Транзакций) — это система управления данными, предназначенная для обработки большого количества мелких транзакций в режиме реального времени, таких как банковские переводы или бронирование билетов, с минимальной задержкой и высокой доступностью данных.

Вопрос остается все тот же - зачем ты тащишь свой хайлоад туда, где он не нужен?

OLTP - это по сути любая набивалка данных

OLAP - аналитика (отчёты, etc.)

Вопрос остается все тот же - зачем ты тащишь свой хайлоад туда, где он не нужен?

Почему туда, где ненужен?

PG по словам СХ не справляется, но highload-а по твоим словам нет, очень весело.

Задачи надо уметь разбивать, а не делать монолит. Тогда и объемы у задачи могут даже уменьшиться. Не просто так появились микросервисы, докеры и кубернетисы - это ментально из той же серии.

По твоему любую OLTP задачу можно разбить на независимые мелкие базы микросервисов? А как быть с аналитикой? Всегда ETL-ить, в то время как проприетарные СУБД неплохо справляются с HTAP (OLTP и OLAP одновременно) нагрузкой ?

Но лицензий для микросервисов можно продать конечно побольше, тут не поспоришь. :) И админов нанять побольше, тоже хорошо, или проплатить облачные базы, а оно стоит огого сколько :)

А, ну это не настоящая субд.

maxcom, ты, конечно, можешь ещё мне накостылять, но вот я не согласен ни разу. Это были не политические споры. К религиозным, конечно, ближе, потому что эпплофаны во власти на уровне фанатиков (я сейчас не только про Россию говорю). Понимаю, времена сложные,не дай бог чего такое попадётся товарищу ИИйору. Но, блин, впервые стало обидно за совершенно неправильно понятую причину удаления. Вот.

Про АНБ? :)

Хз.

Не поню, меня сейчас это не волнует 😀

Поищу если будет время

Без настоящего одмина нет настоящей ДБ ? 😀

Без настоящего одмина нет настоящей ДБ ? 😀

Ну если заниматься буквоедством то: «А ДБ это что?» :) А если серьезно, то нахрена БД админ?

Не поню, меня сейчас это не волнует 😀

Эта ветка форума уже наполнилась нужной информацией о проприетарных СУБД vs PG и развивать её дальше - только портить?

А если серьезно, то нахрена БД админ

.dbf и без админа может.

А облако таки имеет штатного админа.

Я не вам вопрос задал :) Но

А облако таки имеет штатного админа.

А облако уже и не БД.

ну, DBA при крутых и жирных базах часто-таки бывает. правда, обычно это такие прямо прынцессы, к которым на сраной козе подъехать не смей! почему-то именно среди DBA видела много каких-то совершенно необоснованных понтов и пафоса. может, мне так не везло на них.

DBA - все-таки про RDBMS на не про DB.

почему-то именно среди DBA видела много каких-то совершенно необоснованных понтов и пафоса.

У узких, но хорошо оплачиваемых специалистов такое в разных областях встреть можно.

но сидят-то они на вполне себе конкретных базах. а формат базы - дело десятое. просто там все эти сертификаты, понты и гнутые пальцы веером. своеобразная специфика. хотя не сказать, что там прямо какие-то ниэпические знания.

но сидят-то они на вполне себе конкретных базах.

Нет, сидят они на конкретных RDBMS, а не базах.

а формат базы - дело десятое

Эм... вы что под «форматом базы» подразумеваете?

хотя не сказать, что там прямо какие-то прямо ниэпические знания.

А вот это точно! Есть специфики которых дофига и больше, но не более того.

вы что под «форматом базы» подразумеваете?

то, что ты пафосно называешь RDBMS, например. но там может быть и какой-нить nosql.

rdbms, nosql, прочая пафосная чушь - всё это БД. очень просто.

Этот рынок делят не для того что бы всё вернуть обратно.

А облако уже и не БД.

Облачные базы данных (PaaS) ?

rdbms, nosql, прочая пафосная чушь - всё это БД. очень просто.

Если вы используете rdbms на уровне db, то да, это и правда чушь.

Ну, частично это оправдано возложенной ответственностью. +Когда система начинает тормозить из-за корявых запросов/кода, считают, что админ должен разгребать :)

Я намекал на то, что всё что в облаке оно не ваше. Облако можно рассматривать как хранение/обработку чего-то выгруженного из основной БД.

Я намекал на то, что всё что в облаке оно не ваше.

Бэкапить из облака к себе нельзя? Подсказываю, штатными средствами облака обычно нельзя бэкапить за пределы облака, отсюда и проблемы обеспечения сохранности данных в облачных PaaS и SaaS в случае, если они эти данные пролюбят.

Облако можно рассматривать как хранение/обработку чего-то выгруженного из основной БД.

В качестве основной базы никто не использует?

Если вы используете rdbms на уровне db

Это как ? :)