«Росатом» за 828 млн руб покупает лицензии PostgreSQL Pro под российские процессоры «Эльбрус»

Компутеры давно имеют разрядность 64 и копировать туда-сюда какой-то ссаный гигабайт точно ни у кого проблем не возникнет

А теперь давай добавим условие - данные должны быть строго синхронизированы с массивом дисков (рейд6, с рассчётом чётности) и ещё продублировыаны в логе операций. И всё становится совсем не так просто.

Это всё то же самое, что и работа с любым другим куском данных (строка постгреса).

Обычно его рефакторят без явного спроса разрешения у бизнеса. Добавлял фичу и заодно всё переписал - рядовая тема.

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

В любом случае, в коде пропиетарных продуктов есть просто адовое количество багов, костылей, и сомнительных архитектурных решений. Утверждать обратное может только человек, который не работал с пропиетарным кодом.

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

Главное, тон @borisych очень сильно напоминает мне некоего давно покойного товарища Бутенко из fido7.ru.linux (я читал ФИДО только через NNTP), который утверждал то же самое про ядро Linux, и ванговал, что оно сдохнет, т.к. написано «пионерами». Но в итоге, все его предсказания оказались неверны. Хотя читать было интересно.

Это всё очень зависит от реализации и сценария. Что то мне подсказывает, что есть много разных способов засовывания куска данных, и не все из них будут одинаково полезны. Я не знаю .а вдруг там где то по умолчанию выставлено что надо каждые 128Мб записи в базу провести сборку мусора или проверку индексов?

Всё не так просто

Нет, всё именно так просто. При наличии препятствий это не делается, но обычно их нет особо.

Я не знаю .а вдруг там где то по умолчанию выставлено что надо каждые 128Мб записи в базу провести сборку мусора или проверку индексов?

Ну вот бородатые мужики в Postgres PRO и получают 550к/сек денег чтобы это закостылить как надо в сищно-макросном говнокоде и чтобы всё остальное при этом не обезжопилось.

Внутри всё совссем не одинаково

Обычно всё совсем одинаково.

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

Для этого сидят бородатые мужики за 550к/сек денег, чтобы найти лучший способ.

В-третьих, код смотрят коллеги на ревью, не все из них согласны с решением тайком протащить рефакторинг.

Можно не тайком, а отдельным MR. Если какой-то говноед препятствует, то его надо затравить и слить из конторы на мороз.

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

Ничем не отличается от падения «не от рефакторинга». Короче какой-то ной слабаков.

Главное, тон @borisych очень сильно напоминает мне некоего давно покойного товарища Бутенко из fido7.ru.linux (я читал ФИДО только через NNTP), который утверждал то же самое про ядро Linux, и ванговал, что оно сдохнет, т.к. написано «пионерами». Но в итоге, все его предсказания оказались неверны

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

Сейчас это стало отличным поводом уволить оператора.

выйграл

☺

в технологическом плане ваша IT-инфраструктура застряла в 90-х годах прошлого века, и вам на самом деле нужно выставлять на мороз весь ДИТ и срочно модернизировать инфраструктуру

Так у нас, у покупателей Postgres PRO никакой инфраструктуры и нет, постгрес-про и есть вся наша инфраструктура хранения данных.

я совершенно не понимаю чем можно было руководствоваться

Как обычно - совместимостью с чем-то. С чем мы не знаем и всем похрен. Это же постгрес, он древний как кал, какая разница уже. Бугага.

И с виндой тоже, флешку-то там мужик в винду втыкал.

Да и пофиг, отсидят и выйдут, делов-то.

Странные вопросы конечно, я тоже менее 256 гб оперативы давно не видел…

Ну слушай. Если тов. anonmyous и тов. borisych правы, то в ближайшее время мы увидим замедление темпов разработки Росатома и банкротство последнего, потому что Росатом в таких условиях мгновенно проиграет конкуренцию Вестигхаусу и Ареве, которым по-прежнему доступны божественные высокие технологии Intel и Oracle, в десятки раз более быстрые, чем постгрес на эльбрусе.

Или не увидим.

Я имел ввиду другое - голый движок, хранящий конкретные структуры данных (в любой СУБД внутри) гораздо более скромен и понятен, чем собственно машинерия разбора SQL-запросов и планирования их исполнения. Поэтому, если у тебя к той же СУБД прикручен сбоку какой-то другой API бинарного вида с типами запросов 0x01 = READ и 0x02 = WRITE, то это ничем не будет отличаться от внутренностей движка, как если бы в эти «внутренности» пришли эти указания со стороны планировщика, распарсившего SQL - ссанину.

Ну слушай. Если тов. anonmyous и тов. borisych правы, то в ближайшее время мы увидим замедление темпов разработки Росатома и банкротство последнего, потому что Росатом в таких условиях мгновенно проиграет конкуренцию Вестигхаусу и Ареве, которым по-прежнему доступны божественные высокие технологии Intel и Oracle, в десятки раз более быстрые, чем постгрес на эльбрусе.

Проигрыш Вестингхаус и т.п. определяется только объёмом денег физикам в зарплаты, которые Вестингхаус будет платить за разработку нового реактора. Новые реакторы они просто почему-то давно не делали и уже растеряли всякое умение, не знаю почему. А может не растеряли, но скорее да чем нет. Им нужно сейчас понабрать много народу, попереманивать этот народ отовсюду из других стран и тогда заживут. Более того, лидерство США в ИИ может им помочь, если сгрузить на думающие модели какую-то часть работы по разработке-верификации отдельных блоков, устройств или просто трубочек теплоносителей или более элементарных вещей, типа формы и материалов гаек и болтов.

А вы нынче сроки в не советской России видели?

Ну то есть не увидим, и всё то, о чём сильно волнуются вышеуказанные товарищи, на самом деле не так уж и важно.

С другой стороны, а как, интересно, хитровыдуманные запросы на vliw себя ведут... Не лучше ли было risc использовать?

Я тут очень громко намекаю, что выбор постгреса и эльбруса обусловлен совсем не скоростными характеристиками, а ты опять )

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

А вы нынче сроки в не советской России видели?

Да какая разница, некоторые в компьютерные игры по 15 лет играют.

Если бы это было правдой - класса no-SQL баз данных не существовало бы. Как и нескольких конкурирующих реализаций SQL.

США в ИИ может им помочь, если сгрузить на думающие модели какую-то часть работы по разработке-верификации отдельных блоков, устройств или просто трубочек теплоносителей или более элементарных вещей, типа формы и материалов гаек и болтов.

Страстно желаю, что в США построили как можно больше АЭС, спроектированных ИИ.

А лучший случай он лучший только для конкретного случая. Кому то скорость, кому то надёжность подавай, а кому то чтобы работало в 512Мб памяти.

товарища Бутенко из fido7.ru.linux (я читал ФИДО только через NNTP), который утверждал то же самое про ядро Linux, и ванговал, что оно сдохнет, т.к. написано «пионерами»

Поискал, кто это такой. До сих пор пытаюсь вспомнить, где мне регулярно мозолит глаза плашка «CommuniGate Pro» :)

Но раз CommuniGate Pro портировали под Линукс уже в 1998 году, причём в 2 редакциях, значит он считал, что ядро проживёт достаточно долго.

А пожелания Линуксу сдохнуть могли быть просто завистью и обидой. Душевной травмой из-за невзлетевшей MISS.

До сих пор пытаюсь вспомнить, где мне регулярно мозолит глаза плашка «CommuniGate Pro»

Вроде Rambler использует CGP для своей почты.

Но раз CommuniGate Pro портировали под Линукс уже в 1998 году, причём в 2 редакциях, значит он считал, что ядро проживёт достаточно долго.

Да, я так понимаю, что основная его боль была вызвана процессом портирования. Но аргументы там звучали (дословно уже не помню, всё-таки 30 лет прошло) практически такие же: и стиль написания кода на C не тот, и пишут ничего не понимающие пионеры.

Если бы это было правдой - класса no-SQL баз данных не существовало бы. Как и нескольких конкурирующих реализаций SQL.

