Category: знаменитости

Category was added automatically. Read all entries about "знаменитости".

Алкоголь и профессия

Тусовка айтишников-фидошников-сисадминов. Водка, пиво, сосиска и сухарики — всё как полагается. Двое наклоняются друг к другу, и начинают разговор про ассоциативность кэшей в Nehalem, про АрВид, ГолДед и CouchDB. Подходит третий с бутылкой, брякает ей между заговорщиками, и объявляет:

— Эй, хорош о работе! Отдыхаем ведь! Говорим об отдыхе, развлечениях и женщинах!

Знакомо? Похоже, я понял, откуда ноги растут у этого императива: подобный подход к темам разговоров является закономерным результатом эволюционного отбора айтишников.

Для начала представим себе работу мозга, занимающегося осуществлением высшей нервной деятельности. То есть, предположим, что айтишник на работе занят делом. При этом те отделы мозга, где локализуются необходимые инструменты для работы над текущей задачей (области памяти, специфичные конкретной проблематике, необходимый фидошный опыт) используются в повышенной степени, и получают соответствующую энергетическую подпитку. Мозг берёт глюкозу и кислород для своей работы из крови. Наиболее использующиеся в данный момент области мозга запускают гемодинамический процесс, который, через расслабление гладкой мышечной ткани в соответствующих регионах, локально организует усиленный приток крови из местных капилляров, чтобы удовлетворить повышенное потребление нужных веществ.

Теперь представим типичную пьянку. Каков у айтишника в этот момент состав алкоголя в организме? В нём есть немножко крови! И именно эта кровь требуется, когда необходимо обсудить очередной рабочий момент или придумать новый стартап способ сэкономить на спичках.

Помыслив о работе, алкайтишник получает на тусовке дозу пива прямо в ту область мозга, которой он думает, когда он думает, что работает. Как известно, алкоголь разрушает миелиновую оболочку нейронов головного мозга:
Alcohol is a leading cause of myelination destruction of the human brain. While at a young age, alcohol seems to have very little effect on the brain, in the long term it affects he myelin production and ultimately deteriorates the brain just shortly into mid-life.

http://www.associatedcontent.com/article/564309/myelination_of_the_brain_continues.html?cat=70

Зачем нужен миелин? Он не позволяет электрическим сигналам «утекать» с нейронов, на несколько порядков уменьшая их электрическую проводимость в непрофильных направлениях. Иными словами, он позволяет нам думать более эффективно и с меньшим количеством ошибок и сбоев. Миелин — это, грубо говоря, жир, и в этом качестве очень подвержен расщеплению алкоголем. Теперь понятно, почему так важно не говорить и не думать о работе в момент принятия пива?

Представим две стратегии поведения. Одна стратегия заключается в том, что под водочку обсуждаются все насущные дела. Другая — в том, что культура пития воспрещает нам обсуждать работу на активном отдыхе.

Понятно, что те, кто следует первой стратегии, быстро и необратимо алкоголизирует критические для выполнения своих прямых сисадминских обязанностей отделы мозга, и человек вскоре выпадает из айтишной тусовки просто по определению. То есть, перестав быть адекватным айтишником. Про таких мы сейчас скажем, что он не прошёл эволюционный отбор.

Те же, кто следует второй стратегии, подвергают критические для своей профессиональной деятельности отделы мозга меньшему негативному влиянию алкоголя, и поэтому дольше остаются в обойме айтишности.

Теперь об опасностях.

Что произойдёт, если те двое из вступления воспользуются советом третьего, и начнут говорить, скажем, о женщинах? Понятно что: алкоголизация мозговых центров обсуждения и употребления женщин, неминуемая импотенция, развод, премия Дарвина за исключение себя из генофонда. Далеко не блестящая эволюционная стратегия!

Может быть, стоит перестать думать на время тусовки? Мозг не будет нуждаться в дополнительном питании, гемодинамический ответ не запустится, алкоголь не потечёт в отделы мозга, которые в нём не нуждаются. В итоге весь алкоголь придёт обратно. Куда? В печень! Отсюда вывод: если перестанешь думать головой, отвалится печень. Тоже вариантик не сахар.

Так может быть, вариант «говорить об отдыхе»? Это хороший вариант — чем больше об отдыхе говоришь под алкоголем, тем больше атрофируется соответствующий отдел мозга, занимающийся планированием отпуска. В итоге отрезвевший сотрудник работает дольше, думает об отдыхе меньше, и постепенно становится по этим причинам самым ценным кадром на работе.

Других вариантов поведения на тусовке, обладающих лучшей долговременной пользой, похоже, не существует.

Column-Stores vs. Row-Stores: How Different Are They Really?

http://www.google.com/search?q=Column-Stores+vs.+Row-Stores%3A+How+Different+Are+They+Really%3F

Column-Stores vs. Row-Stores: How Different Are They Really?


Daniel J. Abadi, Samuel R. Madden, Nabil Hachem, 2008



