Первые спринты были откровенно неудачными — мы задержали релиз на неделю и начали отставать от графика.
Тут нет причин считать их «неудачные». Первые пару спринтов и предназначены для уточнения методов оценок.
Я специально не показываю сбор требований, время ожидания релиза и другие этапы, которые никак не отображают скорость работы команды
…
Я считал время пяти основных этапов
По идее заказчика интересует время через которую он получит свою «хотелку»
Что бы собрать требования, это же тоже работа какой-то команды и соответственно ее эффективность.
Почему вы их «выкинули»?
Время деплоя на тестовый сервер в сентябре занимало больше 15% — это было чрезвычайно странно. Выяснилось, что после проведения ревью задачи её выкладывал на тест последний исполнитель. Нужно было мержить ветки, иногда возникали конфликты, исполнитель отвлекался от текущих задач.
Это типовые проблемы и по идее должны были быть учтены сразу. Странно что это стало новостью «в процессе»
Очевидно, что Тарантул и прочие IMDB тоже не глупые люди писали, очевидно по каким-то мотивам и явно сравнивали свой результат с тем «что сделали до нас» что бы подтвердить свое решение.
Именно в этом «сравнение в сопоставимых режимах и одинаковых тестовых сценариях» и есть самое интересное. Много будет вам благодарных за такую статью.
Если Вы об этой статье, то там не +35% а поболее.
Смотря что смотрели:
Если сравнивать сценарий со временем задержки в 20 мс, то конфигурация с SSD-накопителями увеличила количество транзакций в 7,7 раз.
…
это дало преимущество в 10,1 раз по сравнению с HDD-накопителями, а в конфигурации с 24 базами и четырьмя экземплярами SQL Server получили прирост в 10,5 раз.
ну запихайте imdb в такой же конфиг. запустите на нем такой же сценарий: 32 таблицы по миллиону записей. 1000 клиентов натравите случайным образом выбирать, удалять, обновлять, добавлять в одной из 32 таблицы.
покажите цифры по imdb и DiskDB. тогда будет предметный разговор, когда построим такие-же графики.
А пока все по принципу:
— давай рельсу возьмем?
— а зачем?
— если устанем, рельсу бросим и побежим очень быстро.
IMDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
DiskDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
Только с кого-то фига, дисковые операции для IMDB «бесплатны», а для DiskDB — прямо дибилы писали, которые только-только с дерева слезли и хвосты у них еще не отпали.
Это подавался как один из криериев :) Весьма весомый
Но, не очень понятно как можно сравнивать продукты предназначенные для разных сценариев работы в специфических сценариях игнорируя другие критерии.
Если сравниваться, то по всем критериям и желательно с цифрами (вроде все технические люди).Например: По объему обрабатываемых данных, по отказоустойчивость, «цена» каждой операции в одинаковых сценариях, по масштабируемости и т.д. А когда не могут внятно объяснить минусы описываемого решения, преподнося его как «Серебряную пулю», это… как-то «не закончено» выглядит :)
У нас документ «по-крупному» должен содержать 4 раздела:
Это фактически у вас работа с рисками: идентификация и анализ/оценка рисков.
Это внутренний документ для управления проектом :) это не техническая документация :))
Ваш ревью спринта, если верно понял, будет привязан к этой «табличке»?
так и называется «Шаблон тех. проекта»
Обычно, это часть PreSale, это тоже не тех документация проекта, и обычно идет в свободной форме что бы " не морщить мозг". По идее этот документ сопровождается бюджетом проекта/решения?
Можно было бы привести еще пару методологий с фишками «ревью».
Возможно, я сильно ошибаюсь, но что-то у вас от карго культа получилось:)
Но если у вас оно работает и приносит пользу — не мне судить :)
А за метрики и детали — спасибо :)
да практически любая из гос кодексов с обвязкой в виде постановлений, инструкций. из межгосударственный вещей с кучей перекрестной документации, специфическая: банковская, налоговая, финансовая, картографическая, медицина.
. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Проектную «спецификацию и ТЗ» — это работа аналитиков, после контракт. там пофиг итерации и показы. Клиент просто скажет: А покажи мне Отчет Х из твоей системы? сошлось с моим? молодец!.. нет? иди фикси дальше, чего людей отвлекаешь?
Мы начали внедрять Scrum с 2011 года.
…
релизный цикл у нас состоит из 6 спринтов разработки
…
длительность итерации – 12 рабочих дней.
…
предметная область — ЕСМ и все что вокруг ЕСМ.
Долгая работа в одной предметной области и уже есть какие «шаблонные» решения :)
Все типовые риски и проблемы уже устранены в этих «шаблонных» решениях и давно :)
И это далеко не заслуга Scrum. После, не означает в следствии.
Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой.
Предположим, освоение нормативного документа и предметной области занимает 3 месяца времени.
Т.е вся команда что бы понять что важно а что нет для проектирования, все 10 человек будут сидеть и читать эту предметную область?
А если изучение предметной области занимает месяцев 3..9? тогда как вписывается в итерации?
Документируем необходимый минимум, в основном в виде мокапов.
Необходимый минимум для кого? Команды или Клиента?
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Наверное, вы знаете что такие «бумажки» пишут как раз не программисты, а архитекторы и аналитики.
Это Presale документация? или уровень функциональной спецификации?
Как этот процес работает с контрактами Time & Material и Fixed Price?
Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?
Если вы работаете в незнакомых и сложных предметных областях — возьмите в команду аналитика, подружитесь с ним – он не кусается.
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»? в какую итерацию они помещаются или делаются вне итераций?
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Сколько у вас примерно «стоит» проектирование, «Показывать заказчику работающие прототипы» и получать отзывы, разработка, тестирование и развертывание? в среднем для 1...5 спринтов по времени. 10% этап Х, 15% этап Y и т.д.
Как новый участник проекта получает необходимие знания по проекту? Куда деваются знания проекта ушедшего человека?
С самим ACID то нет вопросов. Вопрос с несколькими ACID, даже если они меняют не перекрывающиеся данные :) Нашел на сайте описание детальное, а потом потерял.
All database operations in a transaction should use the same storage engine. It is not safe to access tuple sets that are defined with {engine='vinyl'} and also access tuple sets that are defined with {engine='memtx'}, in the same transaction.
Then the only safe atomic functions for memtx databases would be functions which contain only one database request, or functions which contain a select request followed by a data-change request.
Можно ли заставить IMDB использовать только Vinyl или только Memtx в работе?
какую магию, вы о чем?
Когда вы приводите сравнение с «Обычной Базой Данных», то в этой «Обычной Базе Данных» слишком много проблем, по сравнению с IMDB. Основной акцент делается на «что приводит к рандомной записи на диск. Которой в IMDB нет.» и повторяется в разных вариантах.
Правда, будет все равно хуже чем in-memort:
1. Будет хуже по пропускной способности на запись, потому что рано или поздно надо записать данные в индексы рандомно.
Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)
Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
Так что спасибо :)
Так они же вроде как в связке работают и один дополняет другой, или еще и тут «магия»?
Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) говорите и сравнивайте только с аналогичными фичами «данных в памяти».
«выгружая наименее используемые блоки из кэша» — что приводит к рандомной записи на диск. Которой в IMDB нет.
Как происходит «магия» «рандомной записи на диск. Которой в IMDB нет.» если по документации происходит работа с пачкой файлов ?!
Вы контролируете в какой сектор диска и что писать? Так вменяемые DB тоже это контролируют (в какое место внутри файла писать и когда)!
Согласно докам, все что Вы описали как «IMDB нет.» присутствует:
Tarantool’s disk-based storage engine is a fusion of ideas from modern filesystems, log-structured merge trees and classical B-trees. All data is organized into ranges. Each range is represented by a file on disk. Range size is a configuration option and normally is around 64MB. Each range is a collection of pages, serving different purposes. Pages in a fully merged range contain non-overlapping ranges of keys.
3.6.2. Vinyl features
Separate storage formats: key-value (Default), or document (Keys are part of value)
Versional database creation and asynchronous shutdown/drop
A scheduler assigns tasks to multiple background threads for transferring index data from memory to disk, and for reorganizing Runs. To support transactions, Set operations can be delayed until an explicit commit.
3.6.3.3. Inserting the next 200.000 keys
Several times, the in-memory index becomes too large and a Run Creation Thread transfers the keys to a Run. The Runs have been appended to the end of db file. The number of created Runs becomes large.
…
There is a user-settable maximum number of Runs per Range. When the number of Runs reaches this maximum, the vinyl scheduler wakes a Compaction Thread for the db file. The Compaction Thread merges the keys in all the Runs, and creates one or more new db files.
Now there are multiple pairs of in-memory indexes, and each pair has an associated db file. The combination of the in-memory indexes and the db file is called a Range, and the db file is called a Range File.
Спасибо за ссылки. Интересно.
Повторюсь, что я не спец по IMDB и возможно не корретно понял ваш тест.
Но я не заметил у вас:
How sysbench OLTP operates
During each iteration, a worker thread chooses a random table from the pool of defined OLTP tables. For the point selects it randomly chooses a row number between 1 and the number of rows per table (--oltp-table-size). The range queries, the update, and the delete / insert operations also use random row IDs.
Отличие, грубо говоря, в 160 раз
не понял на чем основано, если тестовые сценарии то разные.
Давайте смотреть сопоставимые вещи, а не абстрактные «случайный доступ».
C учетом того, что у статьях упоминается своя версия fork и работы со страницами памяти, мы же оперируем большими наборами данных а не один… двумя байтами, соответсветнно и все «платежи», в виде промахов в кеш процессора, переупорядочиваяния станиц памяти при освобождении и будем пытаться включать. Так чуть корректнее будет.
Одинаковый тест, сопоставимые условия — сопоставимый итоговый результат. IOPS и передача данных.
По итогу и получатся, что при всех узкоспециализиованных преимуществах сумма всех факторов приводит к такому результату.
С этой точки зрения, сравнения количество полезной «работы» в итоге будет более корретно?
Очень интересуют:) Давно собираю метрики со всех доступных проектов :))) Можно в личку
Критерии приемки сразу с новымии «хотелками» продумываете или потом qa придумывает DoD на свой вкус?
Тут нет причин считать их «неудачные». Первые пару спринтов и предназначены для уточнения методов оценок.
По идее заказчика интересует время через которую он получит свою «хотелку»
Что бы собрать требования, это же тоже работа какой-то команды и соответственно ее эффективность.
Почему вы их «выкинули»?
Это типовые проблемы и по идее должны были быть учтены сразу. Странно что это стало новостью «в процессе»
Именно в этом «сравнение в сопоставимых режимах и одинаковых тестовых сценариях» и есть самое интересное. Много будет вам благодарных за такую статью.
Если Вы об этой статье, то там не +35% а поболее.
Смотря что смотрели:
покажите цифры по imdb и DiskDB. тогда будет предметный разговор, когда построим такие-же графики.
А пока все по принципу:
— давай рельсу возьмем?
— а зачем?
— если устанем, рельсу бросим и побежим очень быстро.
IMDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
DiskDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
Только с кого-то фига, дисковые операции для IMDB «бесплатны», а для DiskDB — прямо дибилы писали, которые только-только с дерева слезли и хвосты у них еще не отпали.
ну что сказать — актуально :)
Но, не очень понятно как можно сравнивать продукты предназначенные для разных сценариев работы в специфических сценариях игнорируя другие критерии.
Если сравниваться, то по всем критериям и желательно с цифрами (вроде все технические люди).Например: По объему обрабатываемых данных, по отказоустойчивость, «цена» каждой операции в одинаковых сценариях, по масштабируемости и т.д. А когда не могут внятно объяснить минусы описываемого решения, преподнося его как «Серебряную пулю», это… как-то «не закончено» выглядит :)
Хз что тесты покажут. Может эта нейронная сеть решит: а опять тесты? ну их наифг :))))
Это фактически у вас работа с рисками: идентификация и анализ/оценка рисков.
Это внутренний документ для управления проектом :) это не техническая документация :))
Ваш ревью спринта, если верно понял, будет привязан к этой «табличке»?
Обычно, это часть PreSale, это тоже не тех документация проекта, и обычно идет в свободной форме что бы " не морщить мозг". По идее этот документ сопровождается бюджетом проекта/решения?
Возможно, я сильно ошибаюсь, но что-то у вас от карго культа получилось:)
Но если у вас оно работает и приносит пользу — не мне судить :)
А за метрики и детали — спасибо :)
С этого «нюанса» и надо было начинать :)
да практически любая из гос кодексов с обвязкой в виде постановлений, инструкций. из межгосударственный вещей с кучей перекрестной документации, специфическая: банковская, налоговая, финансовая, картографическая, медицина.
Проектную «спецификацию и ТЗ» — это работа аналитиков, после контракт. там пофиг итерации и показы. Клиент просто скажет: А покажи мне Отчет Х из твоей системы? сошлось с моим? молодец!.. нет? иди фикси дальше, чего людей отвлекаешь?
Долгая работа в одной предметной области и уже есть какие «шаблонные» решения :)
Все типовые риски и проблемы уже устранены в этих «шаблонных» решениях и давно :)
И это далеко не заслуга Scrum. После, не означает в следствии.
Предположим, освоение нормативного документа и предметной области занимает 3 месяца времени.
Т.е вся команда что бы понять что важно а что нет для проектирования, все 10 человек будут сидеть и читать эту предметную область?
А если изучение предметной области занимает месяцев 3..9? тогда как вписывается в итерации?
Необходимый минимум для кого? Команды или Клиента?
Наверное, вы знаете что такие «бумажки» пишут как раз не программисты, а архитекторы и аналитики.
Это Presale документация? или уровень функциональной спецификации?
Как этот процес работает с контрактами Time & Material и Fixed Price?
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»? в какую итерацию они помещаются или делаются вне итераций?
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Сколько у вас примерно «стоит» проектирование, «Показывать заказчику работающие прототипы» и получать отзывы, разработка, тестирование и развертывание? в среднем для 1...5 спринтов по времени. 10% этап Х, 15% этап Y и т.д.
Как новый участник проекта получает необходимие знания по проекту? Куда деваются знания проекта ушедшего человека?
Когда вы приводите сравнение с «Обычной Базой Данных», то в этой «Обычной Базе Данных» слишком много проблем, по сравнению с IMDB. Основной акцент делается на «что приводит к рандомной записи на диск. Которой в IMDB нет.» и повторяется в разных вариантах.
Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)
Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
Так что спасибо :)
Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) говорите и сравнивайте только с аналогичными фичами «данных в памяти».
Как происходит «магия» «рандомной записи на диск. Которой в IMDB нет.» если по документации происходит работа с пачкой файлов ?!
Вы контролируете в какой сектор диска и что писать? Так вменяемые DB тоже это контролируют (в какое место внутри файла писать и когда)!
Согласно докам, все что Вы описали как «IMDB нет.» присутствует:
терзают смутные сомнения… :)
Повторюсь, что я не спец по IMDB и возможно не корретно понял ваш тест.
Но я не заметил у вас:
не понял на чем основано, если тестовые сценарии то разные.
C учетом того, что у статьях упоминается своя версия fork и работы со страницами памяти, мы же оперируем большими наборами данных а не один… двумя байтами, соответсветнно и все «платежи», в виде промахов в кеш процессора, переупорядочиваяния станиц памяти при освобождении и будем пытаться включать. Так чуть корректнее будет.
Одинаковый тест, сопоставимые условия — сопоставимый итоговый результат. IOPS и передача данных.
По итогу и получатся, что при всех узкоспециализиованных преимуществах сумма всех факторов приводит к такому результату.
С этой точки зрения, сравнения количество полезной «работы» в итоге будет более корретно?