Если есть возможность то поднимайте slave read only для аналитики — снижаете риск «положить» прод. Когда это не помогает экспортируйте данные, желательно совместно с обработкой и денормализацией, например в clickhouse или в Vertica (до 1 ТБ — бесплатно).
Если у Вас обработка данных разовая то порой проще выгрузить весь набор данных за период не фильтруя в БД, seq-scan дешевле (особенно на ssd).
Join это боль, лучше делать его на самом последнем этапе, и не в БД.
Если таблица в PostgreSQL разбита на партиции то лучше выгружать и обрабатывать данные по каждой партиции отдельно. Большая боль будет если одновременно нужно сделать join по нескольким партишированным таблицам.
Основной подход — выгрузить данные и обрабатывать их за пределами реляционной БД.
Доброго всем дня.
Статью можно рассматривать как первый шаг к дальнейшему погружению в R и/или статистическую обработку данных, особенно если у Вас уже есть PostgreSQL (или иная БД с ODBC).
Существует одна ошибка начинающих аналитиков — работая с R мы продолжаем мыслить в рамках терминов баз данных, писать SQL… и, по факту, тратить свое время не на исследование данных.
В R есть великолепный инструмент dplyr, который позволяет абстрагироваться от синтаксиса SQL и перейти непосредственно к обработке данных. Но dplyr не ограничивает Вас и позволяет исполнять «рукописные» запросы.
Когда нужны «рукописные» запросы? Здесь варианты, например — сложные join, ручная оптимизация, вызов табличных функций. Да, в этих случаев иногда стоимостный оптимизатор PostgreSQL справляется не блестяще, но не забываем у нас не OLAP БД.
Насколько я помню такого счастья нет. Но у него достаточно быстро работает математический аппарат, можно построить и запросом, но если нужна глубокая специфика именно по timeseries то используте инструмент для этого предназначенный.
Clickhouse больше для аналитики по гигабайтам данных, особенно для изучения этих данных с целью построения итоговых моделей. После того как модель обработки данных определена аналитиком — лучше подумать о узкоспециализированном инструменте под эту модель.
Для этого и есть тестовая эксплуатация. (Не путать с тестированием.)
По поводу инфлюкса именно на этапе тестовой эксплуатации мне пришлось от него отказаться в пользу clickhouse. Т.к. InfluxDB наполненный реальными метриками с продакшена через месяц начал постепенно деградировать по скорости. Самое печальное — он не выдержал проверку на необходимое время с момента рестарта сервера до момента когда InfluxDB начинает обрабатывать запросы — требовались минуты, при размере БД в 50gb.
Когда появится возможность выбирать не только регион но и до узла? С Ираном была проблема пришлось писать в саппорт на отключение Тегерана из проверки, т.к. СМС шли с ложными срабатываниями.
За эти деньги можно у digitalocean взять впс на KVM
Только с одним «но» — с ограничением по трафику, что не для всех приемлимо.
Делал для пауков поисковиков и зарубежных посетителей специальный vps «за бугром» для статики, это кардинально снимает нагрузку по трафику для основного сервера.
Удачный выбор главы, у авторов хорошо получилось создать документ по выводу новичков из однопоточной жизни в наш удивительный и сложный мир.
Спасибо за труд.
Как правило, он не управляет людьми, а вместо этого учит их наилучшим образом выполнять свою работу
В статье большой упор на технологии, но все же Технический директор работает в первую очередь с людьми и уровень вербальной коммуникабельности очень важен (по крайней мере для России).
Кроме кода Технический директор оценивает и людей, влияет на улучшение не только профессиональных навыков но и личностных качеств — ответственность, коммуникабельность, умение выражать мысли,… список огромен. Но это не значит обломать всех под единый стандарт Если есть замкнутый человек создающий прекрасный код по предоставленному ТЗ или устному заданию и ему комфортно в замкнутости то попытка его вовлечь в командный дух чревата потерей качественного разработчика.
Не соглашусь, project manager находится на вершине конечного продукта, а продукт может состоять из нескольких компонентов, у каждого компонента свой team leader.
Сам был в такой ситуации когда являюсь team leader со стороны программистов и в соседнем кабинете team leader от электронщиков, а в сумме реализовали один программно-аппаратный проект и менеджер у нас был один. А потом добавился team leader по внедрению и сопровождению. Который нам через менеджера передавал желаемые нововведения.
Чем крупнее проект и чем больше разработчиков тем тяжелее одному становится контролировать всё, поэтому схема может удлиняться до:
Технический директор -> Руководитель группы (он же - ведущий программист) -> Разработчик
В таком подходе Технический директор формирует команды для выполнения определённого модуля и передает часть своих полномочий Руководителю группы. По достижению результата группа или распускается или ей выдается новый модуль. Часто при выдаче нового модуля без роспуска группы производится изменение Руководителя группы на другого её члена, в основном по принципу знания основной технологии но и самое главное от готовности Руководителя группы брать на себя ответственность.
Адская временная схема для хранения данных, только raid5 утром надежнее чем raid0 предыдущим вечером.
Вероятность того что md3 рассыпется из-за выхода одного из двух винчестеров 100%, вероятность того что после этого деградирует md4 — 100%, вероятность не успешного восстановления деградировавшего md4 — 50%.
Руководство поставили в известность и приложили счёт на два винчестера по 3TB, md3 должен исчезнуть а md4 стать raid6.
Собираюсь проверить схему по дополнительному ускорению восстановления данных, между восстанавливаемым диском и массивом ставится ssd диск для кеширования в режиме Write-Back, для дисков с которых восстанавливаются данные кеш в ОЗУ в режиме Read-Only с запретом индексирования последовательного чтения. По теории все упирается в скорость записи на восстанавливаемый диск, при том что с источников ведется последовательное чтение, но это чтение нарушается запросами на доступ к данным от клиентов, поэтому их запросы и закешируем. Возможно рано написал я еще не проверил в какой последовательности считываются данные с дисков иссточников…
p.s. А в отпуск уже много лет только со связью и компьютером, в стародавние времена gprs модем выдавался.
Один из ограничивающих ресурсов — время, а его было с 18:00 до 9:00 утра.
По правилам организации брать только со «склада» магазина, но оплата только по безналичному расчёту, что резко ограничивает оперативность. Если бы у меня лежал дома на полке абсолютно пустой диск на 3TB+ я бы конечно одолжил его «на время» и данная статья не была бы написана потому как не имела бы смысла.
ZFS для личного развития тестировал в OpenSolaris (буквально как только он появился), есть у него и плюсы и минусы. Недавно ZFS собрал «нативно» в ядро Linux (без fuse), но в боевых условиях я его использовать не буду.
Во-первых, нет подходящих задач. Во-вторых, то количество оперативной памяти которые потребляет ZFS (и которое нужно ему отдавать — так правильно и заложено архитектурой) я с большим удовольствием выделю для кеширования программного raid — выигрыш будет очевиден и виден невооруженным взглядом. Третье и последнее, с mdadm уже не один год, накопленный опыт и отточенные до автоматизма процедуры мониторинга и восстановления массивов позволяют спать спокойно.
Samba можно ввести в домен, для «шар» можно прописывать права в конфигурационном файле, но это сложность — администраторы обслуживающие организацию ориентированы на Windows, как сделать так чтобы они могли раздавать права на отдельные папки внутри Samba пользуясь только средствами Windows (также как для родных папок общего доступа Windows) я еще незнаю… Задача не возникала, но если это возможно буду рад совету, может удастся сдвинуть файловые хранилища в сторону Linux, не ломая для администраторов домена привычных операций в работе.
Прописывать каждый раз в конфигурационном файле новые правила доступа я конечно могу, но я не администратор домена а разработчик с опытом работы в *unix.
ну конечно надежность такой конструкции не ахти, но в случаи жесткой экономии сгодится
Вот здесь я с Вами не соглашусь.
1) Образ любой виртуальной машины можно в сжатые сроки перенести на любой другой Linux сервер и гостевая система даже не поймет что у неё изменился хост.
2) Нет ничего плохого в экономичности. Сокращенные ресурсы заставляют мозг работать и искать варианты, а не действовать по шаблону.
3) Программный рейд от mdadm для данного сервера наиболее подходит чем аппаратный, так как:
— не требуется сверх-высокая производительность;
— добавление каждого последующего винчестера на 3TB автоматически расширяет хранилище на тот же объем;
— массив можно безболезненно перенести на другой сервер.
В целом серверов несколько, DFS используется для сохранения (опять же исторических) названий ресурсов, в ближайшее будущее планирую одну из шар с простыми правами для всех пользователей из AD перевести в samba и спрятать за DFS. Но это из разряда экспериментов для накопления опыта.
Исторически так сложилось, но самое главное то что рейд собранный в Windows для Linux невиден. Сейчас стало попроще, Winwows 2003 находится в виртуальной машине, рейд отдельное блочное устройство — есть пространство для маневра. Вторая причина — права доступа к папкам внутри этого файлового хранилища выдаются администратором через контроллер домена не вставая с места.
Если у Вас обработка данных разовая то порой проще выгрузить весь набор данных за период не фильтруя в БД, seq-scan дешевле (особенно на ssd).
Join это боль, лучше делать его на самом последнем этапе, и не в БД.
Если таблица в PostgreSQL разбита на партиции то лучше выгружать и обрабатывать данные по каждой партиции отдельно. Большая боль будет если одновременно нужно сделать join по нескольким партишированным таблицам.
Основной подход — выгрузить данные и обрабатывать их за пределами реляционной БД.
Статью можно рассматривать как первый шаг к дальнейшему погружению в R и/или статистическую обработку данных, особенно если у Вас уже есть PostgreSQL (или иная БД с ODBC).
Существует одна ошибка начинающих аналитиков — работая с R мы продолжаем мыслить в рамках терминов баз данных, писать SQL… и, по факту, тратить свое время не на исследование данных.
В R есть великолепный инструмент dplyr, который позволяет абстрагироваться от синтаксиса SQL и перейти непосредственно к обработке данных. Но dplyr не ограничивает Вас и позволяет исполнять «рукописные» запросы.
Когда нужны «рукописные» запросы? Здесь варианты, например — сложные join, ручная оптимизация, вызов табличных функций. Да, в этих случаев иногда стоимостный оптимизатор PostgreSQL справляется не блестяще, но не забываем у нас не OLAP БД.
Рекомендую к прочтению Why SQL is not for Analysis, but dplyr is (eng).
Clickhouse больше для аналитики по гигабайтам данных, особенно для изучения этих данных с целью построения итоговых моделей. После того как модель обработки данных определена аналитиком — лучше подумать о узкоспециализированном инструменте под эту модель.
По поводу инфлюкса именно на этапе тестовой эксплуатации мне пришлось от него отказаться в пользу clickhouse. Т.к. InfluxDB наполненный реальными метриками с продакшена через месяц начал постепенно деградировать по скорости. Самое печальное — он не выдержал проверку на необходимое время с момента рестарта сервера до момента когда InfluxDB начинает обрабатывать запросы — требовались минуты, при размере БД в 50gb.
Важно веса зафиксировать до фактических испытаний систем, иначе начнется подстраивание весов под ожидаемые итоги.
Только с одним «но» — с ограничением по трафику, что не для всех приемлимо.
Делал для пауков поисковиков и зарубежных посетителей специальный vps «за бугром» для статики, это кардинально снимает нагрузку по трафику для основного сервера.
Спасибо за труд.
В статье большой упор на технологии, но все же Технический директор работает в первую очередь с людьми и уровень вербальной коммуникабельности очень важен (по крайней мере для России).
Кроме кода Технический директор оценивает и людей, влияет на улучшение не только профессиональных навыков но и личностных качеств — ответственность, коммуникабельность, умение выражать мысли,… список огромен. Но это не значит обломать всех под единый стандарт Если есть замкнутый человек создающий прекрасный код по предоставленному ТЗ или устному заданию и ему комфортно в замкнутости то попытка его вовлечь в командный дух чревата потерей качественного разработчика.
Сам был в такой ситуации когда являюсь team leader со стороны программистов и в соседнем кабинете team leader от электронщиков, а в сумме реализовали один программно-аппаратный проект и менеджер у нас был один. А потом добавился team leader по внедрению и сопровождению. Который нам через менеджера передавал желаемые нововведения.
Чем крупнее проект и чем больше разработчиков тем тяжелее одному становится контролировать всё, поэтому схема может удлиняться до:
Технический директор -> Руководитель группы (он же - ведущий программист) -> РазработчикВ таком подходе Технический директор формирует команды для выполнения определённого модуля и передает часть своих полномочий Руководителю группы. По достижению результата группа или распускается или ей выдается новый модуль. Часто при выдаче нового модуля без роспуска группы производится изменение Руководителя группы на другого её члена, в основном по принципу знания основной технологии но и самое главное от готовности Руководителя группы брать на себя ответственность.
Вероятность того что md3 рассыпется из-за выхода одного из двух винчестеров 100%, вероятность того что после этого деградирует md4 — 100%, вероятность не успешного восстановления деградировавшего md4 — 50%.
Руководство поставили в известность и приложили счёт на два винчестера по 3TB, md3 должен исчезнуть а md4 стать raid6.
Собираюсь проверить схему по дополнительному ускорению восстановления данных, между восстанавливаемым диском и массивом ставится ssd диск для кеширования в режиме Write-Back, для дисков с которых восстанавливаются данные кеш в ОЗУ в режиме Read-Only с запретом индексирования последовательного чтения. По теории все упирается в скорость записи на восстанавливаемый диск, при том что с источников ведется последовательное чтение, но это чтение нарушается запросами на доступ к данным от клиентов, поэтому их запросы и закешируем. Возможно рано написал я еще не проверил в какой последовательности считываются данные с дисков иссточников…
p.s. А в отпуск уже много лет только со связью и компьютером, в стародавние времена gprs модем выдавался.
По правилам организации брать только со «склада» магазина, но оплата только по безналичному расчёту, что резко ограничивает оперативность. Если бы у меня лежал дома на полке абсолютно пустой диск на 3TB+ я бы конечно одолжил его «на время» и данная статья не была бы написана потому как не имела бы смысла.
ZFS для личного развития тестировал в OpenSolaris (буквально как только он появился), есть у него и плюсы и минусы. Недавно ZFS собрал «нативно» в ядро Linux (без fuse), но в боевых условиях я его использовать не буду.
Во-первых, нет подходящих задач. Во-вторых, то количество оперативной памяти которые потребляет ZFS (и которое нужно ему отдавать — так правильно и заложено архитектурой) я с большим удовольствием выделю для кеширования программного raid — выигрыш будет очевиден и виден невооруженным взглядом. Третье и последнее, с mdadm уже не один год, накопленный опыт и отточенные до автоматизма процедуры мониторинга и восстановления массивов позволяют спать спокойно.
Прописывать каждый раз в конфигурационном файле новые правила доступа я конечно могу, но я не администратор домена а разработчик с опытом работы в *unix.
Вот здесь я с Вами не соглашусь.
1) Образ любой виртуальной машины можно в сжатые сроки перенести на любой другой Linux сервер и гостевая система даже не поймет что у неё изменился хост.
2) Нет ничего плохого в экономичности. Сокращенные ресурсы заставляют мозг работать и искать варианты, а не действовать по шаблону.
3) Программный рейд от mdadm для данного сервера наиболее подходит чем аппаратный, так как:
— не требуется сверх-высокая производительность;
— добавление каждого последующего винчестера на 3TB автоматически расширяет хранилище на тот же объем;
— массив можно безболезненно перенести на другой сервер.