да вы правы! спасибо за это уточнение! внесу корректировки в свои материалы
Позвольте здесь привести выдержку из документации относительно параметра synchronize_seqscans, отвечающий за синхронизацию обращений при последовательном сканировании больших таблиц.
В документации сказано "Когда он включён, сканирование может начаться в середине таблицы, чтобы синхронизироваться со сканированием, которое уже выполняется. По достижении конца таблицы сканирование заворачивается к началу и завершает обработку пропущенных строк. Это может привести к непредсказуемому изменению порядка строк, возвращаемых запросами, в которых отсутствует предложение ORDER BY. Когда этот параметр выключен (имеет значение off), реализуется поведение, принятое до версии 8.3, когда последовательное сканирование всегда начиналось с начала таблицы. Значение по умолчанию — on".
Здесь я имею ввиду , что если таблица четко статическая (справочник) и не происходит обновление данных в ней или происходит очень нечастое контролируемое обновление (применяя CLUSTER...), то почему бы не воспользоваться физическим размещением данных в страницах в том порядке в котором нам необходимо выдать результат.
Полностью с вами согласен, если таблица обновляема часто, то без ORDER BY не обойтись.
да именно так, действительно этому подходу не первый десяток лет в PostgreSQL и лично для меня интересно продолжение этой истории. Не люблю сравнивать, но встретившись с функционалом в другой РСУБД с конструкторами / деструкторами / свойствами / членами класса и тд на промышленном проекте - действительно был впечатлен как это можно использовать.
я опираюсь на команду CLUSTER TABLE ... и называю получаемую структуру - кластеризованной таблицей. С вами полностью согласен, что надо быть поосторожнее с терминами.
Вы все верно подметили, позвольте раскрыть тему. ACID состоит из 4 букв
Atomicity — Атомарность
Consistency — Согласованность (консистентность)
Isolation — Изолированность
Durability — Надежность
Функционал для безопасного восстановления после краха сервера - на себя берет буква D. Другими словами, если к примеру произошло обесточивание системы или сбой в оборудовании, то изменения, сделанные на данных успешно завершённой транзакцией, должны остаться после возвращения системы в работу.
В своей статье я отметил, что ACID принцип также гарантирует надежность транзакции, нисколько не преуменьшая роль функции восстановление системы после краха. :-).
Clustered Table - есть в PostgreSQL, но конечно это не тот Index Organised Table от Oracle (пока это так к сожалению).
Во всех таблицах (кроме Foreign) - та же самая парадигма пейджей страниц, можно сказать что Heap Table - это "ancestor" для всего остального (в том числе и например BTree индексов - тоже хочу об этом рассказать ;-).
Спасибо за обратную связь, я учту на будущее пожелание к тому, чтобы добавлять в статьи подводящие предложения.
Если вам вдруг интересна тема сравнений, то хочу пригласить Вас на мой следующий митап. На нём я как раз хочу рассказать про другие типы таблиц (включая какие свойства есть у них и что общего с Heap Tables):
Clustered Table (и как противовес Index Organized Table от Oracle)
В трансляции митапа я старался говорить англоязычные термины (чтобы донести оригинал) без применения жаргонизмов. Первичный автоматический перевод выступления в печатный вид немного добавил огонька :-).
Я использую инструментарий из "коробки", для PostgreSQL - это pg_bench с возможностью написания своих собственных пользовательских скриптов и работой с разными конфигурациями по нагрузочному тестированию (например количество параллельно работающих пользователей, объем транзакций, который необходимо достигнуть каждой сессией, объем времени в течении которого проводится benchmark и много всего остального). Инструмент представляет собой командную строку, но в моей работе это даже лучше, так как проще делать интеграцию в рамках CI/CD pipelines в части LoadBalancing тестов.
Посмотрите пожалуйста вот сюда - тут очень детально расписаны ключи для этого инструмента.
Но хотелось бы отменить, что таких инструментов для тестирования много и Вы даже можете попробовать написать самостоятельно свой, если у Вас есть дополнительные требования к тестам.
Вообще, если подходить к категориям данных, то как раз есть разница в том, как работать с:
1) Big Data
2) ClickStream Data
3) Relational (Structured) Data
4) Unstructured / Semi-structured Data
5) Streaming Data (например, Internet of Things)
6) etc.
Знание SQL, понимание модели и структуры данных, по моему мнению, очень важно.
Data-инженер должен знать SQL (опять же, по моему мнению), так как в большинстве случаев именно с этим языком или его модификацией (не ANSI SQL я имею в виду) приходится сталкиваться в разных хранилищах и в создании ETL-процессов.
Добрый день! Спасибо вам за комментарий и интересный вопрос. По моему мнению, в IT-индустрии сейчас наблюдается тенденция разделения DS и DE ролей. Более того, среди DS-специалистов можно выделить ML Engineer, Computer Vision Engineer, ML DataOps... DS-специалисты стараются работать с данными, которые «уже доставлены до их инструмента», применяя алгоритмы ML / Data Mining / etc. Но хочу отметить, что вопрос очистки / нормализации данных лежит на плечах DS, т. к. процесс исследования данных и поиска наилучшей математической модели может быть итеративным и уточняющим.
Это не говорит о том, что DS-специалисты не знают, как написать SQL или (H|C|*)QL запрос к данным или настроить Data Pipeline. Например, у нас DS-команда имеет в своем хозяйстве такие хранилища, как Cassandra / ClickHouse / PostgreSQL и моменты, связанные с данными, они делают своими силами.
да вы правы! спасибо за это уточнение! внесу корректировки в свои материалы
Позвольте здесь привести выдержку из документации относительно параметра synchronize_seqscans, отвечающий за синхронизацию обращений при последовательном сканировании больших таблиц.
В документации сказано "Когда он включён, сканирование может начаться в середине таблицы, чтобы синхронизироваться со сканированием, которое уже выполняется. По достижении конца таблицы сканирование заворачивается к началу и завершает обработку пропущенных строк. Это может привести к непредсказуемому изменению порядка строк, возвращаемых запросами, в которых отсутствует предложение ORDER BY. Когда этот параметр выключен (имеет значение
off), реализуется поведение, принятое до версии 8.3, когда последовательное сканирование всегда начиналось с начала таблицы. Значение по умолчанию —on".Добрый день, Егор!
Спасибо за ваш комментарий!
Здесь я имею ввиду , что если таблица четко статическая (справочник) и не происходит обновление данных в ней или происходит очень нечастое контролируемое обновление (применяя CLUSTER...), то почему бы не воспользоваться физическим размещением данных в страницах в том порядке в котором нам необходимо выдать результат.
Полностью с вами согласен, если таблица обновляема часто, то без ORDER BY не обойтись.
добрый день!
да именно так, действительно этому подходу не первый десяток лет в PostgreSQL и лично для меня интересно продолжение этой истории. Не люблю сравнивать, но встретившись с функционалом в другой РСУБД с конструкторами / деструкторами / свойствами / членами класса и тд на промышленном проекте - действительно был впечатлен как это можно использовать.
Спасибо!
Добрый день!
спасибо за ваш комментарий и уточнение!
я опираюсь на команду CLUSTER TABLE ... и называю получаемую структуру - кластеризованной таблицей. С вами полностью согласен, что надо быть поосторожнее с терминами.
спасибо за ваш комментарий! мне здесь нечего добавить и я с вами полностью согласен.
Добрый день, спасибо за ваш вопрос и уточнение.
Вы все верно подметили, позвольте раскрыть тему. ACID состоит из 4 букв
Atomicity — Атомарность
Consistency — Согласованность (консистентность)
Isolation — Изолированность
Durability — Надежность
Функционал для безопасного восстановления после краха сервера - на себя берет буква D. Другими словами, если к примеру произошло обесточивание системы или сбой в оборудовании, то изменения, сделанные на данных успешно завершённой транзакцией, должны остаться после возвращения системы в работу.
В своей статье я отметил, что ACID принцип также гарантирует надежность транзакции, нисколько не преуменьшая роль функции восстановление системы после краха. :-).
Добрый вечер!
Спасибо за Ваш отзыв! Я планирую выступить в середине июля месяца и статья появится после выступления.
добрый день!
Спасибо за ваши уточнения, я учту на будущее эти моменты и постараюсь быть более внимательным к терминам, про которые я рассказываю.
Добрый вечер!
Спасибо за уточнения и спойлеры! :-)
Clustered Table - есть в PostgreSQL, но конечно это не тот Index Organised Table от Oracle (пока это так к сожалению).
Во всех таблицах (кроме Foreign) - та же самая парадигма
пейджейстраниц, можно сказать что Heap Table - это "ancestor" для всего остального (в том числе и например BTree индексов - тоже хочу об этом рассказать ;-).Спасибо за обратную связь, я учту на будущее пожелание к тому, чтобы добавлять в статьи подводящие предложения.
Если вам вдруг интересна тема сравнений, то хочу пригласить Вас на мой следующий митап. На нём я как раз хочу рассказать про другие типы таблиц (включая какие свойства есть у них и что общего с Heap Tables):
Clustered Table (и как противовес Index Organized Table от Oracle)
Partitioned Table
Inherited Table
Logged / Unlogged Tables
Temporary Tables
Foreign Tables
Добрый день!
Спасибо Вам за комментарий!
Поверьте , студенты оперируют куда большим разнообразием жаргонизмов в рамках IT :-).
Но сам я не сторонник упрощений и могу сказать, что в проведенном митапе я старался говорить оригинальные англоязычные термины.
Добрый день!
Спасибо за Ваш комментарий!
В трансляции митапа я старался говорить англоязычные термины (чтобы донести оригинал) без применения жаргонизмов. Первичный автоматический перевод выступления в печатный вид немного добавил огонька :-).
Добрый день!
Спасибо за Ваш комментарий!
Вы правы, дело в том что текст был выстроен после обработки видео выступления на митапе и я называл все термины англоязычными словами.
Но жаргонизмы сейчас очень сильно укоренились в ИТ жизни, и например тот же "кортеж" - это "строка" :-).
Спасибо Вам и за упоминание книги Егора Рогова, полностью поддерживаю!
Добрый день! спасибо за Ваш вопрос!
Я использую инструментарий из "коробки", для PostgreSQL - это pg_bench с возможностью написания своих собственных пользовательских скриптов и работой с разными конфигурациями по нагрузочному тестированию (например количество параллельно работающих пользователей, объем транзакций, который необходимо достигнуть каждой сессией, объем времени в течении которого проводится benchmark и много всего остального). Инструмент представляет собой командную строку, но в моей работе это даже лучше, так как проще делать интеграцию в рамках CI/CD pipelines в части LoadBalancing тестов.
Посмотрите пожалуйста вот сюда - тут очень детально расписаны ключи для этого инструмента.
Но хотелось бы отменить, что таких инструментов для тестирования много и Вы даже можете попробовать написать самостоятельно свой, если у Вас есть дополнительные требования к тестам.
Спасибо и удачи Вам!
Добрый день, спасибо за вопрос)
Вообще, если подходить к категориям данных, то как раз есть разница в том, как работать с:
1) Big Data
2) ClickStream Data
3) Relational (Structured) Data
4) Unstructured / Semi-structured Data
5) Streaming Data (например, Internet of Things)
6) etc.
Знание SQL, понимание модели и структуры данных, по моему мнению, очень важно.
Data-инженер должен знать SQL (опять же, по моему мнению), так как в большинстве случаев именно с этим языком или его модификацией (не ANSI SQL я имею в виду) приходится сталкиваться в разных хранилищах и в создании ETL-процессов.
Добрый день! Спасибо вам за комментарий и интересный вопрос. По моему мнению, в IT-индустрии сейчас наблюдается тенденция разделения DS и DE ролей. Более того, среди DS-специалистов можно выделить ML Engineer, Computer Vision Engineer, ML DataOps... DS-специалисты стараются работать с данными, которые «уже доставлены до их инструмента», применяя алгоритмы ML / Data Mining / etc. Но хочу отметить, что вопрос очистки / нормализации данных лежит на плечах DS, т. к. процесс исследования данных и поиска наилучшей математической модели может быть итеративным и уточняющим.
Это не говорит о том, что DS-специалисты не знают, как написать SQL или (H|C|*)QL запрос к данным или настроить Data Pipeline. Например, у нас DS-команда имеет в своем хозяйстве такие хранилища, как Cassandra / ClickHouse / PostgreSQL и моменты, связанные с данными, они делают своими силами.
Добрый день! Спасибо, рад, что статья была вам полезна :) Успехов!
Добрый день! Спасибо за внимание к статье :)
Подскажите, что именно в пирамиде данных вы считаете ерундой? Давайте обсудим? :)
Позвольте заметить, что, например, книга “Turning TEXT into GOLD. Taxonomies and Textual Analytics” написана Bill Inmon, он является отцом основателем классического Data WareHouse, и я не могу сказать, что он пишет «ерунду». Вот, пожалуйста, ссылки:
https://www.amazon.com/DAMA-DMBOK-Data-Management-Body-Knowledge/dp/1634622340/
https://www.amazon.com/Turning-Text-into-Gold-Taxonomies-ebook/dp/B01N7OK2SZ/