Нет никакого «класса no-SQL баз данных». Это какой-то рекламный треш. SQL - это просто язык запросов такой, внутри там всё равно какие-то конкретные код и структуры данных, которые хранят данные и по сети что-то гоняют. Обычно то, что называют noSQL базы данных - это компактные понятные простые движки, созданные только потому, что PostgreSQL жиробас с кучей говна внутри, которая на 99% не нужна в конкретном месте. Грубо говоря, зачем я буду создавать табличку с двумя колонками (key, value) если я могу просто написать на С++ структуру данных типа std::unordered_map<std::string, std::string> и получить сразу key=value хранилку? Как это надёжно в бинлог записать - тоже очень простая задача, а транзакции мне нах не усрались допустим.

Грубо говоря, зачем я буду создавать табличку с двумя колонками (key, value) если я могу просто написать на С++ структуру данных типа std::unordered_map<std::string, std::string> и получить сразу key=value хранилку? Как это надёжно в бинлог записать - тоже очень простая задача, а транзакции мне нах не усрались допустим.

И как данная мысль уживается одновременно с «Обычно всё совсем одинаково» (с) (linux.org.ru)?

Нет никакого «класса no-SQL баз данных». Это какой-то рекламный треш. SQL - это просто язык запросов такой, внутри там всё равно какие-то конкретные код и структуры данных, которые хранят данные и по сети что-то гоняют. Обычно то, что называют noSQL базы данных - это компактные понятные простые движки…

Сам же начиная с третьего предложения опровергаешь первое.

Если есть язык запросов SQL и существуют «понятные простые движки» баз данных, которые не используют этот язык запросов, то это и есть «класс no-SQL баз данных».

Нет никакого «класса no-SQL баз данных»

Все они https://hostingdata.co.uk/nosql-database/ с тобой не согласны. Это же блин очевидно! SQL - это просто язык запросов такой, а значит всегда будут БД, не использующие его! Или использующие, но не предназначенные для работы с ним из за внутренней структуры и принципов работы.

Нет никакой связи между SQL и внутренними структурами данных в движке СУБД вообще. Это всё бред тупых дятлов.

Ваще легко. А почему ты спросил.

Нет никакой связи между SQL и внутренними структурами данных в движке СУБД вообще.

Наличие SQL заставляет иметь внутренние структуры, достаточные для эффективной реализации этого SQL.

Нет никакой связи между целевыми сценариями использования и оптимизацией структуры хранения данных? Ну ОК...

Наличие SQL заставляет иметь внутренние структуры, достаточные для эффективной реализации этого SQL.

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

Если заказчик выбрал СУБД на SQL, значит либо ему нужны запросы на SQL, тогда отражают, либо он неадекватен и не знает, чего хочет, тогда никакие структуры его потребности отразить не могут.

Если заказчик выбрал СУБД на SQL, значит либо ему нужны запросы на SQL, тогда отражают, либо он неадекватен и не знает, чего хочет, тогда никакие структуры его потребности отразить не могут.

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

Из живых примеров могу вспомнить Газпром, у них инфраструктура была на IBM/Oracle (и насколько я знаю, до сих пор так и есть, т.е. импортозамещение их каким-то образом обходит стороной) и они в любой проект пытались всем правдами и неправдами запихнуть DB2 (не та, которая LUW, а что на мейнфреймах крутится), тем самым они пытались ввести искусственный ценз для подрядчиков.

Здесь примерно то же самое происходит: мы закупили анлим на PostgresPRO, наняли персонал, который ее будет сопровождать, теперь любой подрядчик будет должен либо изначально предлагать решение на PostgreSQL либо согласиться это решение адаптировать, совершенно вне зависимости от того подходит ли PostgreSQL для решаемых задач или нет.

Есть

SQL это просто язык запросов, к структурам данных он может легко не относиться ни к каким.

Ну т.е. у тебя под SQL под не-SQL базы всё таки будет разная структура? А может быть ещё и в разных SQL-базах под разные ниши она тоже будет разной?

SQL это просто язык запросов, к структурам данных он может легко не относиться ни к каким.

Если язык запросов SQL, то, как минимум, данные хранятся в типизированных таблицах. Вот есть у Яндекса кэш Интернета, но SQL к нему не прикрутить, к нему есть язык запросов. Или есть данные в LLM, туда тоже SQL не прикрутить.

в случае внедрения какой-то технологии заказчик будет пытаться жить на этой технологии до потери пульса что бы это не означало

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

совершенно вне зависимости от того подходит ли PostgreSQL для решаемых задач или нет.

Его уже выбрали. Значит заказчик уверен, что подходит.