«Row store» и «column store» — два разных способа организации хранения данных. Распространённые SQL системы — MySQL, MS SQL, PostgreSQL — используют row stores: записи в таблицах хранятся в виде последовательности структур, каждая из которых содержит значения для соответствующих колонок. Альтернативным способом хранения является column store (MonetDB, Vertica (C-Store)): в отдельных структурах данных (упрощённо — файлах) последовательно хранятся содержимое ячеек для одной колонки, затем — для другой, и далее для всех колонок.

Column store дизайн представляет возможность использовать следующие оптимизации:
  • Колонки, имеющие низкую вариативность содержимого, могут хорошо сжиматься. В row stores рядом с полем с низкой вариативностью (пол) будет соседствовать поле B с высокой вариантивностью (номер телефона), усложняя или делая невозможным компрессию. Отсутствие подобных «лишних» данных в файле колонки позволяет с успехом использовать простые схемы компрессии, типа RLE.
  • При необходимости делать запросы, которые возвращают только небольшое подмножество колонок из таблицы, системы column store читают только содержимое тех колонок, которые участвуют в запросе. При большом количестве данных это пропорционально снижает количество данных, которые нужно прочитать с диска.
  • Поздняя материализация: данные из нескольких колонок собираются в кортежи на как можно более поздних этапах выполнения запросов.
  • Блочная итерация: значения передаются внутри итераторов обработчика запроса как блоки, а не как серии кортежей.

Бытует мнение, что некоторые из преимуществ, предоставляемых column stores, можно имитировать с использованием чуть более усложнённой схемы данных в row stores. Например, для таблицы, в которой N колонок, но выборка чаще всего производится по определённым M из них (M < N), имеет смысл создать отдельную табличку, включающую только те поля, которые используются в запросах. Также можно поиграться материализованными представлениями, либо делать index-only планы с комбинированными ключами.

Данная статья рассматривает тест TPC-H (несколько таблиц в «звёздной» схеме) на нескольких миллионах записей, и пытается применить все оптимизации row stores, которые призваны имитировать часть функциональности column stores. С противоположной стороны, берётся column store, и из неё последовательно выбрасываются все оптимизации, специфичные для column stores (например, отключается компрессия колонок).

Вывод статьи следующий:


Среднее время выполнения тестов TPC-H было в районе 4 секунды для column store, и 80..220 секунд для row store. Даже при использовании наилучшего сценария для row stores — использования материализованных представлений, которые были специально сделаны под запросы, которые были заранее известны — column stores выиграла: 4 с. vs. 10.2 с.

Никакие из попыток имитировать column stores не были особенно успешными. Вертикальное партиционирование неплохо работает в случае M < ¼N, но при ином отношении избыточное количество служебной информации (заголовки кортежей, избыточные копии идентификаторов записей) начинает доминировать в структуре I/O, и преимущество вертикального разбиения теряется. Index-only планы вынуждают объединять колонки используя дорогие hash джойны на TPC-H схеме, что существенно замедляет запросы. Материализованные представления дают наилучший результат в каких-то случаях, но в некоторых случаях bitmap-объединения могут быть медленнее, чем чисто последовательные сканы.

Что касается тех вещей, которые наиболее сильно влияют на преимущество column stores, то было показано, что компрессия и поздняя материализация дают наибольший вклад (10x и 3x, соответственно).

Отдельным вкладом статьи является то, что авторы предложили ещё одну оптимизацию column stores, а именно «invisible join», которая позволяет иногда ускорить column stores ещё процентов на 50—75.

Конкурс!

Этот пост вообще-то должен был попасть в ru_ucdesign. Но я не дождался, пока модераторы меня в нём авторизуют. А без авторизации нельзя — сиськоспам всех достал, очевидно.

Ну так вот. Дохлое комьюнити какое-то, этот ru_ucdesign. Давайте попробуем разнообразить. Ежели кто имеет доступ к ru_ucdesign — сделайте кросспост или форвард сюда (Upd: сделали).

Конкурс!


Кто лучше всех преобразует вот эту картинку в другую картинку, на которой все эти настройки представлены в юзабельной форме, тот получит приз — iPod nano с видеокамерой. Победитель определится голосованием через неделю или сколько там нужно для того, чтобы варианты устаканились.

Что настройки значат — не суть важно1, предлагаю чуть-чуть фантазию проявить, где это не очевидно.

Спасибо!

P.S. Я к этому приложению никакого отношения не имею. Просто хочу катализировать креатив чуть-чуть. Те, кто говорит "я забесплатно работать не буду", могут продолжить бесцельно торчать в ЖЖ. В смысле, пусть отдыхают. Давайте чуть более позитивно на вещи смотреть.



[1] Конечно, при проектировании интерфейсов исключительно важно знать, что значат настройки. Но в данном случае мы не имеем роскоши знать, что они значат: я не в курсе того, что значат эти настройки. Мопед не мой. Поэтому прошу проявить здравый смысл и самостоятельно придумать наиболее логичную семантику и паттерны использования представленных элементов. И на основании этого спроектировать интерфейс.