А есть такая практическая потребность? Это не то чтобы прямо сложно, просто непонятен спрос. Для разработки приложений можно в докере на том же Windows поднять, а на сервере-то зачем?
Добрый день! В документацию мы постепенно добавляем релевантные секции - например, так было добавлено описание колоночных таблиц, оптимизатора, компонента Workload Manager. Технические статьи, включая результаты тестов, будут опубликованы несколько позднее.
Долгоиграющие незавершённые транзакции не дают автовакууму вычистить «старые» данные оказалось, что некоторым, рекордным транзакциям исполнилось уже 3 дня сессии с состоянием idle in transaction ... Среди этих транзакций тоже нашилсь висевшие часами.
Тема долгоиграющих транзакций не раскрыта. Очевидно, это вопросы к приложениям, а не к БД.
Процессоры работают вовсю, но вхолостую, а с точки зрения Postgres транзакции проводят время в праздности (idle), и автовакуумы штурмуют таблицы и индексы раз за разом.
Ну какой же тут idle? Это либо ожидание чтения блоков, либо ожидание свободных блоков буферного пула, либо ожидание сброса буфера лога.
И да, 180 Тбайт на PostgreSQL с аналитическими запросами... ну такое, на любителя.
Процессам все время приходится синхронизироваться между собой
Зависит от конкретного плана запроса. Если идёт фильтрация для отбора записей и/или расчёт агрегатов, такие виды сканирования прекрасно распараллеливаются. Синхронизация там только по факту завершения каждой подзадачи. Принципиально требуется только возможность назначить каждой задаче свой набор блоков для сканирования, не пересекающийся с соседями.
Сама по себе операция параллельного сканирования не имеет большого смысла, поскольку к обычным затратам на чтение страниц добавляются накладные расходы на пересылку данных от процесса к процессу.
Параллельное чтение разных участков одной таблицы само по себе может оказаться быстрее строго последовательного чтения, если подсистема ввода-вывода действительно способна выполнять запрошенные операции параллельно.
ГОСТы 34-й серии по сути задают стандартную структуру проектной информации и определённую базовую терминологию.
Их использование оказывается полезным при наличии на стороне заказчика и исполнителя специалистов, знакомых с такой структурой и такой терминологией - им оказывается проще понимать друг друга, проще искать нужную информацию (либо обнаруживать факт её отсутствия в документации проекта), проще выстраивать процесс работы над контентом.
Это как стандарт оформления кода и типовая организация модулей - позволяет не спорить о мелочах и не терять важное за частным.
Понятно, что есть альтернативы - более "легкие" шаблоны и наборы правил, придуманные в принципе с той же целью. Или вполне аналогичные (но отличающиеся реализацией) инженерные стандарты западного происхождения.
В итоге важно, чтобы стандарт был выбран и более-менее всеми соблюдался - а какой именно, вопрос сильно религиозный.
Чугунная жопа в программировании да, крайне полезна. Она же терпение.
Плюс точное знание, что чудес не бывает, и каждая хрень имеет своё внятное объяснение. Его просто надо найти - на что требуется много времени, ибо базовые библиотеки и фреймворки писали идиоты пополам с ибецилами (изредка среди них попадались разумные люди, а совсем редко - даже талантливые), и нормальную документацию никто из них не писал.
Oracle DB под "чистую" аналитику — пустая трата денег (imho, разумеется). Есть более годные продукты.
Hadoop и его друг Spark могут быть полезны, но пока скорее делают первые шаги, когда индустрия ушла гораздо дальше.
Коллега, я таки извиняюсь, но вы бредите.
Разговор про partitioning ещё худо-бедно в тему, но rac под аналитику — полнейшая бессмыслица.
Под серьезную аналитику нужна mpp-система, которую на Oracle DB сделать нельзя.
Из бесплатного тут скорее можно посмотреть на Yandex Clickhouse и Greenplum, при всех их недостатках. Коммерческие продукты есть более серьезные — Vertica, Teradata, SAP HANA, IBM Db2.
Вряд ли. Похоже на эффект от независимых действий двух участников:
чиподелов, которые пытаются поднять производительность процессоров в условиях невозможности увеличения частоты, отсюда гигантский кэш и спекулятивное выполнение инструкций;
разработчиков операционных систем, которые не слишком желают возиться с «излишествами» навроде микроядерной архитектуры.
Возможно, буду немножко резок, но уж больно своеобразен набор тезисов статьи.
Изготовитель плохого клона СУБД Oracle рассказывает об устаревании мейнфреймов и невозможности инноваций на платформе System z.
При этом демонстрирует полное отсутствие понимания вопроса, что прекрасно демонстрируют перлы в тексте:
"хранилища данных, ориентированные на работу с файлами" (это про VSAM? про IMS? или про DB2?);
"Данные, хранящиеся на мэйнфреймах, недоступны для новых современных приложений бизнес-аналитики" (DB2 и Classic Federation в помощь);
"трудно внедрить новые пользовательские интерфейсы или более гибкое форматирование отображаемой информации" (собственно, с чего бы? Что мешает использовать весь современный стек Web-технологий?)
"В ИТ-отделе скоро не останется специалистов" (конечно, лучше набрать толпу малограмотных студентов и пытаться заставить их сделать что-то полезное)
"отсутствие гибкости, рост расходов на обслуживание, дефицит специалистов по обслуживанию мэйнфреймов" (Трудно найти более гибкую, адаптивную и притом надёжную платформу. Проект по замене "устаревших" систем потребует понести уйму затрат на такую замену — вместо того, чтобы потратить средства и силы на инновации и получение конкурентных преимуществ)
А есть такая практическая потребность? Это не то чтобы прямо сложно, просто непонятен спрос. Для разработки приложений можно в докере на том же Windows поднять, а на сервере-то зачем?
ГАЗ-24 чем же не массовый отечественный автомобиль с гидротрансформаторной трансмиссией?
YDB существует в трёх вариантах:
open source проект, в рамках которого развивается ядро YDB;
управляемый сервис баз данных Managed YDB в Yandex Cloud;
коммерческое программное обеспечение для установки на собственных серверах пользователей.
Анонс YDB DWH относится к управляемому сервису и к коммерческому программному обеспечению.
Добрый день! В документацию мы постепенно добавляем релевантные секции - например, так было добавлено описание колоночных таблиц, оптимизатора, компонента Workload Manager. Технические статьи, включая результаты тестов, будут опубликованы несколько позднее.
На домене yandex.ru почту может зарегистрировать кто угодно, это примерно как считать сотрудником VK любого пользователя с адресом на mail.ru
Тема долгоиграющих транзакций не раскрыта.
Очевидно, это вопросы к приложениям, а не к БД.
Ну какой же тут idle?
Это либо ожидание чтения блоков, либо ожидание свободных блоков буферного
пула, либо ожидание сброса буфера лога.
И да, 180 Тбайт на PostgreSQL с аналитическими запросами... ну такое, на любителя.
Зависит от конкретного плана запроса.
Если идёт фильтрация для отбора записей и/или расчёт агрегатов, такие виды сканирования прекрасно распараллеливаются. Синхронизация там только по факту завершения каждой подзадачи.
Принципиально требуется только возможность назначить каждой задаче свой набор блоков для сканирования, не пересекающийся с соседями.
Параллельное чтение разных участков одной таблицы само по себе может оказаться быстрее строго последовательного чтения, если подсистема ввода-вывода действительно способна выполнять запрошенные операции параллельно.
ГОСТы 34-й серии по сути задают стандартную структуру проектной информации и определённую базовую терминологию.
Их использование оказывается полезным при наличии на стороне заказчика и исполнителя специалистов, знакомых с такой структурой и такой терминологией - им оказывается проще понимать друг друга, проще искать нужную информацию (либо обнаруживать факт её отсутствия в документации проекта), проще выстраивать процесс работы над контентом.
Это как стандарт оформления кода и типовая организация модулей - позволяет не спорить о мелочах и не терять важное за частным.
Понятно, что есть альтернативы - более "легкие" шаблоны и наборы правил, придуманные в принципе с той же целью. Или вполне аналогичные (но отличающиеся реализацией) инженерные стандарты западного происхождения.
В итоге важно, чтобы стандарт был выбран и более-менее всеми соблюдался - а какой именно, вопрос сильно религиозный.
Чугунная жопа в программировании да, крайне полезна. Она же терпение.
Плюс точное знание, что чудес не бывает, и каждая хрень имеет своё внятное объяснение. Его просто надо найти - на что требуется много времени, ибо базовые библиотеки и фреймворки писали идиоты пополам с ибецилами (изредка среди них попадались разумные люди, а совсем редко - даже талантливые), и нормальную документацию никто из них не писал.
Oracle DB под "чистую" аналитику — пустая трата денег (imho, разумеется). Есть более годные продукты.
Hadoop и его друг Spark могут быть полезны, но пока скорее делают первые шаги, когда индустрия ушла гораздо дальше.
Oracle в серьезном dwh — дань инерции разработчиков и администраторов.
Потому как очень ограничен в возможностях горизонтального масштабирования.
Коллега, я таки извиняюсь, но вы бредите.
Разговор про partitioning ещё худо-бедно в тему, но rac под аналитику — полнейшая бессмыслица.
Под серьезную аналитику нужна mpp-система, которую на Oracle DB сделать нельзя.
Из бесплатного тут скорее можно посмотреть на Yandex Clickhouse и Greenplum, при всех их недостатках. Коммерческие продукты есть более серьезные — Vertica, Teradata, SAP HANA, IBM Db2.
Возможно, буду немножко резок, но уж больно своеобразен набор тезисов статьи.
Изготовитель плохого клона СУБД Oracle рассказывает об устаревании мейнфреймов и невозможности инноваций на платформе System z.
При этом демонстрирует полное отсутствие понимания вопроса, что прекрасно демонстрируют перлы в тексте: