Все привыкли компенсировать свои личные психологические расстройства,
создавая довольно замысловатые коммуникационные барьеры и рабочие ритуалы с обрядами посвящения.
Эти барьеры приводят к ситуации «обсуждать, а не анализировать; полагать, а не принимать обоснованное решение».
Руководство и разработчики чаще всего ригидны и не обладают возможностью видения перспективы,
даже банальный анализ существующих подходов и интрументариев является непосильной задачей.
Привет, Golden Hammer. Сайонара, долгосрочная поддержка.
Зачем разделять разработчиков на тестеров и программистов — высшую и низшую касту племенного сообщества.
У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты…
Вы все же там такие Agile-ные экстремалы с RAD'ом…
Желание компенсироваться — «быть самым главны и/или самым умным» и подсознательно разделять всех на тех кто нравится, и тех, кто не нравится, порождая грибной менеджмент и поверхностную выработку требований.
Привет, «Грибной менеджмент» и «Охота на ведьм».
И наконец у вас должен быть готовый продукт в конце каждой итерации,
с последующим эволюционным рефакторингом и добавлением нового функционала…
Если так не получается — вы делаете что-то не так.
На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
В таком случае V-model легко адаптировать под простой kanban.
V-model это разработка по спецификациям, и документация ставится выше живых людей. Пока не отработан V-model, и не адаптирован под тот же lean или kanban — смысла в Scrum двигать нет. Люди просто не сработаются и не поймут чего от них хотят, а что вообще реально можно предложить клиентам.
Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.
Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum'a.
Ну в общем-то как раз cейсчас пишу статью «freelance — you're doing it wrong», в рамках которой описываю основные организационные и управленческие проблемы с которыми мне приходилось сталкиваться.
Если кратко, то это
Дилетанство и предрассудки — заказчики/руководство не способны учится даже на своих собственных ошибках
Ригидность — не способны адаптироваться к новым условиям
Желание сэкономить, часто на организации труда — напрочь убивают поддержку
Личные психологические расстройства и компенсаторные процессы:
Я хочу быть самым умным и/или самым главным...
Я хочу подчинятся...
… а не разрабатывать качественные, надёжные и конкурентоспособные продукты.
Конечно они могут встретить друг друга, но одному нужно страдать, а другому нужно быстрое удовлетворение его желаний, желательно даром.
Я могу продолжать, это неполный список.
Опять же примитивное гнилое постсоветское общество с протёртыми книжными проблемами передача которых с поколения в поколение ещё и поддерживается родственниками и окружением. Та-да…
Ну путают мягкое и тёплое, ну и что теперь?
Такое у всех бывало, особенно в детстве.
Не все же умными сразу становились.
Это их проблема — пускай считают частный случай общим.
Прочитав Лава, и Linux Device Drivers (ещё в школе, в 2008) могу с уверенностью сказать что подобные материалы служат хорошим введением, но в них мало практической пользы — что бы хорошо понимать принципы работы, нужно самому копаться в ядре и что-то писать/отлаживать руками. К сожалению подобного рода источники довольно быстро устаревают и нужно разбираться с многим по ходу дела.
Нет смысла поддерживать продукт с монолитной архитектурой, без внятных тестов и какого-либо профилирования/оптимизации. В противном случае тут больше половины нужно будет переписать подчистую, ну в общем «как всегда».
Если вам нужны гарантии качества и долгосрочной поддержки — в первую очередь стоит заняться оценкой рисков, вменяемой организацией работ и тестированием, в том числе и нагрузочным.
У меня распределёнка и highload'ы начинаются с 10Гбит трафика, я просто сужу по своим потребностям и задачам которые приходится решать. Не могу сказать что разработку подобных решений можно назвать простой, но она и не особо отличается от разработки любых других RESTful SOA приложений, просто есть свои особенности в архитектуре, и в организации работы.
Если у меня будет 10ток машин в виртуалке, то перво-наперво я сделаю так что бы они между собой не разделяли общих состояний, а только логировали запросы. В итоге это CQRS-ES с логированием текущих транзакций посредством Raft алгоритма.
Нужно отличать вертикальное масштабирование от горизонтального.
Вертикальное — эффективная утилизация мощности каждой конкретной машины с минимальными издержками на коммуникацию, тут работают модели актёров и разнообразные очереди с приоритетами (типа Disruptor), sharedmem тут не обязателен так как почти все сервисы выполняются в рамках одного процесса, ну в общем по аналогии с tasklet'ами линуксовского ядра.
Горизонтальное — распределение нагрузки на несколько машин без существенного увеличения времени отклика, тут нужно понимать что всякие master-master репликации — непозволительная роскошь. У меня обычно всё сводится к Raft'у и нескольким ведомым машинам дублирующим текущие запросы посредством зеркалирования трафика. Шардинг и репликация в таких условиях решается уже на уровне приложения, и с БД совсем не нужно заморачиваться… но это тема отдельной статьи.
Обычно когда люди вспоминают о распределёнке — ни первый, ни второй тип масштабирования не реализовывается должным образом. То отклик медленный, то избыточность не там где надо… то бутылочные горлышки без профилирования, в общем больше половины проектов выглядят довольно костыльно, по этому я так и отреагировал.
Название статьи можно перефразировать как «Масштабируем Слоупочность lvl 100»
1. AMQP толст — если размер Payload'a будет меньше размера Header'а — получаем Amplification в рамках кластера / ноды, сервис ложится при первом же скачке нагрузки. Согласен с prefer ZMQ менее избыточен.
2. Масштабировать вертикально с помощью AMQP в рамках одной ноды — ересь! Сжечь, и не смотреть где прах закопают!
Реализуйте очереди обработки задач по типу Disruptor'a в рамках приложения, или используйте готовые сурогатные модели актёров по типу Greenlet'ов. Пилите SOA.
3. Хотите строить «распределённые» сервисы — проводите нагрузочное тестирование jMeter'ом и Яндекс.танком и профилируйте до потери пульса! Иначе получите бутылочные горлышки и Amplification'ы в самых не очевидных местах.
+1 Табло действительно удобная штука когда данных относительно не много (до 100Гб таблички), и модель хорошо нормализирована.
У себя чаще всего использую Pentaho Mondrian + Weka (для SVM кластеризации) => отчёты в JasperReports.
Обычно на всех OLAP решениях принято ставить надпись «для Big Data», но вот почему-то я не видел OLAP'ов обрабатывающих по терабайту логов в сутки… Тем более там часто нужны различные Spatial индексы на всяких там MVP-деревьях и прочих интересностях, которые обычно недоступны простым смертным.
Чаще всего рядовые козлят логами в популярных СУБД, и это просто напрочь выносит мозг…
Проблема в том что местные B-tree индексы, при любых размерах таблиц, отчасти хранятся в памяти, с расчёта что вероятность обращения ко всем данным подлежит нормальному распределению. Профилятор конечно может там заоптимизировать индексы всякими Adaptive Radix Tree и проч. но собственно ситуацию это никак не меняет: чем выше количество инфы в таблицах — тем больше памяти кушает база. Естественно OLTP-провайдеры могут обработать местное MVCC в СУБД (контроль транзакций) на обобщённом уровне, но FullTable или Partition Scan'ы для синхронизации и пережимки журнала рано или поздно прокатывают, что приводит к диким лагам )
Использовать двумерные R-tree или многомерные X-tree индексы и т.п., которые получше подходят для таких задач, обычно не позволяет отсутствие совести разработчиков СУБД отсутствие знаний и практики в организации подобных решений. Им ничего не нужно хранить в памяти, и с range запросами они справляются на ура, так как пересчитывают все возможные пересечения множеств уже при вставке.
В MySQL вроде отдельно есть ENGINE ARCHIVE для логов с R-tree по-умолчанию, правда туда лучше писать уже обработанные данные, а актуальные продолжать держать в InnoDB etc… естественно многомерных выборок там нет.
Обработка самого whatever-SQL'я довольно медленная обычно агрегацию можно ускорить в 10-30 раз написав расширения с низкоуровневыми SIMD оптимизациями на С, возможно даже и в 100 раз с GPGPU :3
Естественно в проприетарщине такого никогда не будет — никому не выгодны абсолютные приемущества на рынке, а в опенсорсе не так много желающих заниматься подобным извратом — для совести проще писать прикладные решения.
Ставка абстрактного разработчика в вакууме с вменяемым опытом работы в час может составить 20-30$, это ~2500-3500$ (по себе сужу). За меньшие суммы обычно работать не принято…
Проприетарщина будет дешевле пока решаете шаблонные (обобщённые) задачи.
Как только нужно будет дёргать кластерные анализы да кастомную классификацию — обычно начинается шаманизм и отсебятинка.
Лучше со старту определить требования, учитывая возможность нанять джедаев и объём информации который нужно обработать.
ИМХО BI это магическая плюшка которую придумали маркетологи что бы можно было написать и продать кучу никому ненужного ПО, которое должно магическим образом решить очень много важных проблем… в общем что бы руководству без мозгов было на что щёлкать, да квази-графики-отчёты глядеть, что бы «деятельность имитировать» и «казаться важными», хотя на самом деле эти метрики дикий шлак и не имеют ничего общего с реальными проблемами которы. Нужно понимать потребности психологической компенсации и использовать это как возможность продажи продуктов :3
</rage>
Офисные знатоки совсем забыли что есть Microsoft Access с мифическим SQL-конструктором который отлично дружит с MySQL / PostgreSQL посредством ODBC, и ним много чего можно решить на уровне общих прикладных задач (2-3 статистических MOLAP отчёта без сложной аналитики). Офисный планктон до пол-сотни персонала такое вполне переваривает…
Для вещей посложнее есть вполне приемлемые открытые решения по типу JasperReports или Pentaho Mondrian / Weka.
Хотя большинство всей этой OLAP мути можно реализовать материализованными представлениями в БД и своими кастомными агрегирующими функциями с шахматами и поэтессами с map/reduce и GPGPU.
В проприетарщину стоит скатываться когда вам нужна вменяемая поддержка, но все задачи должны быть оч. шаблонны.
Как показывает практика кастомизация проприетарных решений без должного тестирования и организации труда тащит душу в ад чревата сложностями поддержки в долгосрочной перспективе, вплоть до хронической «одно поправили-другое отвалилось».
Вспоминаются ужасы XML-RPC over FTP в поделках умников некоторых умельцев 1С.
Прям Gophernator, я тожe испугался :3
Портировать Go в JVM или CLR нет смысла — это против парадигм самого языка.
Тем не менее GCC / LLVM порты имеют смысл, особенно вместе с peephole'ами (низкоуровневыми оптимизациями) в runtime'е.
p.s. радует недавний мердж llgo в llvm — бэнчмарки просто загляденье.
Тут под кроссплатформом подразумевались особенности целевой архитектуры процессора, а не ОС.
Для пользователей которые дальше glibc не плавают, эти все вещи выглядят довольно эфемерно.
Учитывая особенности организации различных операций, допустим различных SIMD/MIMD в x86 Cortex-m3 ARMv7 ARMv9, можно добиться очень больших приростов производительности используя конкретные решения целевой архитектуры. Поэтому разработчикам кроссплатформенных решений проще абстрагироваться под особенности каждого процессора индивидуально. Компиляторы С/C++ чаще всего либо игнорируют все эти возможности, либо компилируют под что-то одно, игнорируя возможные оптимальные решения для конкретной задачи, но работает естественно быстрее чем пустой сишный лапшекод.
Вообще знатоки разнообразных ASM'ов довольно негативно выражаются в сторону C/C++ компиляторов — слишком много лапши: там где можно 1 специфическую инструкцию — пилят десять общих, ведь так безопасней и слоупочней).
Последние версии GCC вообще много чего могут поломать при -O3.
P.S. у разных архитектур свои ASM'ы, с разными наборами команд, и возможностями.
создавая довольно замысловатые коммуникационные барьеры и рабочие ритуалы с обрядами посвящения.
Эти барьеры приводят к ситуации «обсуждать, а не анализировать; полагать, а не принимать обоснованное решение».
даже банальный анализ существующих подходов и интрументариев является непосильной задачей.
Привет, Golden Hammer. Сайонара, долгосрочная поддержка.
У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты…
Вы все же там такие Agile-ные экстремалы с RAD'ом…
Привет, «Грибной менеджмент» и «Охота на ведьм».
с последующим эволюционным рефакторингом и добавлением нового функционала…
Если так не получается — вы делаете что-то не так.
На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
В таком случае V-model легко адаптировать под простой kanban.
V-model это разработка по спецификациям, и документация ставится выше живых людей. Пока не отработан V-model, и не адаптирован под тот же lean или kanban — смысла в Scrum двигать нет. Люди просто не сработаются и не поймут чего от них хотят, а что вообще реально можно предложить клиентам.
Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.
Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum'a.
Если кратко, то это
… а не разрабатывать качественные, надёжные и конкурентоспособные продукты.
Конечно они могут встретить друг друга, но одному нужно страдать, а другому нужно быстрое удовлетворение его желаний, желательно даром.
Я могу продолжать, это неполный список.
Опять же примитивное гнилое постсоветское общество с протёртыми книжными проблемами передача которых с поколения в поколение ещё и поддерживается родственниками и окружением. Та-да…
Такое у всех бывало, особенно в детстве.
Не все же умными сразу становились.
Это их проблема — пускай считают частный случай общим.
Информационная ценность этой статьи стремится к нулю.
Прочитав Лава, и Linux Device Drivers (ещё в школе, в 2008) могу с уверенностью сказать что подобные материалы служат хорошим введением, но в них мало практической пользы — что бы хорошо понимать принципы работы, нужно самому копаться в ядре и что-то писать/отлаживать руками. К сожалению подобного рода источники довольно быстро устаревают и нужно разбираться с многим по ходу дела.
Если вам нужны гарантии качества и долгосрочной поддержки — в первую очередь стоит заняться оценкой рисков, вменяемой организацией работ и тестированием, в том числе и нагрузочным.
Я бы не стал использовать подобное решение в своих проектах.
Отдавать 40Гбит DWDM'у не проблема…
Я не раздаю контент, в основном Restful API и различные конкурирующие транзакции с большой стоимостью отката и синхронизации.
Если у меня будет 10ток машин в виртуалке, то перво-наперво я сделаю так что бы они между собой не разделяли общих состояний, а только логировали запросы. В итоге это CQRS-ES с логированием текущих транзакций посредством Raft алгоритма.
Нужно отличать вертикальное масштабирование от горизонтального.
Вертикальное — эффективная утилизация мощности каждой конкретной машины с минимальными издержками на коммуникацию, тут работают модели актёров и разнообразные очереди с приоритетами (типа Disruptor), sharedmem тут не обязателен так как почти все сервисы выполняются в рамках одного процесса, ну в общем по аналогии с tasklet'ами линуксовского ядра.
Горизонтальное — распределение нагрузки на несколько машин без существенного увеличения времени отклика, тут нужно понимать что всякие master-master репликации — непозволительная роскошь. У меня обычно всё сводится к Raft'у и нескольким ведомым машинам дублирующим текущие запросы посредством зеркалирования трафика. Шардинг и репликация в таких условиях решается уже на уровне приложения, и с БД совсем не нужно заморачиваться… но это тема отдельной статьи.
Обычно когда люди вспоминают о распределёнке — ни первый, ни второй тип масштабирования не реализовывается должным образом. То отклик медленный, то избыточность не там где надо… то бутылочные горлышки без профилирования, в общем больше половины проектов выглядят довольно костыльно, по этому я так и отреагировал.
1. AMQP толст — если размер Payload'a будет меньше размера Header'а — получаем Amplification в рамках кластера / ноды, сервис ложится при первом же скачке нагрузки. Согласен с prefer ZMQ менее избыточен.
2. Масштабировать вертикально с помощью AMQP в рамках одной ноды — ересь! Сжечь, и не смотреть где прах закопают!
Реализуйте очереди обработки задач по типу Disruptor'a в рамках приложения, или используйте готовые сурогатные модели актёров по типу Greenlet'ов. Пилите SOA.
3. Хотите строить «распределённые» сервисы — проводите нагрузочное тестирование jMeter'ом и Яндекс.танком и профилируйте до потери пульса! Иначе получите бутылочные горлышки и Amplification'ы в самых не очевидных местах.
А я вот думал с чего начать копаться в llgo.
У себя чаще всего использую Pentaho Mondrian + Weka (для SVM кластеризации) => отчёты в JasperReports.
Чаще всего рядовые козлят логами в популярных СУБД, и это просто напрочь выносит мозг…
Проблема в том что местные B-tree индексы, при любых размерах таблиц, отчасти хранятся в памяти, с расчёта что вероятность обращения ко всем данным подлежит нормальному распределению. Профилятор конечно может там заоптимизировать индексы всякими Adaptive Radix Tree и проч. но собственно ситуацию это никак не меняет: чем выше количество инфы в таблицах — тем больше памяти кушает база. Естественно OLTP-провайдеры могут обработать местное MVCC в СУБД (контроль транзакций) на обобщённом уровне, но FullTable или Partition Scan'ы для синхронизации и пережимки журнала рано или поздно прокатывают, что приводит к диким лагам )
Использовать двумерные R-tree или многомерные X-tree индексы и т.п., которые получше подходят для таких задач, обычно не позволяет
отсутствие совести разработчиков СУБДотсутствие знаний и практики в организации подобных решений. Им ничего не нужно хранить в памяти, и с range запросами они справляются на ура, так как пересчитывают все возможные пересечения множеств уже при вставке.В MySQL вроде отдельно есть ENGINE ARCHIVE для логов с R-tree по-умолчанию, правда туда лучше писать уже обработанные данные, а актуальные продолжать держать в InnoDB etc… естественно многомерных выборок там нет.
Обработка самого whatever-SQL'я довольно медленная обычно агрегацию можно ускорить в 10-30 раз написав расширения с низкоуровневыми SIMD оптимизациями на С, возможно даже и в 100 раз с GPGPU :3
Естественно в проприетарщине такого никогда не будет — никому не выгодны абсолютные приемущества на рынке, а в опенсорсе не так много желающих заниматься подобным извратом — для совести проще писать прикладные решения.
Ставка абстрактного разработчика в вакууме с вменяемым опытом работы в час может составить 20-30$, это ~2500-3500$ (по себе сужу). За меньшие суммы обычно работать не принято…
Проприетарщина будет дешевле пока решаете шаблонные (обобщённые) задачи.
Как только нужно будет дёргать кластерные анализы да кастомную классификацию — обычно начинается шаманизм и отсебятинка.
Лучше со старту определить требования, учитывая возможность нанять джедаев и объём информации который нужно обработать.
ИМХО BI это магическая плюшка которую придумали маркетологи что бы можно было написать и продать кучу никому ненужного ПО, которое должно магическим образом решить очень много важных проблем… в общем что бы руководству без мозгов было на что щёлкать, да квази-графики-отчёты глядеть, что бы «деятельность имитировать» и «казаться важными», хотя на самом деле эти метрики дикий шлак и не имеют ничего общего с реальными проблемами которы. Нужно понимать потребности психологической компенсации и использовать это как возможность продажи продуктов :3
Офисные знатоки совсем забыли что есть Microsoft Access с мифическим SQL-конструктором который отлично дружит с MySQL / PostgreSQL посредством ODBC, и ним много чего можно решить на уровне общих прикладных задач (2-3 статистических MOLAP отчёта без сложной аналитики). Офисный планктон до пол-сотни персонала такое вполне переваривает…
Для вещей посложнее есть вполне приемлемые открытые решения по типу JasperReports или Pentaho Mondrian / Weka.
Хотя большинство всей этой OLAP мути можно реализовать материализованными представлениями в БД и своими кастомными агрегирующими функциями
с шахматами и поэтессамис map/reduce и GPGPU.В проприетарщину стоит скатываться когда вам нужна вменяемая поддержка, но все задачи должны быть оч. шаблонны.
Как показывает практика кастомизация проприетарных решений без должного тестирования и организации труда
тащит душу в адчревата сложностями поддержки в долгосрочной перспективе, вплоть до хронической «одно поправили-другое отвалилось».Вспоминаются ужасы XML-RPC over FTP в поделках
умниковнекоторых умельцев 1С.Портировать Go в JVM или CLR нет смысла — это против парадигм самого языка.
Тем не менее GCC / LLVM порты имеют смысл, особенно вместе с peephole'ами (низкоуровневыми оптимизациями) в runtime'е.
p.s. радует недавний мердж llgo в llvm — бэнчмарки просто загляденье.
Для пользователей которые дальше glibc не плавают, эти все вещи выглядят довольно эфемерно.
Учитывая особенности организации различных операций, допустим различных SIMD/MIMD в x86 Cortex-m3 ARMv7 ARMv9, можно добиться очень больших приростов производительности используя конкретные решения целевой архитектуры. Поэтому разработчикам кроссплатформенных решений проще абстрагироваться под особенности каждого процессора индивидуально. Компиляторы С/C++ чаще всего либо игнорируют все эти возможности, либо компилируют под что-то одно, игнорируя возможные оптимальные решения для конкретной задачи, но работает естественно быстрее чем пустой сишный
лапшекод.Вообще знатоки разнообразных ASM'ов довольно негативно выражаются в сторону C/C++ компиляторов — слишком много лапши: там где можно 1 специфическую инструкцию — пилят десять общих, ведь так безопасней и слоупочней).
Последние версии GCC вообще много чего могут поломать при -O3.
P.S. у разных архитектур свои ASM'ы, с разными наборами команд, и возможностями.